Introbroker/Partners
Become a partner

Technical

Cookieless affiliate tracking for brokers

A cookie is a message a browser agrees to give back to you later. Three of the four major browsers have narrowed what they agree to, and forex traffic breaks the remaining assumption anyway by clicking on one device and funding on another.

By The Introbroker partner deskPublished 6 min read

What actually breaks

Three separate failures get reported as one, and they need different fixes.

Third-party cookies are blocked

If the tracking domain is not the domain the reader is on, the cookie is a third-party cookie. Safari has blocked those outright since 2020 and the others have followed to varying degrees. A tracker on its own domain loses the click at the first hop.

First-party cookies are shortened

A cookie written by JavaScript rather than by an HTTP response header is capped at a short life on Safari. A forex account often takes longer than that from first click to first deposit, so the identifier expires before the conversion happens.

The device changes

A reader clicks a link in a chat app on a phone and completes verification on a laptop days later. No cookie mechanism survives that, because the storage is per browser and there are two browsers.

None of these produce an error. The click is recorded, the trader funds an account, and the conversion is simply never attributed. It looks identical to traffic that did not convert, which is why partners underestimate their own performance rather than complain about it.

The five events an introducing broker has to own

Only the first happens on your own infrastructure. The other four happen at the broker, which is why the integration is the whole job.

The five attribution events and where each one is captured
EventWhere it happensHow it is captured
ClickYour own edgeA worker stamps a click identifier, writes a first-party cookie and a server-side row, and carries the sub-IDs with it
RegistrationBroker CRMServer to server postback, matched on the click identifier. The partner is locked to that trader permanently
Verification and first depositBroker CRMServer to server postback carrying amount, method and country
Every closed tradePlatform bridgeSymbol, volume, duration and spread captured per trade, per broker
PayoutYour own ledgerWeekly lock, payout file, immutable ledger entry
The fourth one is the difference. Without trade-level capture you can report that a conversion happened and nothing else. With it you can compute a revenue share yourself instead of accepting a total someone else calculated, and you can show a partner the individual trades behind a payment.

Server side first, cookie second

The fix is not a better cookie. It is to stop depending on the browser to carry the identifier at all. The click handler generates the identifier, writes it to your own database in the same request, and passes it forward in the redirect URL so it arrives at the broker as a query parameter. The cookie is still written, because it is useful when the reader returns without a link, but nothing depends on it.

From that point the identifier travels through the broker's own systems and comes back on a server to server postback. There is no browser in that path, so nothing in the browser can break it.

The click, at the edge

GET https://go.introbroker.io/r/INB-10428?s1=telegram-main

  1. generate ib_cid                    first-party identifier, pseudonymous
  2. write the click row                partner, sub-IDs, country, device, timestamp
  3. set a first-party cookie           convenience only, nothing depends on it
  4. 302 to the broker signup           ?ib_cid=... travels in the URL
  • The identifier is pseudonymous until registration. It identifies a click, not a person.
  • The redirect runs at the edge, so the extra hop costs the reader a few milliseconds rather than a page load.
  • The broker's signup form has to accept the parameter and store it against the account. This is the single hardest thing to negotiate and it is worth more than any rate concession.

Postbacks that survive a bad day

The failure modes here are all operational rather than clever, and every one of them has cost somebody a month of accruals.

  1. Step 1 of 4. Queue before you write

    A postback is accepted, put on a queue and acknowledged. It is never dropped because a database was slow. The broker retries on a non-acknowledgement, and a retry storm against a struggling database is how a slow hour becomes a lost day.

  2. Step 2 of 4. Require an idempotency key on every request

    Brokers retry. Networks duplicate. Without a key, a replayed postback accrues the same trade twice and the reconciliation finds it weeks later, if at all. With one, a replay is a no-op that returns the original result.

  3. Step 3 of 4. Keep the ledger per broker

    With several brokers, a variance you cannot attribute to one broker's general ledger is a variance you will never resolve. Every trade row carries which broker it closed on, from the first day rather than after the first problem.

  4. Step 4 of 4. Flag filtered trades, never void them silently

    Qualified-lot rules exist and they are reasonable. A trade held below a minimum duration or opened during an abnormal spread should be flagged with the rule that fired and shown to the partner. A programme that silently removes trades from your statement is the thing partners are right to be suspicious of.

Cross-device, done deterministically

The click on the phone and the deposit on the laptop are the same person, and the only reliable way to know that is something the person typed on both occasions. At registration the broker has an email address and a phone number. Hashed and matched against the click record, those stitch the two sessions together with certainty.

The alternative on offer is probabilistic fingerprinting, which infers a match from screen size, fonts, time zone and network. It is imprecise, and under European data protection law it is difficult to justify at all, since it processes personal data to identify someone who has not been told about it. Deterministic matching on data the broker already holds for regulatory reasons does not have that problem.

The lawful basis is worth getting right. Server-side attribution that exists to perform the partner contract is not the same processing as a marketing pixel, and it does not sit behind the same consent gate. The marketing pixels do. Treating both the same way either breaks your attribution or over-collects, and both are avoidable.

What to ask a broker for, in order

This list is the real blocker on any introducing broker build. Everything else you can construct yourself.

  • A trade-level data feed, not just a conversion postback. Without it you cannot compute a revenue share yourself.
  • The click identifier carried through the entire signup flow and stored against the account.
  • Postbacks on registration, verification, first deposit, every closed trade and every withdrawal.
  • Read-only access to their own introducing broker report, so you can reconcile against their general ledger rather than trust it.
  • The qualified-lot definition in writing: minimum duration, what happens during a widened spread, and what else can disqualify a trade. This is where partners get quietly short-changed.

Questions

How long does a click identifier stay valid for attribution?

That window is a commercial decision rather than a technical limit, and Introbroker has not published one yet. What is settled is what happens after the match: once a trader is attributed to a partner, the attribution is permanent and the revenue share continues for as long as that trader keeps trading.

Can I keep using my own tracker?

Yes. Events are pushed outbound to your own tracker with your macros for the click identifier, the event, the payout, your five sub-IDs, the symbol, the volume, the country, the device and the broker. RedTrack, Voluum, Binom, the GA4 Measurement Protocol, Meta CAPI and a generic webhook are all supported. There is no requirement to work inside somebody else's dashboard.

Why does every trade row carry which broker it closed on?

Because reconciliation is per broker. Each broker produces its own report from its own general ledger, and a variance can only be chased if you can say which broker's numbers it belongs to. A combined figure hides which integration is losing trades.

About the author

The Introbroker partner desk

Editorial team, Introbroker

The team that runs the partner programme: deal terms, the attribution stack behind the tracking links, the weekly payout run, and the reconciliation against each broker's own ledger. Everything on this page is written from those systems and from the agreements behind them.

  • Sets and versions the commission rules every accrual is computed under
  • Operates the click and postback attribution described on the tracking page
  • Reconciles revenue per broker against each broker's general ledger
  • Runs the weekly payout lock

Where this comes from

Sources

Primary sources only: the regulator, the standards body, the platform vendor, the legislation, or our own agreements. Not another affiliate's summary of one.