A customer completes order order-123 for $79. The backend has one paid order. Meta reports a Purchase. GA4 reports a purchase key event. Google Ads shows a conversion on a different day, or none at all.
It is tempting to add another tag until the dashboards agree. That can turn one order into two conversion signals. I use the order ID to trace the measurement path before changing any tags or bidding settings.
Start with the confirmed order.
The backend order is the control record. For a test purchase, keep the order ID, completion time, value, currency, and refund status together. Then ask which systems observed that specific order.
For order-123, the expected event is one confirmed Purchase for $79 USD. A page view on the thank-you page is weaker evidence. That page can reload, fail to load, or appear before payment is final.
Check the request and the identifier separately.
A tracking pixel is an HTTP request that reports an event. A cookie is a stored value the browser may attach to a later eligible request. The purchase request can arrive without a cookie. A cookie can also remain in storage when the purchase request never fires.
That distinction changes the debug path. If the request is absent, inspect the trigger, consent state, browser blocking, and network errors. If the request arrived but attribution is weak, inspect the landing click ID, cookie scope, and checkout redirects. The tracking pixel vs cookie guide walks through both sides in DevTools.
Send each ad platform its own purchase event.
The same confirmed order can feed Meta Pixel and a Google Ads website conversion action. They use separate destinations and field names. For example:
fbq('track', 'Purchase',
{ value: 79.00, currency: 'USD' },
{ eventID: 'order-123' });
gtag('event', 'conversion', {
send_to: 'AW-123456789/ExampleLabel',
value: 79.00,
currency: 'USD',
transaction_id: 'order-123'
});
Those are illustrative IDs. In production, inspect the fired requests and confirm the real Meta Pixel ID, Google Ads conversion ID and label, value, currency, and order ID. A tag manager preview saying both tags fired is the start of the check. The Meta Pixel vs Google Ads conversion tracking guide covers the two contracts and their duplicate protection.
Decide which Google Ads action should drive bidding.
GA4 can record purchase and mark it as a key event. Google Ads can then create a conversion action from that Analytics event. A direct Google Ads conversion tag is another way to measure the purchase.
Check the source of every Purchase action in Google Ads. If you have both a direct Ads action and a GA4-sourced action, verify which one is Primary in the campaign goal. Primary actions normally feed the Conversions column and bidding; Secondary actions are usually for observation. Importing an Analytics event does not make your goal choice for you.
The GA4 key events vs Google Ads conversions guide gives a reconciliation path for these settings and the resulting counts.
Separate event receipt from attribution.
Suppose a shopper clicks an ad on Monday and buys on Tuesday. The purchase event can be recorded correctly while an ad report credits it to Monday, applies a lookback window, or leaves it unattributed. Meta and Google Ads can also credit the same order under their own rules. Their attributed totals should not be added together as unique sales.
I debug in this order:
- Confirm the paid order in the backend ledger.
- Capture one event per intended destination, with the right order ID and value.
- Check that relevant click identifiers survived the landing and checkout path.
- Inspect each conversion action's source, counting method, goal, and attribution window.
- Compare reports over the same date range and account time zones. In Google Ads, check the by-conversion-time view when daily dates appear to disagree.
The conversion tracking vs attribution guide expands that sequence with examples. I maintain Pixellint to validate captured pixel URLs and conversion payloads. It can check the request contract; the backend ledger and ad platform settings complete the investigation.
Top comments (1)
backend ledger as the control record is exactly right. the debug step people skip is the dedup key. meta and google both dedup duplicates on their own, but only if the order id matches across the requests. mismatched ids turn one order into two conversions, quietly.