Screen by screen, we check whether your app’s events actually fire.
Audit Canvas Base is a small review practice in Pulau Pinang. We install the build you already ship, walk the journeys you claim to measure, and write down the events that leave the device — including the ones that do not.
This is not a dashboard we host. It is a human reading of instrumentation: names, timing, empty parameters, duplicate fires, and consent that arrived later than the measurement plan assumed.
- 01Event names against the screen the person is actually on
- 02SDK versions present in the iOS and Android builds
- 03Payloads that arrive empty, twice, or before consent
- 04Journeys the weekly reading depends on, walked with logging on
Who asks
Product teams who cannot tell an empty funnel from a silent event
We work with owners of consumer and B2B mobile products — often in Malaysia, often with engineering in more than one city — who read weekly numbers they no longer fully trust. A checkout redesign, an SDK bump, a new consent dialog, a WebView: any of these can stop an event without stopping the human from paying.
If you already know the tracking is wrong and only need someone to write the code, this is not that engagement. If you need a named person to walk the path and produce a findings report, it is.
Flagship engagement
Mobile instrumentation audit
One product, the journeys you nominate, ten to fifteen working days. You receive an event map, payload samples, a gap list, and a ninety-minute readout with the people who will change the next build.
We do not merge the fixes. We write them in a form an engineer can ticket. Implementation stays with your team; we can check a later release candidate if you ask.
Related work
Other reviews we take when a full map is not the need
-
Before a version ships
Pre-release tracking check
A short, named-journey pass on a release candidate so a checkout or onboarding change does not go to the stores with silent events.
-
Half-day working session
Measurement plan session
A facilitated half day in which product, engineering, and whoever reads the weekly numbers agree what should be tracked before anyone writes another event.
-
After the map exists
Event taxonomy rewrite
A structured renaming and nesting of events after an audit, so the next version of the app does not keep shipping duplicate names for the same user action.
A review week
What actually happens after you send the build
The method is deliberately slow: install, walk, write. Charts stay closed until the paper from the walk is typed. Read the method in full.
-
Access, not admin
A TestFlight or internal APK, read-only analytics access, and the journeys that matter this quarter. We do not need to own the property.
-
Walk with logging on
We tap through as a new user would, on iOS and Android when both stores are in scope, and capture what leaves the device.
-
Findings, then a call
The report names screens and events. The readout is for deciding what the next version will change, not for discovering the evidence.
They caught that our new menu screen never fired add_to_cart on Android. We had been reading a drop in food-delivery add-ons as a merchandising problem for two sprints.
From the desk
Notes on events, consent, and naming
If a journey looks empty, send the version number
Name the product, the stores, and the path you read every Monday. We reply within two working days with whether an audit, a pre-release check, or a measurement plan session is the right next step.
Write to the desk