Guide
Why analytics documentation is always lost
Analytics work produces very few files and a great many links. The measurement plan is a Google Sheet. The dataLayer spec is a Notion page. The dashboard is Looker Studio. The container is a GTM URL. The decision about why an event was renamed is a Slack thread. The client sign-off is an email.
None of that lives in a repository. It lives wherever the person who made it happened to make it, and the index — if there is one — is somebody browser bookmarks bar. So the answer to "where is the measurement plan for this client?" is a search through chat history, every time, by whoever needs it.
The two axes that actually matter
Generic bookmark managers organise into folders, which forces a single hierarchy. Analytics work has two dimensions that both matter constantly, and folders can only express one:
- By client
- The question you ask most: everything for Acme, in one place. This is what you need at the start of a call, during a handover, and when someone asks a question about an engagement you last touched three months ago.
- By type
- The question you ask when building something: how did we document the dataLayer spec for the last three ecommerce clients? Filtering by type across clients is how you reuse your own good work instead of starting from a blank page.
Tags carry the third dimension — the concerns that cut across both. consent-mode, server-side, migration, handover. Those are the ones you want when a regulation changes and you need every client where consent wiring is relevant.
What to keep here
- Measurement plans and solution designs — the current version, not the one attached to an email in March
- dataLayer specs handed to developers, so the next question about a parameter has an answer
- Dashboards and reports the client actually looks at, which is rarely all of the ones you built
- GTM containers and GA4 properties, linked directly, so nobody hunts through account pickers
- Tickets and threads carrying decisions — why an event was renamed, why a filter was added
- Vendor documentation you look up repeatedly, which for most practitioners is the same eight pages forever
The handover case
The real test of any documentation system is what happens when the person who built the tracking leaves the project. If everything is in their bookmarks and their Slack DMs, the answer is a week of archaeology and a handful of decisions nobody can explain.
A shared, client-organised library makes handover a conversation instead of an excavation. This is also why it belongs in a workspace rather than a personal account — documentation that only one person can reach is not documentation, it is a personal filing habit.
What this is not
Good for
- Agencies juggling many clients
- Keeping the current version findable
- Onboarding someone onto an engagement
- Reusing your own past work as a template
- Handover when someone leaves the project
Not a replacement for
- A wiki or knowledge base with real content
- Version control on the documents themselves
- A measurement plan — write that first, then bookmark it
- A project management tool