Tournaments: from a daily prize to a reason to play

Beeline Kazakhstan · My Beeline Games · Product Designer · 2022

Summary

Context

My Beeline Games, the game catalog inside Beeline Kazakhstan's super-app (~10M MAU). Product Designer in a small team; I owned tournaments from sprint to launch.

Problem

Players came for one daily prize mini-game, not for the games. Nothing else brought them back.

What I did

Ran the 4-day design sprint that picked tournaments over daily rewards
Put a compact tournament block on top of the catalog instead of a full-screen takeover
Tested the card over three rounds, mapped every state and gated the launch with design QA

Result

330K tournament MAU (28% of the audience), ~8-minute sessions against 2–4 in regular games, +1.6 pp paid-game conversion.

Situation

My Beeline Games was a flat list of games inside Beeline Kazakhstan's super-app, with no progression. When I joined in Dec 2021, almost all of its ~200K MAU came for one daily card-flip that paid out mobile data. Beeline wanted more time in the super-app (to cross-sell) and better retention. Time spent depends on retention, session length and frequency.

Goal: Two targets for the games: engagement (longer, more frequent sessions) and monetization (a larger share of paying users).

Action

Bet on tournaments, not daily rewards

Why. Ideas had piled up, from daily rewards to competitive mechanics. To force one bet I facilitated a 4-day design sprint with product, engineering, engagement and analytics. Daily rewards bring players back but only give away; tournaments hit both targets and earn, through paid entry and paid games.

Result. Tournaments won the sprint vote because each function saw its own upside: engineering a quick build (by its own estimate), PM and directors a monetization lever, design an easy fit in the UI.

A block on top of the catalog, not a takeover

Why. Tap-through to the catalog was already weak: nearly all of it went to the prize game. Full-screen takeovers pushed the games below the fold and tanked their tap-through, so I rejected them.

Result. A compact block on top: prize, countdown, one button. The games stay in view, one tap away.

The old Games screen: a plain list of seven games, each an icon and a name, with no tournament — Before: a flat list of games · Shipped: a block on top

Animation of the shipped catalog: the Tournaments block with Cross the road, 100 GB for 1st place, a countdown ticking down from 23h 52m 23s and one Participate button, and the We recommend and Games with prizes grids in view right below it — Before: a flat list of games · Shipped: a block on top

Three test rounds to a card people understood

Why. On the sprint's test day I tested the prototype with respondents I recruited. v1 read as "just a banner or an ad", with no clear next step, so I made it explicit and added a call-to-action button. v2 then put prize, time left, rank, info, leaderboard and CTA on one screen and overloaded it, so the leaderboard and details moved inside the tournament.

Result. v3, with one CTA, "100 GB for 1st place" and "23h 52m 23s left", was understood and shipped.

Animation of three catalog screens side by side, lit in turn: v1 a Tournaments carousel of art cards (Sumo, Gem) with no button or prize info; v2 a Gem Row hero with Grand Prize 100 GB, Time left 23h 59m 59s, Your Place 32/1000, a Tournament Finished button, a leaderboard button and an info button; v3 the shipped block with 100 GB for 1st place, 23h 52m 23s left and one Participate button

Map every state before build; sign off the build against it

Why. A tournament doesn't end in one session: the result arrives on the next visit. So every state had to be decided before build, down to hiding results from people who didn't play.

Result. I mapped every state, specced it pixel by pixel (Eightshapes Specs) and signed off the front-end build against the spec, one of the first design-QA gates on the product, then checked TestFlight builds myself before the Dec 2022 launch. The core mechanic stayed in place after launch.

Animation of the author's tournament flow as dark grey low-fi screens, one by one beside a list of them: Main with the tournament block (100 GB, Sumo) and your stats under it; a pop-up with what tournaments are, rules and prizes while the game loads; the game screen with Game Over, 532 points and a Leaderboard button; the leaderboard with prizes and you at 35th highlighted; and on the next visit a push that the tournament is over and a results pop-up: 5th place, 50 MB, Claim

Result

330K tournament MAU (28% of the platform's audience)
~8 min avg tournament session vs 2–4 min in regular games
10% Day-30 retention on featured games (industry casual-game avg ~1–3%)
+1.6 pp paid-game conversion after launch (≈3% → ≈4.6%)

Platform context, not attributed to tournaments: over ~2 years the platform grew from 200K to 1.3M MAU on super-app traffic and platform strategy.

What I'd do differently

Measure before launch. A/B testing wasn't reliable then, so before/after gave direction, not attribution. Next time: an event dictionary from day one (naming drifted without one), and harder questions to analysts on where each number comes from.
Check feasibility before crowning a priority. Rated quick in the sprint, the backend proved harder and the release slipped.

Assistant

Ask me about Tim

Tamirlan Askar

Lead Product Designer · 7+ years