Planning engagement
Instrumentation Review
A dictionary that nobody checks against the build is a wish list. We walk the same paths a person takes and tick each event against the plan, on the build you give us.
Who it is for
Teams who have a tracking plan on paper and a release that claims to follow it.
What you leave with
A punch list: missing fires, extra fires, wrong types, and properties that leak values the dictionary forbids.
In scope
- Walkthrough of every event in the current plan version
- Trigger timing (too early, too late, twice)
- Property presence, type, and forbidden values
- Identity: anonymous to signed-in on the same device
Included
- A punch list grouped by screen
- A retest of failed items on one follow-up build
- Notes for the engineer who owns each miss
Not included
- Writing the tracker calls
- Load or performance testing
How the work proceeds
-
Agree the build
You provide a test account and a build that is meant to match the plan version.
-
Walk and tick
We fire each path and compare the payload to the dictionary row.
-
Retest once
After engineering patches, we re-walk only the failed rows.
Preparation
Test accounts for each role in the app, and the plan version the build claims to implement.
Constraints
One build flavour (for example production-like staging). Store-review builds with different flags need a second pass.
Next step
Tell us the plan version and when the test build will be ready.