Shiva Creation · Daily Cashback for the player app and Ops Backoffice
Project
Making Daily Cashback Clear & Reliable
platform
Mobile player app (iOS & Android) and web Backoffice for Ops
Responsibilities
End to end: read the funnel and Support data, frame the real problem, write requirements and edge cases, design the player screens and the Ops Backoffice, then define how success is measured and tested.
Feature
Daily Cashback promotion: players earn back a percentage of their settled bets each day, based on their tier (Silver 5%, Gold 8%, Platinum 10%), and can claim it once a day before 23:59.
Overview
Ops reported a low claim rate on Daily Cashback and asked for per-tier minimum spend and a faster pause. The data told a different story: players couldn’t see eligibility, amount and timing at the moment they needed them, and about 1 in 10 claim taps failed. This case study follows the work from evidence to requirements, design and an A/B test plan.
1. Case Study Overview
a. Problem Discovery & Evidence
- Funnel analysis · 100,000 players, 30 days
- Support ticket analysis · 640 tickets
- Ranked hypotheses H1–H3
- Reframing the Ops request with data
c. Final UI & Edge Cases
- Entry / Promotion card · every state
- Cashback Detail & Claim
- Claim edge cases: voids, errors, expiry, pause
- Backoffice: validation & safe pause
b. Requirements & User Flow
- 9 requirements, each traced to a hypothesis
- Player claim journey
- 12 player states & 8 claim outcomes
- 24 edge cases, 12 assumptions, 14 open questions
d. Measurement & Experimentation
- Primary metric & guardrail
- Event tracking plan
- A/B test design
- Decision rule agreed before the test
2. Problem & Evidence
The project started with a stated problem from Ops: the cashback claim rate is low. Before designing anything, I worked through 30 days of funnel data and 640 Support tickets to find where players drop out and what they ask about.
Where players drop out
Context (30 days): 100,000 players opened the app · 62,000 saw the Cashback card · 18,600 opened the detail page. I focused on those 18,600, the players most engaged with the promotion. Most of them couldn’t claim.
What players ask Support
- 640 cashback tickets in 30 days.
- 86% ask about eligibility, amount or timing: questions the screen itself should answer.
- Support handles 136 tickets per 1,000 successful claims.
What the data tells us
- Eligibility blocks the most, but the claim step also leaks. 60% of openers couldn’t claim, and 1 in 10 taps failed for those who could.
- Tickets ask the product to explain its rules. This points to missing information more than broken features.
- “Claim rate” isn’t one number. It reads anywhere from 4.7% to 63.5% depending on the denominator, so Ops and Data need one agreed definition.
What it doesn’t tell us
- How many players were eligible overall, since eligibility is only logged when the page opens
- Why players were ineligible, and why 500 claims failed
- Which group sends “can’t claim” tickets: 2.3% of ineligible players, or 52.4% of failed claims
- Daily behaviour around the 00:00 reset and 23:59 expiry
Ranked hypotheses
Ranked by how many players and tickets each one explains, and how many data sources support it. H2 ranks above H3 despite fewer tickets because two sources point to it. One exception: if a ledger check finds real errors in amounts, H3 goes first. Financial accuracy comes before UX.
Reframing the Ops request
- Per-tier minimum spend is a solution, not a finding. Nothing yet shows the current threshold is wrong, and it adds a rule players already can’t see. Shipped before H1 is solved, it would likely raise “can’t claim” tickets. Ineligibility reasons by tier come first.
- Fast pause makes sense. Worth asking Ops which incidents prompted it, since the answer may link to the “amount looks wrong” tickets.
- Extra data, in order. First: current screens in every state, 100 tickets tagged by player state with a ledger check, and error codes for the 500 failed claims. Then: ineligibility reasons by tier, a daily funnel and daily eligibility for all players.
3. Requirements & User Flow
I turned the evidence into something Engineering and QA can build and test: one claim journey, 12 player states, an idempotent claim contract and 24 edge cases, each traced back to a hypothesis so it can be measured later.
Decisions that shape the build
- One moment, one countdown. “Expires at 23:59” and “resets at 00:00” are the same instant, 23:59:59. Server time decides, not the device clock.
- Claim only on the Detail & Claim page. Money moves only where the player sees the breakdown, what claiming does to the rest of the day, and where errors are handled.
- Tier, rate and minimum are fixed at 00:00. A tier change applies from tomorrow, so the amount never jumps mid-day.
- One cashback day, one credit. Every claim is server-checked and idempotent. An unknown result is rechecked, never shown as failed.
- Never credit less than the player saw without asking. Crediting more is fine and is shown on the Claimed state.
- Ops actions are predictable. Pause blocks claims at once. Once a campaign is live, its rates and minimums never change.
Requirements, traced to the evidence
Nine requirements, each linked to the hypothesis or failure it fixes and to how QA verifies it.
Player claim journey
- The server’s state decides every branch. Every branch ends in a state that says what happened and what comes next.
- The Entry card shows today’s state. Claim when cashback is ready; View when below minimum, claimed or paused; Locked when the tier or account can’t earn today.
- Tapping Claim locks the button and sends one request with one key. Credited or already claimed → Claimed. Refused → explain the state. Not final → recheck, then retry with the same key.
- At 00:00, on any screen, unclaimed cashback shows Expired once and a new cashback day starts.
12 player states, one server response
The card and the detail page show the same states from one server response, so they can never disagree. The card’s CTA is always one of three: Claim, View or Locked.
Claim outcomes: unknown is never “failed”
Every server result maps to a defined state and message, so a slow network never looks like lost money.
Edge cases that matter most
24 edge cases for QA. The 6 Critical ones move or protect money, so any failure there blocks launch. Where the rules were silent, I set a default and tagged it: 12 assumptions and 14 open questions for PM / Ops.
4. Final UI & Edge Cases
The final UI for players and Ops. Every state from the requirements has a designed screen, including the unhappy paths: slow or failed claims, voided bets, expiry at midnight, paused campaigns and invalid campaign setups.
How eligibility, amount and timing are explained
Four rules applied on every screen, each answering one of the ticket types.
Entry / Promotion card
- The working is on the card. “$16.00 ready” comes with “5% of $320.00 settled spend today”, so the number can be checked before the page is opened.
- One countdown, one label. Same Countdown and words as the Detail page. In the last hour it turns amber; nothing else changes.
- Claim opens the page, it doesn’t credit. Claim, View and Locked all open Detail & Claim, so money moves next to the breakdown and the trade-off note.
- Never a stale Claim. Refresh on open, on return, every 60 s, at 00:00 and after a claim. If the state can’t load, the card hides.
- “Why can’t I claim?” answered on the card. Below minimum shows spend vs. minimum and the amount left; Locked gives the reason in one line.
- Factual, not pushy. Urgency is only used for money already earned and about to expire, never to push more spend.
Every card state
- Claimable, Below minimum, Claimed, Checking, Paused, Locked (tier and account) and Loading each have a designed variant.
- No state is only a greyed-out button: every blocked state says why and what unlocks it.
- Load failed, Not started and Ended hide the card instead of showing stale information.
Cashback Detail & Claim
The only place money moves. The first screen answers if, how much and until when, with the Claim button and what claiming does to the rest of the day. All conditions live in “How it works”, collapsed by default, with claim history below.
Claim reliability
- Unknown is never failed. No answer in 10 s shows “Checking your claim…”; retries reuse the same claim key, so a player is credited once.
- Tier changes are announced, not applied mid-day. A banner says the new rate starts tomorrow; today keeps the rate set at 00:00.
Clarity across the day
- A timeline of the cashback day. 00:00 sets tier and rate; 23:59:59 expires unclaimed cashback and starts the new day, drawn as one moment.
- History closes the loop. Claimed, expired and below-minimum days sit side by side, so a missed day is visible instead of silent.
Claim edge cases, designed not described
The cases that usually only live in a spec: what the player sees when the network is slow, a bet is voided, the server fails, the day ends or Ops pauses the campaign. Each state says what happened to their money and what to do next.
Backoffice · Campaign Setup / Edit
Read top to bottom, the way Ops works: create, run, pause, end and copy. Same status names, Countdown and rules as the player app. I added Scheduled to the original four statuses so Ops can see what goes live next and still pull it back.
Prevent tickets at the source
- Validation blocks the ticket-makers. Names, dates, overlap, rate (0.1–20%) and minimum are checked inline and summarised at the top. A missing minimum is exactly what turns into “why can’t I claim?”.
- Ops reads the rule as players will. The preview uses the real Entry card and generated rules, with a “Player sees” column per tier.
Rules that stay put
- Rules are editable until go-live. Drafts edit directly; a Scheduled campaign goes back to Draft first. Active, Paused and Ended are read-only.
- The trade-off I accepted. A wrong rule found after go-live means Pause, End and a new draft from the next 00:00. Rules changing mid-day drive “amount looks wrong”, and Pause covers emergencies.
Clickable prototypes, built with Claude
Clickable versions of the Player app and the Backoffice. The Player app can start from any player state, trigger events such as a settled or voided bet or an Ops pause, and jump the server clock to 00:00, so the team can feel the edge cases instead of reading them.
Validation and risky actions
Ops mistakes become player tickets, so the Backoffice stops them early: inline validation with a summary at the top, Activate locked until the campaign is valid, and a pause confirmation that shows the impact on players and asks for a reason.
5. Measure & Improve
If the redesign fixed the real problem, more of the cashback players earn reaches their wallets, and fewer of them have to ask Support why. Daily return, the business reason for cashback, is watched as a secondary signal, since 4 weeks is too short to decide on it.
What success looks like
One primary metric, one guardrail, one stop rule for money, and a separate metric for the claim fix.
Choosing the denominator
The same 4,700 claims read as anything from 4.7% to 63.5%. The primary metric needs a denominator the redesign can’t move, and the guardrail needs one the primary can’t move.
Event tracking
Five events give every number above. cashback_day_closed is the one new backend job: it gives the denominator for every player, not only page openers.
How we test it
- The claim fix ships to everyone, no A/B. The idempotent claim and the Checking state fix money; they aren’t a design option. Staged 5% → 25% → 100%, comparing failed taps before and after.
- New card and Detail page: A/B, 50/50 by player. Sticky per player, so card, page, history and Support always match. Ramp at 10% for 3 days, then 50/50.
- 4 full weeks in the December campaign, config frozen. No rate, minimum or tier change mid-test, since that would move the denominator.
- Pre-registered analysis. Primary read once at 4 weeks, per player. Guardrail checked weekly, money daily. Ship only if no segment is clearly worse off.
Decision rule, agreed before the test
Read once, after 4 weeks. +3 pp is about the smallest change 4 weeks of traffic can detect.
6. Lesson learned
- The stated problem is a starting point, not the answer. “Low claim rate” turned out to be three separate leaks (eligibility, timing and failed claims), each needing a different fix.
- Agree on the metric before the design. The same 4,700 claims read as 4.7% or 63.5%; choosing a denominator the redesign can’t game keeps the result honest.
- In money flows, unknown is not failed. Idempotent claims, a Checking state and “never credit less without asking” protect trust more than visual polish.
- Push back with evidence, then sequence. Per-tier minimums weren’t rejected; they were scheduled after the data that would prove they’re needed.
- One vocabulary across Ops and players prevents tickets at the source. The Backoffice previews exactly what players will see.
- AI speeds up the work, judgment still owns it. Claude helped me explore edge cases and build clickable prototypes faster, but every decision had to trace back to evidence.
