iGaming Revshare Attribution: How It Works Over Time

If your operation is paid on revshare, the deposit that matters most isn’t the first one — it’s the payout that keeps coming in months later, for as long as that player keeps betting. That’s the core of iGaming revshare attribution, and the problem is that this money has nothing to do with the Meta Ads attribution window, nor with a click_id that only survives until the first sign-up. This guide explains how to keep revshare revenue attribution working over time, not just on the day of the entry.

Why revshare breaks short-term attribution logic

Under affiliate CPA, the operator pays a fixed amount per FTD generated — the event happens, the payout is calculated, and the account closes there. Under revshare, the payment is a recurring share of that specific player’s GGR or NGR, with no end date: if they keep betting and depositing in February, March and April, the payout keeps coming in those months, tied to the same customer who came in through your campaign in January.

The iGaming media buyer metrics guide already covers the difference between CPA and revshare as payment models. What it doesn’t detail — and what decides whether you can measure revshare campaign by campaign — is how to tie each payout, month after month, back to the click that brought in that player, without that thread breaking along the way.

The Meta Ads attribution window isn’t built for this

The Meta Ads attribution window guide explains why an FTD can happen days after the click and still fall outside the configured window — by default, 7 days after the click or 1 day after the view. (The FTD isn’t lost because of that: Track4you sends every conversion that comes in through the postback to the pixel, with no time limit on its side, and it becomes signal for the algorithm — it just isn’t credited to the campaign in Ads Manager.) With revshare, the problem isn’t just bigger: it’s a different kind of problem. There’s no ad attribution window you can set in months, and even if there were, it wouldn’t make sense to use it — Meta Ads wasn’t built to optimize campaigns on revenue that arrives weeks or months after the click. Forcing revshare into that mechanism means asking a tool built for fast signal to answer for a signal that only reveals itself slowly.

That means that, for revshare, Ads Manager will never show a campaign’s real return — and it shouldn’t be expected to. The right question isn’t “why doesn’t Meta show this payout”, it’s “where does this attribution need to live, since it isn’t there”.

Where iGaming revshare attribution has to live: outside the window, inside the click_id

The answer is the same logic that already supports FTD tracking — just stretched over time. The click_id that identifies the original click has to survive not only until the sign-up at the operator, but stay tied to that customer indefinitely, for as long as they remain active. Registration, FTD and deposits usually come back via postback, one event per call, as detailed in the iGaming S2S postback guide. The revshare payout is something else: it’s usually calculated by the operator at the close of each period and shows up in the affiliate dashboard report, per player or per sub ID. It’s the identifier stored on the player’s account (the sub ID) that lets March’s payout still be added to the campaign that brought in that lead in January.

In practice, that takes three things working together over time, not just at the moment of entry:

1. The click_id (or the customer ID derived from it) has to be stored persistently — not just at sign-up, but for months, tied to that player’s record at the operator.
2. Each payout the operator calculates has to be added to that customer’s history, not treated as an isolated monthly number and forgotten afterward.
3. The campaign report has to accumulate that value over time, showing how much revshare a specific campaign has generated since its origin — not just what it generated on the day of the FTD.

Without these three points, revshare still arrives — the operator keeps paying — but it disappears from the reading of which campaign or creative was really worth scaling.

Why redeposits aren’t the same metric as accumulated revshare

It’s worth separating two numbers that look close but answer different questions. The iGaming redeposit tracking guide covers why a redeposit shouldn’t be sent to Meta as if it were a new acquisition — it’s a recurrence signal from a customer who already converted. Accumulated revshare goes one step further: it’s not just knowing that the player redeposited, it’s knowing how much revenue (GGR/NGR) that redeposit generated for the operator, and what share of it comes back to you through revshare, added up month after month, campaign by campaign.

A campaign can have few redeposits, but from high-value players, and still generate more accumulated revshare than a campaign with many more low-value redeposits. Looking only at the redeposit count, without accumulating the revshare value behind each one, hides exactly that difference.

Common mistakes

• Trying to use the Meta Ads attribution window as the reference for revshare: the window was made for short-term signal; revshare stretches over months and will never fit inside it.
• Sending each revshare payout to Meta through the Conversions API as a conversion: it only adds noise to an algorithm that optimizes better on fast signal (enter_channel, FTD) — revshare belongs in your own report, not competing for campaign optimization.
• Letting the click_id (or the customer ID) get lost after the first deposit: without that persistent thread, every future payout arrives with no way to be added to an originating campaign — and there’s no way to rebuild that link afterward.
• Comparing a CPA campaign with a revshare campaign on FTD alone: ignores that revshare’s return only really shows up weeks or months later, once the accumulated payout is added up.

How Track4you helps with this flow

Track4you covers the acquisition end of this equation. Through Integrations (Pro and Enterprise plans), the promo link creates a click_id per click and delivers the lead to the operator’s sign-up page with that value in the parameter the operator reads as the sub ID — that’s what gets stored on the player’s account. From there, registrations, FTDs and deposits (with amounts) come back via postback and reach the pixel as CompleteRegistration, FTD and Purchase, added up in the registrations, FTDs and deposits cards on the Dashboard — with no time limit on Track4you’s side: a deposit months after sign-up still reaches the pixel and becomes signal for the algorithm, even though it’s only credited to a campaign in Ads Manager if it falls inside Meta’s attribution window. The revshare payout itself is calculated by the operator and shows up in its affiliate dashboard report — that’s where the long-term reading happens, crossing the payout per player with the origin of each acquisition.

Frequently asked questions

Terms like GGR, NGR, click_id and postback have a quick definition in the glossary; the iGaming media buyer metrics guide explains the difference between CPA and revshare as payment models.

Conclusion

Revshare rewards whoever measures it right — but only those who can keep the click_id alive for months, adding each payout back to the originating campaign, really see which creative is still worth it after the first deposit. The Meta Ads attribution window doesn’t solve that, and it shouldn’t: it was built for a different kind of signal. iGaming revshare attribution has to live in a persistent report — the operator’s, crossed with the origin of each acquisition — outside any deadline Ads Manager imposes.