Reconcile Email Conversion Events Before Reporting Revenue

Do not call revenue “email-attributed” until the team can reconcile the business event, recipient identity, email click, attribution window, deduplication rule, currency, and reversal. A provider dashboard is one view of that contract; it is not the contract itself.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 3, 2026.

Migma’s Events API documentation makes several material choices explicit. An event needs an external order ID and numeric value to become a conversion. Migma attributes it to the last email the recipient clicked in the previous five days, credits an order once, and records negative amounts when event names contain refund or cancellation terms. Raw events are retained for 90 days. Events can update profile metadata but never change subscription status.

Those choices are useful only when your internal event model can reproduce them.

Define the event contract before instrumentation#

Do not let a model invent event names from free text. Maintain a registry with owner, schema, version, required properties, valid state transitions, and examples.

Reconcile three ledgers#

Build separate ledgers for commerce, messaging, and attribution:

1. Commerce ledger: orders, upgrades, cancellations, refunds, currency, and authoritative timestamps.
2. Messaging ledger: recipient, message or campaign ID, delivery acceptance, human-filtered clicks where available, and click time.
3. Attribution ledger: joined order, eligible click, rule version, credited message, window, and any reversal.

For a period and currency, use this control equation:

net attributed revenue = credited positive events − credited refunds/cancellations + approved adjustments

Then compare it with provider output and record differences by category: missing event, duplicate, unmatched identity, click outside window, no eligible click, currency mismatch, late arrival, reversal mismatch, or provider rule change.

Do not force unmatched revenue into an email bucket simply to make totals align.

Preserve missing, zero, and ineligible as different states#

Migma documents that its conversion block is omitted when no conversion data has been reported. That is not the same as a returned value of zero. Model four states:

This prevents a blank dashboard from being read as poor performance and prevents an integration outage from looking like zero revenue.

Make attribution a versioned rule#

Migma’s documented five-day last-click model is one legitimate rule, not a universal fact about causality. Store a rule ID such as email_last_click_5d_v1 on every attribution row. If the organization changes the window or moves to first-click, linear, or experimental incrementality analysis, do not silently rewrite historical results.

Loops Goals documentation supplies a useful contrasting surface: define the eligible audience, conversion state, and attribution window for a campaign goal. It documents impressions, enrollments, and conversions for outcomes such as activation, upgrade, booking, purchase, retention, or churn. The platform descriptions do not establish equivalent models, so do not compare their dashboard totals without normalizing rules.

The existing open-rate privacy guide explains why opens should remain supporting context. This article deals with the downstream event and attribution ledger rather than campaign optimization signals.

Handle batches and late events#

Migma accepts event batches with per-row dedupe keys and row-level partial success. Persist each outcome. Retrying the whole file without stable row identity can double-count valid rows while attempting to recover invalid ones.

Use a reconciliation state machine:

received -> validated -> stored -> matched -> attributed
                    \-> rejected
                             \-> unmatched
attributed -> reversed

Late events may arrive after the reporting period closes. Define a restatement policy: for example, keep seven daily versions, then freeze the monthly report after an explicit close. The 90-day raw-event retention documented by Migma is a provider boundary; keep your authoritative commerce ledger according to your own retention and legal requirements.

Run a synthetic acceptance set#

Use non-production identities and create:

• one purchase after a qualifying click;
• one purchase with no click;
• two clicks where the later eligible message should win;
• one click outside the window;
• a duplicate purchase retry;
• a partial batch with one invalid row;
• a full and partial refund linked to an order;
• two currencies;
• an event arriving after period close;
• an unsubscribed contact receiving a profile-only event update.

Expected results must name credited message, rule version, gross value, reversal, net value, and subscription invariance. A chart that “looks right” is not an acceptance test.

Evidence limits#

Marketing Wiki did not send events to Migma or configure a Loops Goal. Vendor documentation establishes declared fields and behavior, not causal impact or data quality. The reconciliation model is an inferred control design; teams must align it with their commerce ledger, privacy obligations, analytics policy, and actual provider responses.