Problem
ChargedUp's order-at-table platform had a valuable second life beyond contactless ordering: it put a branded surface in front of drinkers at the exact moment they were choosing a drink. Red Bull, like Jägermeister before it, wanted an in-app activation that felt first-party, but with a playful twist: a drinker sees a Red Bull advert in the app, taps it, and plays a quick game for the chance to win a free Red Bull.
The commercial test was whether that playable moment would actually land: enough drinkers seeing the advert, playing the game, and redeeming a prize to make the activation worth Red Bull's spend, and to prove ChargedUp could run branded games on top of ordering.
Process
The engine built for Jägermeister already treated campaigns as data, so Red Bull reused that foundation. The new work was the game itself and the prize mechanic. The activation took about three weeks to build: mostly the game, the win logic, and the fulfilment of the free-drink reward.
- Campaign as configuration. The Red Bull branding (colours, logo, advert creative) and the game and prize rules were modelled as data, loaded into the app at boot rather than hard-coded.
- Playable advert. Tapping the in-app Red Bull advert launched a short game built to feel snappy on a phone, with the outcome decided server-side so the win rate stayed under control.
- Prize fulfilment. A win produced a redeemable free Red Bull, tracked so a drinker could claim their prize once and the brand could see redemptions.
- Usage tracking. Advert impressions, game plays, wins and redemptions all fed performance back to the brand team.
Outcome
The activation drew strong engagement: around 6,800 users activated it, roughly 14,000 games were played, and about 5,100 free Red Bulls were redeemed across participating venues. It gave Red Bull a genuinely playable brand moment inside the ordering flow, running alongside the Jägermeister campaign as a second live sponsor on one codebase, and proved ChargedUp could layer branded games on top of ordering as a repeatable revenue line.
"The game got people involved rather than just showing them a logo, and we could see exactly how it was landing."
Brand Activation Manager
Architecture
For engineersTechnical Deep DiveExpand
The sponsor-campaign model
Campaigns were stored as a CAMPAIGN#<id> partition in DynamoDB, carrying theme tokens, the advert creative, and the game and prize rules. At boot the app resolved the active campaign and themed itself accordingly. Because the campaign was configuration on top of the existing engine, the reusable parts came for free and the effort went into the game.
Server-decided outcomes
The win/lose result was decided server-side, not in the client. That kept the win rate controllable (Red Bull could cap prizes), made the game resistant to tampering, and let a win produce a single redeemable reward tied to the user. The client animated the result the server returned.
One prize per win, enforced server-side
A winning play created a REDEMPTION#<userId>#<campaignId> record with a conditional write, so a prize could be claimed exactly once even across reinstalls or retries. The client showed an optimistic "you won" state; the server remained the source of truth.
Trade-offs
- Flexibility vs guardrails. Config-driven theming is powerful but lets a bad config break the brand experience. We constrained the tokens to a safe palette and layout set rather than exposing arbitrary styling.
- Game scope. We kept the game deliberately simple to ship in three weeks and keep it snappy on low-end phones, rather than building something richer that would have delayed launch and risked performance on the devices drinkers actually use.