PWA Install Base in iGaming: The Asset That Outlives Your Ad Account

When a buyer counts a PWA, they count a funnel: click, install, registration, deposit. The bundle dies, and mentally everything dies with it. But the installs do not die with the ad account. The icon stays on the phone, the push subscription stays active, and that is the one link in the chain that keeps working after the campaign stops. The question is what it is attached to, because that turns out to decide everything.

What Actually Survives When the Bundle Dies

Your ad account, creative and pixel all live on someone else's infrastructure. They get taken without notice. An installed PWA sits on the user's device: Facebook cannot ban an icon on somebody's phone.

Along with the install you get a second thing almost nobody counts separately: permission to send push notifications. That is a channel to a real person that you no longer pay per click for. It does not depend on the auction, on moderation, or on what a deposit costs in that geo this week.

One honest caveat before the optimism runs away. The icon is out of reach, but the domain the app was installed from is not. It sits one redirect behind the ad, a moderator walking the ad will get to it, and it can be blocked like any other domain. What survives a dead ad account does not automatically survive a dead domain, and that distinction is the whole subject of the next section.

The Numbers

In an Argentina launch the funnel looked like this: 5,938 unique users, 2,938 installs (roughly 50%), 1,007 push subscriptions, 958 registrations, 130 first deposits. Spend $1,620, revenue $2,340, ROI 44%.

Now read the same numbers from a different angle. The campaign ended, the spend stopped, and 1,007 subscriptions remained. That is an audience the size of a third of all installs, reachable tomorrow, next week and next month without paying Facebook another cent.

The same line also shows the bottleneck. There were 2,938 installs and 1,007 subscriptions. Roughly two thirds of the base never became addressable, and not because the traffic was bad.

The Constraint Nobody Prices In: a PWA Is Bound to Its Origin

This is the technical fact the whole asset rests on, and it is the one most rarely stated out loud. A PWA belongs to the origin it was installed from. The manifest, the service worker, the icon on the home screen and the push subscription all live on that specific domain. There is no export, no migration, no transfer. A base cannot be moved to another domain under any circumstances.

Two consequences follow, and both are expensive.

Rotate the domain and you do not move the base, you start a second one from zero. Everything installed from the old domain stays on the old domain. If that old domain goes offline, every one of those installs breaks and every subscription attached to it goes silent, permanently.

And if the domain under a live base gets blocked rather than retired, the base is not damaged, it is gone. Not "harder to reach", not "partially recoverable". Gone.

That puts the domain under an install base in a genuinely awkward position. Domains in this vertical burn, and the usual answer is to treat them as consumables and refresh them. But the domain holding your base is not a consumable, because the base is the domain. Which means the real decision is not how often to rotate, it is how much history you are willing to accumulate on a domain you cannot afford to lose, and that is a trade-off worth making deliberately rather than discovering after the fact.

Why the Base Dies Before the Traffic Does

Three reasons, and none of them is about traffic quality.

Domain churn, per the section above. The most common way a base disappears is that somebody retires a burned domain without realising the audience was stored in it.

One PWA per run of traffic. If every bundle gets its own build, its own domain and its own pool of subscriptions, you do not end up with a base. You end up with a dozen fragments of 200 to 300 contacts each, none of which has the critical mass to be worth working with.

No reason to come back other than a bonus. A push saying "claim 100 free spins" on day three after install works once. After that it gets muted or ignored, and the channel burns out faster than the ad account did.

Where Push Permission Is Actually Lost

Here is the part that gets described wrong more often than anything else in PWA funnels, including by people selling the tooling.

You can only ask for notification permission while the person is on your own page. That is not a design choice, it is how the browser works. After the install, the user goes to the offer, and the offer is somebody else's site: you do not exist there. At the moment of registration, at the moment of the first deposit, you are not on screen, so nobody can ask for permission then. Any advice built on "ask after they register" describes something that cannot happen.

Which leaves exactly two moments that are yours. The first is the install itself, where the person has seen almost nothing and has the least reason to say yes. The second is a launch from the icon: the app opening is your origin again, and it is a far better moment, because a relaunch means the person came back on their own.

So the practical version is: do not spend your one shot at install time. Ask on a launch from the icon, and preferably not the first one, so the first launch stays instant and gets the user where they were going.

There is a cost attached, and it is worth naming. If your launch from the icon redirects straight to the offer without rendering a single byte of your own, then you have no screen on which to ask, and the second moment does not exist either. Bringing that screen back slows the launch slightly. That screen is the price of having a base at all, and in the Argentina numbers it is the difference between 1,007 addressable people and 2,938.

The direction here is well established: a permission prompt after some engagement converts considerably better than a cold one at first contact. We are deliberately not attaching percentages to that, because the honest answer is that it depends on your funnel and you should measure it on your own traffic rather than inherit someone else's number.

Where the Real Economics Hide

One market reference point: on Uzbekistan launches, install-to-registration holds at 10 to 12%, an install is realistically obtainable for a dollar, and players deposit repeatedly. At that entry price a base of several thousand installs costs a few thousand dollars once, and you can address it as many times as you like.

A second reference point shows how fragile that economy is. On the same offer, the same creatives and the same campaigns, switching the PWA service lifted iOS install-to-registration from 10% to 39%. Everything else was identical. Half your base may simply not exist because the technical platform underneath it performs worse than it looks in a demo.

Signals Your Install Base Is Working (or Is Not)

It is working if:

• you can state your push opt-in as a share of installs, and it is a number you have moved on purpose;
• you know how many deposits came from push, counted separately from deposits from the run of traffic;
• domains carrying a live base are treated as long-lived and never taken offline casually;
• a new bundle starts with an existing base rather than from zero.

It is not working if:

• your only push metric is "sent";
• the base is sliced up across bundles and never consolidated anywhere;
• nothing arrives from the base once the spend stops;
• you cannot say how many active subscriptions you have right now.

Summary

• A PWA gives you two things, and teams usually count only the first: the click-to-deposit funnel, which lives as long as the ad account does, and the install base with permission to contact it, which keeps working after the spend stops.
• The base is bound to the origin it was installed from. It cannot be moved, rotating the domain starts a new base rather than relocating the old one, and losing that domain destroys the base outright.
• Permission can only be requested on your own page, so the offer, the registration and the deposit are all moments where asking is impossible.
• The usable moment is a launch from the icon rather than the install, which means keeping a screen of your own at launch instead of redirecting straight through.
• Fragmenting one PWA per bundle produces fragments, not a base.
• If you cannot state the size of your base right now, you do not have one.

Our buyers asked for it, so we built it: a PWA constructor made for daily use, fast and simple, with nothing extra in the way. There is a promo running right now, free installs for the first two months. Get in touch while it lasts.