Pre-migration Analytics Baseline
A written inventory of what your current app actually records, which figures will go dark at cutover, and what the destination build must capture before the old version is retired.
Who it is for
Product owners, analytics leads, and release managers who still ship a legacy iOS, Android, or hybrid app and have a destination platform in view — a rewrite, a new vendor stack, or a move off an ageing wrapper.
What you leave with
A baseline brief you can hand to engineering and to whoever owns reporting after the move. It states the current measurement surface, the comparisons that will break, and the events, screens, and identifiers that must exist on day one of the new build.
Scope
One production app (or a tightly coupled pair of iOS and Android clients that share a release calendar). Historical reporting from the last complete year is reviewed where you can grant access. Advertising accounts and web properties sit outside this engagement unless they are the only source of a figure you rely on.
Included
- A structured intake on the current store listings, release cadence, and the reports leadership actually reads
- An inventory of screens, events, user properties, and identifiers as they exist in the live app and in the analytics property you use today
- Interviews with the people who currently explain the numbers — often an analytics owner plus one product manager
- A gap matrix: what continues, what must be remapped, what will be lost unless it is specified for the destination build
- A written baseline brief (PDF and a working document) plus a ninety-minute walkthrough
Outside this engagement
- Writing production instrumentation or merging pull requests
- Buying, installing, or administering an analytics vendor product
- Media buying, attribution modelling for paid campaigns, or store-listing copy
- A live dashboard we host or a subscription to any software
From intake to the walkthrough.
A Platform Pulse Hub reviewer in Penang, with a second reader on the brief before it is sent. Work is done in English.
-
Intake
You send store links, a recent build or screen map, and the reports you refuse to lose. We agree the app boundary and the cutover window you are aiming for.
-
Inventory
We reconstruct the live measurement surface from the app, the analytics property, and release notes — not from a slide deck about what was meant to be tracked.
-
Interviews
Two conversations, typically ninety minutes each, with the people who currently defend the weekly figures.
-
Gap brief
We draft the baseline, the break-list, and the destination instrumentation notes. You mark factual corrections.
-
Walkthrough
A live session to walk engineering and product through what must be present before the old app is frozen.
Time, place, and what to prepare
Duration. Three to five weeks from complete intake, depending on how scattered the current tracking is and how many historical reports must be reconciled.
Where. Remote across Malaysia and the region, or on-site in Penang and Klang Valley by arrangement. The walkthrough can be held in your office or on a video call.
Preparation. Named contacts who can grant read access to the current analytics property, a recent production build or a complete screen list, and one example of a leadership report you need to keep comparable.
Limits. We do not reverse-engineer obfuscated binaries. If the current app has no analytics property at all, the baseline becomes a reconstruction from store figures, crash mail, and interviews — slower, and the brief will say so plainly.
Fees. Quoted after a short scoping call. Most single-app baselines land as a fixed fee. Day rates apply if the inventory has to span multiple white-label variants. See Rates for the current starting range.
Next step
Write to us with the app name, the destination you are moving toward, and the freeze date you are protecting. We reply with whether a baseline still fits that window.
Request this baseline