Before a version ships
Pre-release tracking check
A pre-release check is for the week when the design of checkout has moved and the event names have stayed the same — or were supposed to. We do not remap the whole product. We ask whether the events this version depends on still leave the device.
Who it is for
Teams about to ship a version that touches onboarding, paywall, checkout, or another path the company reads every Monday.
What you receive
A pass/fail note on the nominated events for that candidate, with payload samples for anything that looks wrong.
Scope
One release candidate, one or two stores, and a list of events you cannot afford to lose in that version.
When to ask for this
Use a pre-release check when a full audit is already on file, or when the product is small enough that a handful of events carry the weekly reading. If you have never mapped the app, start with the instrumentation audit instead.
What the note contains
Each named event is marked observed or not observed, with a timestamp from the session and a parameter list. If an event fires twice, we say so. If it fires before the consent prompt is dismissed, we say so.
Included
- Install and walk of the candidate on the nominated store builds
- Check of the named events against the previous version or the measurement plan
- Written pass/fail with payload excerpts
- Thirty-minute call if any event fails
Not included
- A full instrumentation map of the whole app
- Code changes
- Checks on journeys you did not name
How the work proceeds
-
Candidate in
You send the RC build, the event list, and the previous version's expected names if they have changed.
-
Walk
We complete each named journey twice and capture logs.
-
Note out
You get a short written note, usually within three to five working days.
Preparation
An RC you can actually install, plus the exact event names you need confirmed.
Constraints
This check does not replace a full audit. It only speaks to the events you list.