Affiliate Tracking Setup: the complete stack.

Each layer answers a different question and feeds a different system. They overlap deliberately — redundancy is the whole point. Browser-side tracking gets blocked? Server-side picks it up. Pixel didn't fire? Postback still recorded the conversion. UTM was stripped? The click ID survived the redirect.

• Layer 1 — UTMs: query-string parameters tagged onto your outbound links. Tell your analytics tool which content, channel, and campaign sent the visitor. Read by Google Analytics, Plausible, Fathom, Cloudflare Analytics. UTM parameters explained.
• Layer 2 — Pixels: tiny JavaScript snippets that load on every page and report user activity to ad platforms. Used by Meta, TikTok, Google, Microsoft, LinkedIn to optimize ad delivery and report conversions. Tracking pixel explained.
• Layer 3 — Postback URLs: server-to-server callbacks that the merchant's server fires when a conversion happens. Carries the conversion event from the affiliate network back to your tracker. The most reliable conversion signal you have. Postback URL explained.
• Layer 4 — Server-side / CAPI: conversion events sent directly from your server (or backend) to ad-platform servers, bypassing the browser. Meta Conversions API (CAPI), Google Enhanced Conversions, TikTok Events API. Recovers the conversions that pixels miss due to browser blocking, iOS limits, and ad blockers. S2S tracking explained.

Important: these are not alternatives. They're complements. A working setup runs all four, and each layer is designed to keep working when another fails.

UTMs are the basic layer — query-string parameters appended to your URLs that identify where the visitor came from. The five canonical UTMs:

• utm_source — where the traffic comes from (e.g., youtube, newsletter, facebook)
• utm_medium — the channel type (social, email, cpc, organic)
• utm_campaign — the campaign name (summer-launch, black-friday-2026)
• utm_content — the specific creative or asset (banner-top, cta-2) — optional but useful for A/B testing
• utm_term — the keyword for paid search; rarely used outside Google Ads

Example URL with full UTMs:

https://affbuddy.com/playbook-offers?utm_source=newsletter&utm_medium=email&utm_campaign=2026-q2&utm_content=cta-block

What UTMs are good at

Reading the source/medium/campaign breakdown of your traffic in Google Analytics, Plausible, Fathom, Cloudflare Analytics. Comparing performance of two newsletter sends. Knowing which YouTube video drove a signup. Internal-channel attribution.

What UTMs are NOT enough for

• Telling ad platforms what converted. Meta, Google, and TikTok don't read your UTMs — they read their own pixels and conversion APIs. A UTM-tagged paid campaign is invisible to the ad platform's optimization algorithm.
• Surviving affiliate redirects. Most UTMs get stripped or replaced when the visitor clicks an affiliate link and goes through the network's redirect. The UTM from your blog post never reaches the merchant's analytics.
• Working when query strings are stripped. Apple's Private Relay and some browser privacy features strip query parameters in transit. UTMs are increasingly leaky on iOS.

The fix isn't to abandon UTMs — they remain the cheapest, most universal traffic-identification signal. The fix is to add the other layers underneath.

A tracking pixel is a JavaScript snippet (sometimes a tiny invisible image) that loads on every page and reports user activity to an ad platform. The major ones every affiliate should have configured:

• Meta Pixel (and CAPI) — for Facebook and Instagram ads
• Google tag (gtag.js) — for Google Ads, GA4, and Microsoft Ads imports
• TikTok Pixel + Events API — for TikTok ads
• Microsoft UET tag — for Microsoft Advertising
• LinkedIn Insight Tag — for LinkedIn ads (if you run them)
• X Pixel — for X/Twitter ads

Install the relevant pixel for every ad platform you advertise on, on every page that loads — even pages that don't have ads. The pixel is how the ad platform recognizes returning visitors and learns who converts.

Where pixels go

Site-wide, in the <head> of every page, so they fire on every load. Use a tag manager (Google Tag Manager, Stape, Segment) to centralize and avoid touching every page when one tag changes.

Critical: pixels MUST also fire on your bridge pages if you run paid traffic to them. The bridge page is where the conversion event happens (the click on the affiliate link is the "conversion" the pixel records). Missing the pixel here is the single most common reason paid affiliate campaigns can't optimize.

What pixels miss

Browser-blocked traffic. Safari ITP, iOS App Tracking Transparency, and ad blockers under-report pixel events by 10-30% on average across the industry. iOS users especially — pixels see roughly 40-50% of actual iOS conversions when only browser-side tracking is enabled. The fix is Layer 4 (server-side / CAPI).

A postback URL is a server-to-server callback. When the merchant's server records an affiliate conversion, it makes an HTTP request to a URL you configured — passing along the click ID, conversion value, and other metadata. Every major affiliate network supports postbacks; they're the most reliable conversion signal in the stack because they don't depend on the browser at all.

A typical postback flow

1. Visitor clicks your affiliate link with click ID abc123 attached
2. The affiliate network redirects to the merchant, passing the click ID
3. Visitor converts on the merchant's site
4. Merchant's server fires the postback URL: https://your-tracker.com/postback?cid=abc123&payout=49.00&order=ORD-7891
5. Your tracker records the conversion, attributed to click ID abc123
6. Your tracker can then fire onward — to Meta CAPI, Google Enhanced Conversions, your analytics

The postback URL contains macros that the network fills in dynamically: {click_id}, {payout}, {order_id}, {currency}, etc. Configuration lives in the affiliate network's UI under "tracking settings" or "postback" or "S2S".

Why postbacks are reliable

They run server-to-server. No browser involved means no cookie blocking, no JavaScript execution, no ad blocker interference, no iOS limits. If the conversion happened in the network's books, the postback fires.

Common postback setups

• Network → your tracker (Voluum, RedTrack, BeMob, Binom): the most common pattern. Network fires postback; tracker dedupes and records.
• Network → custom endpoint: for affiliates running their own backend. Receive the postback, store the conversion, optionally forward to other systems.
• Network → Google Sheet: poor-affiliate's analytics. Works for small operators. Use a service like Zapier or Make as the postback receiver.

Server-side tracking sends conversion events directly from your server (or your tracker) to the ad platform's servers, bypassing the browser entirely. Every major ad platform now has one:

• Meta Conversions API (CAPI) — server-side equivalent of Meta Pixel events
• Google Enhanced Conversions — server-side conversion data for Google Ads
• TikTok Events API — server-side conversion events for TikTok Ads
• Microsoft Offline Conversions API — same idea, Microsoft Ads
• LinkedIn Conversions API — same, LinkedIn ads

The setup is similar across platforms: you send a hashed user identifier (email, phone, IP, browser fingerprint hash, or a click ID like fbclid / gclid) plus event data, and the platform matches the conversion back to the original ad click. The match rate is usually 60-90% depending on how much identifying data you can pass through and how cleanly you preserve click IDs.

Why server-side is now critical

The old browser-only model has been hemorrhaging conversions since 2021:

• Safari ITP caps cookies at 7 days (and increasingly less)
• iOS 14+ blocks cross-app tracking unless the user explicitly opts in (90% don't)
• Ad blockers strip pixel scripts before they can fire
• Browser private modes drop cookies on close
• Apple Private Relay masks IP and strips some query parameters

Industry average: paid campaigns that used to see 100% of conversions in 2020 now see roughly 55-75% through browser-only tracking in 2026. Server-side recovers most of the rest, because the server has access to data the browser doesn't (or can't share).

Where server-side data comes from

• Your tracker: when the affiliate network fires its postback (Layer 3), your tracker forwards the event to Meta CAPI, Google Enhanced Conversions, etc.
• Your CRM: when a customer converts in your CRM (Stripe webhook, signup form, paid plan), forward the event to ad-platform conversion APIs.
• Your backend: any event you can reliably capture server-side — a paid trial converted, a lead became a customer, a refund happened — can be sent to ad platforms for better attribution.

Setup paths

Three common approaches by complexity:

• Out-of-the-box integrations. Stape, Stripe + Meta CAPI app, Shopify Conversion API. Minimal config, decent coverage. Best for affiliates running on commerce platforms or who want to avoid custom backend work.
• Server-side Google Tag Manager. One sGTM container forwards events to every ad platform via templates. Moderate complexity, full control. Costs $40-$120/mo to host (Stape, Addingwell, or self-host on Google Cloud).
• Custom endpoint. Write code that receives postbacks/events and forwards them to ad-platform APIs. Maximum flexibility, max work. Suits affiliates with engineering chops who want to dedupe events, enrich with first-party data, and route conditionally.

If you're starting from zero, do this in sequence. Each layer depends on the previous, and trying to add Layer 4 without Layer 3 working will fail.

1. UTM your outbound links. Every internal link from blog → other pages, every campaign URL in newsletters, every paid-ad destination URL. Decide a naming convention (kebab-case, lowercase) and stick to it. Build a UTM template doc you reference for every new campaign.
2. Install all relevant pixels site-wide. Use Google Tag Manager as the wrapper. Add Meta Pixel, gtag.js, TikTok Pixel, Microsoft UET to the GTM container. Fire on every page including bridge pages. Validate with each platform's pixel helper extension.
3. Set up postback URLs in every affiliate network. Get the postback URL from your tracker (Voluum, RedTrack, BeMob) or assemble a custom endpoint. Add it in each network's tracking settings with the correct macros. Trigger a test conversion and verify the postback fires.
4. Implement server-side / CAPI for paid platforms. The forwarding flow: affiliate network postback → your tracker → Meta CAPI / Google Enhanced Conversions / TikTok Events API. Test event quality in each platform's diagnostics dashboard. Aim for 75%+ match rate.
5. Document the click-ID flow. When a paid ad click arrives with fbclid=xyz, make sure the click ID is preserved through your bridge page, into your tracker, and gets sent back to Meta in the CAPI payload. Click ID loss is the #1 cause of CAPI match-quality issues.
6. Set quarterly verification. Drift happens. Pixels go stale, postback URLs break, networks deprecate macros. Quarterly: walk the full flow manually, fix what's broken.

• Missing pixel on the bridge page. The most common single failure. The bridge page is where the conversion fires; if the pixel isn't there, the ad platform sees nothing. Always add every ad platform's pixel to every bridge page.
• Lost click ID. The fbclid / gclid / msclkid arrives on the landing page but doesn't get preserved through redirects or to your tracker. CAPI then can't match the conversion to the original click, and match quality tanks. Fix: explicitly capture the click ID on landing and pass it through every subsequent hop.
• Postback URL with wrong macros. Network fires the postback, your tracker receives garbage data because the macro names don't match. Each network has its own macro syntax ({click_id} vs %CLICK_ID% vs ) — check the network's docs.
• Duplicate conversion events. Pixel fires AND server-side fires AND postback fires — without deduplication, you record three conversions for one sale. Fix: each event should have a unique event_id; ad platforms dedupe by it.
• Ad-blocker-extreme audience. If your audience is unusually tech-savvy (developers, marketers), pixel coverage can drop below 50%. Server-side becomes critical, not optional.
• Stale or revoked API tokens. Meta CAPI and Google Enhanced Conversions use access tokens that can expire or be revoked. If conversion volume suddenly drops to zero on the platform side, check the token first.