{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/email-conversion-event-reconciliation","id":"email-conversion-event-reconciliation","slug":"email-conversion-event-reconciliation","title":"Reconcile Email Conversion Events Before Reporting Revenue","description":"Build event, messaging, and attribution ledgers that preserve deduplication, rule versions, missing data, currencies, and refunds.","dek":"Provider-attributed revenue becomes trustworthy only when every credited outcome can be joined to an authoritative business event under an explicit rule.","category":"Email Analytics","topics":["conversion tracking","email attribution","Migma Events API","revenue reconciliation","Loops Goals"],"publishedAt":"2026-09-03","updatedAt":"2026-09-14","lastVerifiedAt":"2026-09-14","readingMinutes":5,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma Events API","url":"https://docs.migma.ai/events?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-conversion-event-reconciliation"},{"title":"Loops Goals Are Live","url":"https://loops.so/changelog/goals-are-live?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-conversion-event-reconciliation"}],"wordCount":989,"body":"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.\n\n> **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.\n\n[Migma’s Events API documentation](https://docs.migma.ai/events?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-conversion-event-reconciliation) 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.\n\nThose choices are useful only when your internal event model can reproduce them.\n\n## Define the event contract before instrumentation\n\n| Field | Required decision | Example |\n| --- | --- | --- |\n| Event identity | Stable ID across retries and warehouses | `order-10432/paid` |\n| Occurred time | Business time, not ingestion time | `2026-09-03T07:42:11Z` |\n| Customer identity | Durable internal ID plus approved email join | `customer-4182` |\n| Order/session identity | Entity eligible for once-only credit | `order-10432` |\n| Event name | Controlled vocabulary and version | `purchase.completed.v1` |\n| Value | Major/minor unit convention | `49.99` major units |\n| Currency | ISO code and conversion policy | `EUR`, no dashboard conversion |\n| Reversal link | Original event/order being reversed | `order-10432` |\n| Dedupe key | Stable per business event | `order-10432/paid` |\n| Source | System that observed the outcome | `billing-service` |\n\nDo not let a model invent event names from free text. Maintain a registry with owner, schema, version, required properties, valid state transitions, and examples.\n\n## Reconcile three ledgers\n\nBuild separate ledgers for commerce, messaging, and attribution:\n\n1. **Commerce ledger:** orders, upgrades, cancellations, refunds, currency, and authoritative timestamps.\n2. **Messaging ledger:** recipient, message or campaign ID, delivery acceptance, human-filtered clicks where available, and click time.\n3. **Attribution ledger:** joined order, eligible click, rule version, credited message, window, and any reversal.\n\nFor a period and currency, use this control equation:\n\n`net attributed revenue = credited positive events − credited refunds/cancellations + approved adjustments`\n\nThen 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.\n\nDo not force unmatched revenue into an email bucket simply to make totals align.\n\n## Preserve missing, zero, and ineligible as different states\n\nMigma 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:\n\n| State | Meaning | Safe display |\n| --- | --- | --- |\n| `not_instrumented` | No trusted event feed exists | “Conversion data unavailable” |\n| `no_eligible_events` | Feed ran; no event met schema/rule | “0 eligible conversions” |\n| `eligible_not_attributed` | Outcomes exist but no qualifying email touch | Show unassigned count/value |\n| `attributed` | Rule joined an outcome to a message | Show value with rule and window |\n\nThis prevents a blank dashboard from being read as poor performance and prevents an integration outage from looking like zero revenue.\n\n## Make attribution a versioned rule\n\nMigma’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.\n\n[Loops Goals documentation](https://loops.so/changelog/goals-are-live?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-conversion-event-reconciliation) 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.\n\nThe existing [open-rate privacy guide](/articles/email-open-rate-privacy-feedback-loop) explains why opens should remain supporting context. This article deals with the downstream event and attribution ledger rather than campaign optimization signals.\n\n## Handle batches and late events\n\nMigma 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.\n\nUse a reconciliation state machine:\n\n```text\nreceived -> validated -> stored -> matched -> attributed\n                    \\-> rejected\n                             \\-> unmatched\nattributed -> reversed\n```\n\nLate 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.\n\n## Run a synthetic acceptance set\n\nUse non-production identities and create:\n\n- one purchase after a qualifying click;\n- one purchase with no click;\n- two clicks where the later eligible message should win;\n- one click outside the window;\n- a duplicate purchase retry;\n- a partial batch with one invalid row;\n- a full and partial refund linked to an order;\n- two currencies;\n- an event arriving after period close;\n- an unsubscribed contact receiving a profile-only event update.\n\nExpected 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.\n\n## Evidence limits\n\nMarketing 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."}