You Can't Patch a Licensed Game. Every Retention Lever You Own Sits Outside the iframe.

When you license HTML5 games as a catalogue, you inherit finished builds you cannot patch — so every retention lever you own sits outside the game frame.

The live-ops playbook that mobile publishers spent a decade refining assumes one thing so basic nobody writes it down: you own the code. You can ship a Halloween skin, add a limited-time mode, change a drop rate on a Tuesday, and push a notification telling everyone about it. A portal running a licensed catalogue has none of that. The builds arrived finished. They will still be finished next December.

This gets discovered late, usually in month four, when someone asks why returning users are flat and the answer is that nothing on the site has changed since launch except the order of the tiles. Treating that as a licensing failure is the wrong diagnosis. It's a design problem about where your live layer sits — and it sits in the shell, in the wrapper, in the thing you actually control. That layer can be genuinely good. It just has to be planned before you sign, because parts of it are licence deliverables and not sprint tickets.

📉 The Curve You Are Actually Fighting

Start with what normal looks like. GameAnalytics published its 2026 Mobile & PC Gaming Benchmarks on 24 August 2026, and the global median for mobile games sits at roughly 22% D1 retention, just under 4% at D7, and 0.7–0.8% at D30. The top 1% of titles run 64–68% at D1, above 25% at D7, and 13–15% at D30. Median engagement is around 12 minutes of daily playtime across 3.8 sessions, with sessions of 3.1–3.5 minutes.

Two honest caveats before anyone puts those in a board pack. First, other 2026 benchmark write-ups circulating in the industry put median D1 closer to 26–27%; the samples and the definition of an active install differ, so take 22–27% as the range rather than picking the number that suits your slide. GameAnalytics also notes it left genre-level cuts out of this cycle while it reworks categorisation, so "casual D7" is not available from that report at all.

Second, and more important: those are app numbers. A web games portal has no install, no store listing, no home-screen icon, and no push permission granted at first launch. Portal operators who benchmark themselves against app retention curves are comparing against a different sport. What the numbers are good for is the shape of the problem — the gap between the median and the top 1% is roughly threefold at D1 and closer to twentyfold at D30, and almost all of that gap is built by things that happen after the first session.

🔌 The SDK Inside a Licensed Build Belongs to Somebody Else

Here is the technical reason shell-level live ops is harder than it sounds: look at what a licensed HTML5 build actually reports to the page hosting it. Poki's SDK, per its developer documentation, exposes five methods: gameLoadingFinished, gameplayStart, gameplayStop, commercialBreak and rewardedBreak. That is the whole contract. There is no score submission, no leaderboard call, no save-data API and no player identity in it. Every one of those methods exists to tell the platform when it is safe to run an ad.

CrazyGames documents a broader surface — ads, banners, a data module for key/value persistence, and a user module that authenticates players against CrazyGames accounts. That is more useful, and it is still not yours: the identity is the platform's identity and the saved state lives against the platform's account system.

So when a title is licensed to you, one of three things is true, and you need to know which before you plan anything:

• It ships with a platform SDK you don't operate. The hooks fire into a void, or into a stub the licensor swapped in. You get ad-break timing at best.
• It ships with the licensor's own wrapper. Then the question is what that wrapper emits and whether it is documented per title — ask for the event list, in writing, not a verbal "yes it supports scores".
• It ships bare. Common, and not a disaster, but it means the iframe is a black box: cross-origin, so you cannot read into it, and it will tell you nothing except that it loaded.

This is the single most consequential technical fact in the whole licence, and it appears in almost no deliverables schedule.

🧱 Live Ops Needs Three Ingredients. A Licence Hands You One and a Half.

Strip live ops down and it needs three things: content you can change on a schedule, per-player state you can read and write, and a channel to tell a player something changed. Score each against a licensed catalogue.

What you cannot have

• Changing what happens inside a game. No seasonal skins, no limited-time modes, no tuned difficulty. Unless your licence includes source and the right to modify — and the budget to actually do it, per title — this is closed.
• In-game progression state. A cross-origin iframe does not leak its internals. If the build doesn't post a message out, the state does not exist as far as your portal is concerned.
• A patch cadence you control. When a browser change breaks a title, the fix is the licensor's to ship, on their schedule.

What you do have

• Which games are visible, and when. This is the big one, and it is entirely yours.
• Everything around the frame — the page, the account, the currency, the copy, the collections, the tournament rules.
• Wrapper-level telemetry. You can measure that a player opened a game, and how long the frame stayed mounted before they navigated away. Coarse, but real, and it needs no cooperation from the build.
• The return channels, such as they are on the web. See below.

🗓️ Six Live-Ops Moves That Never Touch a Build

1. Stage the ingest. If you license a thousand titles and publish all of them in week one, you have converted your only renewable content supply into a single event. Hold back 60–70% and release on a schedule. This costs nothing, needs no engineering, and is the closest thing a licensed portal has to a content roadmap. Say it plainly in the launch plan or someone will bulk-import on day two out of tidiness.
2. Run a real "today" surface. Not a featured row that changes when someone remembers. A dated, cadenced slot — a game of the day, a weekly theme — that a returning player can check the way they check anything else. Median mobile sessions run three to four minutes; the entire job of this surface is to be answerable in under ten seconds.
3. Tournaments, if and only if you receive a score. Sensor Tower's live ops research reports that 90% of top puzzle games use standard tournaments — the mechanic works. It needs a number. Without score emission from the build, the honest substitutes are rank-by-plays-completed or rank-by-time-in-frame, both of which you can measure from the wrapper and both of which are gameable. Decide which titles can carry a leaderboard before you promise marketing a league.
4. Streak on the visit, not on the skill. A visit streak requires only an account and a date. It is the one retention mechanic that works identically across every title in a catalogue regardless of what the build supports, which makes it the highest ratio of effect to engineering available to a portal. Keep the penalty for a missed day soft; harsh streak resets push people out rather than back.
5. Seasonal collections. Cheap, effective, and gated on metadata: you need per-title theme and occasion tags, or you will be hand-picking a Halloween shelf out of a thousand rows at 11pm in October. That tagging is a licence deliverable, not a content project.
6. A meta-layer with its own currency. Points for playing anything, spent on something. The most powerful option and by far the most expensive — accounts, balances, fraud, support tickets, refunds when a balance disappears. Do not start here. Get 1 through 5 running first; if the "today" surface and the streak don't move returning sessions, a currency won't either.

A counterweight worth carrying into the planning meeting: Sensor Tower reports that 78% of the top 1,000 live-ops games declined in revenue between H1 2024 and H1 2025. Running events is not the same as running good ones. The useful bar is not "did the event get engagement" — it's whether retention after the event is at least where it was before it.

🔔 Web Push Is Not App Push, and the Gap Is Bigger Than You Think

Everything above assumes you can tell a player something happened. On mobile apps that is near-free. On the web it is a fraction of that, for two separate reasons. The structural one: on iOS and iPadOS you cannot even ask. As the WebKit team set out when the feature shipped in iOS 16.4, web push works only for web apps added to the Home Screen — the site must serve a manifest with display set to standalone or fullscreen, the user must go through Share → Add to Home Screen, and only then can a permission prompt be raised from a user gesture. For a games portal, that means a meaningful slice of your mobile audience is not a low-opt-in segment. It is an unaskable one.

The behavioural one: opt-in on the web is small even where you can ask. PushPushGo's 2025 benchmark — vendor data, so treat it as indicative rather than authoritative — reports an average opt-in of about 6% of unique visitors, a click-through of 0.84% on standard campaigns, and deliverability around 33%. Compose those and the arithmetic is unkind. Model web push as a channel that reaches low single-digit percentages of your audience, budget accordingly, and stop treating it as the retention plan.

What actually carries the return visit, in rough order of durability: the habit itself — which is what the "today" surface and the streak are buying — then an email address collected at account creation, then search and direct traffic, and only then push. Capture the email. It is unglamorous and it outlives every browser storage policy change.

📄 Put the Live-Ops Hooks in the Licence, Not the Backlog

Most of this section is procurement, which is why it belongs in the scope conversation rather than a sprint two quarters later. Name these in the deliverables schedule:

• Event emission, per title. Which builds post a score or a level-complete out to the parent frame, in what format, and a written list of which titles do not. "Most of them" is not a list.
• The right to self-host builds on your own domain. Same-origin is what turns an opaque iframe into something you can instrument. If the builds must stay on the licensor's domain, accept that your telemetry stops at the click.
• The right to modify the wrapper page — not the game, the page around it. Anything else makes your shell layer contractually awkward.
• Domain whitelisting and frame policy. Builds that check their host, or ship a restrictive frame-ancestors, will not run where you intend to put them. Confirm every surface: your portal, your app webview, a partner's site.
• Per-title metadata covering theme, occasion, orientation, control scheme and session length — the raw material for every collection and every scheduled surface you plan to run.
• Competitive and prize contexts. Some licences restrict tournament or prize-linked use. If a leaderboard with a reward is in the plan, get it in scope rather than discovering it after launch.
• Staged delivery and in-term additions. Whether new titles arrive during the term, and at what cadence, is literally your content calendar's fuel supply.

🚫 Five Ways Portals Waste the Live Layer They Do Own

• Bulk-ingesting the whole catalogue on day one, then having nothing new to announce for a year.
• Promising a tournament before checking whether any build emits a score. The demo is built, the marketing is booked, and then someone opens the iframe and finds nothing coming out of it.
• Rebuilding the homepage instead of scheduling it. A redesign is a one-off; a cadence is the product.
• Treating push as the plan, given single-digit opt-in and an entire mobile platform you cannot prompt at all.
• Measuring an event by engagement during the event. The number that matters is retention the week after, against the week before.

🎯 Where to License HTML5 Games When You Need a Release Calendar, Not a Bulk Drop

Forestry Games has licensed games since 2017 and holds a catalogue of 1,049 titles spanning HTML5 and Android APK builds, with titles also published on Google Play and the Apple App Store, alongside in-house HTML5 development. A licence conversation covers scope — territory, platforms, term, exclusivity — and delivery: HTML5 builds for embedding or self-hosting, APK builds where the use case is Android, source where applicable, branding, and hosting if you would rather not run the files yourself.

For a portal operator planning a live layer, the practical value of a direct licensor over a feed is that the questions above have answers you can get before signing: what a given title emits, whether you can host it yourself, what metadata comes with it, and whether the catalogue can be delivered in stages rather than one bulk drop. Depth matters here for a specific reason — a thousand titles released over eighteen months is a content calendar, while a thousand released on Tuesday is a launch. Work through the catalogue against the release schedule you intend to run, or start with the format questions at license HTML5 games and APK game licensing if your surfaces include both web and Android.

🧸 Licensing Branded Games for Campaigns, Portals and Events

Branded titles do something no shell-level mechanic can: they give you a scheduled event that people already recognise without you having to build the recognition. 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.

A branded licence is scoped more tightly than a generic catalogue licence — approvals, permitted surfaces and territories all narrow, and the approval calendar is real. That matters directly to anything time-boxed: if a branded title is meant to anchor a seasonal window, the scope conversation has to start well before the window, not in the month before it. If that is part of the plan, raise it at scope stage. Ask for a licence scope, or request a white-label game portal demo to see how a catalogue behaves inside a working front end.

🧭 The Thing to Check This Week

Open your portal's analytics and pull two numbers: how many titles were newly surfaced on the homepage in the last 30 days, and how many of your sessions came from a returning visitor. If the first number is zero, the second one is telling you about your acquisition spend and nothing else. There is no live layer to measure.

Then open one licensed game in your own portal with the console open, and watch what the iframe posts to the parent window. Whatever is in that log is the entire raw material available for tournaments, leaderboards and progression. For most catalogues it is empty — and the useful consequence of knowing that today is that you plan around visits and collections rather than around scores.

If you are scoping a catalogue rather than operating one, the leverage point is earlier than any of this: put event emission, self-hosting rights, per-title metadata and a staged delivery schedule into the licence discussion itself. Browse the catalogue and ask for a licence scope written around the release calendar you plan to run, not just the title count. The shell is where your retention lives — but half of what the shell can do is decided at signature.