Skip to content
Indevaro
Contents
  1. 1How to choose your next app growth experiment
  2. 2Why is my app not getting downloads?
  3. 3App store keyword research and discoverability
  4. 4How to improve app store listing conversion
  5. 5Downloads but no paying users: what to check
  6. 6Did an app update hurt growth? Check crashes and ANRs
  7. 7App competitor analysis: listings, reviews and positioning
  8. 8How to measure an app growth experiment
  9. 9How to market your app after launch
  10. 10How to prioritize growth work across your apps
  11. 11How to learn from app growth experiments
  12. 12Your next two hours of app marketing

Worksheet for chapter 6, Did an app update hurt growth? Check crashes and ANRs

Worksheet 6 — Release regression triage

Download all worksheets (PDF) (28 pages, 449 KB)

Use with chapter 6, Technical regressions. Put release, error and business evidence on one timeline and decide whether to halt, fix first, or proceed.

App: ______________ Platform: ☐ iOS ☐ Android Release under review: version ______ released __________

1. Release facts

  • What changed (features, SDKs/dependencies, server, remote config): ______________________________
  • Rollout: ☐ App Store phased release (day ___) ☐ Play staged rollout at ___ % ☐ full release
  • Other changes in the same window (price, listing, campaign): ______________________

2. Timeline by version

DayRollout %Error metric (crash / ANR / failed purchase / failed sign-in) — new versionSame metric — previous versionBusiness metric (trials, purchases, day-1 return) — newBusiness metric — previous
0
1
2
3

3. Segment match

  • Where are the errors concentrated? OS version ______ device/model ______ country ______
  • Does the business metric move in the same segment? ☐ yes ☐ no ☐ can't split
  • Reviews describing the symptom since release: ____ (qualitative — supports an investigation, not a conclusion)
  • Platform thresholds (Google Play Android vitals bad-behavior lines, overall/per phone model): crash 1.09% / 8%, ANR 0.47% / 8% — over? ☐ no ☐ yes. These are enforcement lines, not targets.

4. Assessment

  • ☐ Not a regression — errors unchanged or not concentrated in the new version.
  • ☐ Plausible — errors changed at release, concentrated in the new version, business metric moved in the same segment.
  • ☐ Likely — plus: halting/rolling back or fixing reversed the business change in that segment.

5. Decision

  • ☐ Halt / pause rollout (Play: halt staged rollout; App Store: pause phased release — max 30 days total)
  • ☐ Fix first — fix release plan: version ______, rollout ___ %, day-2 check by version. On Play, if the broken release was halted mid-rollout, start the fix at no less than the halted percentage: a new release started before the previous rollout completed goes to the same group of users.
  • ☐ Investigate — next check: ______________________
  • ☐ Proceed — reason: ______________________

Growth tests to postpone until two weeks after a stable release: ______________________

6. Fix priority check

QuestionAnswer
Share of active users affected (estimate, source)
Harm now (data loss, cannot pay, cannot open)
Does it corrupt a running test or measurement?
Could it affect store visibility (Play thresholds)?
Effort to fix (estimate)

→ If harm is real and the regression is at least plausible, the fix goes first in the two-hours sheet (worksheet 10).