Why Does a Purchase Get Credited to the Wrong Ad Platform?

A purchase gets credited to the wrong ad platform when the session that paid you carries no click ID. Your reporting falls back to whatever it can still see — a referrer, a retargeting click, a blank source — and hands the sale to the platform that touched the buyer most recently, not the one that caused the purchase.

This is not a rounding error. It is the difference between scaling the campaign that creates demand and scaling the campaign that intercepts it on the way to checkout.

What does “credited to the wrong platform” actually look like?

It shows up three ways: your own dashboard names one platform while the buyer’s real first touch was somewhere else; two or more ad platforms each report the sale in their own interface; or the purchase event you send server-side reaches a platform with none of that platform’s identifiers attached.

They have different causes and different fixes. The first is a model problem. The second is a windowing problem — every platform counts inside its own attribution window and none of them can see each other’s clicks, which is why Google Ads and Meta both claim the same conversion without either one lying. The third is an identifier problem, and it is the one that quietly poisons the other two.

Why does the checkout session lose the click ID?

Because a click ID lives in the landing URL, and the checkout almost never happens on that URL. Each platform stamps its own parameter — gclid and gbraid/wbraid for Google, fbclid for Meta, msclkid for Microsoft, ttclid for TikTok, epik for Pinterest — and each one is a query parameter on the first page the visitor lands on. Nothing carries it forward for you.

Four things strip it before the order is placed:

• Internal navigation. The visitor clicks from the landing page to a product page. The parameter is gone from the URL on the second pageview.
• The checkout hop. Shopify checkout, a hosted payment page, a booking domain — a different host means a different session, and often a regenerated visitor ID.
• Cookie limits. The platform’s own cookie (_fbc, _epik, _uetmsclkid) is the usual fallback, and it is exactly what tracking-prevention rules and blockers target.
• Time. The buyer clicks the ad Tuesday and buys the following Monday by typing your domain into the address bar. The converting session has no source at all, which is the ordinary reason ad conversions show up as Direct.

Because every platform uses its own click ID, losing one is not losing “the” click ID. It is losing credit at exactly one platform while the others keep whatever they still hold — which is how credit ends up lopsided rather than merely missing.

Why does last-click hand credit to the wrong platform so often?

Because last-click rewards proximity to the purchase, and retargeting is designed to be the last thing a buyer sees. The prospecting campaign that introduced your brand three weeks ago gets nothing; the retargeting ad that caught the buyer on the way to checkout takes the whole sale.

Most reporting defaults to a last-non-direct rule: when the converting session has no source, credit rolls back to the most recent session that did. That rule is sensible and it is still wrong here, because “most recent identifiable touch” tends to be branded search or a retargeting click — the channels that harvest demand rather than create it.

The result is a budget that drifts toward closers. You cut the platform that looked unprofitable, demand falls, and the closers’ numbers fall with it a month later, for reasons the report never explains.

What does wrong-platform credit cost you?

Two costs, one visible and one not. The visible one is misallocated budget. The invisible one is algorithmic: a platform that never receives a conversion cannot optimize toward the people who produce them.

That second cost compounds. When your server-side purchase event reaches Meta without fbc or fbp, it still delivers — it is simply an anonymous server event, matched to nobody. Meta’s own documentation is explicit that fbc is built from the fbclid in the landing URL and sent unhashed alongside the hashed customer-information parameters, so a missing click ID is a missing match, not a missing event. The platform receives your revenue and learns nothing from it.

Late reconciliation does not rescue it either. Meta requires the event_time on a Conversions API event to fall within the last seven days of the send, so discovering the true source a month later and re-sending is not a repair path. The credit has to be right at dispatch.

How do you fix mis-credited purchases without a vendor?

You can get a long way with your own engineering. Honestly, though, each fix has a ceiling:

1. Keep auto-tagging on and capture the click IDs server-side on the landing request. This is the highest-value hour of work available. Ceiling: it fixes capture, not persistence — the value still has to survive to checkout.
2. Persist each click ID in first-party storage and inject it into the order. Cart attributes, hidden fields, order metadata. Ceiling: it is per-platform, per-checkout plumbing, and script-written cookies are what tracking prevention truncates first.
3. Pass identifiers into the payment session. Stripe and most processors let you attach metadata to a checkout session. Ceiling: it only works when the buyer reaches checkout in the same browser as the ad click — cross-device buys are untouched.
4. Compare models instead of trusting one number. Export first touch and last touch for the same set of orders and look at the disagreement. Ceiling: most analytics stores one attribution value per order, so there is nothing to compare.
5. Stop reading platform dashboards as a ledger. Reconcile against your own order records and treat each platform’s claimed conversions as that platform’s opinion. Ceiling: this tells you the total is wrong without telling you who deserves the credit.

The common ceiling is that all five treat the purchase as a property of one session. Credit is a property of a person, across every session they had.

How does PartialLeads credit the purchase to the right platform?

By never asking the checkout session to answer the question. The tag captures each platform’s click ID at the first touch — gclid, gbraid, wbraid, fbclid with _fbp/_fbc, msclkid, ttclid and epik — and stores them server-side on that session, alongside the UTMs, referrer, landing page and geo. When fbclid is in the URL but the _fbc cookie is missing or malformed, the backend rebuilds it in Meta’s fb.1.{timestamp}.{fbclid} format, with the URL value treated as the source of truth.

Then those sessions get joined to a person. Visitor identity resolution unions sessions across six tiers — visitor ID, normalized email, normalized phone, IP plus user agent, device fingerprint, and a shared click ID — so the buyer who clicked on a phone and paid on a laptop is one record, not two anonymous visitors. Inside a single visit, visit-sibling inheritance heals the converting session directly: a session with the same client, IP and user agent within ±30 minutes inherits the sibling’s click IDs and UTMs, and a “cellular handoff” tier matches on the _fbc cookie within ±10 minutes when the IP changes mid-checkout.

Purchases land through one pipeline that matches the order to a session by visitor ID, then email, then phone, then IP, and writes both a first-touch and a last-touch attribution row — each snapshotting the UTMs, click IDs, referrer, landing page and time to purchase. The Attribution report shows First Touch, Last Touch and PartialLeads Resolved side by side rather than publishing one winner, and itemises Recovered Attribution by mechanism: ad clicks re-linked to a purchase, sessions reclassified by the session classifier instead of reading as Direct, and revenue from buyers whose form was never submitted.

Dispatch then fans the purchase out to each configured platform through the Conversions API — Meta, Pinterest, TikTok, and Google Ads via scheduled Sheets upload — with a deterministic event_id and a UNIQUE dedup table per config, so a redelivered webhook physically cannot double-fire. Hashing follows each platform’s spec: email and phone hashed, fbp/fbc/IP/user agent sent unhashed.

The honest constraints. We control dispatch; the platform controls matching. Sending every order server-side means every order in your admin produces an event, but whether a platform ties that event to a person and a click depends on the identifiers it holds and on its own graph. Keep your client-side base tag: _fbc can be reconstructed from fbclid, but _fbp cannot be synthesized from nothing, and without the platform cookie a server event is an anonymous one. And the resolved model is a better reading of who was involved — not a verdict on incrementality.

Where should you start this week?

Pull ten orders you know came from paid traffic and check what source your reporting assigned each one. If more than a couple read Direct, branded search, or a retargeting campaign you would not have expected, you have a click-ID persistence problem, not a model preference. Fix capture first, resolve identity second, and only then argue about first touch versus last touch.

Sources

https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices