Blog · Release Signal Lab

A pre-launch analytics checklist for iOS and Android

Laptop showing code during a pre-launch review

Week two of Release Signal Lab is unromantic. Students walk a candidate build with a printed sheet. If an item fails, we do not “note it for later.” We stop that journey until the stamp exists. Here is the list we actually use for Analytics QA for App Releases, trimmed of vendor slogans.

Identity and version

The journey under freeze

Locale, currency, calendar

Thailand still surprises teams who tested only en-US. Baht can arrive as number, string with symbol, or minor units. Buddhist calendar years appear as 2569 on one OS and 2026 on another. Dual-language onboarding can skip a step that only exists in Thai copy. Check all three on both platforms before you call the candidate measurable.

Store and attribution leakage

If you are running a listing experiment, first-open and campaign properties must not be the only way you judge in-app activation. Isolate listing traffic or you will ship a product change because a screenshot won. That isolation is a full module in the lab; the checklist item is simply: “listing test ID is present and queryable.”

Privacy and debug

Debug builds should be able to show a console or inspector for the last 20 events without shipping that inspector to production. ATT / consent flags, if you collect them, must match what your privacy policy claims. We will not QA a silent identifier harvest.

Print the sheet. Tick it on a device, not in a slide. Then read the Firebase vs Mixpanel Thailand note if your vendor queue behaves differently offline.