Reconstruct the current baseline.
Record the live metadata, screenshots, markets and measurement definitions. Review the recent release and acquisition timeline before explaining performance. A mature app may have years of data that are not directly comparable.
Use a change log and note reporting breaks. The baseline should describe the current situation rather than select the most flattering historical period.
Revisit the audience promise.
Products evolve. A listing written for an earlier feature set may no longer reflect the main user task. Ask whether the visible message matches the experience and the audience the business now wants to serve.
Use positioning evidence and inspect actual product capabilities. Familiar copy is not automatically good copy, but age alone is not a reason to rewrite it.
Locate the constraint.
Separate discovery, listing response and product outcomes using compatible evidence. A broad decline and a single-market problem need different investigations. Do not buy a complete redesign because one aggregate line moved.
Start with download diagnosis or conversion diagnosis when appropriate. Preserve the strongest known evidence and label uncertainty.
Change a reason, not everything at once.
Correct verified errors and prioritise a focused hypothesis for uncertain improvements. Record what stays constant and what changes. If several elements form a combined treatment, interpret the result at that level.
Use test prioritization. Existing traffic can support learning, but it does not remove the need for sound comparison and audience context.
Maintain the operating record.
Keep decisions, releases and evaluation notes in a place the next owner can use. Retire stale assumptions and document why priorities changed. An established programme should accumulate reasoning, not just asset versions.
Use monthly reporting and a roadmap to connect each cycle to the next decision.
