Affiliate Conversion Tracking: The Complete Guide

The discipline this cluster calls affiliate conversion tracking measures conversions that happen on a landing page you do not control: the offer belongs to an affiliate network, the pixel sits on their domain, and your only reliable connection is a postback that travels from the network through your tracker to the ad platform. This page is the front door to our entire arbitration cluster. It explains the chain end to end, names the places where conversions leak, and routes you to a deep-dive guide for each specific failure.

Server-side tracking is the backbone of that chain, and the Conversions API is where it ends. Everything between them exists to preserve one thing: the proof that a click you paid for became a conversion someone confirmed.

What Affiliate Conversion Tracking Actually Measures

A classic in-house setup counts a sale at the moment the pixel fires on your own checkout page. Affiliate media buyers work with a different reality. The sale happens on the advertiser's site, the advertiser reports it to the network, the network reports it to you through a postback, and only then can the event reach the ad platform that sold you the click.

That extra distance changes the whole discipline. Each hop adds delay, each hop can drop identifiers, and each hop keeps its own books. The craft of affiliate conversion tracking is keeping the click's identity and the conversion's facts intact across all three hops - not because any single system is unreliable, but because three systems were never designed to agree.

Get the chain right and the payoff is concrete: ad platforms optimize campaigns on the conversions they receive, so a buyer whose postback chain is airtight teaches the algorithm which clicks are worth paying for, while a leaky chain trains the algorithm on noise.

The Postback Chain: Network, Tracker, Ad Platform

The chain looks like this in every affiliate vertical:

1. A user clicks your ad. The platform appends its click ID - fbclid for Meta, ttclid for TikTok, rdt_cid for Reddit - and your tracker stores the click with that identifier.
2. Your tracker then redirects the user through your prelander or straight to the offer URL, appending its own sub ID, typically as the subid or aff_sub parameter the network promised to echo back.
3. Somewhere on the advertiser's page, the user converts. Confirmation lands with the network first.
4. After that confirmation, the network fires a server-to-server postback to your tracker, echoing the sub ID and the conversion details.
5. Your tracker matches the postback to the original click and forwards the conversion to the ad platform, usually through its Conversions API integration.

Keitaro documents its side of step 5 as S2S postbacks: "a tool for analytics and data collection on the side of the traffic source," where each postback URL carries placeholders like {external_id} for the click ID and {conversion_revenue} for the payout, and where outgoing requests are "collected in a queue" with duplicates excluded (see Keitaro's S2S postback documentation).

The table explains the classic frustration: all three systems are correct and all three numbers differ, because each counts at a different point in the chain with a different set of knowledge. Section seven returns to why the numbers diverge and what to do about it.

The mechanical wiring for one platform - Meta, with the built-in Keitaro integration and the manual S2S path - is in Facebook CAPI Keitaro: setup without losing conversions.

Click IDs and Sub IDs: Keeping Identity Through the Funnel

Every hop in the chain passes identity forward, and every hop is a chance to drop it. The platform's click ID must survive from the ad click into your tracker's storage. Your tracker's sub ID must survive from the redirect into the network's postback. If any link breaks, the conversion still happened - but it arrives at the tracker unmatched, or at the platform unattributed, and your money bought an event nobody can credit.

Meta expects its identifiers back on server events whenever they exist: the documented _fbp and _fbc cookie values travel in the fbp and fbc fields of a Conversions API call's user_data, and _fbc can even be constructed on the server from the fbclid URL parameter when no browser cookie is available (Meta documents both parameters on the fbp and fbc parameters page). Our click ID glossary entry covers the platform-specific names; where fbclid and ttclid get lost is the deep dive on the loss points.

Sub IDs deserve the same discipline. Keitaro's documentation makes the failure mode explicit: if {external_id} arrives empty in a postback URL, "the source's traffic isn't passing the parameter" - meaning the network never echoed your sub ID back, and no amount of tracker configuration will fix that from your side. Testing the full loop with a test conversion before scaling traffic is cheaper than discovering the gap from a week of unmatched postbacks.

Conversion Statuses: What Each One Means for Your Pixel

Affiliate networks do not report final truths - they report statuses. This is where affiliate conversion tracking diverges most from in-house analytics. A conversion can arrive as a registration, get confirmed by the advertiser's call center, sit in hold for the refund window, or come back rejected. Networks and trackers model this as a status attached to every conversion, and Keitaro lets you configure which status fires which postback: on the S2S postback setup you "choose the conversion status to send a postback," and each status can drive a different destination.

That single setting decides what your pixel learns. Sending every raw lead as a Purchase teaches the algorithm to optimize for registrations that never pay. Withholding everything until approval starves it of data during the confirmation lag. Most buyers land somewhere deliberate in between, and the choice is per-offer: a COD vertical with a 40 percent approve rate behaves nothing like a trial funnel with instant card charges.

The status plumbing has its own deep dives: postbacks versus the Conversions API compares the delivery channels, and the Keitaro status wiring for two platforms is in Keitaro postback setup for Facebook and TikTok.

From Tracker to Conversions API: How Delivery Works

The last hop repeats one pattern per platform: your tracker - or an automation acting for it - POSTs the conversion to the platform's server-side endpoint, authenticates with a token, and includes the identifiers and event facts the platform requires.

Meta's Conversions API requires website events to carry action_source, event_source_url, and client_user_agent, accepts event_time at most seven days in the past, and fails an entire request over a single stale event (Meta documents this on the Conversions API parameters page and the using-the-api guide). Reddit's Conversions API accepts server events within seven days of the conversion as well, and deduplicates against its pixel by conversion ID; the setup path is in Reddit Conversions API setup. TikTok's server-side counterpart is the Events API, documented in the TikTok Events API article, with the tracker-side wiring in TikTok Events API for affiliate trackers.

Two consequences of the server-side hop matter for every buyer. First, timing stops being academic: a postback that reaches your tracker three days after the click must still be forwarded inside the platform's acceptance window, so delivery delays compound across the chain. Second, the platform grades the event's data completeness - which is the subject of the data quality section below.

Passing Payout as Conversion Value

An in-house store sends its order value with the Purchase event. Buyers in affiliate, by contrast, send the payout the network reported, which the tracker already received in the postback - Keitaro's {conversion_revenue} placeholder exists precisely for this hop. Forwarded as the event's value with its currency, the payout lets value-based optimization work on real money instead of a flat counter.

The mechanics get interesting where payouts are not flat: partial approvals, rebills on subscription offers, and currency differences between the network's report and the ad account. Those cases decide whether value should carry the gross payout, the confirmed amount, or the expected value, and the deep dive on payout passing walks them.

For the complete guide it is enough to fix the principle: the platform can only optimize toward the value you actually transmit. A flat Purchase with no value trains the algorithm on volume; a truthful value trains it on money.

Duplicate Conversions: Three Systems, Three Numbers

Every buyer eventually asks why the tracker says 80 sales, the network balance says 74, and Ads Manager says 92. The gap is rarely one bug - it is the sum of counting rules, window differences, and genuine duplicates. Platform-side deduplication is documented and mechanical: Meta keeps the first copy of an event with the same event_id and event_name arriving within a 48-hour window, so a pixel fire and a server POST about the same purchase count once (Meta documents the method on the deduplication page); Reddit pairs pixel and server events by conversion ID within its own window.

The harder duplicates are business-logic duplicates: the network re-sends a postback after a status change, or both the tracker and a CRM forward the same confirmed sale. Keitaro excludes duplicate postbacks inside its S2S queue, but a queue can only dedupe what arrives with the same identity - which is why the event ID discipline matters across the whole chain, not just at the platform boundary.

Pixel-versus-CAPI deduplication for Meta specifically is in Facebook pixel and CAPI event deduplication. The tracker-versus-money discrepancy question has its own guide: why tracker ROI never matches Ads Manager ROAS.

Data Quality: What the Platforms Grade You On

Server-side delivery put quality scoring on the buyer's desk. Meta's Event Match Quality grades how completely your events identify the user behind the conversion - the hashed email or phone, the client IP and user agent, the fbp and fbc cookies - and that grade feeds how usable the event is for attribution and optimization (Meta describes the metric in About Event Match Quality). A conversion forwarded with nothing but a timestamp and an event name carries almost no matching surface.

For affiliate conversion tracking the quality problem has a twist: the conversion happens on a domain you do not control, so first-party signals like cookies and browser data are scarce by construction. What you can control - forwarding the click ID, sending the tracker's stored IP and user agent of the original click, hashing contact data the network actually shares - decides whether your events land at the useful end of the quality scale. Our event quality entry and the match key glossary cover the fields platform by platform.

Data quality is also the reason junk clicks cost more than they look: bots and trash segments that convert into fake leads poison both the event stream and the optimization trained on it. Filtering before events are sent is a tracker-side job, and it gets its own guide in this cluster.

Warming a Pixel Without Burning It

"Pixel warming" is the buyer's term for a sequence every platform implies but none turns into a checklist: run traffic that produces clean, well-attributed events so the delivery system has a trustworthy baseline before you push budgets. The mechanics are platform-agnostic:

1. Start with a narrow, well-targeted audience and one conversion event you can actually feed.
2. Make sure event delivery is verified working - test events visible in the platform's tools - before scaling spend.
3. Keep identifiers and values complete on every event, because the baseline period is when quality scoring does the most lasting damage or good.
4. Scale budgets gradually so the optimization keeps learning from fresh, consistent data instead of re-learning from shocks.

The failure modes are just as consistent: warming on unconfirmed leads, warming with events missing match keys, or scaling into a broad audience before the baseline exists. Our pixel warming glossary entry holds the definition, and a practical sequencing guide in this cluster walks the full procedure.

When Numbers Disagree: A Troubleshooting Map

Cluster experience with affiliate conversion tracking compresses into a short diagnostic map. When something looks broken, locate the bucket first:

1. No conversion at the tracker. The network postback never arrived or carried an empty sub ID. Check the tracker's postback log - Keitaro's S2S postback log shows "which subid initiates S2S sending, which link converted" and the source's response.
2. Conversion at the tracker, nothing at the platform. Delivery failed: token, endpoint, or the event fell outside the acceptance window. Meta's seven-day event_time limit and one-stale-event-fails-all rule are the classic silent killers.
3. Conversion arrived but unmatched. The click ID or user identifiers were lost upstream; the event lands with a thin match key.
4. Everything arrived, numbers still differ. Counting rules: platform attribution windows, network hold policies, and attribution differences are doing their job. Reconcile with the definitions, not by "fixing" the pipe.
5. Sudden shift after a working period. Something changed in the chain - an offer URL migration, a new prelander dropping parameters, an expired token. Diff the chain against its last known-good state.

The postback troubleshooting checklist turns this map into a full walkthrough, and Meta CAPI event delay covers the timing bucket in depth.

Automating the Chain: Trackers, Pixel Activator, Most

Every part of this guide can run manually once: a hand-built Conversions API POST proves your token and parameters, the way Pixel Activator lets you fire test conversions for free without any infrastructure. Manual proof is exactly the right tool for setup and debugging.

Recurring delivery is a different job. Postbacks arrive at 3 a.m., platforms have transient errors, statuses change after the fact, and every failure mode in this guide eventually happens on a live funnel. That is the job Most performs: it sits between your tracker and the ad platforms, routes each conversion with its identifiers and value, retries failed deliveries, and keeps duplicates out - the whole chain of this guide, running unattended.

This cluster grows section by section: the deep dives behind each link above are already live, and guides on hold-status handling, payout passing, click ID preservation through prelanders, and duplicate elimination across systems are landing in the arbitration section over the next batches.

Affiliate Conversion Tracking: Frequently Asked Questions

Sources