How Gambling Conversions Work | Blog

We spend a lot of time digging into nutra and all kinds of crypto, but rarely talk about gambling — even though it’s the one feeding a huge chunk of the arbitrage community. Time to fix that: today I’ll break down, from a technical angle, how conversions in this vertical actually work under the hood, why a February deposit can end up sitting in January’s stats, and how to set up your tracker or platform for the job — anywhere from Lite to Pro.

The Classic Model: One Lead for the Whole Funnel

Broadly speaking, there are two approaches to tracking conversions. Trackers most often default to the first one — the classic model: one conversion gets one lead, and as the user moves through the funnel, that lead passes through different statuses.
The typical flow:

Registration. A lead is created with the status pending / new.
First deposit received. The lead moves to hold.
Deposit confirmed. The lead moves to approved.
User gets blocked, or the deposit’s cancelled. The lead moves to trash / cancelled.

Advantages:

No pile-up of extra entities. One user, one lead — not a scattering of records for every single action — so the leads table doesn’t bloat for no reason.
The user’s entire funnel lives in a single lead. Open one record and you’ve got the customer’s whole journey in front of you, from registration to approved or trashed, with no cross-checking scattered records against each other.
Easy to track status changes. The lead card in the tracker keeps a status-change log, so you can see right away what stage of the funnel the player’s at, and the exact moment an approve suddenly turned into a cancellation.
Simple data structure. Registration creates the lead, the deposit moves it through statuses — that’s it: no separate chains, no relations between records, so reporting and postbacks are easy to set up without extra hassle.

Drawbacks. The real problem shows up in verticals where a lot of time can pass between registration and deposit. The deposit conversion — the one that actually brings in money and moves the balance — gets logged under the lead’s creation date, i.e. the registration date. Nothing breaks exactly; it’s just that your monthly balances end up shifted.
Registration in January, FTD in February:

Your system books the extra balance to January, while the advertiser — and the real world — books it to February: the lead only has one date, its creation date, and the whole deposit lands on it.
Caps get tricky to calculate too: a cap relies on that same single lead date, not the day the deposit actually came in.
Your stats end up skewed across the board: past months keep growing retroactively, and you can no longer tell at a glance how much money actually came in this month.
Basically, it’s a pain: you constantly have to remember that this month’s numbers aren’t quite what they look like, and you end up explaining that to yourself, your team, and the advertiser.

If you’re running a full platform like AlterCPA Pro or Cloud instead of a bare tracker, this is partly solved. The platform can show several dates at once: when the lead came in, when it was sent to the CRM, when it was approved or cancelled, when it was bought out or returned. You can even calculate the cap off a timestamp of your choosing — lead arrival, sending to the advertiser, approval, or deal closure.
In a regular tracker, though — AlterCPA Red, One, or Lite — the lead has just one date: the arrival date, and it doesn’t change when the status does. That’s why verticals like gambling, where weeks can pass between a lead’s creation and its approval, call for a different approach.

The Goals Model: A Separate Chain for Every Conversion Type

So what do you do about gambling? Switch to the goals model! The idea is simple: a separate chain for every conversion type. The simplest example is registration and deposit.
When a user registers:

A lead is created.
The lead’s goal is reg, registration.
Status is pending or approved.

When that same user makes their FTD:

A new lead is created.
It gets a new external ID.
The lead’s goal is dep, deposit.
The lead’s date is the actual deposit date.

The whole trick is in that new external identifier. In the postback, that’s the uid parameter — say, uid=depXXX with the payment ID. Without a unique uid, a deposit on the same click won’t create a new lead — it’ll just update the registration lead, and hello again, classic model with shifted balances.
Advantages of this approach:

Conversions get counted more accurately. Each one lands on its own date: reg on the day of registration, dep on the day of the deposit — and past months stop growing retroactively.
Caps get calculated correctly. Deposits count against their real date, and a cap on a way can “eat” just the goal it’s set for: if it’s issued for deposits, only those count, and registrations are ignored.
You get an accurate picture of daily deposit inflow. The lead’s date matches the payment date, so your day-by-day stats show exactly how many deposits came in on a given day.
Statuses don’t go anywhere. Both registration and deposit come in as a lead with the status pending and move to approved once confirmed, and deposits still get the familiar hold status too.
Money is visible separately: there are dedicated columns for what’s sitting in hold and what’s already confirmed — I’ll show you how to turn those on in the practical part.

Revshare. Working on RS is exactly where you use this second approach: registration is its own lead, and every single payment is its own lead too, with its own date, amount, and status (this is where it’s handy to pass the payment ID in uid). That way you get the customer’s whole history right in front of you — every payment they’ve made, and the exact dynamics of their revenue.
Two postback parameters come in handy for tracking amounts — both of them cumulative:

addcost — adds the deposit amount to an already-existing lead: every new deposit gets added to the running total, whereas a regular cost would just overwrite the amount. Life hack: on every payment, add the deposit amount to that first lead with the reg goal, and keep the player’s full running total sitting right there.
addprice — adds income the same way, i.e. the payout on a lead. Comes in handy on revshare, where the payout from the same customer builds up gradually instead of arriving as one lump sum.

Grouping data by customer. When one player ends up with several leads — registration, deposits, and so on — it’s much more useful to group the data by the Customer ID the network passes you. The tracker has a dedicated field for it: the player’s ID comes in through the postback as the customer parameter. Group your stats by click, and you get one massive table across thousands of clicks, where only a small fraction of the rows actually have any data in them. Group by customer ID instead, and every row is a specific player: their registration, all their deposits, and all their stats in one place. The complete picture of how the user interacts with the system — right there at a glance.
Long story short, the goals model on its own already makes your own stats noticeably more accurate. And if the advertiser also shares payment amounts with you, you can keep an eye on traffic quality on your end and pull a ton of useful data for tuning your combo — and RS gets counted fair and square.

Setting It Up in Practice

Feeling inspired by all these ways of tracking conversions? Now it’s time to get it all done with your own paws, in the tracker or the platform.

First, the Lite Level

Head into the “Statistics” section and take a look at the nav bar. There’s a button with a circumpunct on it. Go google what a circumpunct is, marvel at your newfound knowledge, and click it — it’s the very last one there. That opens up the goal settings.
Registration with the code reg and deposit with the code dep are usually already sitting there — just tick the checkboxes to turn them on. The goal code is what the tracker will expect from you in the goal field of the postback; the name, on the other hand, is just for your own convenience — pick whatever you like, it’s purely cosmetic. Save it, and let’s move on.
Look for the button with two gear icons on the nav bar. You don’t need to google what gears are, do you? That opens up the column settings. It’s going to look scary in there — you’ve been warned.

Uncheck everything from CR through CPC — you won’t need any of it.
Check “CR” and “Total Leads” for the “Registration” goal.
For the “Deposit” goal, check: EPC, EPL, approval rate among all, total, hold, approved, and from the money metrics — total earnings, hold, paid.
If you’re tracking not just commissions but deposit amounts too, via cost — add the “Total Check” and “Average Check” checkboxes.

Save it, and enjoy your brand-new, gorgeous stats. Repeat the same thing in the “Analytics” section — except there’s no need to turn the goals on there, they’re already active by now. And if five goals somehow aren’t enough for you (remember, Lite has no ceiling), drop me a DM — I’ll tell you about the secret XTRACK_GOALS constant.

Leveling Up to Pro — Platform Settings

Yes, the platform can break stats down by goal too, but it’s about as gentle as a Chelyabinsk tough guy wiping with sandpaper instead of toilet paper.
First, a fork in the road. If you’re only working CPA offers, you don’t need to set up goals at all: registration creates the lead, and the deposit either confirms it or sends it to hold — basically, that same classic model. But if you’re mixing different payment models — say, CPA and revshare — always set registration and deposit up as separate goals, or the stats will display incorrectly. For that case, here’s the step-by-step:

Set up your offers on the platform with goals, after thoroughly chewing through this manual. When creating an offer, pick the “External” or “RevShare” template — it’ll add the goals on its own.
Head to “Management → Settings → References → Goal Stats Blocks” — that’s where you set up your goal groups.
Add the “Registration” goal and go into editing. Set the English name to Registration and the goal to reg — the offers need to use that exact same goal name. Visibility: everyone. Checkboxes: count and conversion.
Add the “Deposit” goal and go into editing again. Set the English name, and the goal to dep. If the offers call that same goal something else, those names go under “Aliases” — deposit, ftd, say. This one needs a few more checkboxes: counts for the “Total,” “Pending,” “Hold,” “Approved,” and “Cancelled” or “Trash” statuses. From the metrics — EPC and approval rate. Finance — all three: hold, payout, and total.
Go to “Management → Settings → Advanced,” and in the “Statistics Table Columns” block, move the metrics, counts, and lead amounts from “Enabled for Everyone” to “Available to Everyone, Hidden by Default.”

Voilà — gorgeous, goal-by-goal stats, even on the platform!
I humbly hope all of this made sense. And if it didn’t — no big deal. Welcome to the chat, we’ll hash it all out and chew the fat there: t.me/altercpatalk