When an iGaming operator runs a casino and a sportsbook under the same group, the affiliate attribution question stops being simple. A player referred by Affiliate A registers on the casino, makes a deposit, then opens the sportsbook three weeks later using a direct URL. Who referred them? Does the casino affiliate get commission on both verticals? Does the sportsbook traffic count as a new player or the same player? And when that player eventually churns, does the negative carryover hit one affiliate balance or two?
These questions don’t have obvious answers. Most affiliate platforms don’t have documented answers either — they have default behaviors that operators discover at reconciliation time.
⚡ TL;DR — Cross-Brand Player Attribution in iGaming
- Cross-brand attribution is the question of which affiliate gets commission when a player they referred generates revenue across more than one brand or vertical in the same group. Most platforms resolve this with a hard default — first-touch wins, or brand-isolated attribution — that operators don’t discover until the commissions are already wrong.
- The core conflict is between player-level tracking and brand-level tracking. Your casino platform counts players. Your affiliate platform counts conversions. When one player creates conversions on three brands, these two systems disagree about how many events occurred and who gets credit for them.
- Commission deduplication is the most commonly misconfigured setting in multi-brand iGaming programs. Without explicit deduplication rules, a single high-value player can generate CPA commissions on three brands simultaneously — a threefold acquisition cost for a player the program already owns.
- The platform has to enforce attribution rules that the contract specifies. “Cross-brand commission applies only to the referring affiliate for the first qualifying brand, with no further CPA on subsequent brands” is a common contract clause that most affiliate platforms cannot actually enforce at the event level.
This is a post about attribution logic in multi-brand iGaming programs — the decisions that have to be made explicitly before an operator scales to a second brand, and the systems failures that happen when those decisions are left to platform defaults.
We’ve handled enough multi-brand migrations and program audits to know that cross-brand attribution is where operators lose the most money they didn’t know they were losing. It doesn’t show up as a single catastrophic event. It accumulates quietly — one over-attributed CPA here, one duplicated RevShare calculation there — until a finance audit asks why acquisition costs are 40% higher than modeled.
Why Single-Brand Attribution Logic Breaks at Scale
Most iGaming affiliate platforms were originally designed around a single-brand, single-vertical assumption: one casino, one set of affiliates, one commission structure. Attribution in that model is relatively clean. A player clicks an affiliate’s link, registers, deposits, and generates revenue on one brand. The affiliate who owns the click gets the commission. Done.
The moment you add a second brand — a sportsbook launched under the same group, a crypto casino operating on a separate domain, a regional variant targeting a different market — the single-brand attribution model encounters problems it was never designed to handle.
The first problem is player identity resolution. Across two brands with separate player databases, the platform has to decide whether “player ID 4421 on Casino Brand A” and “player ID 8873 on Sportsbook Brand B” are the same human being. They might be. They might not be. The answer determines whether brand B’s first deposit counts as a new acquisition event or a cross-sell on an existing player.
The second problem is attribution ownership. If the same affiliate referred the player to both brands — because they’re running traffic to a group landing page that promotes both — do they get a CPA on each brand separately? One CPA for the group? No CPA at all on brand B because they already earned a CPA on brand A? This has to be an explicit rule. There is no universally correct default.
The third problem is revenue aggregation. If you’re running RevShare and a player generates €3,000 NGR across casino and €1,500 NGR across sportsbook in the same month, does the affiliate earn RevShare on €4,500 combined? Or separately on €3,000 from brand A’s account and €1,500 from brand B’s account? The difference matters when the RevShare deal includes negative carryover — a player who wins on casino and loses on sportsbook in the same period needs a defined consolidation rule before the commission calculation makes sense.
None of these problems are exotic edge cases. They are standard operating questions for any iGaming group running more than one product. The platforms that handle them well make the rules explicit and configurable. The platforms that don’t handle them well apply a default and hope the operator doesn’t notice.
The Four Attribution Models Multi-Brand Programs Use
Before configuring cross-brand attribution, an operator needs to decide which model their program uses. These four models represent the real options. Most programs use a hybrid of two or more, applied differently depending on commission type and affiliate relationship.
| Attribution Model | How It Works | When to Use It | Key Risk |
|---|---|---|---|
| Brand-isolated attribution | Each brand runs a completely separate affiliate program. Player activity on Brand A has no relationship to Brand B. An affiliate can appear in both programs independently and earn commissions on each brand separately. | Brands operate in different markets, different verticals, or are acquired rather than built in-house. Affiliate relationships may differ by brand. | Same player generates multiple CPA events across brands. No group-level view of acquisition cost per unique player. |
| First-touch cross-brand | The affiliate who refers a player to any brand in the group owns attribution for that player across all brands indefinitely. If they earn a CPA on brand A, they earn nothing additional on brand B when the same player converts there. | Operators who want to prevent commission duplication and are willing to offer strong first-touch protection to affiliates as compensation. | Affiliates promoting brand B get no commission for cross-sold players, reducing their incentive to send high-quality traffic to secondary brands. |
| Brand-specific commission, group-level deduplication | Each brand can have its own commission rates, but a player is recognized as the same entity across brands. CPA eligibility is determined at the group level — a player who has already triggered a CPA on any brand cannot trigger another. | Groups with strong brand differentiation but shared player identity. Common for casino + sportsbook combinations targeting the same market. | Requires shared player identity layer across brand databases. Complex to configure; most platforms require custom implementation. |
| Consolidated RevShare, split CPA | CPA is awarded brand-by-brand with explicit eligibility rules (typically first brand only, or different CPA per vertical). RevShare is calculated on consolidated group NGR — all the player’s activity across all brands rolled up into a single revenue base. | Hybrid and RevShare-heavy programs where long-term player value matters more than per-brand acquisition economics. | Consolidated NGR requires synchronized revenue reporting across brand backends. Deduction attribution (bonuses, chargebacks) must also be consolidated, which most platforms don’t do natively. |
The choice of model isn’t primarily a commercial decision — it’s primarily a technical decision. The commercially preferred model may be unimplementable on a given platform. Operators frequently choose a worse commercial model because it’s the only one their affiliate platform can actually enforce.
Operator decision point: Before choosing an attribution model, ask your affiliate platform vendor to demonstrate how it handles this specific scenario: Player X is referred by Affiliate A to Brand 1 in month one, triggers a CPA, then navigates directly to Brand 2 in month three and deposits. Show us the attribution record, the CPA eligibility check, and what the affiliate statement shows. The answer reveals more about the platform’s actual multi-brand architecture than any feature list.
Player Identity Resolution: The Problem Underneath the Attribution Problem
Cross-brand attribution doesn’t work without cross-brand player identity resolution. This sounds obvious. The implementation is not.
In most iGaming groups that have grown through acquisition or sequential brand launches, each brand has its own player database with its own ID scheme. Casino Brand A has player IDs issued by its casino platform. Sportsbook Brand B has player IDs issued by its sportsbook platform. These systems don’t talk to each other natively. A shared player identity — a group-level player ID that follows a human being across brands — has to be built or inferred.
There are three approaches operators use, each with different accuracy and infrastructure requirements.
Approach 1: Email-Based Identity Matching
The simplest identity resolution method: if a player registers on Brand B with the same email address they used on Brand A, they’re the same person. This works for players who use a consistent email. It misses players who use different email addresses per registration — deliberate behavior by bonus-hunters, but also incidental behavior by legitimate players who use work email for one brand and personal email for another.
Email-based matching is the baseline. It catches the obvious cases. The error rate on legitimate cross-brand activity is higher than most operators expect — typically 15–25% of genuine cross-brand players will not be resolved by email alone, based on what we see in migration data when operators consolidate player databases.
Approach 2: Device and Session Signal Matching
More sophisticated identity resolution uses device fingerprinting, browser session data, IP address history, and behavioral signals to infer that two registrations are probably the same person even when email doesn’t match. This is the same signal layer used for bonus abuse detection — and it’s worth noting that the two applications use the same underlying data differently. Fraud detection uses these signals to flag suspicious patterns; cross-brand identity resolution uses them to confirm legitimate ones.
Device-based matching substantially improves resolution rates but introduces false positives — shared devices (household members, office computers) can incorrectly merge distinct player identities. Any identity resolution layer needs a confidence threshold and a manual review pathway for ambiguous matches.
Approach 3: SSO and Shared Account Infrastructure
The cleanest solution: a single sign-on layer where a player’s group account spans all brands. One login, one player ID, explicit brand associations. When the player navigates from Brand A to Brand B, the system knows exactly who they are and what their attribution history is.
SSO requires infrastructure investment and is usually only viable for operators launching multiple brands simultaneously, or groups that have the development resource to retrofit it. For operators who have grown sequentially — casino first, sportsbook added two years later — retrofitting shared account infrastructure is significant work. But it’s the only approach that produces reliable attribution data without approximation.
The identity resolution method the operator uses determines what’s possible in attribution. An operator running email-only matching will have a residual attribution error rate regardless of how carefully the commission rules are configured. That error rate has a cost — it shows up as unexpected CPA duplication, unresolved RevShare disputes, and affiliate statements that don’t match operator-side revenue records.
Commission Deduplication: Where Multi-Brand Programs Hemorrhage Cost
CPA deduplication is the most financially consequential multi-brand attribution configuration, and the one most commonly absent or incorrectly implemented.
In a brand-isolated program, CPA deduplication isn’t a concern — each brand has its own affiliate program, its own commission pool, its own economics. A player who converts on both brands is two conversions in two separate systems. The operator may have intentionally accepted this as the cost of separate brand operations.
In a group-level program, the same behavior is typically a configuration error. The operator intends for a CPA to fire once per unique player per group. The platform fires a CPA for every qualifying event on every brand, because the deduplication rule was never set.
The financial exposure compounds quickly. Consider an affiliate sending 200 FTDs per month across a group’s two brands. Without deduplication, if even 15% of those players convert on both brands, the operator is paying 30 duplicate CPAs per month — commission on conversions they don’t actually owe. At €100 CPA, that’s €3,000 per month in unnecessary commission from one affiliate. Across a program with 50 active affiliates and meaningful cross-brand activity, the number becomes significant at a program level.
The correct configuration isn’t just “deduplicate CPAs at the group level” — it’s a set of explicit rules that the platform enforces at event ingestion:
| Deduplication Rule | What It Prevents | Configuration Requirement |
|---|---|---|
| Group-level CPA eligibility check | CPA firing on Brand B for a player who already triggered CPA on Brand A | Platform must query group-level player history before approving a CPA event, not just brand-level history |
| Cross-affiliate deduplication | Two different affiliates earning CPA for the same player when attribution is ambiguous across brands | First-touch or last-touch rule must be enforced at group level with explicit timestamp logic |
| Affiliate-specific cross-brand CPA caps | An affiliate earning unlimited CPAs across brands for a player pool that includes high cross-brand overlap | Per-affiliate cross-brand CPA cap configurable in commission plan settings |
| RevShare player-pool consolidation | Same player contributing to RevShare calculations in two separate brand accounts, creating artificially inflated commission bases | Consolidated NGR rollup at group level; player revenue attributed once to the referring affiliate across all brands |
Deduplication rules are only as reliable as the player identity resolution underneath them. A deduplication rule that checks “has this player already triggered a CPA?” is useless if the platform doesn’t know that player ID 4421 on Casino Brand A and player ID 8873 on Sportsbook Brand B are the same person.
Multi-Channel Attribution: When the Tracking Source Gets Complicated
Multi-channel attribution is a related but distinct problem. Where multi-brand attribution asks “which brand does this conversion belong to?”, multi-channel attribution asks “which touchpoint in a player’s acquisition journey gets credit for the conversion?”
In straightforward iGaming affiliate programs, this is simple: one affiliate link, one click, one registration, one CPA. The channel is the affiliate. The credit is unambiguous.
It gets complicated when a player interacts with more than one channel before converting. A player sees a display ad, clicks an affiliate review article three days later, then types the casino’s URL directly on day seven and registers. Three touchpoints. One conversion. The affiliate who owns the review article was the last affiliate touch — but they weren’t the first influence on the player’s decision.
iGaming affiliate programs overwhelmingly use last-touch attribution. The affiliate whose click is most recent before registration gets full commission credit. This is simple to implement, easy for affiliates to understand, and directionally wrong as a measure of actual acquisition influence.
Last-touch is wrong in two directions. It over-credits affiliates who operate bottom-of-funnel comparison sites and under-credits affiliates who drive initial awareness through content or social traffic. Over time, a last-touch program trains its affiliate ecosystem to optimize for late-funnel intercept — SEO content targeting “casino X review” and “casino X bonus code” — rather than genuine acquisition. The program’s affiliate base evolves toward affiliates who capture credit rather than affiliates who generate demand.
Attribution Model Options and Their Operator Trade-offs
| Attribution Model | How Commission Is Assigned | Operator Advantage | Operator Disadvantage | Platform Support Complexity |
|---|---|---|---|---|
| Last-touch | 100% to the final affiliate click before registration | Simple to explain; no affiliate disputes about credit splitting | Trains affiliates to intercept rather than generate; misrepresents actual acquisition economics | Low — standard implementation |
| First-touch | 100% to the first affiliate click in a defined lookback window | Rewards early-funnel affiliates; more stable attribution across long consideration periods | Disadvantages bottom-of-funnel affiliates; complex to communicate during affiliate recruitment | Low — requires lookback window configuration |
| Linear (equal split) | Commission divided equally across all affiliate touchpoints in the conversion path | Recognizes multi-affiliate journeys; reduces incentive gaming | Affiliates rarely accept reduced commission for shared conversions; complex contracts | Medium — requires multi-touch path tracking |
| Position-based | Fixed percentage to first touch and last touch, remainder distributed across mid-path touches | Rewards both demand generation and conversion capture | Requires sophisticated attribution logic; rarely implemented in iGaming programs | High — complex path weighting logic |
| Last-touch with lookback limit | Last-touch attribution, but only within a defined window (typically 30–90 days) | Prevents old traffic claims on organically returning players; common industry compromise | Still over-credits bottom-of-funnel but limits the worst cases | Low — standard with lookback window |
Most iGaming programs use last-touch with a 30 or 60-day lookback window. This is a reasonable operational compromise — simple enough that affiliates understand it, bounded enough that operators don’t pay commission on players who returned organically six months after the original referral.
The lookback window is where the real commercial negotiation happens. Affiliates want longer lookback windows — they want credit for players who take time to convert after discovering a brand through their content. Operators want shorter windows — they don’t want to pay acquisition commission on players who have already demonstrated they know the brand. A 30-day window is operator-favorable; a 90-day window is affiliate-favorable. Neither is wrong. Both need to be explicitly configured in the platform and enforced consistently.
Attribution window misconfiguration risk: The lookback window must be enforced at event ingestion time, not at report generation time. A platform that records the original click timestamp but only evaluates lookback eligibility when the monthly commission report runs will produce different results depending on when in the month the report is generated. We see this consistently in programs migrating from platforms that calculate attribution eligibility as a reporting filter rather than a tracking rule. The commissions have been running on an undefined window for months.
Promo Code Attribution: The Channel That Breaks Every Model
Promo codes are where multi-channel attribution models break in iGaming, and they break in a specific way.
A player finds an affiliate’s review article, doesn’t click the tracking link, but copies a promo code visible on the page and navigates directly to the casino. They register, enter the promo code, and deposit. From the affiliate platform’s perspective, there is no click record for this player — they arrived via direct navigation. From the operator’s perspective, the promo code they entered clearly identifies the affiliate source.
This is an untracked conversion in a click-based attribution system. The affiliate who provided the promo code on their page gets no commission. The player is attributed to no affiliate, or to a default “direct” bucket. The operator’s affiliate cost looks lower than it is — and the affiliate whose traffic actually drove the conversion is undercompensated.
Promo code attribution requires the affiliate platform to maintain a separate attribution path: the code itself carries affiliate identity, operates independently of click tracking, and triggers commission events without a corresponding click record. This sounds straightforward. The failure modes are numerous.
Promo codes can conflict with click-based attribution. If a player clicks Affiliate A’s link and then enters Affiliate B’s promo code during registration, two attribution signals are pointing at different affiliates. The platform needs an explicit priority rule: does click attribution override promo code attribution, or does promo code override click? This must be configured. Most platforms have a hard default — usually click wins — that operators never see until an affiliate dispute forces it into the open.
Promo codes also create a specific fraud vector when combined with multi-brand programs. An affiliate can issue a promo code for Brand A and generate CPA commissions on Brand B if the code is accepted cross-brand without explicit scope restrictions. The scope of a promo code — which brands it applies to, which commission plans it triggers, which deduplication rules it respects — has to be configured at creation time and enforced at redemption time.
Postback Architecture for Multi-Brand Programs
The tracking infrastructure underneath multi-brand attribution is worth examining directly, because this is where configuration errors actually live.
In a single-brand setup, the postback architecture is a direct pipe: casino platform fires a conversion event to the affiliate platform, which records it and calculates commission. One brand, one postback endpoint, one event type per conversion.
In a multi-brand setup, the architecture branches. Multiple casino platforms (or one platform with multiple brand configurations) need to send events to the same affiliate platform. Those events need to carry brand identifiers so the affiliate platform knows which brand generated the conversion. The affiliate platform needs to apply brand-specific commission rules, group-level deduplication checks, and consolidated revenue calculations — all in the right sequence, before the event is committed to the commission record.
| Postback Event Parameter | Single-Brand Requirement | Multi-Brand Additional Requirement | What Breaks Without It |
|---|---|---|---|
| Brand / advertiser identifier | Not required — implicit from the program | Required — must identify which brand fired this event | All events attributed to a default brand; cross-brand commission rules cannot be applied |
| Group-level player ID | Not required — brand player ID sufficient | Required for deduplication — must map to shared player identity | Same player triggers CPA on every brand without deduplication check |
| Cross-brand eligibility flag | Not required | Recommended — pre-checks whether this player has triggered eligible events on other brands | Platform must run synchronous deduplication query at event time; latency risk if not pre-computed |
| Revenue rollup scope | Brand-level by default | Must specify whether NGR should be calculated at brand level, group level, or both | RevShare calculations run on brand-isolated NGR; consolidated commission calculations require manual reconciliation |
| Deduction attribution scope | Single brand — all deductions belong to this brand’s account | Must specify whether deductions (bonuses, chargebacks) are brand-isolated or rolled into group NGR | Double-counting of deductions when consolidated NGR is attempted post-hoc |
Every parameter in the table above represents a decision that has to be made at platform configuration time. None of them have obvious correct defaults. Operators who deploy a multi-brand program without explicitly configuring each of these parameters are running their attribution on the platform’s guesses about what they wanted.
What Your Platform Has to Support for Multi-Brand Attribution to Work
Not all affiliate platforms are built for multi-brand operation. Some support it at a shallow level — multiple offer pages, a brand field in reporting — without the underlying attribution architecture that makes it accurate.
Multi-Brand Attribution: Platform Capability Checklist
| Capability | What It Means in Practice | What Fails Without It |
|---|---|---|
| Brand-level offer and commission plan separation | Each brand can have distinct commission structures, qualification rules, and affiliate relationships without contaminating other brands | Commission rules from Brand A bleed into Brand B; separate brand economics cannot be enforced |
| Group-level player identity layer | Platform maintains or accepts a shared player identifier that links activity across brands | Deduplication is impossible without a common identity reference; CPA over-attribution is unavoidable |
| Configurable CPA deduplication scope | Operator can specify whether CPA eligibility is checked at brand level, group level, or per a custom rule | Default behavior (usually brand-isolated) generates duplicate CPAs on group-wide programs |
| Consolidated NGR calculation option | RevShare can be calculated on consolidated player revenue across brands, not just brand-isolated revenue | RevShare programs either overpay (counting same player revenue twice) or require manual consolidation |
| Promo code scope enforcement | Promo codes can be scoped to specific brands, offers, and commission plans with cross-brand application rules | Promo codes accepted across brands create attribution conflicts and potential CPA fraud exposure |
| Attribution model configuration per affiliate | Different affiliates can operate under different attribution windows, touch models, and cross-brand rules within the same program | All affiliates operate under identical attribution rules regardless of their traffic type or contract terms |
| Brand-level reporting with group rollup | Operators can view performance per brand and per group simultaneously, without exporting and combining data manually | Group-level program economics are invisible; finance team reconciles manually from multiple report exports |
We, the team behind Scaleo, see the consequences of missing capabilities in this checklist every time an operator migrates to us from a platform that treated multi-brand as a reporting feature rather than an attribution architecture problem. The migration audit consistently reveals the same pattern: months of CPA over-attribution, RevShare calculations running on brand-isolated data when the contracts specified consolidated NGR, and promo code redemptions creating ghost conversions in affiliates’ dashboards that nobody can explain.
The audit is always uncomfortable. The operators who catch it early — before the affiliate relationships are strained and the commission disputes are filed — come out significantly better than the ones who discover it after a partner escalation forces a full payout review.
The Transparent Ecosystem Problem Multi-Brand Programs Expose
Multi-brand programs make the opacity problem in iGaming affiliate relationships worse, not better. In a single-brand program, an affiliate can at least model their expected earnings with reasonable confidence — one commission rate, one set of qualifying rules, one revenue base. A high-quality affiliate with consistent traffic can predict what they’ll earn within a reasonable range.
In a multi-brand program, the affiliate is often operating blind. They don’t know how many of their referred players have cross-brand activity. They don’t know whether the consolidated NGR calculation is including or excluding revenue from the sportsbook they didn’t actively promote. They don’t know whether their 90-day lookback window applies to the group or to each brand separately. When their commission statement doesn’t match their model, they have no way to audit it.
This is a structural problem, not just a reporting problem. The platforms that handle multi-brand attribution well are the ones that expose the attribution logic to affiliates in their dashboards — not just the final commission number, but the brand breakdown, the player-level activity, the deduplication events that reduced their CPA count, and the consolidated NGR calculation that produced their RevShare figure. Affiliates who can verify the calculation trust it. Affiliates who can’t verify it dispute it — or quietly reduce the traffic they send while they look for a program that’s easier to audit.
Until iGaming affiliate programs treat attribution transparency as a partner management requirement rather than a reporting nicety, multi-brand programs will continue to generate more commission disputes than single-brand programs, not fewer. The complexity is real. The transparency that would make it manageable is not yet standard infrastructure.
Configuring Multi-Brand Attribution: The Decision Sequence
When an operator is setting up multi-brand attribution — whether launching a second brand, migrating to a new platform, or auditing an existing multi-brand program — the configuration decisions follow a specific logical sequence. Getting these in the wrong order creates dependencies that require restarting earlier decisions.
| Step | Decision | Options | Downstream Effect |
|---|---|---|---|
| 1 | Player identity resolution method | Email matching / device fingerprint / SSO | Determines the accuracy ceiling of all subsequent deduplication and attribution rules |
| 2 | Attribution scope: brand-isolated or group-level | Separate programs per brand / unified group program | Determines whether cross-brand rules apply at all, or each brand operates independently |
| 3 | CPA deduplication rule | Brand-isolated / group-level first-touch / group-level with per-brand eligibility windows | Defines the financial exposure from cross-brand activity; must match contract language exactly |
| 4 | RevShare revenue base scope | Brand-isolated NGR / consolidated group NGR / hybrid (CPA brand-isolated, RevShare consolidated) | Determines the commission calculation basis; consolidated requires synchronized revenue reporting |
| 5 | Attribution model and lookback window | Last-touch / first-touch / position-based; 30/60/90-day window | Determines which affiliate gets credit in multi-touch journeys; must be enforced at event ingestion |
| 6 | Promo code attribution priority | Click overrides code / code overrides click / most-recent signal wins | Resolves conflicts between tracking link and promo code attribution signals |
| 7 | Affiliate reporting scope | Brand-level view only / group-level view / configurable per affiliate | Determines what affiliates can audit; directly affects commission dispute volume |
Step 1 is not optional. Every other decision in the sequence depends on the accuracy of player identity resolution. Operators who skip to step 3 without a reliable identity layer will configure deduplication rules that don’t actually deduplicate anything, because the platform can’t confirm that the player on Brand B is the same human as the player on Brand A.
Attribution Without an Identity Layer Is Theater
A multi-brand affiliate program that doesn’t have a reliable cross-brand player identity layer is running attribution rules on top of incomplete information. The deduplication checks, the consolidated RevShare calculations, the CPA eligibility queries — all of them are approximate. The commissions they produce are approximately correct, which means they’re wrong by an amount nobody can quantify until someone does the audit.
Scaleo’s multi-brand architecture supports group-level player identity, configurable CPA deduplication scope, consolidated NGR calculation, and brand-level reporting with group rollup — so operators can run the attribution model their contracts specify, not the one the platform defaults to.
Frequently Asked Questions: Cross-Brand Player Attribution
What is cross-brand player attribution in iGaming affiliate programs?
Cross-brand player attribution is the process of determining which affiliate gets commission credit when a player they referred generates activity across more than one brand or vertical in the same operator group. It requires resolving whether two registrations on different brands are the same human being, whether a CPA triggered on Brand A prevents another CPA on Brand B, and how RevShare is calculated when a player’s revenue spans multiple products. Most affiliate platforms handle this with undocumented defaults rather than configurable rules — operators typically discover the defaults when a commission dispute forces an audit.
How does CPA deduplication work in multi-brand iGaming programs?
CPA deduplication prevents the same player from triggering a Cost Per Acquisition commission event on multiple brands within the same operator group. The platform checks, at the point a CPA event fires, whether that player has already generated a CPA on any other brand in the group. If they have, the new CPA is suppressed or held for review depending on the configured rule. This check requires a group-level player identity layer — the platform must be able to confirm that the converting player on Brand B is the same person who previously triggered a CPA on Brand A. Without this identity layer, deduplication checks produce false negatives and CPA over-attribution occurs.
What is the difference between last-touch and first-touch attribution in iGaming?
Last-touch attribution assigns full commission credit to the affiliate whose click is most recent before a player registers. First-touch attribution assigns full commission credit to the affiliate whose click was first within a defined lookback window. Last-touch is the iGaming industry default — it’s simple to implement and easy for affiliates to understand. Its commercial weakness is that it rewards bottom-of-funnel interception over actual demand generation, training affiliate ecosystems to optimize for review and comparison content that captures credit rather than content that introduces players to brands. Most programs use last-touch with a defined lookback window of 30–90 days as a compromise between simplicity and operator protection against stale attribution claims.
Why do promo codes create attribution problems in multi-channel iGaming programs?
Promo codes create attribution problems when a player uses a code to register without clicking the affiliate’s tracking link. The affiliate platform has no click record for that player, so they appear as unattributed or direct traffic — even though the promo code clearly identifies the affiliate source. This requires the platform to maintain a separate attribution path for promo code redemptions, independent of click tracking. The conflict arises when a player both clicks a tracking link and enters a promo code — the platform needs an explicit rule for which signal takes priority. Without this rule, the platform applies a default (usually click wins) that may not match the affiliate contract, and disputes follow.
How should iGaming operators configure RevShare for multi-brand programs?
Operators running RevShare across multiple brands have two options: brand-isolated RevShare (each brand’s NGR is calculated separately, and the affiliate earns commission on each brand’s revenue independently) or consolidated RevShare (the player’s NGR is rolled up across all brands and the affiliate earns commission on the combined figure). Consolidated RevShare better reflects actual player value but requires synchronized revenue reporting across brand backends and a shared player identity layer. Brand-isolated RevShare is simpler to implement but can produce anomalies when players generate positive NGR on one brand and negative NGR on another in the same period — the negative carryover treatment differs depending on whether the accounts are consolidated or separate.
