PWA split test on gambling traffic: why infrastructure determines the result

A PWA split test on gambling traffic compares two technical flows and shows how infrastructure affects conversion to deposit. It is used to separate the quality of the PWA, caching, sessions and push from the creative, offer and traffic buying. In real scenarios, account for weak internet, Android restrictions, proxies and clean test profiles, because these factors often eat into ROI before the first deposit.

This material does not describe Afina's own test and does not reproduce proprietary figures from another company. It is a generalized educational case from vertical practice for teams working with traffic arbitrage in Tier-3 geos, where unstable 3G quickly reveals the weak point in a setup.

The main idea is simple: if the creative, offer, pre-landing page and tracker are the same, the difference in profit often depends not on the banner but on how the PWA loads the webview, keeps the session after minimization, works with Service Worker and how cleanly proxies for advertising flows are separated. A creative can be changed in an evening, while the infrastructure either holds up over time or quietly breaks the deposit funnel.

What a split test of two PWA builders on the same offer shows

Such a split test shows whether the same setup really remains the same after the click. In the example, traffic was split 50/50 between two PWA builders on one gambling offer: Tier-3 geo, Android audience, identical creatives, pre-landing pages, tracker, budget cap and a 30-day period.

It is important not to turn the test into a brand comparison. The task is different: understand why two PWA flows with the same input can produce different Inst2Dep, Cost per FTD and ROI. Test hygiene should resemble a laboratory setup: separate campaigns, separate links, synchronized launch and identical attribution in the tracker.

In a normal setup, the team records not only spend and deposits. Technical events are also needed: install, first open, webview loaded, registration completed, deposit page opened, FTD.

1. fix the same offer, payout, geo, devices and time zone
2. split traffic 50/50 at the tracker or campaign level, not manually in the middle of the day
3. check install, open, registration and deposit events in test clicks
4. set the same frequency cap and the same audience exclusions
5. do not change creatives until the test window is complete

For teams that are only building the process, it is useful to keep a basic traffic arbitrage guide for beginners nearby, but this case focuses on what happens after install.

Which metrics show the real difference: Inst2Dep, Cost per FTD, ROI

The real difference is shown by post-install metrics, because CTR and install rate can look normal even when the deposit part of the funnel is already losing conversions. Inst2Dep shows the share of installs that ended with a first deposit. Cost per FTD shows the cost of acquiring one user with a first deposit, while ROI makes it possible to assess the final efficiency of traffic buying.

A table is more useful here than a long comment. CTR may be high because of a strong creative, but it does not see a white screen in the webview, session loss after minimization or a push notification that does not arrive because of Android background restrictions.

Imagine that both flows produced similar CTR and almost identical install rates. At the ad account level, the test looks even. But in one PWA, Inst2Dep drops, Cost per FTD rises and ROI turns negative. This is a signal that some users are being lost inside the PWA.

In practice, Inst2Dep is an indicator for the buyer of the health of the lower part of the funnel, where the advertising platform can no longer help. If Inst2Dep drops on weak networks or older Android devices, check caching, resource weight, session recovery and the order in which the casino loads in the webview.

Why a PWA shows a white screen on 3G and breaks conversion

A PWA shows a white screen on 3G when the application shell has opened but critical resources or the casino webview have not loaded yet. For the user, this is an empty screen that looks like a broken application.

In Tier-3 geos, the problem is more noticeable because of weaker devices, unstable networks and Android smartphones with aggressive memory saving. Service Worker helps if it caches the app shell, key styles, JS bundles, icons and a fallback page. But a poorly configured cache makes things worse: an old script version conflicts with a new one and the webview freezes.

Technical diagnostics should not begin with the assumption of "bad traffic". Start with the user's technical profile: network type, Android version, TTFB, time to first meaningful display, Service Worker errors and the amount of JS before the first render.

For weak internet connections, the PWA should be optimized and tested using the following scheme.

1. cache the app shell and a fallback screen that explains loading without false promises
2. separate critical JS and secondary scripts so the first screen does not wait for everything at once
3. check CDN and TTFB for the target geo, not only from your office Wi-Fi
4. log Service Worker errors and the webview loaded event separately
5. test 3G throttling, cold start and reopening after memory cleanup

Infrastructure tests often require residential proxies for arbitrage, because an office IP or data center will not show the real experience of a mobile audience in a specific geo.

This scheme is useful when analyzing logs: it immediately separates network latency from a problem in registration or the payment step.

How PWA application session stability affects deposits

PWA application session stability directly affects deposits because the user often switches between SMS, a messenger, a banking application and the PWA. If returning throws the user out of registration or the deposit page, part of the audience will leave.

A user may open the PWA, register, leave to get a confirmation code, return and see the start screen instead of the next step. On paper, the install exists. In reality, the intention to make a deposit is gone.

Technically, session storage, cookies, refresh token flow and webview state recovery should be checked. If the PWA keeps state only in memory, Android may terminate the process in the background. A short-lived token without renewal after returning causes a logout.

There is more than one solution here, but the checking order is simple.

1. open the PWA on a real Android device, not only in DevTools on a computer
2. start registration and minimize the application for 30 seconds, 2 minutes and 10 minutes
3. return through SMS, a messenger and a banking application
4. record whether the user remained at the same step
5. log session restored, session expired and forced reload as separate events

When these events are available in analytics, the team stops arguing blindly about "traffic quality". It becomes clear exactly where the session disappears.

Which gambling PWA push campaigns bring users back to deposit

Gambling PWA push campaigns work when they are tied to a specific unfinished step. The strongest triggers are usually placed after install without registration, after registration without a deposit and after opening the deposit page without payment.

Push should not fix a broken funnel. If the PWA freezes on 3G or loses the session after minimization, notifications will return the user to the same failure. Stability comes first, then reactivation.

A practical set of triggers may look like this:

• install without first open within 10 minutes
• first open without registration within 30 minutes
• registration without moving to the deposit page within 1 hour
• deposit page opened without FTD within 2 hours
• repeated open after push without a deposit to avoid excessive notification frequency

Android background restrictions must be taken into account honestly: Doze mode, battery restrictions, notification permission, vendor-specific battery savers. It is better to segment users by events, limit the frequency cap and check delivery rate separately from click rate.

For automation, an event-based scenario is appropriate: the tracker or CRM passes an event, the push system places the user in a segment, the notification is sent with a frequency limit and the result returns to analytics. If there is an open after the push but no deposit page opened, the problem may be in the landing screen.

Why infrastructure is more important than creative for Tier-3 gambling traffic geos

For Tier-3 gambling traffic geos, infrastructure is often more important than creative because technical losses accumulate after the click. The creative brings the user to install, but caching, session stability, push and other infrastructure elements directly affect subsequent conversion to FTD.

If two flows received the same creatives and the same offer, it is logical to look for the reason for the ROI difference in the infrastructure. On weak 3G, even a small webview delay hurts Inst2Dep. On Android, losing state after minimization knocks the user out of the deposit intent.

Another problem is the cleanliness of the test itself. If one team runs several flows from one browser, with the same cookies, mixed accounts, repeated IPs and no environment isolation, the split result can easily be contaminated. This is where separate browser profiles are useful: each test flow gets its own environment.

Afina is appropriate precisely at this stage, when the problem has already been formulated: the team needs to isolate flows, bind proxies to profiles, separate accounts and obtain clean comparison data without cross-contamination. This approach makes it possible to run controlled tests and maintain an independent context for each profile. The material is provided solely for informational and educational purposes.

When the split test is built this way, the team sees the cause rather than noise. One PWA may lose because of cache, while the other may lose because of session restore or push delivery problems.

Download