Meta Conversions API: setup, deduplication, and verification

Start with the business event, not the API request

Meta Conversions API sends event information from a server-side system to Meta. A successful request is only one stage of a measurement workflow: the underlying business event must be real, its fields must describe it correctly, and the destination must be the one your campaigns use.

Define the conversion before connecting anything. A completed registration, started trial and successful purchase are different outcomes. A purchase should use the selected successful payment event and its value, rather than a page load that might repeat or appear before payment completes.

Write down the source event, destination dataset or pixel, standard event mapping, value, currency and delivery owner. This small contract makes later debugging substantially easier than starting with a dashboard total.

• DATALYR Meta integration guide

Choose one owner for each purchase delivery

Inventory existing senders before adding another one: a commerce integration, a tag manager, a browser Pixel, a payment connector or a custom backend may already send the same transaction. Two successful integrations can still create an incorrect measurement system if their event identity is not coordinated.

Where browser and server events represent the same business event, verify the current Meta deduplication requirements and inspect their event identity. Do not assume a browser receipt page and a billing webhook independently generate matching identifiers. For two server-side vendors, selecting one owner is usually easier to reason about than assuming cross-vendor deduplication.

For example, Whop can already send purchases to Meta. DATALYR’s Whop documentation specifically advises against sending the same purchase to the same Meta destination through both paths.

• Whop delivery ownership guidance
• Meta: Pixel and server-event deduplication
• Check purchase delivery ownership for Whop memberships

Connect the intended account and conversion rule

In DATALYR, connect Meta from Sources using an account with access to the intended ad account. Select the account you want to use. Then configure a conversion rule with an event that already exists in your workspace and the intended Meta destination.

Map that source to the correct standard event. For revenue, inspect the dynamic value mapping and currency rather than entering a fixed value that only matches your first test. Confirm whether your source reports gross receipts, an adjusted amount or another basis.

Treat connection and rule configuration as separate checks. An authorized ad account does not prove that the correct pixel is selected, that the rule is enabled, or that the trigger matches the source event.

• Confirm the ad account and destination identifiers.
• Find an actual eligible source event.
• Review event name, value and currency mappings.
• Check consent and any saved platform restrictions.
• Review every other sender for the same transaction.

• For Google Ads: choose and verify its delivery path

Verify a single event through four distinct outcomes

Use permitted, non-sensitive test data and the platform’s supported testing workflow. Keep a record of the source transaction, timestamp, event identifier, amount, currency and selected destination. Never put access tokens or customer details into a shared debugging document.

First establish that the source event exists. Next inspect the rule and delivery result. Then examine the receiving destination’s event diagnostics. Finally, review attribution separately after the appropriate processing interval and reporting window.

A received event is not necessarily attributed to an ad. It may have no eligible ad interaction, insufficient matching information, a different reporting window, or an intentional restriction. Diagnose the failed stage instead of repeatedly submitting the transaction.

Compare like-for-like totals

Suppose the billing source records a $120 payment and later a $20 refund. A purchase event originally sent with $120 does not become a $100 event merely because your internal report now shows $100 net receipts. Determine each destination’s adjustment behavior before comparing totals.

Align the time zone, reporting date basis, conversion definition, attribution window and revenue basis. Compare one currency at a time unless the report’s currency conversion behavior is explicitly known.

Use a small sample of transaction-level records to explain the differences. The purpose is not to force every dashboard to show an identical number; it is to know which differences follow from definitions and which reveal a broken handoff.

• Revenue attribution and payment reconciliation

Keep the integration understandable after launch

Recheck the workflow when the checkout, billing provider, consent configuration or event taxonomy changes. A new subscription flow can emit a different source event while an old purchase rule remains enabled.

For health and wellness businesses, review the permitted data and any restrictions before delivery. A server-side route does not make a restricted event permitted. Keep sensitive details out of the collected data and apply the appropriate platform controls.

The useful completion criterion is an inspectable conversion with a known delivery owner, correct business fields and understood diagnostics. That is stronger evidence than an unexplained increase in the event count.

• DATALYR health and wellness filtering