TUNE is a well-built platform. It solves the problem it was designed to solve — performance marketing attribution at scale for ad networks and media buyers. iGaming affiliate management is a different problem, and the gaps show up in specific, expensive ways once an operator’s program reaches any meaningful complexity.
⚡ DIRECT ANSWER
TUNE (formerly HasOffers) is a general-purpose performance marketing platform built for ad networks and media buyers. It handles click attribution, conversion tracking, and partner management reliably across verticals. What it does not handle — and was never architected to handle — is the iGaming-specific event chain from registration through KYC to FTD and into ongoing NGR calculation, native RevShare with negative carryover logic, or casino-grade behavioral fraud scoring. Operators who build iGaming affiliate programs on TUNE work around these gaps with manual processes that fail at scale. This post maps where those gaps are, what migration looks like, and what operators report gaining on the other side.
Where TUNE Works — and Why Operators Land There in the First Place
TUNE is not a bad choice for every use case. It earned its market position. Understanding where it genuinely performs well is the starting point for an honest evaluation — because operators who switch to an iGaming-native platform for the wrong reasons end up running two platforms, not one better platform.
TUNE performs well for operators running mixed-vertical affiliate programs where iGaming is one channel among several. If your affiliate team is managing CPA campaigns across fintech, e-commerce, and casino simultaneously, TUNE’s generalist architecture is a genuine advantage — one platform, one reporting interface, one integration layer. The cost of that consolidation is iGaming-specific functionality that simply does not exist in a platform designed to be vertical-agnostic.
TUNE also performs well for media buyer programs — affiliates running paid search, programmatic, and native campaigns who need fast postback confirmation and clean CPA attribution. The platform’s core click-to-conversion tracking is solid. Postback delivery is reliable. The API is well-documented. For operators whose entire affiliate program is effectively a CPA-only media buying operation with no RevShare component, TUNE can serve the purpose without major operational pain.
The problems start when the program grows beyond CPA-only. The first RevShare affiliate, the first NGR-based commission plan, the first fraud investigation that requires player-level event data — these are the moments when TUNE’s architecture shows its limits in iGaming context.
Where TUNE Breaks for iGaming Operators: The Specific Gaps
1. No Native RevShare With Negative Carryover Logic
TUNE’s commission model is built around conversion events — a click leads to a qualifying action, the action triggers a commission, the commission is paid. This model maps cleanly onto CPA. It does not map onto RevShare, because RevShare is not event-based — it is balance-based.
An affiliate’s RevShare commission is a running calculation on a monthly NGR balance that can go positive or negative depending on player cohort performance.
Negative carryover — the mechanism by which a negative NGR month carries into the next period as a deficit the affiliate must earn back before receiving commission — does not exist as a native concept in TUNE. There is no NCO policy field. There is no per-affiliate balance that persists across billing periods. There is no automated reset logic for threshold-based NCO models.
Operators running RevShare deals on TUNE track negative balances in spreadsheets, calculate carryover manually, and adjust payout figures before each commission run. At ten affiliates this is manageable. At 100 it is a monthly reconciliation exercise that occupies a full-time staff member and produces no errors.
2. No Per-Player NGR Calculation
TUNE’s revenue model assumes a single revenue value pushed via postback at conversion time. The platform stores that value and uses it for commission calculation. For CPA programs, this is sufficient — the conversion is the FTD, and the commission is a fixed amount per qualifying event.
For RevShare programs, the revenue value is not fixed at conversion time. It accumulates over months. A player who deposits on day one may generate €50 NGR in month one, €200 NGR in month three, and a negative €800 NGR event in month six when they hit a jackpot.
TUNE has no mechanism to receive ongoing player-level revenue events, aggregate them into a per-affiliate NGR balance, apply deduction formulas, and calculate a commission on the result. Operators push a pre-calculated NGR figure to TUNE via postback at the end of each period — meaning the NGR calculation happens in their back-office or in a spreadsheet, not in the affiliate platform. The affiliate platform becomes a payment ledger, not a commission engine.
The practical consequence: when an affiliate disputes their commission, the operator cannot show them the underlying player-level data that produced the number.
They can show the postback value that was pushed to TUNE. The calculation that produced that value lives somewhere else, in a format that may or may not be auditable, maintained by someone who may or may not still work there.
3. Incomplete iGaming Event Schema
The iGaming player journey has a specific event chain: click → registration → KYC verification → first deposit → wager activity → withdrawal → ongoing deposit/wager cycles → NGR accumulation. Each event in this chain is a data point that affects commission calculation, fraud scoring, and player quality assessment.
TUNE’s event schema supports conversion events — a click leads to a qualifying event, the event is logged, the commission fires. It does not natively support the multi-event, multi-state player lifecycle that iGaming commission structures require.
Running a sportsbook that pays RevShare on settled NGR — where the revenue value of a bet is not known until settlement, which may be days after placement — requires an event schema that handles placement events, settlement events, void events, and amendment events as distinct postback types with defined relationships.
TUNE handles one event type per conversion. The multi-event requirement is a custom engineering problem for each operator who needs it.
4. No Casino-Grade Behavioral Fraud Scoring
TUNE has fraud detection tooling. It handles click fraud, duplicate conversion detection, and basic traffic quality filtering.
What it does not have is iGaming-specific behavioral fraud scoring — the analysis of player behavior patterns (registration-to-deposit timing, deposit-to-withdrawal velocity, device fingerprint clustering, session interaction entropy) that identifies bonus-abuse traffic and click farm registrations before a commission run pays out on fraudulent FTDs.
The fraud profile of a performance marketing click farm is different from the fraud profile of an iGaming bonus abuser. The first is caught by click deduplication and traffic quality filters.
The second looks like a legitimate player at the click and registration level — they complete KYC, make a qualifying deposit, satisfy the CPA trigger conditions — and only reveals themselves through downstream behavior: immediate withdrawal after bonus release, device overlap with other recently registered accounts, deposit-to-withdrawal timing that is statistically anomalous relative to genuine player behavior.
TUNE has no mechanism to score this downstream behavioral pattern and no native connection to the player-level event data required to do so.
⚠️ The cost of the workaround: Operators running iGaming RevShare programs on TUNE typically maintain a parallel spreadsheet system — NGR calculations, NCO balances, fraud flags — that is reconciled against TUNE’s commission records before each payment run. Based on Scaleo’s internal data from 2025, operators migrating from TUNE to Scaleo report spending an average of 22 staff-hours per month on manual reconciliation processes that became fully automated post-migration. That is not a TUNE criticism — it is a structural consequence of using a generalist platform for a specialist use case.
TUNE vs Scaleo: The Technical Comparison
We, the team behind Scaleo, built the platform specifically for iGaming operators. The architectural decisions that differentiate it from TUNE are not feature additions — they are foundational design choices that reflect the specific data model and commission logic that iGaming programs require.
| Capability | TUNE | Scaleo |
|---|---|---|
| RevShare commission model | Not native — requires pre-calculated NGR value pushed via postback; no running balance logic | Native — configurable deduction formulas applied at calculation time; per-affiliate NGR balance tracked across periods |
| Negative carryover (NCO) | No native support — manual spreadsheet tracking required | Native — per-affiliate NCO policy (full carry, monthly reset, threshold reset) configured at commission plan level, automated at period close |
| iGaming event schema | Single conversion event per click; multi-event lifecycle requires custom postback engineering | Native multi-event schema — registration, KYC, FTD, wager, settlement, withdrawal tracked as distinct event types with defined commission trigger conditions |
| Per-player NGR calculation | No — revenue value is a single postback field; player-level accumulation not supported | Yes — player-level event aggregation with configurable GGR-to-NGR deduction formula; commission calculated from live data, not pre-processed postback values |
| Behavioral fraud scoring | Click fraud and deduplication only; no player behavioral analysis | Native — registration velocity, device fingerprint clustering, deposit-to-withdrawal timing, session entropy scoring at the player level |
| Sub-affiliate / tiered networks | Basic sub-affiliate support; no native override commission plans at network tier level | Native — parent affiliate override plans and sub-affiliate individual plans calculated simultaneously from a single commission run |
| Postback retry logic | Standard postback delivery; retry behavior varies by configuration | Exponential backoff retry queue with full HTTP audit log visible to operator and affiliate; every delivery attempt logged with timestamp and response code |
| Affiliate-facing NGR transparency | Affiliates see commission values pushed via postback; no breakdown of deduction components | Itemized portal — GGR line, bonus deduction, processing fee deduction, net commission visible to affiliate per period |
| Multi-brand / multi-jurisdiction | Supported via separate accounts; no native cross-brand unified reporting | Native multi-brand architecture — per-brand tracking domains, commission plans, and reporting within a single operator account |
| Media buyer CPA tooling | Strong — TUNE’s core strength; extensive partner management and optimization tooling for paid traffic programs | Solid CPA support; less extensive optimization tooling for pure media buyer programs than TUNE |
The Architecture Difference That Explains Most of the Table
TUNE’s data model is event-centric: a click is recorded, a conversion event is received, a commission is triggered. The platform optimizes for the speed and reliability of that event chain. It is an excellent model for CPA programs where the commission logic is simple and the revenue value is known at conversion time.
Scaleo’s data model is player-centric: a click is attributed to a player, the player’s event history accumulates in the platform, and commission is calculated as a function of that accumulated history against the affiliate’s commission plan rules.
The platform stores GGR events, applies deduction formulas, maintains per-affiliate running balances, and calculates commission from live data rather than from pre-processed values. This architecture is more complex. It is also the only architecture that can natively support RevShare, NGR-based commission, NCO policies, and player-level fraud scoring without external calculation systems.
The postback structure reflects this difference directly. TUNE receives a postback carrying a revenue value that was calculated elsewhere. Scaleo receives postbacks carrying raw event data — GGR amount, bonus cost, player ID, event type — and calculates the commission-relevant values internally. An operator migrating from TUNE to Scaleo is not just changing which platform receives their postbacks. They are changing where the commission calculation happens and who is responsible for its accuracy.
Scaleo: Built for the iGaming Event Chain
Scaleo is a dedicated iGaming affiliate management platform. The distinction from a general-purpose tracker like TUNE is not a matter of feature count — it is a matter of data model design and the specific iGaming workflows the platform is built around.
The Multi-Event Postback Schema
Scaleo’s postback schema defines distinct event types for each stage of the iGaming player lifecycle.
Registration, KYC verification, first deposit, wager placement, bet settlement, and withdrawal each fire as separate, typed events carrying the parameters relevant to that event. Commission triggers are configured against specific event types — a CPA fires on a qualifying FTD event, a RevShare commission calculates from the accumulated GGR events across a billing period, a sportsbook settlement commission fires only when a bet settlement event confirms the final revenue value.
This schema means the platform always has the underlying event data. When an affiliate questions a commission figure, the operator can show them the specific GGR events, the deductions applied, and the net figure that produced the commission — at the player level, at the event level, auditable to the HTTP timestamp. That is not possible when the commission figure arrives as a single postback value calculated outside the platform.
Commission Plan Architecture
Scaleo’s commission plan builder treats the NGR formula as a configurable operator-owned asset, not a fixed platform parameter.
Bonus cost deduction rate, jackpot contribution percentage, payment processing fee, applicable levies — each is a defined field in the commission plan. Change the bonus cost structure and the updated formula propagates across all active commission plans using that deduction set at the next calculation cycle. No manual recalculation. No spreadsheet adjustment. No reconciliation call with the affiliate manager.
NCO policy is assigned at the commission plan level — per affiliate, not program-wide. A program running monthly reset NCO for its top SEO affiliates and full carryover for new partners runs both policies simultaneously from the same platform, with automated balance tracking and reset logic for each. The affiliate sees their NCO balance, the deduction applied, and the net commission in their portal statement. No black box.
Behavioral Anti-Fraud at the Player Level
Because Scaleo stores player-level event data — not just conversion events — the Anti-Fraud Logic™ engine has the raw material to score behavioral patterns that a conversion-event-only platform cannot access. Registration-to-FTD interval analysis, deposit-to-withdrawal timing relative to cohort baseline, device fingerprint entropy overlap with recently registered accounts, and session interaction scoring are all calculated from player event history stored within the platform. Fraud alerts fire before a commission run.
Operators set automated threshold-based blocks. Affiliates generating consistently high fraud scores are flagged for review before the first payout — not after six months of fraudulent FTDs have been paid.
Dashboard Performance
Scaleo’s affiliate-facing dashboard loads in under 1.4 seconds on average — approximately three times faster than legacy PHP-rendered tracker interfaces. For operators managing large affiliate portfolios, dashboard latency is not cosmetic. An affiliate who logs in and waits eight seconds for their NGR report to render is an affiliate who logs in less often, catches discrepancies later, and generates more support tickets. Speed is a retention mechanism built into the technical infrastructure.
Scaleo internal data, 2025: Operators who migrated from TUNE to Scaleo for RevShare-heavy programs report an average 41% reduction in affiliate commission disputes within the first six months post-migration — attributed to itemized NGR statements replacing single postback-derived commission figures. The same cohort reports a 67% reduction in fraudulent FTD payouts within 90 days of enabling behavioral fraud scoring, compared to their TUNE-era baseline using manual fraud review processes.
Benefits of Migration: What Operators Report Gaining
The gains operators report after migrating from TUNE to Scaleo fall into three categories. They are specific enough to be useful and honest enough to include the conditions under which they apply.
Operational Time Recovered from Manual Processes
The most immediate gain is the elimination of the parallel spreadsheet system. NGR calculation, NCO balance tracking, fraud flag management, and commission reconciliation — the processes operators run outside TUNE to compensate for its iGaming limitations — become automated functions inside Scaleo.
The affiliate team that was spending 20+ hours per month on pre-payment reconciliation spends those hours on affiliate relationship management and recruitment instead. This is not a hypothetical efficiency claim — it is a direct consequence of moving the commission calculation from an external spreadsheet into a platform that was built to perform it.
Affiliate Relationship Quality
Top-tier SEO affiliates — the RevShare partners who generate the highest long-term NGR — evaluate program credibility in part by the transparency of their commission statements. An affiliate who receives a single monthly figure with no breakdown is an affiliate who has to trust the operator’s calculation without being able to verify it.
An affiliate who receives an itemized statement — GGR line, deduction components, NCO balance movement, net commission — can verify the calculation themselves. The difference in affiliate trust and retention between these two experiences is measurable. Operators who switch from a pre-calculated postback model to an itemized native calculation model report that their RevShare affiliate churn decreases materially in the first year post-migration.
Fraud Detection Before Payout
Operators who implement behavioral fraud scoring post-migration consistently report the same pattern: the first fraud review after enabling SubID-level and player-level behavioral scoring identifies fraudulent traffic that had been paying out on their TUNE-era CPA program for months.
The fraud was not new. The detection capability was. The shift from reactive fraud identification — catching fraud after a commission has been paid and attempting a clawback — to proactive fraud blocking — flagging suspicious sources before the commission run — changes the financial dynamics of the fraud problem entirely.
The Migration Path: From TUNE to Scaleo
Migration from TUNE to a purpose-built iGaming platform is not a simple platform swap. It requires a structured sequence covering data portability, click ID continuity, affiliate re-credentialing, and postback transition. Operators who attempt it without a defined sequence experience attribution gaps that generate commission disputes and relationship damage with affiliates. Operators who follow the sequence below complete the migration without a detectable interruption in affiliate tracking.
Step 1: Data Export from TUNE
TUNE provides data export via its API and its reporting interface. Before any migration activity begins, export the following in full: affiliate account records (IDs, contact details, commission plan assignments), historical conversion records (click IDs, conversion timestamps, revenue values, affiliate attribution), and postback log data if accessible.
The completeness of this export determines whether historical performance data can be imported into the new platform or only used for reference. Request the export at least 30 days before planned cutover to allow time for data quality review.
TUNE’s export formats are primarily CSV and JSON via API. Scaleo’s import tooling accepts both. The field mapping — TUNE’s affiliate ID format to Scaleo’s affiliate account structure, TUNE’s conversion event schema to Scaleo’s multi-event schema — requires a mapping document prepared before import begins. Do not attempt a live data import without a field mapping review. A mismatched affiliate ID field in an import of 50,000 historical conversions produces attribution errors that take weeks to untangle.
Step 2: Click ID Remapping
Every affiliate in your TUNE program has tracking links containing TUNE’s click ID parameter format. Every publisher placement, review page, comparison table, and banner on the affiliate’s sites carries these links. When you switch postback endpoints to Scaleo, TUNE click IDs stop generating attributed conversions. If affiliates have not yet updated their links to Scaleo-format tracking links, conversions during the transition period are unattributed.
The solution is a postback continuity window: a defined period — minimum 30 days, ideally 60 — during which both TUNE and Scaleo are active simultaneously. TUNE continues receiving postbacks for traffic generated by old links. Scaleo receives postbacks for traffic generated by new links. Affiliates update their links during the continuity window. At the end of the window, old TUNE links are deprecated. The continuity window requires your casino backend to fire postbacks to two endpoints simultaneously — a one-line configuration change in most PAM systems, but one that must be tested before the window opens.
Step 3: Affiliate Re-Credentialing
Affiliates need new account credentials in Scaleo, new tracking links, and a communication explaining what is changing and why. This communication is an opportunity, not an obligation.
The migration to a platform with itemized NGR statements and transparent commission calculation is a program quality upgrade for your affiliates. Frame it that way. Send the communication four weeks before the continuity window opens. Include the new tracking link, the new portal URL, and a brief explanation of what they will now see in their commission statements that they did not see before.
Affiliates who do not update their links during the continuity window need a direct follow-up from your affiliate manager — not an automated reminder, a personal message.
High-value affiliates whose tracking links are embedded across hundreds of pages are not going to update them on the basis of a bulk email. Identify the ten affiliates whose link update is most critical to attribution continuity and handle those manually.
Step 4: Postback Schema Reconfiguration
The postback reconfiguration is the technical core of the migration. Your casino backend currently fires a single conversion postback to TUNE carrying a pre-calculated revenue value. Scaleo’s architecture requires raw event postbacks — separate events for registration, KYC, FTD, and wager activity, each carrying the parameters relevant to that event type. This is a back-office engineering task, not just a URL change. The postback schema reconfiguration should be developed, tested in a staging environment, and verified against Scaleo’s event log before the continuity window opens. A postback that fires with incorrect parameters — wrong player ID format, missing event type flag, revenue value in the wrong field — produces silent attribution errors that are difficult to identify and expensive to backfill.
Migration Timeline: Realistic Expectations
| Phase | Activity | Typical Duration |
|---|---|---|
| Preparation | TUNE data export, field mapping document, postback schema design, Scaleo account and commission plan configuration | 2–3 weeks |
| Parallel testing | Scaleo staging integration, postback verification against event log, test affiliate account validation | 1–2 weeks |
| Continuity window | Both platforms live; affiliates updating tracking links; dual-postback endpoint active on casino backend | 30–60 days |
| Cutover | TUNE postback endpoint deprecated; all active affiliates on Scaleo links; commission calculation verified for first cycle | 1 week |
| Post-migration validation | First commission run reconciliation; affiliate statement review; fraud scoring baseline establishment | 1 billing cycle |
Total migration timeline for a program with under 150 active affiliates: eight to fourteen weeks from preparation start to stable post-cutover operation. Larger programs — 300-plus active affiliates, multi-brand, multi-currency — should plan for sixteen to twenty weeks and allocate a dedicated migration resource on the affiliate team for the duration of the continuity window.
What TUNE Still Does Better: The Honest Assessment
An honest comparison does not pretend the migration is purely additive. There are specific capabilities where TUNE’s architecture produces better outcomes than an iGaming-native platform, and operators who depend on those capabilities need to factor them into the migration decision.
Media buyer optimization tooling. TUNE’s partner management infrastructure for high-volume paid media programs — traffic source management, campaign-level optimization, bid adjustment integrations, and network-facing reporting — is more mature than what iGaming-specific platforms offer. If your program is primarily a CPA operation with media buyers running Google, programmatic, and native at scale, TUNE’s tooling for that use case is genuinely better. The iGaming-native platforms are built around managing affiliate relationships, not optimizing paid media campaigns.
Multi-vertical network management. Operators running affiliate programs across multiple verticals — casino alongside fintech, e-commerce, or lead generation — benefit from TUNE’s vertical-agnostic architecture. A single platform managing attribution across all verticals is operationally simpler than a vertical-specific platform for casino alongside a separate solution for other channels. The cost of that simplicity is the iGaming-specific functionality gaps documented above. It is a genuine trade-off, not a clear win for either side.
Enterprise API depth. TUNE’s API surface area is extensive. Operators with in-house engineering teams who have built custom integrations against TUNE’s API — custom reporting dashboards, CRM connections, automated partner management workflows — are factoring in re-engineering cost when they evaluate a migration. That cost is real and should be calculated explicitly rather than treated as a negligible migration overhead.
Frequently Asked Questions
Can TUNE handle RevShare commission models for casino affiliates?
Not natively. TUNE’s commission model is built around conversion events — a click generates a qualifying event, the event triggers a fixed or percentage-based commission. RevShare in iGaming requires a running per-affiliate NGR balance that accumulates across a billing period, applies operator-defined deduction formulas, tracks negative carryover states, and resets or carries forward according to the NCO policy. None of these are native TUNE capabilities. Operators running RevShare on TUNE maintain the NGR balance and NCO logic in external systems, then push a pre-calculated commission value to TUNE for payment processing. The affiliate platform becomes a payment ledger rather than a commission engine.
What data can I export from TUNE before migrating?
TUNE provides affiliate account records, historical conversion data, and reporting data via CSV export and API. The export covers affiliate IDs, conversion timestamps, attributed revenue values, and campaign parameters. What it does not contain — because TUNE does not store it — is player-level event history beyond the conversion event, NGR calculation components (GGR, bonus costs, deductions), or NCO balance history if that was maintained externally. Plan your migration around the data that actually exists in TUNE’s export, not the data you wish existed. Historical NGR data maintained in your back-office or spreadsheet system can be imported separately into Scaleo’s historical records if it is in a mappable format.
How long does it take to migrate from TUNE to Scaleo?
Eight to fourteen weeks for programs with under 150 active affiliates, assuming a structured migration with a 30 to 60-day postback continuity window. The technical complexity of the migration is primarily in the postback schema reconfiguration — your casino backend needs to send raw event postbacks to Scaleo rather than pre-calculated conversion values — and in the affiliate link update process during the continuity window. Programs with 300-plus active affiliates, multiple brands, or multiple currencies should plan for sixteen to twenty weeks. The continuity window is the variable that most affects the timeline — longer windows give affiliates more time to update links and reduce attribution gap risk at cutover.
Will my affiliates need to change their tracking links when I migrate?
Yes. Every affiliate tracking link currently in use contains TUNE’s tracking domain and click ID parameter format. After migration, those links need to be replaced with Scaleo-format tracking links pointing to your new tracking domain. The continuity window — the period during which both TUNE and Scaleo are simultaneously active — gives affiliates time to update their links without a gap in attribution. Affiliates who have not updated by the end of the continuity window lose attribution continuity on traffic from old links after the TUNE endpoint is deprecated. High-value affiliates with large site footprints should be contacted directly by your affiliate manager to prioritize their link update during the window.
What is the main technical difference between TUNE and Scaleo for iGaming?
The fundamental difference is data model architecture. TUNE is event-centric: it receives a conversion event, records a revenue value, and triggers a commission. Scaleo is player-centric: it receives typed player events across the full iGaming lifecycle, aggregates them into per-player and per-affiliate NGR balances, applies configurable deduction formulas, and calculates commission from live accumulated data. This architectural difference is why TUNE cannot natively support RevShare with NCO logic, per-player NGR calculation, or player-level behavioral fraud scoring — these capabilities require a player-centric data model. The postback payload reflects this directly: TUNE receives a calculated value; Scaleo receives raw event data and performs the calculation internally.
The Workaround Stops Working When the Program Scales
Running iGaming RevShare on a general-purpose tracker works until it doesn’t — and the point at which it stops working is always the same: the moment the manual reconciliation overhead exceeds the capacity of the team managing it, or the moment a fraud event exposes the gap between what the platform can detect and what an iGaming-native platform would have caught three months earlier. Neither of those moments announces itself in advance.
See how Scaleo’s iGaming commission architecture handles the event chain, NGR calculation, and NCO logic that TUNE leaves to external processes — or explore the Anti-Fraud Logic™ that catches bonus-abuse patterns at the player behavioral level before the commission run.
