Design a streak-saver mechanism

WHAT THIS TESTS This evaluates state modeling for a recurring time-based feature, timezone correctness, and the maturity to test a motivation policy against retention rather than a vanity metric.

A GOOD ANSWER COVERS State: per user store current_streak, longest_streak, last_active_date evaluated in the user's local timezone, and saver_balance. A day counts when a qualifying action occurs; the streak increments if the last active day was yesterday, resets if a gap appears unless a saver covers it. Rules: cap saver inventory, define how savers are earned or replenished, decide whether a saver auto-applies on a miss or must be claimed, and bound how many consecutive days a saver can bridge. Testing: treat forgiveness generosity as the variable; randomize users across policies and measure D7 and D30 retention as primary, with guardrails on daily active days per user and on streak inflation so you do not win retention by making streaks meaningless.

COMMON WRONG ANSWERS Storing dates in UTC and breaking streaks for users near midnight in their timezone. Unlimited free savers, which removes the loss that drives the behavior. Optimizing for average streak length, a metric easily gamed by generosity. No guardrails, so a policy boosts a vanity number while hurting real retention.

LIKELY FOLLOW-UPS How do you prevent travel and timezone changes from unfairly breaking streaks? How do you avoid savers becoming a pay-to-win mechanic? How long to run the test given retention is the metric?

ONE CONCRETE EXAMPLE A user with current_streak 12 and saver_balance 1 misses Tuesday in their local timezone. The system consumes one saver, keeps the streak at 12, and notifies them. In the experiment, one arm grants one saver per week, another grants three; both are evaluated on D30 retention with a guardrail that median real active days does not drop.