Server-Side vs Client-Side Affiliate Tracking

Most affiliate programs still attribute conversions with a tracking pixel and a third-party cookie. A script fires in the browser, drops an identifier, and hopes it survives long enough to be read at checkout. That model was already brittle in 2015. In 2026, between aggressive ad-blockers, Safari capping script-set cookies at seven days, and bot traffic that runs a full headless browser, the browser is the worst possible place to record money-moving events.

Server-side tracking moves the system of record off the client and onto infrastructure you control. The difference is not cosmetic. It changes what you can measure, what an attacker can forge, and how much of your commission spend is going to real referrals versus noise. Here is the comparison that actually matters to a growth or engineering team running a payout budget.

Where client-side tracking loses data

Client-side attribution depends on code executing in a hostile, unpredictable environment. Every assumption it makes is something the visitor's browser, extensions, or network can break. The failure modes are not edge cases — they are the median experience for a meaningful slice of traffic.

• Ad-blockers and content blockers strip known tracker scripts before they run, so the conversion is never recorded at all.
• ITP and similar privacy defaults expire script-set cookies in days, breaking any attribution window longer than a week.
• Cross-domain hops between the landing page, a payment provider, and a thank-you page routinely drop the identifier.
• The client is fully attacker-controlled: a fraudster can replay the pixel, fabricate conversions, or fire it from a script farm.
• Network flakiness and early tab closes mean the beacon firing last in the funnel is exactly the request most likely to be lost.

How server-side tracking closes the gaps

Argus Grape records the click the moment it happens, server-side, at the edge. Every affiliate has one link. A request to the Go edge tracker resolves the campaign destination from a Redis cache, mints a click id, and answers with a 302 redirect in well under ten milliseconds. The visitor never sees a tracker domain and never runs a script that a blocker can recognize, because there is nothing to block — it is a plain redirect.

The click id, argus_cid, is a 32-character hex string drawn from 128 bits of crypto/rand. It is appended to the destination URL, not stored in a cookie, so it is not subject to ITP expiry and is unguessable by design. Attribution becomes your job of forwarding one query parameter to checkout rather than the browser's job of preserving state across an attribution window.

Fraud resistance is an architecture decision

When the browser is the source of truth, fraud detection is guesswork after the fact. When the edge owns the event, you can score traffic before it ever counts. Argus Grape salts and hashes each visitor IP — the plaintext address is never stored — and rate-limits per hashed IP. Past the configured threshold, clicks are flagged shadow_banned.

The crucial part: a shadow-banned visitor is still redirected, exactly like a valid click. A fraudster hammering their own link sees normal behavior and gets no signal to adapt to.

Shadow-banned clicks earn no contest points, and any conversion they later produce is rejected automatically. That rejection happens at the conversion webhook, which is signed and verified server-to-server — so a forged client request cannot mint a payout. The browser never gets a vote on whether a commission is real.

The one thing you still have to do

Server-side tracking is not zero-effort. Attribution survives navigation only if argus_cid reaches your checkout. Capture it once when the visitor lands, stash it in session storage, and attach it to the purchase event — as your webhook payload, or as Stripe metadata.argus_cid or client_reference_id. That is the whole integration. Everything fraud-related, multi-level, and latency-sensitive stays on the server where it belongs. See the tracking links documentation for the exact redirect contract and the checkout snippet.