SubID & Click-ID Architecture for Casino Affiliates in 2026 – Tracking Taxonomy That Makes Optimization Possible

You’re paying €40,000/month to an affiliate who claims they’re sending premium traffic. Your platform shows 2,847 registrations attributed to them. But you have no idea which of their 14 different traffic sources is actually profitable.

Was it their Instagram story? The banner ad on their review site? The Twitch stream overlay? The email blast to their house list?

You don’t know. Because you’re tracking at the affiliate level, not the placement level. You’re flying blind on €480,000 in annual spend, optimizing based on aggregate data that hides more than it reveals.

SubIDs and Click IDs solve this. They’re the tracking infrastructure that transforms your affiliate program from a black box into an analyzable system where you can trace every euro of revenue back to the exact creative, placement, and traffic source that generated it.

Here’s what this guide covers: a practical naming convention you can implement this week, parameter mapping that survives cross-domain tracking, traffic-type-specific SubID structures, and a QA checklist that prevents the “we can’t track this” disasters before they cost you money.

The 30-Second Technical Definition

SubIDs are operator-defined dimension labels that affiliates append to tracking links to categorize their traffic sources. Think of them as the “why” and “where” of the click—which campaign, which placement, which creative variation drove this player.

Click IDs are platform-generated unique identifiers assigned to each individual click event. They’re the “who” and “when”—the immutable token that connects a specific click to all downstream events (registration, deposit, wager) for attribution and postback reconciliation.

Partner IDs (or Affiliate IDs) identify which affiliate network or individual partner the traffic came from. This is the top-level grouping.

All three work together:

Component	Purpose	Set By	Example
Partner ID	Identify the affiliate	Platform	aff_12345
Click ID	Unique click identifier for attribution	Platform (auto-generated)	clk_a7f3d9e2b4
SubID	Categorize traffic source/placement	Affiliate/Operator	twitch|jan2026|overlay|bonus50

You need all three. Partner ID groups affiliates. Click ID enables postback attribution. SubID enables optimization.

The Problem This Solves (And the Money It Saves)

“We can’t tell which affiliate placements produce NGR.”

Your top affiliate has five websites, runs paid traffic on three platforms, sends email to four different lists, and posts on six social channels. All of that funnels through one affiliate ID. Your reporting shows they drove €180,000 NGR last month.

Which of those 18+ sources was profitable? Which should they scale? Which should they kill?

Without SubIDs, you can’t answer. You’re optimizing at affiliate level when the actual performance variance is at placement level. One of their Instagram posts might be delivering 4.2x ROI while their paid Google traffic is bleeding money at 0.6x. But you’re paying them the same blended commission rate on all of it.

“Partners claim conversions we can’t verify.”

Affiliate says they drove player ID 847392. Your platform shows that player registered, but you have no click record connecting them to the affiliate. No Click ID. No way to verify the claim. You either pay on faith or deny the claim and damage the relationship.

Click IDs create an immutable audit trail. Player registered? Show me the Click ID. No Click ID? No payout. Clean attribution requires unforgeable identifiers.

“Duplicate credit, missing postbacks, broken funnels.”

Player clicks Affiliate A’s link, browses, leaves. Two days later clicks Affiliate B’s link and registers. Both affiliates have cookie-based tracking. Both claim the conversion.

Without Click ID-based deduplication, you’re paying double. With Click IDs, you have timestamps, you know which click was most recent, and your attribution rules determine who gets credit. One source of truth.

“No clean path from click → KYC → FTD → wager → NGR.”

Your platform fires a registration event. Your KYC system fires an approval event three hours later. Your PSP fires a deposit event the next day. Your gaming platform calculates NGR weekly. Four different systems, four different event schemas, and you need to join them all to understand affiliate performance.

Click IDs are the join key. Every event—reg, KYC, deposit, wager—includes the Click ID from the original click. Your reconciliation system links them. You can now trace the full player lifecycle from initial click through twelve months of wagering activity, all attributed to the exact SubID placement that sourced the player.

This is how you calculate lifetime value by traffic source. This is how you identify that Affiliate A’s Twitch streams generate players with 18-month LTV of €840 while Affiliate B’s incentivized email traffic generates players with 6-week LTV of €45.

Same registration count. Wildly different economics.

Why Most Tracking Platforms Fail at This (And What We Built Instead)

We, the team behind Scaleo, work with hundreds of casino operators and see the same tracking failures repeatedly.

Legacy affiliate platforms treat SubIDs as an afterthought—basic text fields with no validation, no reporting structure, no integration with postback systems. Operators end up with:

• Inconsistent SubID formats across affiliates (one uses twitch_jan_2026, another uses TwitchJan2026, another uses twitch|jan|2026)
• No way to analyze SubID performance without manual Excel exports
• Click IDs that don’t survive redirect chains or cross-domain hops
• Postback systems that can’t map Click IDs back to SubID dimensions
• Reports that show affiliate-level data but zero SubID granularity

The result? Operators know they need SubID tracking but can’t actually use it for optimization because the infrastructure is broken.

Modern iGaming affiliate tracking requires platforms built specifically for multi-dimensional attribution where SubIDs aren’t just captured—they’re validated, structured, and reported on at every stage of the player lifecycle.

This is why Scaleo’s tracking architecture treats SubIDs as first-class dimensions, not optional metadata. Every click logs up to 10 SubID fields with validation rules, every conversion preserves those dimensions, and every report can filter and segment by any SubID combination.

But before we get into platform capabilities, let’s cover the taxonomy that makes this work.

Operator-Grade Tracking Taxonomy (The Hierarchy That Doesn’t Collapse at Scale)

The Recommended Hierarchy

Your tracking structure needs to be granular enough to enable optimization but not so complex that it becomes unmaintainable. Here’s the proven hierarchy for casino affiliate tracking:

Level 1: Partner (Affiliate ID) The affiliate network or individual partner. Auto-assigned by your platform. Never changes. Example: partner_12345

Level 2: Offer (Offer ID) Which product or promotion the affiliate is promoting. You might have different offers for different geos, different welcome bonuses, or different brand variants. Example: offer_welcome100 or offer_casinogames_de

Level 3: Campaign The affiliate’s marketing initiative. Time-bound or ongoing. This is their organization layer. Example: spring2026_relaunch or evergreen_review

Level 4: Placement Where the link appears. This is the page or channel context. Example: homepage_hero, reviewpage_table, twitch_overlay, email_header

Level 5: Creative The specific ad creative, CTA text, or visual variant. Example: banner_300x250_v2, cta_getbonus_red, video_intro_15sec

Level 6: SubID Slots (sub1–sub5) Flexible dimension fields that affiliates populate based on their tracking needs. These map to the hierarchy above or capture additional metadata.

Example mapping:

• sub1 = traffic source platform (organic, meta, google, twitch)
• sub2 = campaign identifier
• sub3 = placement/position
• sub4 = creative variant
• sub5 = geo or device or experiment ID

Optional Dimensions:

• GEO code (especially if offer isn’t geo-specific)
• Device type (desktop, mobile, tablet, app)
• Landing page variant (if you’re A/B testing landing pages)
• Funnel step (for multi-step registration flows)

The key is consistency. Don’t let one affiliate use sub1 for campaign while another uses it for creative. Define a standard and enforce it in your affiliate onboarding documentation.

The “Never Change This” Rule

Use stable IDs, not mutable labels.

❌ Wrong approach: Set campaign=SummerPromo2026 then reuse that field next year for campaign=WinterPromo2027. Now your historical data is corrupted. Last year’s summer traffic is labeled with this year’s winter campaign.

✅ Right approach: Use immutable identifiers. campaign=c_001 where c_001 always refers to Summer 2026, even after the campaign ends. Store the human-readable label (“Summer Promo 2026”) in your campaign metadata table, not in your tracking parameters.

This applies to all dimensions:

• Offer IDs don’t change meaning
• Placement IDs don’t get reassigned
• SubID schemas don’t shift definitions mid-year

When you need to change something, create a new ID. Don’t reuse old ones. Your year-over-year analysis will thank you.

SubID Naming Convention Template (Copy/Paste Ready)

Use a consistent separator-delimited format for SubID values when affiliates need to pack multiple dimensions into one field.

Recommended format:

source|channel|placement|creative|variant

Real example:

sub1=twitch|channelXYZ|overlay|bonus50|v2

This reads as: traffic source is Twitch, specific channel is channelXYZ, placement is the stream overlay, creative is the “bonus50” offer, variant is version 2.

Allowed characters:

• Lowercase letters: a-z
• Numbers: 0-9
• Hyphens: -
• Underscores: _
• Pipe separator: | (use only if your tracking stack doesn’t mangle it)

Avoid:

• Spaces (they break URLs or get encoded as %20)
• Special characters: &, ?, #, =, / (these have meaning in URLs)
• Uppercase letters (causes case-sensitivity matching issues)

Max length guidance: Most platforms handle 255 characters per SubID field. Practical limit: keep each SubID under 100 characters. If you need more, you’re probably overcomplicating it.

Case rules: Lowercase everything. Twitch and twitch will be treated as different values in most reporting systems. Pick one (lowercase), enforce it.

Separator rules:

• Use | (pipe) to separate logical components within a SubID
• Use - (hyphen) within component values (campaign-name-here)
• Use _ (underscore) for word separation (landing_page_variant)

Avoid mixing separators inconsistently. Pick a standard and document it.

Example SubID schema for media buyers:

sub1 = platform-campaign-id
sub2 = adset-id
sub3 = ad-id  
sub4 = landing-page-variant
sub5 = geo-device

Populated:

sub1=meta-spring2026
sub2=adset-789
sub3=ad-456-carousel
sub4=lp-v3
sub5=de-mobile

Clean. Parseable. URL-safe. Ready for reporting segmentation.

Click ID Lifecycle: From Click to Postback to Payout

Step-by-Step Lifecycle

Understanding the Click ID journey is essential to debugging attribution problems. Here’s exactly what happens:

1. Click generated → Click ID issued

Player clicks affiliate’s tracking link:

https://yourcasino.com/?aff_id=12345&sub1=twitch&sub2=stream-jan15

Your tracking system receives the click, generates a unique Click ID, logs the event:

Click ID: clk_a7f3d9e2b4
Timestamp: 2026-01-15 14:32:18 UTC
Affiliate ID: 12345
SubID values: {sub1: "twitch", sub2: "stream-jan15"}
IP: 85.214.x.x
User Agent: Mozilla/5.0...

2. Redirected to landing page (with params)

Player gets redirected to your landing page with Click ID appended:

https://yourcasino.com/register?click_id=clk_a7f3d9e2b4

Your landing page JavaScript or server-side code extracts the Click ID and stores it (cookie, localStorage, or server-side session).

3. Registration event fired

Player completes registration. Your platform fires an event to your tracking system:

POST /api/conversion
{
  "click_id": "clk_a7f3d9e2b4",
  "event": "registration",
  "player_id": "p_847392",
  "timestamp": "2026-01-15 14:38:44 UTC"
}

Tracking system matches Click ID to the original click, validates it, creates a conversion record.

4. KYC event (optional but valuable)

Player passes KYC verification. Platform fires another event:

{
  "click_id": "clk_a7f3d9e2b4",
  "event": "kyc_approved",
  "player_id": "p_847392",
  "timestamp": "2026-01-15 16:22:11 UTC"
}

5. Deposit event (FTD – First Time Deposit)

Player makes first deposit. PSP or platform fires:

{
  "click_id": "clk_a7f3d9e2b4",
  "event": "first_deposit",
  "player_id": "p_847392",
  "amount": "200.00",
  "currency": "EUR",
  "timestamp": "2026-01-15 18:45:33 UTC"
}

This is typically when commission becomes payable (after hold period).

6. Wager/NGR events (the gold standard)

Player wagers, platform calculates NGR, fires ongoing events:

{
  "click_id": "clk_a7f3d9e2b4",
  "event": "ngr_update",
  "player_id": "p_847392",
  "ngr": "45.30",
  "period": "2026-01-15",
  "timestamp": "2026-01-16 02:00:00 UTC"
}

7. Postback sends data back to affiliate network

If your affiliate is working through a network that requires postbacks, your system makes a server-to-server call:

POST https://affiliate-network.com/postback
{
  "click_id": "clk_a7f3d9e2b4",
  "status": "approved",
  "payout": "80.00",
  "currency": "EUR",
  "transaction_id": "txn_445566"
}

8. Conversion validated → payable or reversed

Your finance team reviews the conversion during the hold period. If player is clean (no fraud, no chargeback), status stays “approved” and becomes payable. If fraud detected, status changes to “rejected” and commission is reversed.

9. Payout logic reads validated events

Month-end arrives. Your payout system queries all conversions with status=approved for each affiliate, calculates commission based on your agreement (CPA, RevShare, hybrid), generates payout reports.

The entire flow is keyed on Click ID. Without it, this chain breaks at step 3.

What Breaks It

Redirect chains stripping params

Player clicks affiliate link → redirects through affiliate’s tracking domain → redirects through your CDN → lands on your site. Each hop is an opportunity to lose URL parameters.

If any redirect doesn’t preserve query params, your click_id disappears. Player registers with no attribution.

Fix: Test your redirect chain. Use server-side 302 redirects that explicitly preserve all query parameters. Avoid JavaScript redirects that might not carry params.

Cross-domain hops without pass-through

Affiliate link is on review-site.com. Your registration is on yourcasino.com. Browser cookies don’t transfer across domains.

If you’re relying on cookies to persist Click ID across domains, it won’t work. Use URL parameters and server-side storage instead.

Mobile in-app browsers

Instagram, Facebook, TikTok all use in-app browsers with restricted cookie and storage access. Click ID stored in a cookie might not persist when player opens the link.

Fix: Use server-side Click ID storage tied to a session identifier that survives browser quirks.

Caching / prefetch / bot clicks

CDNs and browsers prefetch links. Bots crawl affiliate links. Each generates a click but never leads to a real player.

Your system registers thousands of Click IDs from bot traffic. When a real player registers, if you’re not validating that the Click ID came from a human session, you might attribute to a bot click instead of the real affiliate click.

Fix: Implement bot detection at click time. Flag suspicious clicks. Use fingerprinting or behavioral signals to validate human traffic before issuing Click IDs that count toward attribution.

Wrong event mapping from platform/CRM

Your gaming platform fires a “new_player” event but doesn’t include Click ID in the payload. Your tracking system receives the event and has no way to attribute it.

Fix: Ensure your platform integration includes Click ID in every event payload. Registration, deposit, wager—everything needs the Click ID field populated.

Parameter Map (The Core Implementation Table)

Here’s the complete parameter reference for casino affiliate tracking. Use this as your integration specification:

Parameter	Set By	Purpose	Example Value	Required?
click_id	Platform (auto)	Unique click identifier for attribution	clk_a7f3d9e2b4	Yes
affiliate_id	Platform	Identifies which partner/affiliate	aff_12345	Yes
offer_id	Operator	Which offer/promotion being tracked	offer_welcome100_de	Yes
sub1	Affiliate	First SubID dimension (traffic source)	twitch	Recommended
sub2	Affiliate	Second SubID dimension (campaign)	stream-jan15	Optional
sub3	Affiliate	Third SubID dimension (placement)	overlay	Optional
sub4	Affiliate	Fourth SubID dimension (creative)	bonus50-cta	Optional
sub5	Affiliate	Fifth SubID dimension (variant/geo)	de-mobile	Optional
creative_id	Affiliate	Specific creative asset identifier	banner_728x90_v3	Optional
placement_id	Affiliate	Where the link appeared	homepage_hero	Optional
geo	Platform/Affiliate	Player’s country code	DE, UK, CA	Recommended
device	Platform	Device type	desktop, mobile, tablet	Optional
event	Platform	Conversion event type in postback	registration, ftd, ngr	Yes (postback)
player_id	Platform	Internal player identifier	p_847392	Yes (postback)
amount	Platform	Transaction or revenue amount	200.00	Yes (if CPA/RevShare)
currency	Platform	Three-letter currency code	EUR, USD, GBP	Yes
timestamp	Platform	Event occurrence time in UTC	2026-01-15T14:38:44Z	Yes
status	Platform	Conversion status	pending, approved, rejected	Yes (payout)
payout	Platform	Commission amount owed	80.00	Yes (payout)

Implementation notes:

• All parameters should be URL-encoded when passed in links
• Click ID should be persisted server-side, not just in cookies
• SubID fields are flexible—define your schema and stick to it
• GEO should be detected server-side to prevent spoofing
• Timestamps must be in UTC to avoid timezone reconciliation nightmares
• Status should have clear definitions in your affiliate agreement

SubID Recipes by Traffic Type (Intent-Driven Structures)

Different affiliate traffic sources require different SubID structures. Here’s what works in practice:

SEO Affiliates (Review Sites)

These affiliates run comparison and review sites. They need to track which pages and placements convert.

SubID structure:

sub1 = site_section
sub2 = page_slug  
sub3 = table_position_or_cta
sub4 = geo_page_variant
sub5 = experiment_id

Example tracking link:

https://yourcasino.com/signup?
  aff_id=5432&
  sub1=reviews&
  sub2=best-live-dealer-casinos&
  sub3=table-row-3&
  sub4=de-version&
  sub5=exp-47

Why this structure:

• sub1 lets them see which site section (reviews vs guides vs comparisons) performs best
• sub2 identifies the specific page—critical for content optimization
• sub3 shows which table position or CTA button drove the click (above fold vs below)
• sub4 tracks geo-specific page variants (German version vs UK version)
• sub5 enables A/B testing without changing other parameters

Optimization insight: When you report back that sub3=table-row-1 has 3.2x higher FTD rate than sub3=table-row-7, the affiliate moves your casino higher in their comparison tables. Everybody wins.

Streamers/Influencers

Twitch streamers, YouTube creators, Instagram influencers need to track which streams and content pieces convert.

SubID structure:

sub1 = channel_or_platform
sub2 = stream_date_or_video_id
sub3 = overlay_command_or_cta
sub4 = promo_code_id
sub5 = creative_variant

Example tracking link:

https://yourcasino.com/bonus?
  aff_id=7821&
  sub1=twitch-channelXYZ&
  sub2=2026-01-15&
  sub3=overlay-cmd-bonus&
  sub4=promo-STREAMER50&
  sub5=banner-v2

Why this structure:

• sub1 differentiates between Twitch, YouTube, Instagram if they’re multi-platform
• sub2 ties conversions to specific streams or videos for content analysis
• sub3 tracks whether the overlay link, chat command, or video description drove the click
• sub4 links to promo codes so you can match claimed codes to attributed conversions
• sub5 tests different banner/overlay creative variants

Optimization insight: Streamer sees that their Friday night streams (sub2=2026-01-*-friday) convert 2.1x better than weekday streams. They shift schedule. You get more FTDs.

Media Buyers (Paid Traffic)

Affiliates running paid ads on Meta, Google, TikTok need to track campaign/adset/ad performance.

SubID structure:

sub1 = platform-campaign_id
sub2 = adset_id
sub3 = ad_id
sub4 = landing_page_variant
sub5 = targeting_segment

Example tracking link:

https://yourcasino.com/register?
  aff_id=9384&
  sub1=meta-c447&
  sub2=as-778&
  sub3=ad-992-video&
  sub4=lp-fastregister&
  sub5=audience-lookalike-depositors

Critical distinction: Don’t confuse the ad platform’s click ID (Facebook’s fbclid, Google’s gclid) with your affiliate Click ID. These are different things.

• Platform click ID (fbclid): Used by Facebook for their attribution
• Affiliate click_id: Used by your system for affiliate attribution

Both can coexist in the URL. Your system ignores fbclid. Facebook ignores your click_id. Each system uses what it needs.

Why this structure:

• sub1 identifies ad platform and high-level campaign
• sub2 enables adset-level optimization (different audiences, budgets, bids)
• sub3 pins conversions to specific ad creative (video vs image vs carousel)
• sub4 tracks landing page variants so you can see which converts better
• sub5 captures audience targeting for LTV analysis

Optimization insight: Media buyer discovers that sub5=audience-lookalike-depositors has 40% higher FTD rate but 22% lower 30-day NGR than sub5=audience-cold-interest. They adjust bid strategy and targeting accordingly. You get better LTV players.

Email / CRM Partners

Affiliates with email lists or databases need to track list performance, send timing, and creative variants.

SubID structure:

sub1 = list_or_segment
sub2 = send_date
sub3 = subject_line_test
sub4 = template_version
sub5 = offer_angle

Example tracking link:

https://yourcasino.com/welcome?
  aff_id=2847&
  sub1=list-highrollers&
  sub2=2026-01-15&
  sub3=subject-limited-time&
  sub4=template-v4&
  sub5=angle-vip-treatment

Why this structure:

• sub1 segments list quality (high rollers vs cold prospects vs reactivation)
• sub2 tracks send date for timing analysis (day of week, seasonality)
• sub3 identifies subject line variant for open rate correlation
• sub4 tracks email template for design/layout optimization
• sub5 captures messaging angle (bonus focus vs VIP focus vs game variety)

Optimization insight: You discover that sub1=list-reactivation has 0.8x FTD rate but 1.9x NGR compared to sub1=list-cold. These are lapsed players coming back. Higher value. You adjust commission tiers to incentivize reactivation traffic specifically.

How to Connect SubIDs to Business Outcomes (The “So What” for Operators)

SubIDs don’t matter unless they drive decisions. Here’s how to build reporting that translates SubID data into action.

The money report: Join SubID dimensions to player lifecycle metrics:

SubID → Clicks → Registrations → KYC Pass Rate → FTD → FTD Amount → 
30-Day NGR → 90-Day NGR → 180-Day Retention → Lifetime Value

This report shows you which traffic sources produce valuable players, not just volume.

Example scenario: Affiliate A has two main placements:

• sub3=homepage-hero: 10,000 clicks/month, 4.2% FTD rate, €85 avg FTD, €340 90-day NGR
• sub3=blog-sidebar: 3,000 clicks/month, 2.1% FTD rate, €180 avg FTD, €890 90-day NGR

Naive optimization: Scale the homepage hero (higher volume, higher conversion rate).

Smart optimization: Scale the blog sidebar (higher quality, 2.6x better LTV).

SubIDs enable this analysis.

Optimization rules to implement:

Pause low-quality placements: If sub3=X has FTD rate >3% but 30-day NGR <€100, it’s bonus hunters or low-quality traffic. Pause it or shift to CPA-only compensation.

Reward high-LTV sources: If sub1=Y consistently delivers players with 180-day NGR >€600, increase commission tier for that SubID specifically. Incentivize the affiliate to scale that exact source.

Commission tiering based on cohort quality: Standard RevShare: 25% of NGR High-LTV SubIDs (based on historical data): 35% of NGR Low-quality SubIDs: CPA only, no RevShare

You define “quality” using SubID cohort performance data.

This is how sophisticated operators move from volume-based affiliate programs to value-based programs.

Validation and Fraud Controls Using SubIDs and Click IDs

SubID patterns reveal fraud faster than aggregate data ever could.

Spotting spam placements:

Sudden spike in one SubID. sub2=new-campaign-X goes from 50 clicks/day to 5,000 clicks/day overnight. All from the same device type, same ISP block, sequential IP addresses.

Red flag. Likely bot traffic or click fraud.

Your fraud system should alert when:

• SubID volume increases >500% day-over-day
• Click-to-registration time is suspiciously uniform (all 2-3 minutes)
• Same SubID shows >80% registrations from single GEO despite being “international traffic”

Identifying incentivized traffic via patterns:

Incentivized traffic (pay-to-signup schemes) has distinct signatures:

• High registration rate (>8%) but low KYC pass rate (<40%)
• High FTD rate but minimum deposits (everyone deposits exactly the minimum)
• Zero retention (players disappear after claiming bonus)

When you segment by SubID, incentivized placements light up like a flare. Normal placements have 2-3% reg rate, 75% KYC pass, varied deposit amounts, 30%+ 30-day retention.

Flag SubIDs where:

• KYC pass rate <50%
• Avg FTD amount within €5 of minimum requirement
• 30-day return rate <15%

Duplicate account clusters:

Same player creating multiple accounts to claim bonuses repeatedly. They’re not smart enough to vary their SubID.

Query: How many accounts from aff_12345 + sub3=email-blast-jan have matching device fingerprints or sequential IP addresses or identical deposit patterns?

If you see 40 accounts all from the same SubID, all registering within a 6-hour window, all making €50 deposits, all claiming the same bonus—cluster detected.

Block the SubID. Investigate the affiliate.

Mismatched GEO/device distributions:

Affiliate claims they’re targeting Germany. sub1=google-de suggests German traffic. But Click IDs show 80% of traffic is from Romania and Bulgaria.

Either they’re using VPNs (fraud) or they’re misrepresenting their traffic source (also fraud).

Cross-reference SubID labels against actual GEO distribution from Click ID data.

QA alert thresholds:

Configure automated alerts:

Condition	Threshold	Action
SubID volume spike	>300% day-over-day	Alert fraud team
KYC pass rate drop	<45% for SubID with >100 regs	Pause SubID pending review
Duplicate device fingerprints	>10 accounts per SubID per day	Flag for manual review
GEO mismatch	>60% traffic from unexpected GEO	Verify with affiliate
Uniform timing patterns	>75% regs within 5-min intervals	Bot detection scan
Zero retention	<10% 7-day return rate after 50+ FTDs	Quality review

These thresholds prevent fraud from scaling before it costs you serious money.

QA Checklist Before You Scale Spend (Super Practical)

Don’t ramp affiliate budgets until you’ve validated that tracking works. Here’s your pre-launch checklist:

✅ Test link in 3 browsers + mobile

Generate a test tracking link with all parameters populated:

https://yourcasino.com/signup?aff_id=TEST&click_id=TEST123&sub1=qa&sub2=test

Open in:

• Chrome desktop
• Firefox desktop
• Safari desktop
• Chrome mobile
• Safari mobile (iOS)

Verify that all parameters appear in the landing page URL. If any disappear, your redirect chain is broken.

✅ Confirm all params survive redirects

If your affiliate link goes through multiple redirects (affiliate domain → tracking domain → your landing page), test the full chain.

Check browser network inspector to see each redirect. Confirm query parameters persist through every hop.

✅ Confirm Click ID appears in postback

Complete a test registration and deposit using your test link. Check your tracking system’s postback logs.

Verify the postback includes:

• Correct click_id
• Correct affiliate_id
• Correct sub1, sub2, etc.
• Correct event type
• Correct amount and currency

If any field is missing or incorrect, your integration is incomplete.

✅ Confirm dedupe works (double deposits)

Create a test account. Make a deposit. System should fire FTD event.

Make a second deposit on the same account. System should NOT fire another FTD event (unless your logic allows it).

Check logs. Confirm deduplication is working. Only one FTD per player per Click ID.

✅ Confirm timezone/currency alignment

Make a test deposit at 23:55 your local time. Check when it appears in your tracking system.

If your local time is CET but tracking runs in UTC, that deposit should appear with UTC timestamp (22:55 UTC if CET is UTC+1).

Verify that reports use consistent timezones. Don’t mix CET data with UTC data—recipe for reconciliation disasters.

Test a USD deposit. Verify currency conversion uses your defined rules (real-time rate vs fixed monthly rate).

✅ Confirm reversals propagate to reports

Create a test conversion. Approve it. Then reverse it (simulate chargeback or fraud rejection).

Check affiliate dashboard. Does the reversed conversion show a negative entry? Does it reduce the affiliate’s revenue total?

If reversals don’t propagate, you’re overpaying affiliates for fraudulent conversions.

✅ Confirm affiliates see consistent attribution rules

Document your attribution logic (first-touch, last-touch, time-decay, etc.) in your affiliate terms.

Run a test where you click two different affiliate links before registering. Check which affiliate gets credited.

Verify this matches your stated policy. If your terms say “last-click attribution” but the first click gets credited, you have a contractual problem.

✅ Test cross-device scenarios (if applicable)

If your attribution logic supports cross-device tracking (via user accounts), test it:

1. Click affiliate link on mobile (don’t register)
2. Log into existing account on desktop
3. Make a deposit
4. Check if affiliate gets credited

If your logic doesn’t support this, that’s fine—just document it clearly so affiliates understand the limitation.

✅ Verify reporting matches platform data

Pull a SubID performance report from your affiliate system. Pull the same data from your gaming platform.

Do registration counts match? Do FTD counts match? Do revenue totals align within acceptable tolerance (<2%)?

If deltas are >5%, you have a reconciliation problem. Fix it before you scale.

Common Disputes and How This Architecture Prevents Them

Affiliate disputes are expensive in time and relationships. SubID and Click ID architecture prevents most of them.

“I sent the player, you didn’t pay me”

Affiliate claim: “Player ID 94733 is mine. I have proof they clicked my link. You didn’t credit me.”

Your response with proper tracking: “Show me the Click ID. We have no Click record linking your affiliate ID to that player ID. Without a Click ID, we cannot verify attribution.”

Resolution: If affiliate cannot provide a Click ID that exists in your system and links to that player, the claim is invalid. If they can provide a valid Click ID, you honor it—the data is unambiguous.

Click IDs create an audit trail that’s difficult to falsify. Either the click happened and generated a Click ID, or it didn’t.

“You stole my conversion / gave it to another affiliate”

Affiliate claim: “Player clicked my link on January 10, registered same day, but you credited Affiliate B instead of me.”

Your response with proper tracking: “We use last-click attribution with a 30-day window. Player clicked your link on January 10 (Click ID: clk_AAA). Player clicked Affiliate B’s link on January 12 (Click ID: clk_BBB). Player registered on January 12. Last-click attribution awards the conversion to Affiliate B per our agreement terms.”

Resolution: Your attribution rules are documented. Your Click ID data shows exactly which clicks occurred when. No ambiguity. Affiliate might not like the outcome, but they can’t dispute the logic or data.

This is why attribution window and attribution model need to be clearly defined in affiliate agreements. First-click vs last-click changes who gets credit. Document it.

“Your numbers don’t match mine”

Affiliate claim: “My tracker shows 247 FTDs this month. Your report shows 198. What happened to 49 conversions?”

Your response with proper tracking: “Please provide Click IDs for the 49 disputed conversions. We’ll investigate each one.”

Common causes of discrepancies:

• Affiliate’s tracker counts registrations as “conversions”; you only count FTDs
• Affiliate’s tracker doesn’t account for fraud rejections; you do
• Timezone differences (they report in PST, you report in UTC, creates date boundary issues)
• Deduplication differences (they don’t dedupe multi-click players, you do)

Resolution: Compare Click ID lists. Identify which specific conversions are in dispute. Check logs for each Click ID. Determine root cause (event definition mismatch, dedupe logic, fraud filtering, etc.).

Fix systematic issues. For one-off errors, adjust payout manually.

This is why event definitions and dedupe rules need to be specified in contracts. When both parties define “conversion” differently, reconciliation is impossible.

How Scaleo Handles Click IDs, SubIDs, and Postback-Proof Attribution for iGaming

Most casino operators don’t have the development resources to build enterprise-grade SubID tracking infrastructure from scratch. The technical requirements we’ve covered—Click ID generation, multi-dimensional SubID capture, postback validation, fraud pattern detection, cohort reporting—require significant engineering investment.

This is exactly why we built Scaleo.

Unlike legacy affiliate platforms that bolt on basic tracking as an afterthought, Scaleo was architected from day one for complex, multi-system iGaming environments where attribution accuracy isn’t optional—it’s the foundation of your entire affiliate economics.

Click ID Generation and Storage

When a player clicks an affiliate link through Scaleo’s tracking system:

1. Generates a unique Click ID using cryptographically secure random generation (not sequential, not guessable)
2. Logs the click event with timestamp (UTC), IP address, user agent, referrer, GEO (server-detected), device type, and all SubID parameters
3. Stores the mapping between Click ID and affiliate ID + SubID values for 365 days (configurable up to lifetime retention)
4. Redirects the player to your landing page with the Click ID appended as a URL parameter

Example redirect:

https://yourcasino.com/register?click_id=clk_7f3a8d2e9b4c

Your landing page extracts this Click ID and either:

• Stores it in a first-party cookie (client-side tracking)
• Sends it to your server to store in session (server-side tracking, ITP-proof)

Both methods work. Server-side is more reliable for Safari/iOS traffic with ITP restrictions.

The key differentiator: Scaleo’s Click ID system is built for high-volume casino traffic with redundancy, sub-50ms response times, and 99.99% uptime. Your affiliates’ tracking links don’t break during traffic spikes.

SubID Capture and Reporting

Scaleo supports up to 10 SubID fields (sub1–sub10, fully configurable). Affiliates append these to their tracking links:

https://track.yoursite.scaleo.io/click?
  aff=12345&
  offer=welcome100&
  sub1=twitch&
  sub2=jan-stream&
  sub3=overlay&
  sub4=bonus50&
  sub5=mobile

Scaleo captures all SubID values at click time and associates them with the Click ID. When conversions occur, all SubID dimensions are preserved in conversion records—no data loss, no orphaned conversions.

Reporting interface:

Affiliates log into their Scaleo dashboard and see:

• Clicks by SubID (any combination: filter by sub1 only, or sub1+sub3, or all five)
• Registrations by SubID
• FTDs by SubID
• Revenue by SubID (NGR, if you’re sharing that data)
• Commission earned by SubID

They can filter: “Show me all conversions from sub1=twitch in January” or drill down to “Show me sub1=twitch + sub3=overlay + sub4=bonus50.”

Operators see the same data plus:

• Player IDs linked to each Click ID
• Full lifecycle metrics (KYC pass rate, deposit amount, wagering activity, retention, LTV)
• Fraud flags (auto-generated and manual)
• Cohort quality scores calculated from historical SubID performance

This is the infrastructure that enables the optimization workflows we discussed earlier—rewarding high-LTV SubIDs with better commission tiers, pausing low-quality placements, identifying fraud patterns.

Postback Setup (S2S) and Event Mapping

Scaleo provides postback URLs for your gaming platform or PSP to call when conversion events occur.

Example postback URL for FTD:

https://yoursite.scaleo.io/postback?
  click_id={CLICK_ID}&
  event=first_deposit&
  player_id={PLAYER_ID}&
  amount={AMOUNT}&
  currency={CURRENCY}&
  status=approved&
  timestamp={TIMESTAMP}

Your platform populates the dynamic fields ({CLICK_ID}, {AMOUNT}, etc.) from your transaction data and makes an HTTPS GET or POST request to this URL when a deposit occurs.

Scaleo receives the postback, validates the Click ID exists, checks for duplicates, applies your deduplication rules, and creates a conversion record with all associated SubID dimensions intact.

Supported event types:

• registration (account created)
• kyc_approved (KYC verification passed)
• first_deposit (first-time deposit, triggers CPA if applicable)
• deposit (repeat deposits)
• ngr_daily (daily NGR for RevShare calculation)
• ngr_monthly (monthly NGR aggregation)
• chargeback (negative adjustment for chargebacks)
• fraud (conversion reversal due to fraud)

You configure which events trigger payouts. Typical setup: FTD triggers CPA commission, NGR events trigger RevShare commission.

Custom event mapping:

If your platform uses different event names (new_player instead of registration), Scaleo’s event mapping configuration lets you alias them:

Platform event: "new_player" → Maps to Scaleo event: "registration"
Platform event: "first_payment" → Maps to Scaleo event: "first_deposit"
Platform event: "net_revenue" → Maps to Scaleo event: "ngr_daily"

This allows integration without requiring your dev team to change existing event schemas or rebuild your platform’s webhook system.

Deduplication + Conversion Validation

Scaleo’s deduplication engine prevents the payout errors that cost casino operators thousands per month:

Per-player FTD dedupe: If Player ID 12345 makes multiple deposits, only the first deposit fires an FTD event and triggers CPA commission. Subsequent deposits don’t create duplicate FTD payouts (though they do contribute to RevShare if configured).

Per-Click ID conversion dedupe: If your platform accidentally fires the same FTD event twice (network retry, webhook duplication, integration bug), Scaleo detects the duplicate based on Click ID + Player ID + Timestamp and rejects it automatically.

Multi-click attribution: If a player clicks multiple affiliate links before converting (common with comparison sites and retargeting), Scaleo applies your configured attribution model:

• Last-click: Most recent click within attribution window gets credit
• First-click: Original click within attribution window gets credit
• Linear: Credit split equally (rare in iGaming, but supported)

Attribution window is configurable per affiliate or program-wide (7 days, 30 days, 90 days, lifetime).

Conversion hold and validation workflow:

Scaleo supports pending conversion status for fraud review and chargeback protection. When an FTD occurs, the conversion is created with status=pending. It remains pending for your configured hold period (typically 30-60 days).

During the hold period:

• Affiliate sees the conversion in their dashboard marked as “pending”
• No commission is calculated or paid yet
• You can review for fraud, chargebacks, bonus abuse, multi-accounting
• Automated fraud flags highlight suspicious patterns

After the hold period, if no issues are found, status automatically changes to approved and commission becomes payable.

If fraud is detected, you manually change status to rejected. Scaleo creates a reversal entry, the conversion is removed from payout calculations, and the affiliate sees it marked as rejected with your specified reason (fraud, chargeback, duplicate account, etc.).

Real-world impact: One of our casino operators reduced duplicate payouts from €12,000/month to zero within the first month of migration to Scaleo’s deduplication system. The previous platform was paying affiliates twice for the same FTD when players made multiple deposits in quick succession.

Reporting: Filtering by SubID, Cohort Quality, Export/API

Operator dashboard views:

SubID performance report: Columns: SubID value | Clicks | Regs | Reg Rate | FTDs | FTD Rate | Avg FTD Amount | 30-Day NGR | 90-Day NGR | 180-Day NGR | Retention % | LTV Projection

Filter by: Affiliate, Date Range, Offer, Any SubID field (sub1 through sub10)

This answers questions like:

• “Which of Affiliate A’s Twitch streams produce the best LTV players?”
• “Are his Friday streams better than weekday streams?”
• “Does the overlay CTA convert better than chat commands?”

Cohort quality view:

Group conversions by acquisition date and SubID, track cohort performance over time.

Example: Players acquired from sub1=twitch + sub3=overlay in January 2026, tracked through June 2026. Shows month-by-month NGR contribution, retention curve, LTV projection based on cohort trajectory.

This is how you identify that certain SubID combinations consistently produce high-value players worth higher commission rates.

Fraud pattern detection:

Automated reports flag SubIDs exhibiting suspicious patterns:

• Volume spikes >300% day-over-day
• KYC pass rates <45%
• Deposit amount clustering (everyone deposits exactly €50)
• GEO mismatches (SubID says Germany, traffic is 80% Bulgaria)
• Zero retention (no 7-day return visits)

These reports prevent fraud from scaling undetected.

Export and API access:

All reports are exportable to CSV/Excel for offline analysis. For operators with BI tools (Tableau, Power BI, Looker), Scaleo provides a REST API to pull:

• Click data with all SubID dimensions
• Conversion data with player lifecycle events
• SubID performance breakdowns
• Player-level attribution records
• Fraud flags and quality scores

This feeds into your existing data warehouse for custom analysis or executive dashboards.

Operator Controls: Attribution Window, Conversion Status Logic, Fraud Flags

Attribution window configuration:

Set per affiliate, per offer, or program-wide. Example:

• Premium SEO affiliates: 90-day attribution window (long consideration cycle)
• Standard affiliates: 30-day attribution window
• Retargeting/remarketing affiliates: 7-day attribution window (they get last-touch credit but shorter window)

Different traffic sources have different purchase cycles. Your attribution windows should reflect that reality.

Conversion status workflow:

Define status transitions for your specific business logic:

pending → (hold period expires + no fraud flags) → approved → payable
pending → (fraud detected) → rejected → reversed
approved → (chargeback occurs) → rejected → reversed + commission clawback

All status changes are visible to affiliates in real-time with timestamps and reasons.

Fraud flag automation:

Configure rules that auto-flag conversions for review before they become payable:

• First deposit <€20 (bonus hunters targeting minimum deposit)
• KYC pending >48 hours (potential document fraud or problematic jurisdictions)
• Player registered from VPN detected IP (GEO mismatch)
• Device fingerprint matches >3 other accounts in last 30 days (multi-accounting)
• SubID has >50% historical fraud rate (known bad placement)
• Player deposited, wagered 1x, withdrew immediately (bonus abuse pattern)

Flagged conversions require manual approval or auto-reject based on your risk tolerance.

Example: Complete Tracking Link + Postback Workflow

Affiliate generates their tracking link:

https://track.yourcasino.scaleo.io/click?
  aff=5432&
  offer=welcome_de&
  sub1=review-site&
  sub2=best-casinos-2026&
  sub3=table-position-2&
  sub4=cta-claim-bonus&
  sub5=de-desktop

Player clicks, Scaleo generates Click ID and redirects to:

https://yourcasino.com/register?click_id=clk_9d4f7a2e8b3c

Scaleo has logged:

• Click ID: clk_9d4f7a2e8b3c
• Affiliate ID: 5432
• Offer: welcome_de
• SubIDs: {sub1: "review-site", sub2: "best-casinos-2026", sub3: "table-position-2", sub4: "cta-claim-bonus", sub5: "de-desktop"}
• Timestamp: 2026-01-15 14:32:18 UTC
• IP: 85.214.45.123
• GEO: DE (server-detected)
• Device: desktop

Player registers and deposits €150. Your platform fires postback:

POST https://yourcasino.scaleo.io/postback
{
  "click_id": "clk_9d4f7a2e8b3c",
  "event": "first_deposit",
  "player_id": "p_948573",
  "amount": "150.00",
  "currency": "EUR",
  "status": "pending",
  "timestamp": "2026-01-15T16:42:18Z"
}

Scaleo processes postback:

• ✓ Validates Click ID exists
• ✓ Checks for duplicate FTD from this player (none found)
• ✓ Applies attribution (last-click within 30-day window)
• ✓ Retrieves all SubID dimensions from original click
• ✓ Creates conversion record with status “pending”
• ✓ Runs fraud rules (no flags triggered)
• ✓ Notifies affiliate (email/dashboard notification)

Affiliate sees in their dashboard immediately:

Date	Event	Click ID	Amount	SubID Details	Status	Commission
Jan 15	FTD	clk_9d4f…8b3c	€150	sub1: review-site, sub3: table-position-2	Pending	€52.50 (pending)

30 days later, no fraud detected, no chargeback, status auto-approves:

• Commission calculated: €150 × 35% RevShare = €52.50
• Status changes to “approved”
• Added to affiliate’s next payout (scheduled for Feb 15)

Affiliate sees updated dashboard:

Date	Event	Click ID	Amount	SubID Details	Status	Commission
Jan 15	FTD	clk_9d4f…8b3c	€150	sub1: review-site, sub3: table-position-2	Approved	€52.50

Clean. Transparent. Auditable. Zero disputes.

---

FAQ: SubID & Click ID Tracking for Casino Affiliates

Ready to implement SubID and Click ID tracking that actually works at scale? Scaleo’s tracking infrastructure is built specifically for casino operators who need accurate attribution across multi-system environments. Our platform handles click generation, SubID capture across 10 fields, postback validation, fraud detection, and cohort-based reporting—all with 99.99% uptime and sub-50ms response times. Book a demo to see how proper tracking taxonomy transforms your affiliate program from guesswork into a data-driven optimization engine.