Your In-Store Screens Can't Be Played. License HTML5 Games for the Phone in Front of Them.

Before you license HTML5 games for retail screens, settle one thing: most in-store signage has no input device, so the game has to run on the shopper's phone.

The pitch arrives fully formed. A grocery chain, a fashion group or a telecom retailer has a few thousand screens in stores, a retail media team that has been told to sell them, and a slide that says "interactive experiences". Somebody suggests games. The brief lands on a licensor's desk asking for a catalogue that can run "on our in-store network".

Almost none of those networks can run a game. Not because the content is wrong, but because the screen is a broadcast device: no touch, no keyboard, no pointer, mounted above reach, driven by a playlist that expects every item to have a fixed duration. A game is an input-driven, variable-length application. Those two things do not fit, and no amount of catalogue depth fixes it.

There is a version of this that works, and it is worth building. It just is not the version in the brief.

💸 The Budget Is Real. It Is Also Smaller Than the Deck Suggests.

In-store screens are a genuine growth line, and they are a rounding error inside retail media. eMarketer's forecast puts US in-store retail media ad spending at $1.06 billion in 2028 — 0.8% of all retail media spend. Growing fast, off a small base, against a retail media market that is overwhelmingly on-site and off-site digital.

That number should shape what you propose. A retail media team with 0.8% of the pot is not commissioning a bespoke game engine for the screen network. They are looking for content that fills slots, proves play, and gives a brand partner something to buy. If your proposal requires new hardware in every store, it dies at the capex line before anyone reviews the games.

👆 The Screen Has No Input Device

Walk a store and count the screens you could actually touch. Menu boards above the counter. Aisle-end promo panels at eye height behind a shelf. Window displays behind glass. Queue-line screens in a ceiling rail. Every one of them is out of reach, out of arm's length, or physically sealed off.

Touch-enabled signage exists, but it is a different purchase: a touch overlay or PCAP panel, a lower mounting height so the reach envelope works for seated and standing shoppers, a sturdier enclosure, and a cleaning regime that store operations has to agree to. It is a store-fit decision, not a content decision, and it is made years before anyone asks about games.

The second missing input is sound. Most in-store screens run muted, and where they do not, store audio is a licensed background music contract that nobody will let you interrupt. A large share of casual games lean on audio feedback for the moment-to-moment loop. Muted, they play like a slideshow with a score counter.

🧭 Attention Is Measured in Seconds. Games Need Minutes.

This is the part that kills the concept quietly, after the hardware objections are solved.

Quividi's audience-measurement benchmark, published in 2018 from more than 30 million anonymous observations across 96 screen networks, put average attention time at 4.6 seconds, with a spread from roughly 1.5 seconds to 27 seconds depending on venue and screen placement. Academic work using the same computer-vision approach has reported far lower figures in specific settings — a study in a clothing store measured average attention well under a second per passer-by.

Take the range seriously rather than picking the flattering end. Somewhere between under a second and about half a minute is what an unattended screen gets from a moving shopper. A casual HTML5 title needs 30 to 60 seconds to teach itself and one to three minutes for a satisfying session. You are asking for an order of magnitude more attention than the medium has ever measured.

The failure is not "low engagement". It is worse: a shopper starts a game, is interrupted by the queue moving, and abandons a screen showing a half-finished board to the next twelve people who walk past. Now your premium slot displays a dead state.

🖥️ The Browser on That Panel Was Chosen at the Factory

Suppose you get past all of it — touch panel, waiting area, real dwell. You still have to ship into a web runtime you did not pick and cannot upgrade.

Samsung publishes the web engine for every signage model year. Its own Tizen web engine specifications list Chromium M56 for 2018 panels, M94 for 2023, M108 for 2024, M120 for 2025 and M130 for 2026. The engine ships with the display. It is not a browser the estate can update; a 2018 panel still hanging in a store is a 2017-era Chromium build, permanently.

The picture is the same elsewhere. signageOS, which maintains device documentation across signage platforms, lists LG webOS 4.0 and 4.1 at Chromium 53 and webOS 6.0 at Chromium 79, and BrightSign firmware 8.0.x at Chromium 65 with later firmware reaching Chromium 87 and above. Commercial displays stay in service for seven to ten years. A national estate is therefore four or five different engines at once, and your catalogue has to run on the oldest one in the fleet, not the newest one in the demo room.

What actually breaks

• Modern JavaScript syntax. Optional chaining, nullish coalescing and newer language features parse fine on a 2025 panel and throw a syntax error on a 2018 one — a blank screen, not a degraded one.
• WebGL and WebGPU assumptions. Engine exports that assume a current WebGL2 baseline, and anything targeting WebGPU, have no path onto older signage silicon.
• Iframes. Embedding a hosted game portal into a signage app is an iframe in most CMS products, and any host sending a restrictive frame-ancestors or X-Frame-Options header simply refuses to render.
• Autoplay and audio policy. Gesture-gated audio behaves differently across a decade of Chromium releases, and there is no user gesture on a non-touch screen to unlock it with.

This is why licence scope should include the build format and a target baseline, not just the titles. "Runs in a modern browser" is not a specification you can hold anyone to.

⏱️ A Playlist Expects a Duration. A Game Does Not Have One.

Signage CMS platforms schedule content as slots with fixed durations, then report proof of play back to whoever bought the slot. That reporting is the commercial product — it is how a retail media team invoices a brand and how make-goods get calculated.

A game breaks every assumption in that model. It has no natural duration. You cannot preempt it at the ten-second mark without wrecking the experience, and you cannot let it run indefinitely without stealing inventory that has been sold to someone else. Whatever the CMS logs as "played", nobody can tell from it whether a human touched the screen or the panel sat idle on a title card for six hours.

If you take one operational rule from this post: an unattended screen in a sold ad loop is inventory, and inventory has to be schedulable. Games are not schedulable. Put them where nobody is selling the seconds.

📱 The Screen Nobody Budgeted For Is Already in the Shopper's Hand

The store already contains a device with touch, sound, a current browser, a network connection, an identity you can attach to a loyalty account, and a person whose attention it holds for minutes at a time. It is the phone. The signage screen's job is to be a poster that starts the session, not the thing that runs it.

Practically, that means the in-store screen carries a short loop and a QR code, and the game itself loads on the phone at a URL you control. This inverts every constraint above:

• Browser baseline. You target current mobile Safari and Chrome instead of the oldest panel in the estate. Standard HTML5 builds work as shipped.
• Dwell. The session leaves the store with the shopper. A 4.6-second glance becomes a three-minute play in the car park or on the bus.
• Inventory. The screen keeps its fixed-duration slot and its proof-of-play. Nothing about the ad loop changes.
• Measurement. A scan is a real, attributable event — per store, per screen, per hour — and everything after it is standard web analytics.
• Hygiene and accessibility. No shared touch surface, no reach-envelope problem, no store-ops negotiation.

Design the handoff properly. One code per screen or per store, so scans tell you which locations work. A landing page that starts the game in under three seconds on a mid-range Android over store Wi-Fi, because an impatient shopper standing in an aisle is the least forgiving audience there is. A reward that is redeemable in that store, that day — that is what converts play into a basket. And no app install between the code and the game; the install is where the funnel dies.

🕹️ Three In-Store Placements That Do Take a Game Directly

Not every store screen is a passing glance. Three placements have genuine dwell and a plausible input device, and they are worth separating from the general estate:

• Waiting areas with a captive queue. Telecom stores, service desks, pharmacy consultation waits, vehicle service departments. People are seated, waiting a measured number of minutes, and bored. A tablet or a low-mounted touch panel earns its place here.
• Staffed demonstration units. A pop-up, an endcap activation or a brand takeover with a person present. Staff reset the unit, hand it over and handle the data capture, which is the same operating model as a trade show booth game and should be briefed the same way.
• Family and kids' zones. Play corners in family retail, malls and larger stores, where the dwell is deliberate and long. This is also the placement with the strictest content rules: age-appropriate titles, no ad units, no data capture from children.

Everything else in the estate is a poster. Treat it as one.

🚫 Five Ways In-Store Game Budgets Get Wasted

• Buying touch hardware to justify the content. If the games budget is driving a store-fit programme, the business case is upside down. Start with placements that already have the input device.
• Licensing a catalogue for a screen network. Breadth is worth paying for when a player returns and browses. A shopper passing a panel plays one thing or nothing. Buy depth where there is a session, not where there is a glance.
• Specifying only titles, never the runtime. Agree the build format, the browser baseline and how the games are hosted before signing, or discover it on install day across four hundred stores.
• Counting plays as the outcome. Scans, session length, reward redemption and basket effect are the numbers a retail media team can sell. "Plays" is not one of them.
• Running it as a single burst. One two-week activation gives you no read on which store formats work. Run the same mechanic across formats for a quarter and let the scan data rank the placements.

📋 What to Specify When You License HTML5 Games for Retail

Licensing directly from a company that owns and develops its catalogue means the licence covers the things a retail deployment actually turns on. Forestry Games has operated since 2017 and licenses a catalogue of 1,049 titles across HTML5 and Android APK builds, with in-house HTML5 development for the cases where a stock title does not fit the placement.

For a store programme, ask for: HTML5 builds you can host yourself on the domain behind the QR code; APK builds where the placement is a managed Android tablet in a waiting area; source access where a title needs reskinning to a retailer's brand; and a written browser baseline so you know what the build assumes. A catalogue of that size matters less as raw breadth than as coverage — you can pick titles that load fast on mid-range phones, play in one hand, and finish inside a session a shopper will actually give you. Browse the HTML5 games catalogue or the full catalogue and shortlist against those three tests before you talk scope.

🧸 Licensing Branded Games for In-Store Campaigns

Retail activations often want recognisable characters rather than generic casual titles, particularly in family retail and kids' categories. 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.

Branded content carries its own approval process — what the game may say, where it may run, for how long and in which territories — so bring the campaign dates and the store list to the first conversation, not the third. If you want to see how the same content works as a campaign game, start there. Ask for a licence scope covering your store estate and campaign window, or request a demo portal to test the phone-side experience end to end.

✅ Where This Leaves the Brief

The in-store screen network is not a games platform and will not become one. It is a distribution channel for the first three seconds — a poster with a scan on it. The game belongs on the phone that scans the code, on a tablet in a waiting area where somebody is genuinely sitting still, or in a staffed activation where a person hands the device over.

That is a smaller-sounding proposal than "games on 3,000 screens", and it is the one that produces measurable sessions instead of dead boards. Rewrite the brief around the phone, pick a dozen titles that load in under three seconds on a mid-range Android, and pilot across three store formats before anyone orders hardware. When you are ready to price it, buy HTML5 games from a direct licensor and put the licence scope — hosting, branding, territories, campaign window — in writing at the start.