Affiliate Tracking Explained for iGaming

Affiliate tracking connects a casino player’s activity to the partner who referred them. It starts by recording a referral and preserving an identifier, then links that referral to registration, deposits and any revenue used to calculate commission. Cookies can help preserve the identifier in a browser. Server-to-server (S2S) tracking sends events between systems, often through postbacks. First-party tracking describes collection in the operator’s own site context; it can work alongside both cookies and S2S.

For an iGaming operator, the important question is whether that connection survives the actual player journey. A visitor may register today, deposit later and continue playing for months. The affiliate agreement determines which of those events earn commission. The tracking integration needs to supply the evidence for that calculation.

This guide follows the journey from the first click to the partner’s report, explaining what each method does and what to check before choosing an integration.

What does affiliate tracking need to connect?

An iGaming tracking setup needs to connect three things: the referral, the player account and the events covered by the affiliate agreement. Recording each separately is not enough if the systems cannot match them.

A typical integration uses several identifiers:

These identifiers serve different purposes. A SubID such as review_top_button may describe thousands of clicks. It cannot replace a unique click ID. Likewise, one player can make several deposits, so a player reference alone cannot identify an individual deposit transaction.

Use opaque references where practical. An affiliate does not need a player’s name or email address to understand whether a placement generated a qualifying acquisition.

How are affiliate clicks tracked?

A click is recorded when the visitor follows a tracking link through a redirect, or when tracking code records the referral on the destination page. The implementation determines where the click ID is generated and how it reaches the casino.

With a redirect link, the visitor passes through a tracking endpoint before reaching the landing page. The tracker records the referral and can append a click ID to the destination URL. With direct linking, the visitor reaches the casino page first and a script can record the referral there.

Trackdesk documents both approaches: redirect tracking passes a CID to the landing page, while the click-script callback lets an integration access the CID returned through the browser script. The operator’s team still needs to carry that identifier into the relevant session or account record.

Consider this illustrative landing-page URL:

https://casino.example/welcome?click_id=C1048&subid=review_top_button

The parameter names are examples, not a ready-to-use Trackdesk configuration. Here, C1048 identifies the referral interaction and review_top_button identifies the placement. If the registration form sits on another domain or a different application, the implementation must deliberately preserve the referral through that transition.

A click count is not a player count. Repeat visits, link checks and automated requests can affect the numbers, depending on the system’s filtering and counting rules. Ask whether a report shows total clicks, unique clicks or another defined measure before comparing it with registrations.

What role do cookies play?

A cookie can preserve a reference between visits or page requests in the same browser. In affiliate tracking, that reference can help the site recover an earlier referral when the visitor registers or completes another action.

For example, a visitor arrives with a click ID, browses several pages and registers later. A cookie may allow the registration process to recover the ID after it has disappeared from the address bar. The cookie usually holds an identifier; the associated affiliate and campaign details can remain in the tracking system.

MDN’s guide to HTTP cookies explains the attributes that control cookie lifetime and scope. A session cookie and a persistent cookie behave differently, and a cookie available on one domain is not automatically available on an unrelated registration domain.

A cookie can also be deleted, expire or become unavailable under browser settings. It does not travel automatically from a player’s phone to their laptop. Treat browser storage as one part of the referral process, not a permanent player record.

Is cookie lifetime the same as an attribution window?

Cookie lifetime controls how long a browser is intended to retain a cookie. An attribution window controls how long a referral is eligible to receive credit under the configured rule. Those settings can differ.

Suppose an agreement allows a registration to be attributed within 30 days of a qualifying click. That is an illustrative commercial rule, not a recommended default. A browser might lose the identifier earlier; alternatively, the identifier might remain available after the attribution window has closed. Neither situation changes the agreed eligibility rule.

Trackdesk’s platform terminology guide distinguishes server-side attribution timing from browser cookie storage. When reviewing an implementation, ask about both settings rather than accepting a single “cookie duration” as the complete answer.

The period for crediting an initial referral is also separate from the duration of ongoing RevShare. Once a player has been attributed, later commission depends on the agreement and the retained player relationship, not simply on whether the original cookie remains in the browser.

What is first-party tracking?

First-party tracking collects referral information in the context of the operator’s own site. It may use a first-party cookie, a server-side session and an account record together. The term does not tell you whether every event is collected in the browser or sent from a server.

For cookies, the distinction is about the site context. A cookie used in the context of the site the visitor is browsing is first-party; a cookie used in a cross-site context is third-party. MDN’s explanation of first- and third-party cookies describes this distinction. A software vendor can provide code that sets a first-party cookie on an operator’s page; vendor ownership alone does not determine the cookie’s browser context.

For a casino, a useful design question is when the referral becomes part of the operator’s account data. If the click ID is associated with the player at registration, subsequent backend events can use that stored relationship rather than trying to rediscover the original browser visit every time.

That requires implementation work. A first-party cookie does not automatically populate a player account. A branded tracking domain does not, by itself, establish that the registration system receives and retains the identifier. Ask the integration team to show the handover.

First-party tracking also does not guarantee cross-device attribution. An authenticated account may connect later activity across devices once the referral has been saved. An anonymous click on a phone followed by an unrelated registration on a laptop presents a different problem. Without a valid way to connect those interactions, the original referral may remain unassigned.

What is a postback in affiliate tracking?

A postback is an HTTP request that tells another system an event occurred. In affiliate tracking, it typically carries a referral identifier and event details so the receiving system can record or update a conversion.

The word “postback” does not require the HTTP POST method. Trackdesk’s advertiser postback documentation supports GET and POST requests for recording conversions. The receiving endpoint determines the required method, fields and values.

An iGaming integration can involve two separate postback directions:

The second notification cannot repair a missing first event. If the casino never reports the deposit, configuring an affiliate-facing postback does not make that deposit appear.

An affiliate may also have its own click ID. The integration needs to preserve that alongside the platform’s identifier if the publisher expects its tracker to match the notification to its original click. Trackdesk’s affiliate postback guide describes passing the partner’s click ID through fields such as affS1 and returning it in the notification.

Agree on what the notification represents. A registration, a first deposit and an approved CPA acquisition are different events. Sending them under an ambiguous “conversion” label makes the partner’s report harder to interpret.

How does server-to-server tracking work?

S2S tracking sends event data directly from one server to another. For a casino, this can mean reporting a confirmed deposit from the operator’s backend instead of relying on a conversion script loading in the player’s browser.

The backend obtains the event from the relevant operational system, attaches the required referral reference and sends it to the affiliate platform. This makes the conversion-reporting step independent of a player returning to a confirmation page. It does not remove the need to capture the referral correctly at the start.

Trackdesk’s POST conversion guide illustrates that dependency: the integration must capture and store a CID before using it in a later conversion request. A server request without a usable attribution reference cannot reconstruct an unknown referral.

For implementation, decide which system is authoritative for each event:

• Registration should come from the system that confirms the account was created.

• A deposit should reflect the agreed successful transaction state, rather than the player merely opening the cashier.

• First-time-depositor status should be determined against the relevant account and brand rules.

• Commissionable revenue should come from the agreed calculation process, with corrections handled explicitly.

S2S delivery still needs monitoring. Requests can fail, arrive late or be retried. Keep a stable event identifier across retries and define how the receiving system prevents a second request from creating a second payable event. Confirm the endpoint’s actual deduplication rules instead of assuming that an arbitrary transaction field will be sufficient.

A successful HTTP response is useful delivery evidence. Reconciliation should also confirm that the event was processed with the expected affiliate, amount and status.

How do clicks, cookies and S2S work together?

A common design uses browser-side referral capture for the initial visit and backend reporting for later player activity. The point where the referral is attached to the player account connects the two.

Here is an illustrative journey. The identifiers are fictional, and the sequence describes an integration design rather than a specific API schema.

If the player closes the browser after initiating a deposit, backend confirmation can still provide the event once the transaction succeeds. If the referral was never saved against the account, backend reporting may accurately record a deposit without knowing which affiliate deserves credit.

This is why “we use S2S” is only part of an integration answer. The team also needs to explain how the referral reaches the player record and what happens when that association is missing.

How does tracking become a commission?

Tracking supplies events and attribution references. Commission rules determine whether those events are payable and how much the partner earns.

Keep these distinctions visible in reporting:

A deposit amount is not automatically gaming revenue or commissionable NGR. Do not send deposit values into a revenue-share calculation simply because an integration field is named “revenue.” Define the value that each field represents and how the agreement uses it.

For the commercial definitions, see our guide to iGaming affiliate commission models.

Attribution rules need their own decisions. If a player clicks two affiliates before registering, which eligible referral wins? Does a later visit affect an existing player assignment? How are returning players treated? Cookies and postbacks move information; they do not settle those commercial questions.

Does first-party or S2S tracking remove consent requirements?

Neither label establishes that an implementation is exempt from privacy requirements. Assess what information is collected, whether information is stored or accessed on a device, why it is used and who receives it.

In the UK, the ICO’s guidance on storage and access technologies explains that first-party and server-side contexts do not, by themselves, determine whether PECR applies. Personal-data processing also brings data-protection obligations. Requirements elsewhere need a market-specific review.

Include the consent behavior in the integration specification. If a required permission is declined, what stops collecting or transmitting? Which events remain available for other permitted purposes? How is the resulting measurement gap shown? Moving an event to a server is not a reason to ignore the visitor’s choice.

Limit affiliate-facing notifications to the fields needed for the agreed purpose. An opaque player reference can still be personal data when it can be linked to an individual; changing the identifier’s format does not automatically make the data anonymous.

What should operators check when choosing a tracking setup?

Choose a setup that can preserve the referral through your registration flow and report the events your agreements require. A small program still needs reliable deposit reporting; a large program does not benefit from complexity it cannot maintain.

Browser-based conversion tracking can be useful for an observable page event or an initial integration. It is less suitable as the sole evidence of a transaction confirmed asynchronously in the backend. If the casino needs later deposits, qualification changes and ongoing revenue, assess how the integration receives those backend records.

For a platform or integration review, ask the team to demonstrate:

1. Referral capture: where the click ID is created and how it survives redirects and registration.

2. Account association: where the eligible referral is saved and which rule controls subsequent changes.

3. Event mapping: how registration, FTD, qualified CPA and revenue are distinguished.

4. Delivery controls: what happens after a failed request, a retry or an out-of-order event.

5. Corrections: how a reversed transaction or revised revenue amount affects reporting and commission.

6. Partner visibility: what the affiliate sees and which events trigger outbound postbacks.

Use a test journey that includes a delayed deposit, a repeated event and a later correction. Compare the operator’s records with the platform’s report and the affiliate’s notification log. A screenshot of one successful conversion does not demonstrate the complete flow.

Trackdesk documents inbound advertiser postbacks and an outbound affiliate postback log. These cover different parts of delivery. When evaluating Trackdesk for iGaming, use your own registration and deposit sequence to check how the required player events and commission rules will be implemented.

Before launch, write down who owns referral capture, account mapping, event delivery and reconciliation. Those responsibilities give your affiliate manager a clear route to investigate a missing acquisition without guessing which system lost it.

For the wider operating setup, our guide to building an iGaming affiliate program covers the terms, materials and partner support that need to sit alongside tracking. More guides are available in the iGaming Growth Hub.

FAQ

Are postback tracking and S2S tracking the same thing?

A postback is a common way to deliver an S2S event notification. S2S describes communication between servers; postback describes the request reporting the event. Confirm which systems send and receive it, because an operator-to-platform postback and a platform-to-affiliate postback have different jobs.

Can affiliate tracking work without cookies?

Yes, a design can capture a referral identifier and retain it server-side without relying on an affiliate cookie for later conversion reporting. It still needs a valid way to connect the initial visit to the eventual account or event. “Cookie-free” does not mean identification-free or automatically exempt from privacy requirements.

Can S2S tracking recover a missing click ID?

S2S transports the data supplied to it. It cannot recreate a missing referral on its own. An integration may use another supported reference or an already-established player association, but that matching method must exist and be valid before the event can be attributed.

Does first-party tracking work across casino brands?

Not automatically. Separate brand domains and account systems require an explicit integration and an agreed attribution policy. Confirm whether player references are unique across brands, whether the agreement allows cross-brand credit and how the implementation handles the relevant privacy requirements.

Is a first-time depositor always a payable CPA conversion?

No. FTD records the first-deposit milestone as defined by the program. A CPA agreement may impose additional qualification conditions. Reporting should distinguish the deposit event from an approved acquisition so that operators and affiliates can explain the difference.