iGaming user acquisition is the controlled movement of eligible users from a paid source toward a value event the operator has defined in advance. An install, often the least informative event, confirms a download and says nothing about eligibility, registration, a deposit or a return visit.
This guide treats acquisition as an operating system rather than a media plan. It runs from event definitions and economics to testing, measurement, diagnosis and scale. Stages differ by product and market: a web-only sportsbook has no install, and verification can come before or after the first deposit. Treat the sequence as a template and adapt it.
What iGaming user acquisition means
iGaming user acquisition covers paid acquisition and partner-sourced activity that brings eligible new users into an operator’s product and moves them toward a defined commercial outcome, usually a first-time deposit and then repeat value. Once users are registered and depositing, retention, CRM and loyalty programs take over most of the work.
Acquisition quality combines eligibility, progression through the events that matter, a cost that fits the operator’s economics and repeat value from the cohort. A source that wins on volume and fails all four is expensive at any CPI.
| Included in acquisition | Adjacent: shared handoff | Owned elsewhere |
|---|---|---|
| Source selection and test design | Re-engaging non-depositors | Brand and channel strategy |
| Creative-to-destination continuity | Onboarding and verification UX | Retention, CRM, loyalty |
| Event definitions and optimization signals | Payment flow and deposit success | Fraud investigation |
| Allowable cost and scale decisions | Bonus and offer design | Licensing and legal review |
The wider channel, retention and brand plan belongs in an iGaming marketing strategy.
Define the funnel before choosing channels
Channel performance can only be read against a funnel agreed in advance. Before any spend, each stage needs a written definition, an owner, a source system, an expected reporting delay and the decision it supports. Without them, two teams can read the same campaign in opposite ways.

Figure 1. The iGaming acquisition funnel, from traffic to value. Dashed stages are conditional; filled dots mark the recording system.
The handoff from media tools to the backend is covered in our guide to mobile app attribution.
Map traffic and source to click, store or landing experience
In iGaming acquisition, the measurable funnel starts with the impression or click the media platform records. The user then reaches an app-store page, a landing page or a web sign-up form; many casino and sportsbook brands acquire on the web, with no store at all.
Two failures can happen before any registration exists. In a message mismatch, the ad promises an offer, game or market the destination does not show. In a broken redirect chain, tracking parameters are lost, so later events cannot be tied to the source. Both look like poor traffic.
Separate install, registration start and completed registration
An install answers a technical question: did the app reach the device? Registration answers a commercial one: did a person create a usable account?
If the product records both registration started and registration completed, use both. Healthy starts with few completions point to the form; few starts point to the audience or the promise. Check the trigger, too: an event fired on a screen view inflates the stage. In web journeys, the first destination session plays the part of the install.
Treat verification as a market- and product-dependent gate
Verification, often called KYC (know your customer), confirms identity and age, and sometimes location or payment ownership. Whether it is a funnel stage at all depends on the market and product. It may come before any deposit or after a first deposit within limits, and vendor results can arrive late.
A drop here has several readings: ineligible users (under age, out of area, duplicate accounts), a document request users are not ready for, or a result still pending in the backend. Each has a different owner, so the drop alone is no verdict on the traffic. The requirements come from the operator’s compliance team and the current rules for each market.
Define FTD or deposit success precisely
FTD, or first-time deposit, is the first successful funding of a user’s account. It is an initial monetary activation event. It shows that a source can produce users who pay; whether they return is a later question.
A deposit is initiated, authorized and confirmed, each step with its own timestamp. Decide which step counts, which system records it and how duplicates are removed when a user retries a failed payment. Apparent FTD delays often start here, with a late confirmation or a backend event sent in a later batch.
Review repeat behavior and contribution after cohort maturity
One deposit does not establish quality. What follows is whether the cohort deposits again, stays active as players and produces contribution: value left after the variable costs of serving those depositors. The operator fixes the measure and window in writing before sources are compared.
A cohort is mature when the chosen outcome has had time to show. Set three-day-old cohorts against thirty-day-old ones and the older source wins by default, so compare cohorts of equal age. D7 or D28? What Changes for Media Buyers explains how window length changes optimization.
Calculate an allowable acquisition cost
An allowable acquisition cost is the most an operator can pay for one acquisition outcome and still meet its own economic target. It comes from the operator’s numbers, not from a market benchmark.
Allowable acquisition cost = (expected contribution in a stated window × confidence factor) − attributable variable costs
This is an internal decision rule, and a published “average FTD CPA” cannot stand in for it: it describes someone else’s economics, measured with someone else’s definitions. Our guide to app user acquisition cost covers the wider method, including CPI and CPA denominators.
Define the economics inputs before using the formula
| Input | Definition | Typical source | Limitation |
|---|---|---|---|
| Expected contribution | Value per outcome within the payback window | Finance, backend cohorts | Early cohorts understate it |
| Payback window | Period to recover acquisition cost | Commercial plan | Longer windows add risk |
| Confidence factor | Discount for uncertainty, from 0 to 1 | Finance and analytics | A judgment; record why |
| Variable costs | Payment, servicing, bonus costs | Finance, payments, CRM | Bonus cost varies with uptake |
| Denominator | Registration, verified user or FTD | Event dictionary | Changes the answer |
The denominator matters most. In first-time depositor acquisition the allowance is set per FTD and applies to registrations only through the registration-to-FTD rate, which differs by source. Record each input, its source and the date it was set.
Use a worked example without turning it into a benchmark
| Expected contribution per FTD within the payback window: $120. Confidence factor: 70%. Attributable variable costs per FTD: $20.($120 × 0.70) − $20 = $84 − $20 = $64 allowable cost per FTD |
A 60% confidence factor cuts the allowance to $52; variable costs of $30 cut it to $54; both together leave $42, about a third below the base case. The denominator moves it further: if, again for illustration, 25% of a source’s registrations deposit, the allowance per registration is $16, and it must fall if that rate falls.
Choose channels by the signal they can use
Channels also differ in the feedback they can act on. A source that optimizes toward a deposit event behaves differently from one that only sees installs, even at the same CPI.
Google Ads, like many platforms, restricts gambling ads: it requires advertisers to apply for certification and serves those ads only in listed countries, under conditions that vary by market (Google Ads Help).
| Criterion | What to ask |
|---|---|
| Role | Reach, registrations, FTDs, re-engagement or learning? |
| Eligible reach | How much eligible traffic can it deliver: approved markets, legal age? |
| Optimization event | What is the deepest event the source can receive and use? |
| Diagnostic events | Which further events can it report? |
| Feedback latency | How soon does the optimization event reach it? |
| Creative fit | Which formats and claims does it accept? |
| Transparency | Are placements, apps or sub-sources reported? |
| Market constraints | Which policies, certifications or audience limits apply? |
Assign each source a role and evidence requirement
Every source test in iGaming acquisition should answer one question: can this source deliver eligible users at volume, or depositors within the allowance? A test that tries to answer both yields nothing actionable.
Record each source’s eligible market, primary event and known limitation. A source optimizing on registrations is judged on registrations first, then on FTD and repeat value once cohorts mature. That keeps it comparable with an FTD-optimized source, which delivers fewer, costlier events early on. Winning back registered non-depositors is a separate role, closer to retargeting than to new-user acquisition.
Run a controlled source or channel test
Source-test card: fix every field before launch
| Field | What to record |
|---|---|
| Question | The single decision the test informs |
| Market and eligibility | Approved geo, age gate, policy status |
| Audience and source | Targeting, placements, exclusions |
| Creative set | Version IDs and one hypothesis per asset |
| Event QA | Events fire, deduplicate and reach the MMP and source |
| Budget and guardrail | Spend cap and the downside limit that ends the test |
| Observation window | When early data is read |
| Maturity date | When the primary outcome can be judged |
| Decision rule | Which result leads to stop, continue or scale |
| Change log | Every edit during the test, dated |
Treat each source as its own test cell and change one major lever at a time where you can; otherwise a better FTD rate cannot be credited to anything.
Align creative, offer and destination
A strong click-through rate can sit alongside weak registrations and deposits. The usual cause is a broken promise: a bonus unavailable in the user’s market, a game the app does not feature or a match that has already kicked off.
Creative-to-funnel continuity checklist
- Claim and offer match the destination, in that market, on that day.
- Required disclosures, age notices and responsible-gambling messages appear where applicable.
- Localization covers the ad, the store or landing page and the sign-up flow.
- The registration path the ad implies is the one the user gets.
- Each asset has a version ID and one stated hypothesis.
- The operator has approved claims and bonus terms.
Asset production and testing sit with a performance creative team.
Apply geo and market gates before traffic is bought
An attractive audience does not make a market testable. Eligibility is the operator’s decision: licensing, legal review and responsible-gambling obligations stay with the operator and its advisers. Platform rules add a second layer: Apple requires real-money gaming apps to be licensed and geo-restricted where used, and free on the App Store (App Review Guidelines 5.3.4). Google Play requires an application, a license for each country or state of distribution and blocking of unlicensed areas (Play Console Help).
| Gate | Typically confirmed by |
|---|---|
| Operator license for the market | Operator legal |
| Eligible products and regions | Operator compliance |
| Platform and store policy, certification | Acquisition lead |
| Age and responsible-gambling notices | Compliance, creative |
| Payments and verification working | Product, payments |
| Localized ads and onboarding | Product, creative |
| Approved claims and bonus terms | Marketing, compliance |
| Gate owner and review date | Acquisition lead |
Requirements change by jurisdiction, so verify them from current primary sources before each launch. This gate is not legal advice.
Build the measurement and source-of-truth plan
Platform reports, the mobile measurement partner (MMP), product analytics and the backend all count the same funnel, and they rarely agree. Each applies its own rules and receives events at its own speed, so decide before launch which system answers which question.
| Question | Primary system | Watch for |
|---|---|---|
| Spend, impressions, clicks | Media platform | Self-attributed conversions |
| Install and source credit | MMP | Lookback windows; iOS privacy reports |
| Registration and onboarding | Product analytics or backend | Event triggers |
| Verification status | Backend or verification provider | Pending results |
| FTD and deposit success | Backend or payment records | Retries, reversals, timestamps |
| Repeat value and contribution | Backend, CRM, finance | Cohort maturity |
Reporting delays differ as well: AppsFlyer documents that attributions in its continuous reports usually appear within 15–30 minutes and in-app events within 30–60 minutes (AppsFlyer).
Apple’s AdAttributionKit sends postbacks to ad networks at least 24 to 48 hours after a conversion event (Apple Developer), while backend events follow the operator’s own schedule.
Attribution assigns credit by rule; it does not prove that media caused a deposit. Incrementality needs a holdout or another controlled test.
Create an event dictionary and acquisition event ladder
The event dictionary settles arguments about definitions. For each event, record business meaning, technical trigger, parameters, owner, source system, expected latency, deduplication rule and decision use.
Events play three roles. Optimization events steer a source’s bidding; diagnostic events show where the funnel breaks; commercial outcome events are what the business is judged on. The best optimization candidate is usually the deepest reliable event: the latest stage that fires often enough, and arrives fast enough, to trust. In first-time depositor acquisition, that may be the FTD itself or, when deposits are too sparse or slow, completed registration.
| Stage | Usual role | Latency | Decision use |
|---|---|---|---|
| Impression and click | Diagnostic | Near real time | Delivery, creative pull |
| Install or first session | Early optimization | Fast in MMP; slower in iOS privacy reports | Volume and cost by source |
| Registration completed | Optimization or diagnostic | Fast if sent server-side | Onboarding, audience fit |
| Verification, where applicable | Diagnostic | Variable; external checks | Source eligibility |
| FTD | Optimization or outcome | Variable; payment confirmation | Allowance, source ranking |
| Repeat deposit and contribution | Commercial outcome | Set by cohort window | Scale and budget |
Reconcile platform, MMP and backend data
- Align the basis: date range, time zone, currency, and event date versus install date.
- Compare definitions, so each system counts the same event with the same trigger.
- Check attribution windows. AppsFlyer treats a seven-day click lookback as standard, with one-day view-through by default (AppsFlyer); longer windows or self-attribution report more.
- Confirm receipt: no rejected, delayed or duplicated postbacks.
- Isolate a slice, such as one source, market and week.
- Document the residual gap, its likely cause and whether it changes the decision.
Do not average the systems. A blended number belongs to no system and cannot be checked later.
Use the diagnostic matrix
When a stage of the iGaming acquisition funnel underperforms, the instinct is to cut the source. But a weak stage shows where to look, not what went wrong, so the matrix gives several explanations per symptom.
| Stage | Symptom | Possible explanations | First checks |
|---|---|---|---|
| Delivery | Spend will not pace | Policy limits, small audience, rejected ads | Policy status, audience size |
| Click | Clicks without arrivals | Redirect break, slow page, click anomaly | Redirect chain, timing by placement |
| Install | Visits, few installs | Store page differs from ad | Store page vs creative |
| Registration | Installs, few sign-ups | Form friction, release bug, trigger error | Start-to-complete gap, release log |
| Verification | Sign-ups stall | Ineligible users, document friction, delay | Pending vs failed status |
| FTD | No deposits | Payment gaps, offer mismatch, failures | Failure codes, offer terms |
| Repeat value | One deposit only | Bonus-led users, young cohort | Cohort age, bonus uptake |
Diagnose media, destination, eligibility and data separately
Run the cheapest checks first.
- Confirm data integrity. A tracking fault looks like a traffic problem.
- Segment by source, placement, creative, geo and device. A problem everywhere points to the product or the data.
- Check the destination for releases, onboarding or landing-page changes.
- Check eligibility, payments and verification, which can cut conversion without any traffic change.
- Then investigate quality, once the first four checks are clear.
Cut a source, swap creative and ship an onboarding fix in one week, and the next week’s numbers explain nothing.
Treat suspicious traffic as a hypothesis to investigate
An anomaly is a reason to look, not proof of fraud. Measurement standards separate general invalid traffic, which routine filtering catches, from sophisticated invalid traffic, which needs deeper analysis (Media Rating Council). Add ordinary data errors, and most patterns have several causes.
| Signal | Possible explanations | First checks | Escalate when |
|---|---|---|---|
| Volume in few placements | Strong placement or poor supply | Funnel by placement | No downstream events |
| Odd click-to-install timing | Click injection or tracking setup | SDK setup | Persists after fixes |
| Clicks without arrivals | Broken redirect or click spam | Redirect logs | Gap persists for days |
| Registration collapse | Non-human installs or bug | Release log | Source-specific |
| Geo or device mismatch | Proxies, emulators or travel | IP vs declared geo | Clusters by source |
| Identical event patterns | Scripts or duplicate events | Timestamps, deduplication | Source-specific |
Detailed signals and disputes are covered in our research on fraudulent traffic in iGaming.

Scaling multiplies whatever is unresolved, from a tracking gap to an immature cohort. Spend should rise only with event integrity, cohort maturity, creative capacity, eligibility, quality monitoring, economic headroom and a decision owner in place.
Choose stop, diagnose, continue or scale

Figure 2. One next action per source. The first “no” decides.
| Action | Choose it when | Next step |
|---|---|---|
| Stop (stop rule) | A gate fails, the guardrail is hit or mature economics miss the allowance | End spend; record why |
| Diagnose (diagnostic hold) | Data or funnel evidence conflicts | Hold budget; run the diagnostic sequence |
| Continue (continue rule) | The test is valid, but the cohort or operations are not ready | Hold budget; recheck at maturity |
| Scale (scale gate) | Mature evidence, economics and operations support volume | Increase in steps; recheck the guardrail |
A failed gate overrides strong performance. Continue is not a softer scale; it means the evidence has not arrived.
Use a pre-scale checklist
Give each line a named owner and a review date.
| Check | Question |
|---|---|
| Eligibility | Is the market still approved? |
| Event QA | Are events firing and deduplicated? |
| Source of truth | Is system ownership agreed? |
| Maturity | Has the cohort reached its maturity date? |
| Economics | Is cost within the allowance, with headroom? |
| Source review | Are placements reviewed? |
| Creative | Are replacement assets approved? |
| Product and payments | Are onboarding and deposits stable? |
| Monitoring | Do anomaly checks cover added volume? |
| Downside limit | Which result stops the increase? |
| Approval | Who signs off, and when is the next review? |
What to do next
Start with the funnel: map the stages your product uses, find the weakest or least trustworthy one and choose one action for it: stop, diagnose, continue or scale.
Bring these to your next acquisition review
- Agreed funnel and event definitions
- A breakdown by source, campaign and creative
- Event timestamps and normal reporting delays
- Registration, verification, FTD and repeat-value cohorts
- Attribution settings and the approved source of truth
- Market-eligibility and platform-policy status
- Recent product, onboarding, payment or tracking changes
- Economics assumptions and the current downside guardrail
If your team wants an outside view of that evidence, ROCKAPP’s iGaming marketing and user acquisition team can review a funnel export with you. For support beyond iGaming-specific planning, see our managed mobile user acquisition service.





