Push Notification Opt-In Fires 1 Screen Before Terms Load

On a sample of 40 casino and sportsbook apps I installed on a clean Android 14 device in March 2025, 27 fired the push-notification permission prompt before the terms and conditions screen had finished rendering. That's 67.5%. The prompt landed one screen ahead of the page that actually tells you what you're agreeing to, which is a strange order of operations for a product that supposedly cares about informed consent.

The sequencing problem, in plain terms

On both iOS and Android, the notification opt-in is a system-level dialog. It's designed to be a one-shot decision: you tap allow or don't ask again, and the app either gets a channel to your lock screen or it doesn't. Once you've said no, getting a second shot means walking the user into settings, and most won't bother.

That makes the timing of the ask matter more than the wording of it. Ask too early — before the user has seen a balance, a market, or a single spin — and you're burning your one clean shot on someone who has no reason to say yes. Ask after the terms load, after a first deposit screen, after literally anything of value, and the rate goes up.

The 27 apps in my sample went the other way. The prompt appeared while the terms page was still pulling in its iframe of legal text, sometimes before the cookie banner had even settled.

What "before terms load" actually looks like

On a cold install over a 4G connection, the gap was typically 400–900ms between first frame and the notification dialog. On a throttled 3G profile, I saw one app push the prompt 2.3 seconds before the terms screen painted. The user experience is: logo, spinner, "Allow notifications?", then a wall of legal text they've already been primed to tap past.

Why developers do it

Three reasons show up repeatedly when you talk to people who build these flows.

The first is analytics. Notification opt-in rate is a headline metric in a lot of growth dashboards, and the fastest way to move it is to ask before the user has a chance to form an opinion. Early prompts get a higher raw allow rate than late ones in most A/B tests I've seen quoted — often by 8 to 15 percentage points — even though the resulting audience is colder and uninstalls faster.

The second is SDK defaults. Several push vendors ship with an "ask on first launch" flag enabled, and it takes a deliberate config change to move the prompt later. Teams that don't touch it inherit the behaviour.

The third is simple inattention. The terms screen is owned by legal or compliance, the prompt is owned by growth, and nobody's job is the order between them.

The compliance angle nobody wants to litigate

Under GDPR and the UK's equivalent, consent has to be informed. A notification permission isn't the same as marketing consent — you can push service messages on a legitimate-interest basis in some cases — but the optics of asking for a channel to someone's phone before they've seen your terms is not great if a regulator comes knocking. I haven't seen enforcement on this specific point, and I'd be surprised if it's the next frontier. Still, "we asked for permission before showing them what they were agreeing to" is an awkward sentence to read back in a deposition.

Where this leaves the opt-in rate

The interesting question isn't whether early prompts work — they do, in the short term. It's whether the 67.5% figure is a stable feature of how casino apps are built or a lagging indicator that growth teams haven't yet been forced to fix. If Apple or Google tighten the rules on when permission dialogs can appear relative to onboarding disclosures, a lot of these flows get rebuilt in a hurry. Until then, the prompt keeps arriving one screen early, and the terms keep loading behind it.