Flagship review

Mobile instrumentation audit

Most empty funnels we are asked to explain are not empty because people vanished. They are empty because a screen was redesigned, an SDK was bumped, or a consent prompt started blocking the first event, and nobody walked the path with logging on before the release notes went out.

Hands holding a smartphone above a notebook during a product review

Who it is for

Product owners, growth leads, and analytics managers of consumer or B2B mobile products who cannot tell whether empty funnels are a product problem or a tracking problem.

What you receive

A written findings report you can hand to engineering: which events fire, which do not, which fire twice, which carry empty parameters, and which fire before consent is granted.

Scope

One named mobile product, on iOS, Android, or both, for the journeys you nominate (typically onboarding, core action, and a paid or conversion path).

What we actually open

We install the build you give us. We turn on the debug view or proxy for the analytics SDK you already use. Then we tap through onboarding, the main action, and the conversion path as if we had never seen the product. At each screen we record the event name, the time it fired, the parameters that arrived, and the parameters that did not.

What you can hand to engineering

The report is a working document, not a slide theme. Each finding names the screen, the expected event, the observed event (or the silence), and a suggested fix in the language of the SDK you already ship. Engineers should be able to open a ticket from a single paragraph.

What this is not

This is not a subscription to a dashboard we host, and it is not a rewrite of your product strategy. We read the instrumentation that is already in the app. Implementation of the fixes stays with your team, unless you later commission a follow-up check on a new build.

Included

  • Screen-by-screen event map for the agreed journeys
  • Inventory of analytics SDKs and versions present in the build you give us
  • Sample raw payloads captured during a recorded session
  • Gap list: missing, duplicate, mistimed, or empty-parameter events
  • Notes on consent timing relative to first-open and first-event
  • Written findings report and a 90-minute readout with your product and engineering contacts

Not included

  • Writing or merging tracking code into the app
  • Day-to-day ownership of the analytics property after the audit
  • Paid media setup or campaign measurement
  • Load, crash, or performance testing of the app itself

How the work proceeds

  1. Brief and access

    You send the product name, nominated journeys, a TestFlight or internal APK, read-only access to the analytics property, and any measurement plan you already have.

  2. Journey walk

    We walk each nominated path with debug logging on, the way a new user would, and capture what actually leaves the device.

  3. Map and gaps

    We draft the event map, mark collisions and silences, and sample payloads for the events that do fire.

  4. Readout

    You receive the report, then we spend ninety minutes walking the findings with the people who will change the next build.

Preparation

A current internal build, a contact who can grant read-only analytics access, and a list of the journeys that matter this quarter. A measurement plan helps; we can still review against observed product behaviour if you do not have one.

Constraints

We do not need production admin rights. We will not install extra SDKs on your users. Reviews pause if a build cannot be installed or if debug logs cannot be produced.