Skip to content
Browse documentation

How attribution works

The exact steps the tracking engine runs to match a conversion to a click, an offer, a partner and an amount.

Last updated 6 min read

On this page

A conversion is an action — a lead, a sale, an install, a deposit — that an advertiser reports to TrackCrown. Attribution decides which click (and so which partner) gets credit, which offer event it belongs to, what it is worth and which status it gets. This page describes the pipeline step by step, in the order the tracking engine runs it.

Ways a conversion reaches TrackCrown#

ChannelEndpointAuthenticated byArticle
Server-to-server postbackGET/POST https://trackcrown.com/pb (also /postback, /conversion)token parameterS2S postback reference
Image, iframe or JavaScript pixel/px, /px.gif, /px.jsnothing (public page)Conversion pixels
Landing-page SDKArcTrack.conversion() → /pxnothingLanding-page SDK
Panel, REST API, CSV importReports → Conversions, POST /api/v1/conversionsyour login or API keyReversals & adjustments

The postback and the pixels share one engine. The differences are listed where they matter below.

The pipeline#

1. Authentication#

Server-to-server postbacks must carry token: the workspace postback token or the postback token of the offer's advertiser (Settings → Postback tokens). A missing token returns 401 token required, a wrong one 401 invalid token. An advertiser token may only report conversions for that advertiser's offers (401 token not valid for this offer). Pixels are never authenticated; a token on a pixel URL is ignored.

2. Finding the click#

The engine looks for the click in this order and stops at the first that applies:

  1. conversion_id — the request updates an existing conversion instead of creating one (S2S only). See Reversals and status updates.
  2. click_id (aliases transaction_id, tid): 32 hexadecimal characters. The engine checks the recent-click cache first (every click stays there for 2 hours) and then the click database. A click younger than 30 seconds is retried up to 3 times, one second apart, so a postback that arrives a second after the click still matches. An S2S postback only finds clicks of its token's workspace (otherwise unknown click_id); a pixel finds the click in any workspace, but the offer's workspace must then be served by the tracking domain the pixel was sent to.
  3. Ad-platform click IDs (S2S only): gclid, then gbraid, wbraid, msclkid. The engine takes the newest click of your workspace that carries the value — within the offer's attribution window when you send offer_id, otherwise within 90 days. With an advertiser token only that advertiser's clicks (and clicks of workspace-level links without an offer) are searched.
    • No click found and no offer_id, coupon_code or email → no click found for gclid (or gbraid, …).
    • No click found but offer_id given → a conversion without click is stored, and the ad click ID is kept on it so the conversion can still be uploaded to Google Ads.
  4. Pixel cookie (pixels only): when a pixel has no click_id, the atk_cid cookie that the tracking domain set at click time is used — only if the workspace turned on First-party pixel cookie (Settings → Workspace).
  5. Coupon code — coupon_code (alias coupon) attributes a conversion without click to the coupon's partner.
  6. No identifier — an S2S postback with offer_id (and optionally aff_id or email) creates a click-less conversion. Without any of these the request fails with 400.

3. First touch#

If the workspace uses First touch (Settings → Conversion rules → Attribution) and the request carries first_click_id — the landing-page SDK sends it automatically — the engine credits that earlier click instead, provided it belongs to the same workspace, is older than the current click and is for the same offer (or one of the two clicks has no offer). The default, Last touch, credits the click ID the conversion carries.

4. Coupon priority#

A valid coupon with a click present is only recorded on the conversion. When Coupon codes win over click ids is on, a valid coupon_code always credits the coupon's partner (a synthetic click with link type coupon is recorded). An unknown or inactive coupon is ignored when a click attributes the conversion.

5. Offer, workspace and method checks#

  • The offer is the click's offer. If you also send offer_id, it must match (offer_id does not match the click).
  • A click of a workspace-level transparent link has no offer: send offer_id (offer_id required: the click is not tied to an offer).
  • The workspace must be active and the request must arrive on a tracking domain of the same brand and workspace (this tracking domain does not serve the offer's workspace).
  • The offer's Conversion tracking setting (offer → Tracking tab) must allow the method: Server postback or pixel, Server postback only or Pixel only.

6. Event#

event selects the offer event by code; empty or default means the offer's default event. adv_event=<code> selects the offer event linked to an advertiser-level event when event is not given. An unknown code is 400 unknown event "…" for this offer.

7. Partner#

The partner is the click's partner. When there is no click, or the click has no partner, an S2S postback can name it with aff_id (id or code). A click-less postback without aff_id but with an email the engine has seen before on this offer credits the partner whose conversion first used that address (e-mail ownership, within the offer's attribution window). Addresses are stored only as SHA-256 hashes.

8. Money#

Currency conversion runs first: if currency differs from the offer's currency, amount, revenue and payout are converted at the ECB rate of the day (original values are kept on the conversion). Payout and revenue are then resolved, most specific first: partner + event override → partner override → event → offer, then custom payout rules and commission tiers. revenue= overrides revenue for any token; payout= overrides payout only with the workspace token.

9. Status#

OrderCheckResult
1Offer's Default conversion statusapproved or pending
2status parameter (S2S only)as sent; rejected gets reason postback
3Click was blocked by transparent-link validationrejected click_blocked
4Click older than the Attribution window (days) (1–365)rejected outside_window
5Faster than the minimum click-to-conversion timerejected too_fast
6S2S request from an IP outside the advertiser allowlistrejected ip_not_allowed
7Fraud rulesflagged, or rejected fraud:<check>
8Postback rules (first match)approved, rejected rule:<name> or pending
9Partner throttlepending throttled
10Hold periodpending hold, approved automatically later

Details: Conversion rules.

10. De-duplication and caps#

A repeat for the same click and event, or the same txid on the offer, is stored as a rejected duplicate (Duplicates). Approved and pending conversions then count against the offer's and the partner's conversion and payout caps; over a cap the conversion is rejected cap_exceeded (or only flagged when the offer's caps are alert-only).

11. Storage and partner postbacks#

The conversion and the partner postbacks it triggers are written in one transaction, so a stored conversion never loses its postbacks. See Partner postbacks.

Statuses#

StatusMeaningCounted in reports asFires Approved postbacks
approvedPayable.Conversions, revenue, payoutYes
pendingWaiting for review, a hold period or the advertiser.PendingNo (only Approved and pending ones)
rejectedNot payable; kept for the audit trail.Rejected (includes duplicates)No

Every status reason is listed in the error and reason codes reference.

Something unclear or missing in this article?Tell us