the-repeat-purchase-checklisted

> **Ask the product's actual consumption cycle before diagnosing timing.** A category inference is a > guess, and the whole diagnosis inverts on it: a reorder prompt that is late for a 30-day consumable is > early for a 90-day one, and recommending the wrong direction is worse than recommending nothing. Ask > how long a unit lasts in normal use, or derive it from the observed gap between first and second > orders among customers who did reorder. Where neither is available, say the timing finding is > unavailable and diagnose only the parts that do not depend on it. # The Repeat Purchase Check Take the flows a customer sees after their first order and find the specific gap, timing or message, that's stopping the second one. > **Input integrity.** Run the checks in `references/data-input-integrity.md` before computing > anything, and report what they found. Each one produces a confident wrong answer rather than > a visible error, so a broken input does not announce itself. Recent cohorts have not had time to repeat, so they always look worse. Do not read an immature cohort as a decline. > Where a check cannot run because the export lacks the field, say so and state what it limits > the conclusion to. ## How to run Ask the user for these inputs. If any are missing, ask before analyzing. 1. **Existing post-purchase flows**: names, trigger, timing, and what each message says, from an export or screenshots. 2. **Product type and purchase cycle**: replenishable, seasonal, gif