Cookieless Attribution With a Server-Issued Click ID

Third-party cookies are dead, first-party cookies get cleared, and a meaningful slice of your traffic runs an ad blocker that strips tracking scripts before they fire. If your affiliate attribution depends on a pixel surviving the round trip from click to checkout, you are losing conversions you already earned and paying partners on a fraction of what they drove.

The fix is to stop trusting the browser as your system of record. Argus Grape mints a click identifier on the server at redirect time, hands it back in the destination URL, and asks you to forward that one value to your conversion call. No cookie has to survive. No script has to load. The identifier is the attribution.

What argus_cid actually is

When a visitor hits an Argus tracking link, the edge redirect resolves the partner, the campaign, and the referral tree node, then writes a click row and generates a unique, opaque click id we call argus_cid. That id is appended to your destination URL as a query parameter before the 302 fires. The whole exchange happens server-side in single-digit milliseconds, so there is nothing for an ad blocker to intercept and nothing for a privacy extension to delete. Because the id is opaque and random, it carries no personal data on its own. It is a pointer into our click store, not a profile.

The flow from click to commission

• A visitor clicks an Argus tracking link and the edge resolves it and issues argus_cid.
• We 302 the visitor to your landing page with argus_cid in the query string.
• Your front end reads argus_cid once and stashes it in a hidden field, session, or local storage tied to the funnel.
• At purchase or signup, your server includes argus_cid in the signed conversion webhook to Argus.
• We match the id back to the original click, walk the ltree referral path, and split the commission across every level.

The only contract you have to honor is that one value making it from the landing URL into the conversion call. Everything fragile about pixel-based tracking falls away, because the proof of attribution travels inside your own checkout payload rather than in a cookie a browser may have thrown out hours earlier.

Why this beats client-side pixels

Client-side attribution fails in three predictable ways: the script is blocked, the cookie is partitioned or expired, or the user crosses a device or browser boundary mid-funnel. A server-issued id sidesteps all three. The redirect always runs because it is the redirect itself, and once argus_cid lands in your funnel state it is yours to carry forward however your stack already moves data to the backend.

If the value reaches your conversion webhook, the sale is attributed. The browser never gets a vote.

Forwarding it cleanly

Read argus_cid on first landing, not at checkout. Visitors browse, refresh, and navigate away from the parameter, so capture it the moment the page loads and persist it for the length of your funnel. When you fire the conversion, send the stored id in the webhook body, not as a URL parameter that can be stripped by a referrer policy. Treat a missing id as an unattributed sale rather than guessing, because a wrong attribution corrupts your partner payouts and your fraud scoring downstream. If a partner returns the same conversion twice, the webhook is idempotent on your transaction id, so a retried delivery never double-pays.

What you get for the effort

One query parameter, forwarded once, removes your dependence on cookies and scripts you do not control. Attribution rates climb because blocked and cleared sessions still resolve, partner trust improves because payouts reflect real conversions, and your privacy story gets simpler because the identifier is opaque by design. The implementation is small enough to ship in an afternoon and durable enough to outlast the next round of browser privacy changes.