Why the first day matters
The daily wheel was built for players who already had a habit. The biggest leak was before the habit. A new player who deposits for the first time and does not return the next day is, most of the time, gone. In the cohort I used for the missions (first deposits from early December 2025 to early January 2026), 14.2% came back on day 1, 9.5% on day 2 and 7.7% on day 3. The curve then settled between 5% and 7% until day 6. It falls fast and flattens, and the steep part is the first step.
How much the player deposits changes the odds a lot. For the D0 wheel PRD I used a later cohort (first deposits from late January to late February 2026), split new players into nine bands by the size of the first deposit and measured who came back the next day. In the lowest band, 8.4% returned. In the second-highest, 37.3% did. The bands in between climb steadily. The very top band dips slightly, but it holds about one new player in a thousand, so I would not read anything into it.
Day 1 is a long shot for the smallest first deposits, and still under four in ten for the biggest. The share in brackets is how much of the new-player base each band holds.
Most new players sit in the bands that return least. The three smallest bands held roughly 80% of new players, with day-1 retention between 8% and 15%. That is where there is most room to improve, and where a prize costs least, because small deposits get small prizes. In the missions PRD I argued that lifting retention from 10% to 14% in the three smallest bands moves the overall number more than lifting it from 35% to 40% in the three largest.
I tracked it as FDRR, first-day retention. It is the share of players who are active the day after their first deposit: if 1,000 people deposited for the first time yesterday and 100 are back today, FDRR is 10%. The PRD tables count players who deposit again on day 1, while FDRR counts any activity, so the two are close relatives. The 2026 roadmap aimed to take day-1 retention from 14% to 27%. The missions PRD asked for +5 percentage points from the missions alone. The Missions strategy was approved in December 2025, and I chose to start with the step from day 0 to day 1, the biggest opportunity I saw.
A week of missions for new players
A mission asks for something first, and that changes the economics. The daily wheel gives a benefit and bets on what the player does afterwards. A mission pays only after the player completes a task, so the cost can start near neutral. The risk is the opposite one: part of the play a mission asks for would have happened anyway. A player who bets 80 a week by habit and completes a mission asking for 100, with a prize of 2, added only 20 of play, and the margin on 20 can be smaller than the prize (round, illustrative numbers). The only reliable answer was a control group, so every design decision in the first-week program protects one.
The prize comes from an opportunity, not from a guess. For each deposit band and day, I looked at what the players who did come back deposited. A player who does not return is an opportunity: the value he would have brought if he had. The prize is 20% of the profit that opportunity represents. The share is conservative on purpose: it leaves room to raise prizes later, because players who get generous prizes on day one feel any later cut as a loss.
Every mission followed rules I set before the first one was built. The rewards platform offers six mission types. I leaned on “total spins”, because “play 20 rounds” is easier to understand than “wager an amount”, and kept “wager & get” as the alternative. Missions that require a deposit were blocked, because Brazilian regulation does not allow them. The rest was a short list: the prize is at most 70% of the effort needed to earn it, a free spin is never worth more than the minimum bet the mission asks for, free bets need a minimum odd of 1.3, no crash games in “total spins” because they are easy to manipulate, and missions that run together cannot count the same play twice. The platform could not read sportsbook activity, so no mission could ask for a sports bet, but a prize could still be a sports free bet.
Players opted in, and could always see their progress. A mission counted only after the player pressed accept. Up to five could be active at once, with a progress bar in the rewards modal. There was no failure, only the clock. Players flagged as bonus hunters got missions that were possible but had the worst effort-to-prize ratio. I avoided missions nobody could finish, because players complain about those publicly.
The first test in the PRD was a deliberately weak mission. It covered the three smallest bands, about three in four new players, for two weeks, with one simple mission. Effort was high and the prize small, between 2% and 8% of the play required, against a ceiling of 70%. That discourages bonus hunters, and it sets a floor: if a weak mission lifts retention, a better one should lift it more. I wrote targets before launch, and they are targets, not results: day-1 retention +3 percentage points expected and +1 the minimum, more than 15% of exposed players starting a mission and more than 30% of those finishing it. In my first model, with 10% of players engaged, break-even was about 1.6 points of retention.
Support got the explanations before the players did. I wrote an announcement and a FAQ for the support desk. It explained where to find missions, that a mission must be activated before playing and lasts 24 hours, and why a friend has a different mission (goals and prizes scale with the first deposit). It had checklists for “I completed it but got no prize” (activated first, right game, minimum bet, not expired), “my mission disappeared” and “I got no mission”. Anything else went in three steps: the desk, operations, then product. One welcome mission on day 0, valid for seven days, was paid from the acquisition budget and not from the retention model.
Testing it: ten digits, five groups
The last digit of the player ID is a free, stable way to split a base. It needs no new system, the rewards platform can segment on it, and a player always lands in the same group. I had used the same idea to roll out the daily wheel in waves in July, August and September 2025. For the missions I gave each digit group a different version of the first week. In the D0 wheel PRD I asked the data team to check that the groups were comparable before reading anything.
The first split, for day 0. Digits 5 and 7 are the control and get no mission at all.
Five groups, and as I set them up each one changed one thing. Digit 0 kept the original design from the PRD. Digit 4 got four missions. Digit 8 got a prize twice as large. Digits 1, 2, 3, 6 and 9 got “wager & get”, the alternative mission type, which made it the largest group, with half of the base. Digits 5 and 7, 20% of players, got nothing and are the comparison for everything else.
The test then moved toward one version. My change log shows the sequence. Day 0 was first set up for every level-1 player, with “wager & get” at 50% of the base. Levels 2 and 3 were to follow the same pattern on day 0. Then “wager & get” would go to 80% of the base for days 1 to 6, every digit except 5 and 7, and switch off the original and the other versions. From then on there would be no variants in days 1 to 6, for the time being. That keeps a clean comparison running while most players move to one design. The readout of the five groups was not finished when I left, so I do not claim why “wager & get” was the version I scaled.
The second step, for days 1 to 6. One version for everyone except the control, which stays at 20%.
The third step opened missions to the whole base. The plan was to clone the segments of the daily wheel, release missions to both the odd and even groups and keep 5 and 7 as control. A new rule, more than 7 days since registration, kept it from overlapping the first-week program for the same player. The design called for one activity per level and weekday, starting with the first three levels. By early February activities with that rule existed on the platform. I have no record of how far each step went after that.
IDs carry the design, so a report can be read. Each activity had a code in its name: a macro version, a micro version and a level. ID 2110 is macro version 2, micro version 1, level 1. A cost report that lists “ID 2110” can be traced back to a design without anyone’s memory. For missions the day was added to the code.
From approval to the base-wide rule. The wait on 19 January was the rewards platform refusing to register the mission bonuses.
The integration with the rewards platform took its own work. On 19 January the platform’s bonus registration was failing, which blocked the prizes, and I opened a support case. The March backlog of its timed activities, told in Part 5, matters here too: a program with one activity per level and weekday needs light fields and spread start times from the start.
The D0 wheel
The welcome wheel is one spin after the first deposit, with a bonus the player must wager. It is for new depositors whose identity check was approved. A modal tells them on the first page view after the deposit that a free spin is waiting, and the wheel opens from the Rewards area, where the button only appears after the check. The spin is valid for one day from the first deposit. The prize is a bonus with a 35x rollover, usable only on slots, with one day to complete it. When the rollover is done, the balance can be withdrawn.
The player’s path. Both the deposit and the check are needed before the modal appears.
I put it after the deposit and the check on purpose. The leadership suggestion was the first screen after the check, with three arguments that I adopted in the PRD. It is easier to measure, because the wheel cannot change the conversion to deposit or to identity check. It lowers fraud risk, since players verified by hand do not see it at first. And bigger prizes for bigger deposits can come later, once the first version is tuned. The cost was giving up wide communication before the deposit. Because the offer appears only after the deposit, it is not advertised as a prize for depositing, but its size does follow the first deposit, which is the line I discuss in Part 1. Compliance still had to confirm that reading, along with the terms and the tax treatment, before launch.
The wheel has eight slices and one outcome. There are nine wheels, one per deposit band, with only four distinct designs because several bands share a prize. On each wheel one slice has 100% probability and the other seven have 0%, so the band fixes the result. The seven extra slices are part of the game and keep the eight-slice format the art team knew. A fixed outcome dressed as a wheel has its own risk, how it reads to the player, which is another reason the mechanic went to compliance. The prize base is 20% of the first deposit, with a floor for the smallest bands so the prize still feels worth taking, and a cap for the largest so exposure stays controlled.
The cost model assumes most players will not finish the rollover. A 35x rollover is in the middle of what the Brazilian market charges for slots (30x to 40x in a benchmark I made in March 2026). The PRD assumes about 5% of players complete it, so the nominal bonus could be up to three times the cost target. The real cost has two parts: taxes, close to 24% of the bonus value at the moment it is granted, and the payout of the few who finish. I calibrated it for 100% of players spinning, a conservative case, since I expected 20% to 30% to spin. That is also the uncomfortable part: a bonus most people lose can feel like a trap, so the wheel had to be clear about the rollover and its deadline.
The hypothesis is that wagering pays for the prize. Every unit of bonus needs 35 units of bets, and the house keeps about 4% of what is bet. If the player completes the rollover, the house earns 1.4 units for each unit it gave, so the net cost is negative. Break-even is at 25 units of play per unit of bonus. This is the arithmetic of a model, not a result. At 20% to 30% of players spinning, the PRD showed the wheel paying for itself if it lifted day-1 retention by less than one percentage point.
The test I planned was simple. Half of the new depositors, those with an odd last digit, would see the wheel and the other half would not. It would run at least four weeks and compare retention on days 1 and 7, the share finishing the rollover and the cost per player, band by band. It was written on 27 February 2026, with the data team to define the thresholds for scaling before the start. There was no readout by the time I left, so this case has no result for the D0 wheel.
Measuring the real cost
The cost of a mission is not the number stored on the bonus. To follow mission cost day by day, I wrote a query that starts from the table of bonuses granted to players and picks out the missions by name. The field that holds the amount does not hold money for a free spin: it holds how many spins were given. Add that column as if it were money and a prize of 20 spins is counted as 20, when its face value is a small fraction of that and its real cost is whatever the spins won (round, illustrative numbers). For a free spin the real cost is the winnings the spins paid out. For any other type, a free bet or a wagering bonus, it is the amount paid. The query picks the field by bonus type. I wrote the rule into the notes of the query so the next person would not repeat the mistake.
The cost is read in two views. One query lists everything by day, mission name, prize type and first-deposit band, for drilling down. A second has one line per day, with totals and a running cost, for the executive view. The band comes from the real first deposit, not from the average ticket. The query also pulls deposits on days 0, 1, 2 and 7 after the bonus and divides the day-7 deposits by the cost. That ratio is a rough sign, not a measure of what the mission caused. Only the control group could say that.
Two prize types change the books. A free spin counts as a non-financial reward: it does not enter reported gaming revenue when granted, and a payout is deducted. A bonus with a rollover that cannot be withdrawn counts as a financial reward and enters reported revenue the moment it is granted, with taxes due then. Since most of a 35x bonus is never cashed out, the books can show more revenue than the business earned. The switch from free spins to a bonus with rollover was a question for compliance as much as for product.
The same arithmetic led to a second test, on the daily wheel. In March 2026 I wrote a separate PRD, still a draft, to replace the free spins of the daily wheel with a bonus with a 35x rollover and 24-hour validity. The daily wheel had a clear effect in the causal study (+39% in deposits), but its cost is almost the full value: players keep what the spins win and can withdraw it. The hypothesis was that a rollover would cut the net cost and raise the nominal value players see, on the same budget. It would give 20% of eligible players the new bonus and keep 80% on free spins, run at least 30 days, and stop if day-7 retention, revenue per player or complaints moved past set limits. In the model, an average rollover of 15x already cuts net cost by more than half. The test had not started when I left.
What I could not close, and what I took from it
I do not have a measured result for the missions or for the D0 wheel. The missions launched with a test structure: a control group fixed by the last digit of the ID, targets written before launch and a cost view updated every day. The D0 wheel was designed with the same structure and a written plan to read it. When I left Grupo H2 in March 2026 the readout had not been completed. The numbers here are the size of the problem, the design and the plan. I will not turn a plan into a result.
A split fixed by ID digit let the experiment survive its own changes. The test went from five groups to one version in a few weeks, and the control group did not move. When the design changes fast, the comparison needs a part that stays still.
Write down what a number means before someone adds it up. A column called “amount” had two meanings, a count of spins and a sum of money. The note caught it, and the query now knows which one it is reading.