Timeline Missions: Moving Retention Across Seven Games

Turning a manual workaround into a native multi-day retention primitive, across a 100M+ user gaming portfolio.

Role: Product Manager I, Audience Platform Company: Junglee Games (Flutter Entertainment) Duration: Apr – Sep 2023 Team: 1 PM (me), 4 engineers, client teams across Poker, Rummy, Howzat

The platform

Junglee Games ran seven titles — Junglee Rummy, Junglee Poker, Howzat (a fantasy-sports super app hosting multiple games), and a set of casual titles — each with its own product and marketing team, its own economy, and its own retention problems. Audience was the internal platform those teams ran their entire lifecycle stack on: segmentation, multi-channel communication, A/B testing, and gamification. It replaced CleverTap entirely, ran ~2,000 campaigns a month, and served ~120 internal users across marketing, product marketing, and product.

Critically for this story: my users were the game teams, and their users were the players. Every feature I shipped had to work as a configurable primitive across seven very different economies, not as a one-off for whichever team asked loudest. That constraint shaped both halves of this project.

Starting point: Adaptive Quests

Before this project there was one quest type, so ubiquitous it was just called "Quests." A player entered a mission and progressed to the next based on performance — completion-rate thresholds or finishing well under the allotted time — with only the current mission ever visible.

Adaptive Quests optimize for depth: they respond to how well a player is doing and adjust the next ask accordingly. What they don't do is impose a rhythm. A player having a good session could progress through several missions in one sitting, collect the rewards, and have no structural reason to return tomorrow. The Rummy Product Marketing Manager surfaced this: missions were producing engagement, not habit. Retention is a frequency problem, and a mechanic that gates on performance rather than time can't address frequency.

The workaround, which was also the POC

Rather than requesting a new quest type on a hypothesis, I built day-gating out of what the platform already had. The construction: one quest per day, so a seven-day campaign meant seven quests. To stop a player racing into tomorrow's quest today, I used dummy variables — one per possible concurrent mission — to hold an activity state, flipped by Mission Nudge events on entry and back on completion or expiry.

It worked, and it answered the expensive question — whether a time-gated rhythm actually changed return behavior — without spending engineering capacity to find out. It also cost something real: seven quests per campaign per game turned multi-day campaigns into assembly jobs; wiring the gate wrong on any one of seven quests could leak the gate or strand a player mid-arc; and dummy attributes stored per user across a 100M+ base meant real storage cost and read latency on a system already doing segmentation at scale.

What it still didn't solve was visibility. Because each day was a separate quest, the player saw only today's missions — never how many days the arc ran, what was coming, or what the terminal reward was. They were being asked to return daily without being shown what they were returning for.

The diagnosis

Day-gating without visibility is a return requirement — it forces a player back if they want the next reward, but gives no reason to form that intention in advance. Day-gating with visibility is a return commitment — a player who can see the full arc, and the Day 7 reward, decides on Day 1 whether it's worth committing to. The mechanic stops being a series of daily surprises and becomes a plan the player has opted into.

That's the behavioral bet: anticipation of a known future reward drives return behavior more reliably than discovery of an unknown one. The trade-off cuts both ways — a player who can evaluate the full arc can also decide it isn't worth seven days and opt out on Day 1, rather than discovering that on Day 4. You trade some entry volume for higher completion intent among those who enter.

What I built

Timeline Missions — a native quest type where a single quest spans X days. Player-facing, the full day-by-day arc is visible upfront, including upcoming missions and the terminal reward, with day-gating preserved natively. Operator-facing, it's one quest instead of X quests, with gating handled by the construct rather than dummy-variable wiring — removing the setup overhead, the error surface, and the per-user attribute bloat in one move.

The operator half is easy to under-sell and shouldn't be: multi-day campaigns had been technically possible and practically expensive, so teams ran them rarely and carefully. A retention primitive nobody has the patience to configure produces zero retention. Making a seven-day arc a single configuration changed how often the mechanic actually got used. Timeline Missions didn't replace Adaptive Quests — both stayed, because they solve different problems: Adaptive Quests optimize depth, Timeline Missions optimize frequency, and a platform serving seven economies needs both primitives available rather than one opinionated one.

The hard part: quest overlap and revenue leakage

Multiple quests ran concurrently across the platform, and a player active in one could simultaneously enter another — creating reward stacking, where a single qualifying action counted toward missions in multiple active quests, and the platform paid out multiple rewards for one unit of player behavior. In a real-money gaming economy that isn't a cosmetic bug: every reward is a faucet into the economy, and uncontrolled faucets are direct revenue leakage.

The fix reused the same attribute mechanism the day-gating workaround was built on: quest-level activity attributes, driven by Mission Nudge events, made readable across quests, so a player active in one quest is blocked from entering another that would overlap with it. This had to be a platform decision, not a feature decision — the rule had to hold across seven games with different economies, reward currencies, and campaign calendars, enforced by the system rather than by convention. Relying on marketing managers across seven teams to coordinate calendars would have failed on the first busy week; making exclusion an attribute the platform evaluates meant a Poker campaign manager needed to know nothing about the Rummy calendar for the guarantee to hold.

Getting it shipped

Changes to mission mechanics touched multiple client teams with independent roadmaps and independent revenue targets — Howzat and Rummy mattered most, since Howzat hosted Rummy as an embedded game. I aligned with each team informally ahead of the formal walkthrough, surfacing and resolving concerns individually rather than discovering them in the sign-off meeting. Sign-off was a genuine gate, not a formality — the goal was to make the walkthrough a confirmation of positions already agreed, not the venue where positions got formed.

Measurement

Multiple A/B tests ran across Rummy, Howzat, and Poker, with windows of roughly 7 to 21 days depending on the retention horizon being measured. The control mechanism was Hidden Missions, a capability I'd already built on the platform earlier — real missions assigned to real users but never surfaced, and therefore paying no rewards. The behavior of that cohort is what the same player population does without the incentive: a true counterfactual rather than a pre/post comparison, without which any observed lift is indistinguishable from seasonality. Assignment was governed centrally by a company-level experimentation module enforcing non-overlap between concurrent experiments, so results weren't confounded by players sitting in multiple tests at once.

Stated plainly: experiments were designed and analyzed by the respective PMM teams' analysts, not by me. These results weren't self-graded by the team that built the feature.

Results

Poker

Rummy, via Howzat

Fantasy Quests, via Howzat

Reading the results

The impact was not uniform, and the variance is the part I find most interesting: the mechanic performed roughly six times better on Poker's D14 retention than on Fantasy Quests. I don't have a validated explanation for that spread. The most plausible hypothesis is that the games impose different natural cadences — fantasy sports already has an externally imposed return rhythm through match schedules, so a day-gated arc adds structure where structure already exists, while Poker has no equivalent daily anchor and more headroom for an artificial one. That's a testable claim, and it wasn't tested.

The split within Poker is cleaner: new users showed retention lift while existing users showed monetization lift, suggesting the mechanic did different jobs for different cohorts — habit formation where the habit was absent, session-frequency lift where it was already present.

← Audience Platform Subscriptions →