Tracking plan and naming
Whether your events and properties follow a plan, mean what people think they mean, and are named so the next person understands them.
Whether your events and properties follow a plan, mean what people think they mean, and are named so the next person understands them.
How users are identified across devices, logins and platforms, and whether anonymous and known users merge the way you expect.
Events that fire twice, never fire, or fire on one platform but not the other.
Whether anything you shouldn't collect is being collected, and whether tracking respects the consent people gave.
SDK versions and settings in Amplitude, GA4, Mixpanel or your attribution tool, and how they connect to each other.
Whether the events your engagement platform and dashboards depend on actually arrive, and arrive the same way everywhere.
What's wrong, why it matters and how sure we are, in plain language your product team and developers can both read.
What to fix first, what can wait, and roughly how much work each fix is.
The events and properties you should have, written down, so the next release doesn't undo the work.
A call with the people who will do the fixing, so nothing gets lost in a PDF.
Amplitude, Google Analytics 4 and Mixpanel most often, plus the attribution tools that feed them, such as AppsFlyer and Branch. If you use something else, ask: we'll tell you straight if it's outside what we know well.
No. Read-only access is enough for the audit. We'd only ask for more if you want us to make the fixes too.
No. Amplitude is a partner of ours, but most tracking problems come from the plan and the implementation, not the tool. If the tool you have is fine, we'll say so.
Access to your analytics tools, any tracking plan or event list you already have, and an hour with someone who knows how the app or site is built.

Tell us which tools you use and what's bothering you. We'll come back with a straight answer on whether an audit is the right next step.