How IB Tracking Actually Works: Cookies, Sub-IDs, and Server-to-Server

You send traffic. Someone clicks your link, browses, closes the tab, comes back three days later on their phone, funds an account two weeks after that. Did you get paid for it? The honest answer is: it depends entirely on plumbing you usually cannot see. Between your click and your commission sits a chain of cookies, identifiers, redirects, and server calls — and every weak link in that chain is money that silently leaks away from you and toward the broker.

This guide takes that plumbing apart. As an Introducing Broker (IB) or affiliate, you do not need to become an engineer, but you do need to understand tracking well enough to ask the right questions, spot a broker whose attribution will quietly cheat you, and structure your own links so you can prove which of your channels actually convert. We will walk the full journey of a single referral — from the moment someone clicks to the moment a commission posts — and name every place it can break.

The core problem: attribution is a chain of custody

Tracking exists to answer one question: which partner introduced this funded client? That sounds trivial until you notice how many steps separate the click from the deposit. Each step has to correctly pass along a token that says "this person belongs to partner #4821." Lose the token at any point and the client becomes "organic" — the broker keeps 100% instead of paying you.

Think of it as a chain of custody, the way a courier signs for a package at each handoff. In IB tracking there are four handoffs:

1. The click — your link is opened and an identifier is created.
2. Storage — that identifier is parked somewhere (a cookie, local storage, or a server record) so it survives the reader leaving and coming back.
3. The signup — the identifier is read back and stamped onto the new account.
4. The conversion event — a deposit or qualifying trade fires a message that tells the tracking system to credit you.

Two different technologies dominate steps 2 and 4: the old client-side world of browser cookies and pixels, and the newer server-to-server (S2S) world where the broker's backend reports the event directly. Understanding the difference is the whole game, so we will build up to it.

Step 1: The click and the tracking link

Everything starts with a tracking link — the URL a broker's affiliate system gives you. It looks ordinary but carries a partner identifier, usually as a query parameter:

https://broker.com/?ib=4821&utm_source=youtube&utm_campaign=review

When that link is opened, the broker's system does two things: it records a click, and it typically issues a unique click ID — a per-click token (the same idea as Google's gclid or Meta's fbclid). This click ID is the single most important object in the whole chain. In modern setups it, not the cookie, is what ultimately ties a deposit back to you.

The utm_source, utm_campaign, and similar tags you see are UTM parameters — labels you control to describe where the traffic came from. They are not how the broker attributes the commission (the ib= id does that); they are how you later slice your own performance. We will return to that under sub-IDs, because it is where most IBs are leaving intelligence on the table.

Step 2: Storage — cookies, and why they are dying

Once a click is registered, the identifier has to be remembered, because almost nobody signs up on the first visit. The classic mechanism is the browser cookie: a small file the broker's site writes to the visitor's browser, holding the click ID and the partner ID for some length of time.

That length of time is the cookie duration (also called the cookie window), and it is one of the most commercially loaded numbers in your entire deal. If the window is 30 days and your reader funds on day 31, you are not paid — even though you unquestionably introduced them. We cover this fully in Cookie Windows and Attribution, because the length of that window, and how it renews, quietly decides how many commissions you actually collect.

Here is the problem: browser cookies are failing as a tracking method. Three forces are eroding them, and none are reversing in 2026:

• Third-party cookie deprecation. Browsers increasingly refuse cookies set by a domain other than the one in the address bar — exactly the pattern a lot of legacy affiliate tracking relied on.
• Apple's Intelligent Tracking Prevention (ITP) and Safari/Firefox privacy defaults cap or delete tracking cookies, often within 24 hours to 7 days regardless of the window your broker advertises.
• Ad blockers and privacy extensions strip pixels and cookies outright, so a meaningful slice of your audience is invisible to any cookie-based system from the first click.

The practical effect: a broker who only tracks with cookies will systematically under-count your conversions, and the more privacy-conscious your audience (a common trait among crypto and advanced-trading audiences), the worse it gets. Independent affiliate audits through 2025-2026 consistently found cookie-only setups missing a large minority of conversions that server-side tracking recovered. This is not paranoia; it is measurable leakage, and it is the single biggest reason attribution has moved server-side.

Step 3 and 4: Server-to-server tracking and postbacks

The fix for everything above is to stop trusting the browser to remember anything important, and instead have the broker's own servers do the remembering and the reporting. This is server-to-server (S2S) tracking, and it is now the industry default for serious IB and affiliate programs.

The mechanics are simpler than the acronym suggests:

1. On the click, the broker captures the click ID and stores it on the broker's server, tied to the browsing session and later to the account — not in a browser cookie the user's device can throw away.
2. When a real business event happens — an account opens, a first-time deposit (FTD) clears, a qualified FTD threshold is met — the broker's backend fires a message directly to the tracking platform.
3. That message is a postback (also called an S2S postback or conversion callback): a server-to-server HTTP request carrying the original click ID plus the event details.

Because the postback travels server-to-server, it does not care about cookies, ad blockers, ITP, or which device the user is on. A reader who clicks your YouTube link on a laptop today and funds from their phone next week is still credited to you, as long as the broker linked both sessions to the same account and the click ID survived. This is why postbacks and S2S tracking deserve their own deep dive — done right, they are the difference between getting paid for what you earned and getting paid for what the browser happened to remember.

A postback URL you might see configured looks like this, with placeholders (called macros) the broker fills in at fire time:

https://track.network.com/postback?clickid={click_id}&event=ftd&payout={amount}&sub1={sub1}

The {click_id} macro is the reunion point: the tracking platform matches the incoming click ID to the click it recorded days earlier and books the conversion against your account.

Notice the trade in that last row. S2S is more accurate, but it moves the entire process inside the broker's infrastructure, where you cannot watch it. That is the central tension of modern IB tracking, and it is why auditing matters more than ever.

Sub-IDs: the intelligence layer you control

So far we have covered how the broker knows a client is yours. Sub-IDs are how you know which of your own efforts produced that client — and this is where most IBs are flying blind.

A sub-ID is an extra parameter you append to your tracking link to tag the traffic's source. The broker passes it back untouched in the postback, so it appears next to each conversion in your report:

https://broker.com/?ib=4821&sub1=yt-reviewvideo&sub2=pinned-comment

Now, instead of a single undifferentiated pile of "commissions," you can see that your pinned-comment link converts at triple the rate of your video description, or that one blog post drives 60% of your funded accounts. That is the entire premise of Sub-ID tracking: turning a lump-sum payout into a per-channel profit-and-loss statement. The difference between UTM parameters and sub-IDs is subtle but worth pinning down:

• UTM parameters are read by your analytics (and sometimes the broker's landing page). They are a labelling convention, not an attribution mechanism.
• Sub-IDs are carried by the broker's tracking system and returned in the postback, so they attach to real money events, not just page views.

Most affiliate platforms give you several sub-ID slots (sub1 through sub5 or more). A disciplined naming scheme — channel in sub1, campaign in sub2, creative in sub3 — is the cheapest analytics upgrade you will ever make. Do it from day one, because you cannot retroactively tag traffic you already sent untagged.

Deep linking and link cloaking

Two related techniques change where your link sends people and what it looks like while still carrying your identifier.

Deep linking means your tracking link lands the user on a specific inner page — a particular platform's page, a promotion, a comparison — rather than always dumping them on the broker's generic homepage. The tracking parameters ride along, so you keep attribution while sending people exactly where your content promised. Matching the landing page to the intent of your content lifts conversion rate substantially; sending a "best MT5 broker" reader to a homepage instead of the MT5 page wastes qualified traffic.

Link cloaking replaces the long, ugly, parameter-laden tracking URL with a clean branded one (for example yoursite.com/go/broker) that redirects through your own domain to the real tracking link. Done properly it protects your links from being copied and stripped, keeps affiliate parameters out of sight, and — importantly for finance — routes around social platforms that ban raw broker URLs. Done improperly, a bad redirect chain can drop your parameters and destroy attribution. Our guide to link cloaking and deep linking covers how to build redirects that protect traffic without breaking tracking.

Where money leaks: the failure modes to know

Every handoff in the chain is a place a commission can vanish. Knowing the failure modes lets you diagnose a suspiciously low report instead of just accepting it.

1. Window expiry. The reader funded after the cookie/attribution window closed. Fix: negotiate a longer window and confirm it is enforced server-side.
2. Cross-device loss. Click on desktop, sign up on mobile, and a cookie-only system sees two strangers. Fix: choose brokers with account-level S2S attribution.
3. Cookie deletion. Safari/ITP or an ad blocker wiped the cookie before signup. Fix: server-side storage.
4. Parameter stripping. A redirect, a social app's in-app browser, or a cloaking misconfiguration dropped the identifier. Fix: test the full redirect path end-to-end.
5. Last-click override. The user later clicked a broker's own retargeting ad or a different affiliate's link, and the broker's attribution model credited the last touch instead of you. Fix: understand the broker's attribution rules before you promote.
6. Silent event mismatch. The broker counts a "conversion" as a qualified deposit with conditions you never saw, so clicks look fine but conversions look thin. Fix: audit the reporting definitions.

That last cluster is why you should never take a dashboard at face value. Learn to audit a broker's reporting dashboard — run test clicks, fund a test account where feasible, and reconcile what you see against what you did. And once you work with several partners, the reconciliation problem multiplies; managing attribution across multiple broker partners becomes its own discipline.

How the pieces fit: a worked example

Walk one referral through the whole chain to see the parts working together.

1. You publish a broker review on YouTube. Your description link is yoursite.com/go/broker-x?sub1=yt&sub2=review-oct — a cloaked link.
2. A viewer clicks. Your domain redirects to the broker's real tracking link, preserving ib=4821, sub1=yt, sub2=review-oct. The broker records a click and mints a click ID stored on its server.
3. The viewer isn't ready. They close the tab. No cookie needs to survive, because the click ID lives server-side, keyed to their session.
4. Nine days later they return — on a different device — search the broker's name, land on the site, and open an account. The broker links the new account to the earlier click (via login/email/session logic) and stamps click ID abc123 and your ib/sub values onto it.
5. Three days after that, the client makes a first-time deposit. The broker's backend fires a postback: ...?clickid=abc123&event=ftd&payout=250&sub1=yt&sub2=review-oct.
6. Your tracking platform matches abc123, credits your account, and — thanks to the sub-IDs — files it under YouTube → October review. You now know that video earns.

Every arrow in that story is a place cookies would have failed and S2S did not. That is the case for insisting on server-side attribution, in one concrete walk-through.

From understanding tracking to choosing partners

Understanding this chain changes how you evaluate a broker. Attribution quality is not a footnote to a partnership — for a tracking-dependent business, it is the partnership. A broker with a generous commission model but a leaky, cookie-only tracking stack will pay you less, in practice, than a broker with a smaller headline rate and airtight S2S attribution, because you actually collect what you earn. And a broker who is evasive about their tracking belongs on your due-diligence checklist as a warning sign, not a technicality.

When you are ready to compare partners on exactly these criteria — attribution method, cookie window, sub-ID support, postback transparency — the fastest way to build shared vocabulary and vet the terms is to work through Revenika's reference definitions. Our partner glossary breaks down every term in this article and the surrounding deal mechanics, so you can read a broker's affiliate agreement and know precisely which clauses protect your commissions and which quietly surrender them.

Frequently Asked Questions

Are cookies completely useless for IB tracking now?

Not useless, but no longer trustworthy on their own. First-party cookies (set by the broker's own domain) still work reasonably in many browsers and can supplement attribution. The problem is depending on them: third-party cookie deprecation, Apple's ITP, and ad blockers delete or block tracking cookies unpredictably, so a cookie-only broker will under-report your conversions. Treat cookies as a fallback layer, and insist that the primary attribution is server-to-server.

What is the practical difference between a cookie and a click ID?

A cookie is storage on the user's device; a click ID is the identifier being stored and passed along. In old setups the click ID lived inside the cookie, so if the cookie died, attribution died. In S2S setups the same click ID is stored on the broker's server and returned in the postback, so it no longer depends on the browser keeping anything. The click ID is the thing that matters; the cookie is just one (fragile) place to keep it.

Can I verify a broker's tracking myself without engineering skills?

Partly, yes. You can open your tracking link in a private window and confirm your identifier survives every redirect. You can send a small burst of tagged test clicks and check they appear in your dashboard. Where terms allow, you can fund a test account and confirm the conversion posts with the correct sub-IDs. What you cannot see directly is the server-side postback firing — for that you rely on the contract's attribution definitions and on reconciling your traffic against reported conversions over time.

Why do sub-IDs matter if the broker already credits me the commission?

The broker's ID answers "is this client mine?" Sub-IDs answer "which of my efforts produced this client?" Without them, you get one lump payout and no idea which video, post, or campaign drove it, so you cannot double down on what works or cut what doesn't. Sub-IDs turn a black-box payout into a per-channel report. Because you cannot tag traffic retroactively, the cost of skipping them is permanent — you simply never learn.

Does server-to-server tracking mean I have to trust the broker blindly?

It shifts trust toward the broker, because the attribution logic runs on their servers where you cannot watch it. That is exactly why the contract matters: specify the attribution window, the exact conversion event definition, sub-ID pass-through, and your right to reconcile. Combine that with your own test clicks and periodic dashboard audits. S2S buys you accuracy; contractual terms and verification buy you the ability to enforce it.

Conclusion

IB tracking is a chain of custody, and your commissions survive only as long as the identifier does. Cookies were the old way to carry that identifier, and privacy changes have made them leak badly; server-to-server tracking with postbacks is the modern, resilient replacement, and sub-IDs are the layer that turns raw attribution into business intelligence you control.

You do not need to build any of this. You need to understand it well enough to ask the sharp questions: Is attribution server-side or cookie-dependent? How long is the window and how is it enforced? Are sub-IDs supported and passed back in the postback? Can I deep-link and cloak without breaking tracking? Can I reconcile the numbers? A broker who answers those clearly is one whose dashboard you can eventually trust. A broker who deflects them is telling you where your money will go. Read the plumbing before you send the traffic — because in this business, the partner who understands attribution keeps the commissions the partner who doesn't quietly loses.

For deeper reference, the UK's Financial Conduct Authority and the US National Futures Association publish the introducing-broker and financial-promotions rules that shape how referral relationships and their disclosures must work; and neutral explainers of server-side postback tracking and browser attribution changes such as Apple's Intelligent Tracking Prevention are worth reading to see the mechanics first-hand.