Chrome Now Unsubscribes Your Quietest Players. Own the Re-Engagement Layer Before You License HTML5 Games.

Chrome now auto-revokes notification permission from low-engagement sites. Settle who owns the re-engagement layer before you license HTML5 games for a portal.

Every retention lever a games portal owns sits outside the game. The build is a black box you cannot patch, so the only things you control are the shell around it and the channel you use to bring a player back to that shell. For most operators that channel is push, and push got structurally harder on all three platforms inside eighteen months — once in Chrome, once in Safari, once in Android's permission model.

None of those changes were aimed at games portals. All three land hardest on them, because a games portal is exactly the shape of site the new rules are written to suppress: high notification volume, spiky engagement, a lot of one-visit traffic. Here is what actually changed and what you should settle with a licensor before you sign.

🔕 Chrome Started Unsubscribing Your Quietest Players in October

On 10 October 2025 the Chromium team announced that Chrome would begin automatically revoking notification permission from sites, on Android and desktop. The stated criteria are two conditions together: very low user engagement and a high volume of notifications being sent. The justification is a number worth sitting with — Google says less than 1% of all notifications receive any interaction from users.

Read the criteria as a pair, because that is how they are written. Sending a lot is not on its own disqualifying. Sending a lot to people who do not come back is. A portal that pushes a daily "new games added" blast to a subscriber list built from cold traffic is describing the exact profile.

Two details change what you should do about it. First, Chrome shows the user a message that they were unsubscribed due to low activity, and they can restore it through Safety Check — so this is recoverable, but not by you. Second, and this is the strategic one: the revocation does not apply to installed web apps. A player who added your portal to their home screen is exempt from the sweep. A player who merely clicked "Allow" on a prompt in a tab is not.

That single exemption reframes the whole retention plan. Install is no longer a nice-to-have conversion step ahead of push. On Chrome it is now the thing that protects the push permission you already earned.

📱 On iPhone, Push Needs an Install You Have to Ask For

iOS reached the same destination from the opposite direction, and got there first. The Push API has been available on iOS since 16.4 in March 2023, but only for web apps saved to the Home Screen. A site open in a Safari tab has no access to it. There is no prompt to optimise, no clever timing to test — the permission does not exist until the player installs.

Two changes since then are worth knowing. In March 2025, Safari 18.4 shipped Declarative Web Push, which lets a site request a subscription and display notifications without an installed service worker, using a window.pushManager API. WebKit's stated aims are lower battery and CPU cost and less room for misuse. Practically, it removes a chunk of engineering from the job — and it matters more than usual for a licensed catalogue, where the service worker is often the same piece of infrastructure fighting with third-party game assets over caching scope.

The second change is that installing got easier. WebKit's Jen Simmons confirmed that in iOS 26, every website added to the Home Screen opens as a web app by default, whether or not it ships a Web Application Manifest, with the user able to untick "Open as Web App" during the add flow. Previously the site's own metadata decided that. The gate is now the player's willingness to add, not your manifest.

One correction, because a lot of European operators are working from stale information: Apple announced it would drop Home Screen web apps in the EU with iOS 17.4, then reversed that decision on 1 March 2024, as reported at the time by TechCrunch and 9to5Mac. If your 2024 plan wrote off iOS web push for EU traffic, the premise no longer holds. Re-check it before you budget around it.

📉 Two Opt-In Numbers That Are Ten Times Apart

This is where operators build the wrong model, so treat the numbers carefully. The available benchmarks are vendor studies rather than independent research, and they disagree — but they disagree in a consistent direction, which is itself the useful finding.

• Web push, measured against unique site visitors. PushPushGo's 2025 figures put the average around 6%. Omnisend's analysis lands near 5% for e-commerce and 6–8% for media sites. Well-placed prompts are commonly reported in the 10–15% range.
• App push, measured against installs. Pushwoosh's benchmark study covering Q1–Q4 2024 reports an overall average near 61%, with iOS around 56% and Android higher.

The gap is not a measurement artefact you can optimise away. It is a different denominator and a different moment: an app install is a deliberate act by someone who already decided they want the thing, while a web push prompt interrupts a stranger who arrived from search. If your board deck models web push subscribers off an app benchmark, you are out by roughly an order of magnitude before you start.

Pushwoosh's vertical breakdown adds a specific warning for this business. It found iOS users of action and hypercasual game apps significantly less likely to allow push than the all-industries average, with Android users far more receptive. Games are not a favourable vertical for this channel. Plan for that rather than around it.

🤖 A Licensed APK Catalogue Burns One Prompt Per App

The Android side has its own trap, and it scales badly with catalogue size. Since Android 13 (API level 33), sending notifications requires the POST_NOTIFICATIONS runtime permission. For new installs on Android 13 and above, notifications are off by default.

The detail that catches licensees is what happens when an app targets API 32 or lower. Then the system decides when to show the dialog — typically on first launch, when the app creates its first notification channel — and you lose the ability to ask in context. Worse, if the user denies it even once, they will not be prompted again until the app is uninstalled and reinstalled, or updated to target Android 13 or higher.

Now apply that to a catalogue strategy. If you ship forty separate licensed titles as forty separate APKs, that is forty independent permission prompts, forty first-launch moments, and forty chances to spend a one-shot ask on a cold user thirty seconds after install. Each app is its own package with its own permission state. Nothing is shared. A single portal app wrapping the catalogue asks once, at a moment you choose, after the player has actually played something. That is a real argument for portal-over-fleet that has nothing to do with store listings.

🧱 The Licensed Build Emits Nothing You Can Trigger On

Here is the part specific to licensed content, and the part most re-engagement plans quietly assume away.

Good push is triggered by what the player did: they reached level 7 and stopped, they were two points off their best score, they have a run going. All of that lives inside the game. In a licensed catalogue the game is a third-party build served in an iframe or wrapped in an APK, and unless the licensor deliberately exposes an interface, nothing crosses that boundary. No score, no level, no game-over event, no session length. You cannot patch it in, because you do not own the source.

So your triggers are the ones your own shell can see, and you should write that list down before you promise anyone behavioural messaging:

• Shell-side and available to you: which game they clicked into, how long the page was open, favourites, search terms, category browsing, account state, and anything from a challenge or tournament you run around the games.
• Inside the build and not available by default: score, progress, level, completion, in-game currency, actual play time as distinct from tab-open time.

Some licensors do expose a lightweight event API — a postMessage bridge or a small SDK the build calls on start, game over and score. Some expose nothing. This is a normal thing to ask for and a cheap thing to check, and it is far easier to raise before signature than to retrofit across a thousand titles afterwards. Ask for it in writing, and ask which titles in the catalogue actually implement it, because coverage is rarely 100%.

🗓️ Your Shell Owns the Calendar. Build It There.

The workable answer is to stop trying to message from inside the games and build the reasons to return in the layer you control. A weekly tournament on a rotating title, a daily challenge scored by your own shell timer, a new-titles batch that lands on a fixed day, a seasonal collection — all of these generate legitimate, dated, non-repetitive notification content without needing a single event from the build.

Cadence is now a technical constraint, not a matter of taste. Chrome's revocation criteria combine high volume with low engagement, so an untargeted daily blast to a broad list is the fastest route to losing the permission entirely. Segment by whether someone has opened anything in the last thirty days, send the quiet segment less rather than more, and treat install as the conversion that protects the channel. If you are running a paid tier, the same calendar is what makes a subscription games portal renew.

🚫 Five Ways Re-Engagement Goes Wrong on a Licensed Catalogue

• Prompting on first pageview. You spend your one ask on a stranger who has not played anything yet, and on Chrome you then feed a low-engagement subscriber into a high-volume list — the precise revocation profile.
• Modelling web push off app benchmarks. A 60% opt-in assumption against a 5–6% reality does not miss the forecast, it invalidates the business case built on it.
• Shipping forty APKs and forty permission prompts. Each package burns its own one-shot ask, and on apps targeting API 32 or lower a single denial is effectively permanent.
• Promising behavioural triggers you have no events for. "We'll notify players who nearly beat their high score" is a commitment to data the licensed build never sends you.
• Treating iOS tab traffic as addressable. There is no iPhone push without a Home Screen install. If your iOS plan has no install prompt in it, it has no push in it either.

📋 Nine Questions to Ask Before You License HTML5 Games for a Portal You Intend to Re-Engage

1. Does the build emit any events to the parent page — start, game over, score, progress? Via postMessage, an SDK, or not at all?
2. How many titles in the catalogue actually implement that interface, by name?
3. Does the licence permit wrapping the catalogue in an installable web app and an Android package, or only embedding on a website?
4. Can the game files be served from our own domain, so an installed web app's scope covers them?
5. Are we permitted to use title names and screenshots in notification and lifecycle messaging?
6. For branded titles, does the brand's approval process cover marketing copy that names the character — including push copy?
7. If we ship a single portal APK rather than one app per title, does the licence price and permit that?
8. Who is responsible for a build that breaks under a browser update mid-term, and how fast?
9. What analytics, if any, does the licensor already collect from the build, and can we get it?

🎯 What You Get When You License HTML5 Games From a Direct Licensor

Licensing direct rather than through a feed or a marketplace mostly buys you answers to the questions above, from someone with the authority to give them. Forestry Games has operated since 2017 and licenses a catalogue of 1,049 titles spanning HTML5 and Android APK builds, with titles also published on Google Play and the Apple App Store. A licence conversation covers what you receive — HTML5 builds, APK builds, source where applicable, branding and hosting options — and it covers deployment shape, which is the part that decides whether an installable portal and a single permission prompt are even on the table. Because HTML5 and Android sit under one conversation, you do not have to run the web and app sides of this decision through two different suppliers with two different answers. You can license HTML5 games for the web shell and buy Android games for the packaged build against the same catalogue.

🧸 Licensing Branded Games for Portals, Apps and Campaigns

Branded content changes the re-engagement plan in one specific way: a recognisable character gives a notification a reason to be opened that a generic title does not, and it puts your message copy inside somebody else's approval process. Worth planning for, not a reason to avoid. Forestry Games works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros, and businesses can license branded game content through it for campaigns, portals, events and apps. If a branded title is part of your retention calendar, raise the messaging question during scoping rather than the week before launch. Browse the catalogue, ask for a licence scope for your deployment, or request a portal demo.

✅ Run the Trigger Inventory This Week

This does not need a project. Open your portal, pick your five most-played titles, and write down every signal your own stack can observe about a session in each one. Most operators find the list is shorter than their retention deck assumes, and that everything on it is shell-side — a click, a duration, a return visit. That list is your re-engagement product. Everything else is a request you need to put to a licensor.

Then do the two-minute platform check: is there an install prompt anywhere in your iOS flow, and does your Chrome list contain a large quiet segment you are still blasting daily? The first decides whether iPhone push exists for you at all. The second decides whether Chrome takes the channel away. If the answers point at a rebuild of the shell, settle the wrapping and event questions with your licensor first — those are cheap to agree before signature and expensive to renegotiate across a catalogue you have already deployed.