Casino sub-affiliate tracking connects two relationships: the affiliate who brings in a player and the partner who recruited that affiliate. Getting the first relationship right determines player attribution. Getting the second right determines who earns an override, how much they receive and whether that payment comes from the operator’s margin or the affiliate’s commission.
The essential rule is to separate player attribution from partner recruitment. Store both relationships, define their effective dates and calculate commissions from an auditable ledger. A referral link alone cannot resolve ownership disputes, negative carryover or retrospective changes to a partner hierarchy.
The two relationships behind casino sub-affiliate tracking
A sub-affiliate is an affiliate recruited through another partner, often called a parent or master affiliate. The child affiliate acquires players, while the parent may receive an agreed commission for introducing or managing that affiliate.
A sub-ID is different. It usually identifies a campaign, placement or traffic segment within an affiliate’s activity. A tracking parameter such as sub_id=review-page does not, by itself, establish a separate partner or payment entitlement.
Keep these records distinct:
| Record | What it establishes | Example |
|---|---|---|
| Affiliate ID | The partner credited with player acquisition | Affiliate B |
| Parent relationship | The approved recruitment relationship | Affiliate A recruited Affiliate B |
| Campaign sub-ID | The placement or campaign producing traffic | A comparison page placement |
| Player attribution record | The eligible acquisition source assigned to an account | Player assigned to Affiliate B |
| Commission agreement | The rules determining each party’s earnings | B earns revenue share; A receives an override |
Do not infer the hierarchy from a URL parameter supplied by a visitor. Resolve it against an approved partner record and preserve the relationship applicable to the commission being calculated.
For an online casino, this separation also helps prevent a common reporting error: counting one player as two acquisitions because both the parent and child appear in revenue reports.
Define attribution before accepting traffic
Establish who owns the partner relationship
A parent referral should become payable only after the operator accepts the child affiliate and approves the relationship. The agreement should specify whether existing partners can be recruited, whether self-referrals are prohibited and how duplicate recruitment claims are resolved.
Record the parent ID, child ID, approval timestamp, effective date and applicable agreement version. Restrict hierarchy changes to authorized users and retain a change history.
A parent reassignment should not silently rewrite historical earnings. Define whether a transfer applies only to newly acquired players, to future activity from existing players or to another expressly agreed scope. Each approach has different financial consequences.
Start with one payable parent level unless the commercial case requires more. Multiple levels introduce additional allocation, disclosure and reconciliation requirements.
Establish who owns the player relationship
Choose an attribution model and document its boundaries. For example, an operator might use the last eligible affiliate click within a 30-day window before registration. That is an illustrative policy, not an industry-wide standard.
Your terms should explain:
- Which clicks qualify and how the attribution window is measured.
- Whether attribution locks at registration or another defined event.
- Whether existing players, duplicate accounts or reactivated accounts qualify.
- How affiliate links, promotional codes and competing marketing channels interact.
- Whether acquisition credit expires independently of the commission agreement.
A tracking cookie’s lifespan is not the same as commission duration. A player might register within a short attribution window while generating eligible revenue over a longer contractual period.
Reliable casino sub-affiliate tracking preserves the acquisition decision instead of recalculating it from whichever cookie happens to be present at deposit time.
Handle missing and conflicting signals explicitly
Capture a click identifier and resolve it to the account at the agreed attribution event. Once linked, subsequent financial events can use the account’s stored attribution rather than relying on another browser visit.
Cross-device attribution requires a supported, lawful identity connection. Server-to-server tracking does not automatically identify an anonymous visitor across devices, nor does it remove applicable consent or privacy obligations.
When a click and promotional code disagree, apply the published precedence rule. When neither provides valid attribution, send the record to an unattributed or review state. Do not manufacture a parent-child relationship to make reporting totals reconcile.
Make commission rules mathematically unambiguous
Define the revenue base first
Revenue share is only meaningful when the contract defines the revenue being shared. Specify the net gaming revenue, or NGR, calculation and identify every permitted deduction.
Depending on the agreement, deductions might include bonuses, gaming taxes, payment costs, chargebacks or other expressly listed items. These are not interchangeable, and there is no universal NGR formula that every casino uses.
The parent override also needs a defined base. Possible bases include the child’s approved revenue-share commission, qualifying NGR or a separately defined commission pool.
State whether CPA earnings, hybrid payments, manual bonuses and exceptional adjustments are included. An override on revenue-share earnings should not automatically apply to every amount payable to the child affiliate.
Distinguish percentages from percentage points
Consider an illustrative month with $100,000 in eligible NGR and a 30% child revenue-share rate. The following arrangements have very different costs:
| Arrangement | Child receives | Parent receives | Total operator commission |
|---|---|---|---|
| Parent gets 5% of the child’s commission, paid additionally | $30,000 | $1,500 | $31,500 |
| Parent gets an additional 5 percentage points of NGR | $30,000 | $5,000 | $35,000 |
| A 30% NGR pool is split into 25 points for the child and 5 for the parent | $25,000 | $5,000 | $30,000 |
In the first model, the calculation is $100,000 × 30% × 5% = $1,500. The operator’s combined commission cost is 31.5% of eligible NGR, not 35%.
In the shared-pool model, the child’s entitlement must be expressly agreed. Do not advertise a 30% child commission and then deduct an undisclosed parent share.
If you are still choosing the underlying payout model, compare CPA, revenue-share and hybrid commission economics before adding recruitment overrides.
Specify negative carryover and aggregation
Negative carryover needs separate treatment for the child’s balance and the parent’s override. Define whether losses carry forward, whether they offset other children’s earnings and whether any reset or exceptional-player policy applies.
Suppose one child generates $3,000 in eligible commission while another records a negative $1,200 balance. Under a 5% override calculated separately on each child’s positive eligible commission, the current override would be $150. Under an agreement that nets the two balances first, it would be $90.
Neither outcome follows automatically from the phrase “5% sub-affiliate commission.” The contract must specify the method and what happens to the negative balance afterward.
For casino sub-affiliate tracking, retain child-level balances even when the parent’s statement shows an aggregate total. Otherwise, losses and later recoveries become difficult to explain.
Build a commission ledger, not just a dashboard
Preserve the calculation inputs
A dashboard summarizes results. A ledger explains how those results were produced.
Each commission entry should identify the acquiring affiliate, eligible parent, attribution record, revenue period, calculation base, rate and agreement version. Include the source transaction or batch reference, currency, approval status and any adjustment reference.
Keep the acquisition event separate from eligibility and settlement. Registration, first deposit, qualifying activity, approved commission and completed payout are different events. A deposit may later be reversed or fail the conditions for a CPA award.
Version rules by effective date. Also define which date selects a version: player acquisition, financial activity or another contractual trigger. A rate change should not produce different historical results simply because a report was rerun.
Make events replayable without paying twice
Server-to-server events need authentication, validation and duplicate protection. Use stable event identifiers and idempotent processing so that retrying a deposit notification does not create a second commission.
Record event time separately from processing time. Late-arriving transactions should follow a documented cutoff and adjustment policy rather than disappearing from the calculation.
After settlement, correct errors through traceable adjustment entries referencing the original item. Avoid silently overwriting paid records. This allows finance to reconstruct both the original payment and the subsequent correction.
Separate earnings from payment execution
An earned commission is not necessarily an immediately payable balance. Distinguish pending, approved, held and paid amounts, with clear reasons for holds and a defined dispute process.
Payment thresholds should normally defer payment rather than erase earnings, subject to the contract and applicable law. Reconcile the payable balance to the payout instruction and the confirmed settlement record.
For multi-currency operations, specify the reporting currency, conversion source, valuation time, rounding method and responsibility for transfer fees. Crypto payouts also need an agreed asset and network, plus a defined conversion point when earnings are denominated in fiat.
Apply rounding at a documented stage. Repeatedly rounding player-level amounts can produce different totals from rounding a consolidated balance once.
Control hierarchy abuse without exposing player data
Parent-child structures create additional opportunities for self-referrals, related-party accounts, fabricated recruitment and attempts to move profitable accounts between agreements.
Verify partner identities and relevant ownership information, screen for prohibited relationships and require review for changes that affect payment entitlement. Shared contact details or payment destinations can justify investigation, but should not automatically establish fraud.
Before releasing a first parent payment, reconcile the approved hierarchy against the children generating the earnings. The operator’s pre-payout affiliate fraud checks can complement this hierarchy-specific review.
Access should follow role and purpose. A parent generally needs enough information to verify commission calculations, not player identity documents, full payment details or unrestricted behavioral records. Use aggregate or appropriately limited reporting, avoid personal data in tracking URLs and set retention periods around documented legal and operational needs.
Regulatory responsibility also remains relevant when traffic comes through another partner. In Great Britain, the UK Gambling Commission’s responsibility for third parties requirements place obligations on licensees concerning contracted third parties. Have counsel confirm how recruitment chains, advertising controls and partner oversight should operate in each target market.
Test the rules before the first settlement
Acceptance testing should prove that casino sub-affiliate tracking produces the contractual result, not merely that a click appears in a report.
Use a written test agreement with a known attribution model, hierarchy policy and commission formula. Then run controlled cases against expected ledger entries:
| Test case | Expected behavior |
|---|---|
| Two eligible affiliate clicks before registration | The configured attribution model selects one acquiring affiliate |
| An existing player follows a new partner link | No new acquisition credit unless an approved reactivation policy applies |
| The same qualifying deposit event arrives twice | One eligibility result and no duplicate commission |
| A parent relationship changes after acquisition | Historical and future earnings follow the agreed transfer policy |
| One child has positive earnings and another has a negative balance | The defined aggregation and carryover rules determine the override |
| A chargeback arrives after payout | A traceable adjustment follows the correction policy |
| A payout uses a different currency | The agreed exchange rate, fees and rounding reproduce the statement |
Reconcile three totals separately: eligible gaming revenue, affiliate commission expense and settled payments. They answer different questions and will not necessarily match within the same reporting period.
Also test what each partner can see. Correct financial calculations do not excuse a report that reveals another affiliate’s confidential rates or unnecessary player data.
Frequently asked questions
Is a sub-ID the same as a sub-affiliate? No. A sub-ID usually labels a campaign or placement. A sub-affiliate is a separate partner with an approved relationship and defined commission rights.
Does the parent receive commission directly from player deposits? Not necessarily. The parent’s entitlement might be based on approved child commissions, qualifying NGR or another contractual base. A deposit alone does not establish the amount owed.
Should parent commissions reduce the child affiliate’s earnings? Only when the agreement explicitly establishes a shared pool or deduction. An additional operator-funded override is a different commercial arrangement and should be calculated separately.
Can sub-affiliate commissions be paid automatically? They can be automated when the system supports the agreed rules and eligibility controls. Automation should still include duplicate protection, reconciliation, exception handling and a traceable approval process.
Validate the rules against your platform
Spinlab combines an affiliate and bonus engine, real-time analytics and open API integration within its modular iGaming platform. Those capabilities are relevant to implementing a partner program, but specific hierarchy and settlement behavior must be confirmed for the proposed configuration.
Discuss your attribution policy, parent override formula, carryover rules and reconciliation requirements with Spinlab. Use the test cases above as acceptance criteria before approving implementation or processing the first sub-affiliate payout.
