iGaming Redeposit Tracking: Why a Redeposit Isn't an FTD

If your operation has already closed the loop all the way to the FTD via postback, there’s a next mistake that’s easy to miss: treating a redeposit — a deposit from someone who already converted — as if it were the same event. That’s the gap iGaming redeposit tracking has to close. The difference looks small, but it distorts CPA, ROAS and your reading of which campaigns are really worth scaling. This guide shows why it happens and how to track each type of deposit separately.

What a redeposit is (and why it isn’t an FTD)

An FTD is a new customer’s first deposit — the event that marks the switch from lead to customer. A redeposit is any deposit after that first one: the same person putting money into the account again, days, weeks or months later. They’re two events with completely different meanings: one marks acquisition, the other marks retention of someone who was already acquired.

Most operators and affiliate platforms report both through a postback, as detailed in the iGaming S2S postback guide, usually with one postback setting per event (registration, FTD, deposit) in the affiliate dashboard. The problem isn’t the operator failing to report the difference — it’s the tracking on the other end receiving everything through the same URL, or under the same event name, and treating every postback call as the same thing.

The mistake of sending redeposits to Meta as acquisitions

When a redeposit is sent to Meta Ads as the same conversion event as the FTD, two distortions happen at once. The first is in the number: the total of “first conversions” reported gets artificially inflated, because part of it is people who were already customers, not new leads. The second is in optimization: the algorithm starts learning from an audience that mixes people converting now with people who converted before — and people who are already customers tend to behave very differently from those who haven’t converted even once.

In practice, the most common symptom usually isn’t a visibly exaggerated ROAS — it’s a campaign that converges too slowly, or scales toward the wrong audience, with no obvious cause in the report. The reason is subtle: Meta is being fed recurrence signal mixed with acquisition signal, and it has no way to separate the two on its own. The iGaming tracking mistakes guide covers this error briefly — here the focus is on fixing the cause, not just recognizing the symptom.

iGaming redeposit tracking: how to tell FTD and redeposit apart

Fixing this doesn’t require renegotiating anything with the operator — it already separates the events. The adjustment is in how each one is received and sent to Meta. In Track4you, the separation comes from the structure of Integrations itself:

1. One integration per event type: one for FTD and, if you want deposit amounts in the pixel, another of the Deposit type — each with its own postback URL, with event= already filled in.
2. Each URL on the right event at the operator: the FTD integration’s URL goes on the first-deposit postback; the Deposit one, on the deposits postback. Pasting the same URL on both is what mixes the events.
3. Different names in the pixel: Track4you sends both server-side through Meta’s Conversions API, but the FTD arrives as the custom event FTD and the Deposit arrives as Purchase, with the amount. The acquisition campaign optimizes for FTD, confirmed in Events Manager, and redeposits stay out of the “first conversions” count. If you don’t want any deposits in the pixel, just don’t create the Deposit integration — recurrence stays in the operator’s report.
4. Validate with a test case: make a test deposit through the promo link and check in the Integrations event history (the event type and pixel event columns) that it arrived as FTD; then make a second one and check that it arrived as Purchase, never as a second FTD. The history shows each lead’s most recent event, so check after each deposit.

Where redeposits really matter: revshare, LTV and recurrence

A redeposit shouldn’t feed acquisition optimization — but it’s far from disposable data. It’s exactly the number that decides whether a revshare payment model is worth more than CPA for a specific campaign: whoever is paid CPA has already been paid on the FTD, and redeposits don’t change that payout; whoever is paid revshare depends directly on the player’s recurrence to sustain the payout over time, because revshare is calculated on GGR or NGR — revenue that only exists if the player keeps depositing and betting after the first deposit.

That changes what’s worth watching depending on the campaign’s payment model. Under CPA, the KPI that decides whether to scale is FTD over CPL — redeposits are background information, useful for understanding audience quality, but they don’t move the payout. Under revshare, redeposits (and how often they happen) are the KPI that actually decides whether that campaign is still worth it months after acquisition — a creative with a higher CPL that brings players who redeposit often can beat a cheaper creative that brings players who deposit once and vanish.

Common mistakes

• Pasting the FTD postback URL on the operator’s deposit event too: every redeposit arrives as FTD and is counted as a new acquisition.
• Throwing redeposit data away entirely: even if it doesn’t go to Meta as an optimization event, it should still be recorded — it’s the data that supports campaign decisions in a revshare operation.
• Comparing campaigns only by FTD when the deal is revshare: ignores the number that really decides the payout over time.
• Not validating the separation with a real test: setting up the logic and assuming it works is the most common way to discover the mix-up only weeks later, when acquisition numbers don’t match what the operator reports.

How Track4you helps with this flow

In Track4you, FTD and deposit are separate integrations (Pro and Enterprise plans), each with its own postback URL: the FTD reaches the pixel as the custom event FTD, and deposits arrive as Purchase, with the amount — so the acquisition campaign optimizes for FTD without redeposits getting into that count. In the dashboard, the FTDs and deposits cards stay separate, and the event history shows each conversion’s type and the name it reached the pixel with. There’s no time limit on Track4you’s side: a redeposit that comes in through the postback months after the FTD still goes to the pixel as Purchase and becomes a value signal for the algorithm; whether it’s credited to any campaign in Ads Manager is decided by Meta’s attribution window (default: 7 days after the click or 1 day after the view) — which is why the campaign-by-campaign reading of recurrence doesn’t come from Ads Manager. Long-term recurrence per player, and the revshare it generates, are still worked out in the operator’s report.

Frequently asked questions

Terms like FTD, postback, GGR and NGR have a quick definition in the glossary; the CPA in iGaming glossary entry explains the difference between CPA and revshare in more depth.

Conclusion

FTD and redeposit are two events with opposite meanings — one marks acquisition, the other marks recurrence — even when they come in through the same postback route in most integrations. Mixing the two when sending data to Meta Ads inflates the number of reported conversions and feeds the algorithm a blended signal, without it ever showing up as an obvious error in the report. Separating them from the moment you set up the postback is what makes sure CPA is calculated on real acquisition and that redeposit data stays available to decide whether a revshare campaign is worth scaling.