Data governance for analytics

Analytics governance is the set of decisions about who can see the data, how long it is kept, who may change what a metric means, and what happens to all of it when you stop paying. It is nobody's favourite meeting and it is the difference between a measurement system that is still trusted in two years and one that quietly stopped being trusted eighteen months ago without anybody announcing it.

It is also, in this market, unusually tractable. Most governance frameworks are written for data warehouses holding millions of customer records. Analytics governance is smaller, and a large part of it can be removed entirely by choosing a tool that does not collect the thing you would otherwise have to govern.

The four questions governance has to answer

Who can see it. Analytics data is usually less sensitive than customer records and is usually far more widely shared, which is a poor combination. Decide who needs access, and check whether your tool's pricing works against you: a tool that charges twenty dollars per additional seat produces exactly one outcome, which is a shared login, and a shared login means no access control and no audit trail at all. Seat pricing is a governance question disguised as a commercial one.

How long it is kept. Retention is a control, not a default. Longer is not better: it increases what a breach would expose and what a disclosure request would cover, while adding nothing after the point where you have stopped comparing against it. Two to three years covers year-on-year comparison for almost everybody.

Who decides what a metric means. This is the one people forget and it causes the most damage. If two people can create two goals both called signup with different definitions, every number built on top of them is contested. Somebody has to own the dictionary.

What happens when you leave. Export format, API access, and whether history survives cancellation. A measurement system is supposed to give you a long baseline, and a baseline you lose at renewal was never one.

The event dictionary, and keeping it honest

Every analytics implementation older than a year has events nobody can define. The fix is boring and it works.

Keep a single document listing every event and goal, what it means in plain English, where it fires, who owns it and when it was last reviewed. Keep it in version control next to the code rather than in a wiki nobody opens, so a change to an event and a change to its definition arrive in the same pull request and are reviewed together.

Name things consistently: object then past-tense verb, lower case, underscore separated, with variable parts in properties rather than in the name. Review the list quarterly and delete what nobody has queried. An event nobody has looked at in a year is costing you allowance, adding noise, and making the list harder to trust.

The governance failure to watch for is renaming. Changing what an event means without changing its name silently rewrites your history, and anybody comparing against last year is now comparing two different things without knowing it. Retire the old name and create a new one instead.

Access, retention and the paperwork

Three practical controls, in descending order of how often they are actually implemented.

Named accounts, not shared ones. This is where seat pricing bites. Tools that include a sensible number of seats by tier, or that charge nothing per seat, make good governance the path of least resistance. Pirsch includes unlimited members on its entry plan, Mixpanel and Amplitude give unlimited seats on every plan including free, Plausible and Absolutely Analytics include three and ten by tier, and Simple Analytics charges twenty dollars a head, which will produce a shared login in most organisations within a month.

Retention set deliberately. Check the default and change it. GA4's default retention is short and surprises people. Pirsch and Matomo offer very long or unlimited retention, which is a feature only if you have decided you want it.

The paperwork, proportionate to the data. A data processing agreement, a named set of sub-processors, and a note of where the data is stored. If the tool stores no personal data at all, this shrinks to almost nothing, which is the cheapest governance available. If it stores identifiers, you also need a documented process for finding and deleting one person's data within a month of being asked, and that process should be tested rather than assumed.

When you need the heavier machinery

Some organisations need governance features rather than governance habits, and it is worth knowing when you are one of them.

If you must evidence who accessed what to an auditor, you need an audit log. If access must be granted and revoked centrally through your identity provider, you need SAML single sign-on. If different teams may see different properties or different levels of detail, you need role-based access control rather than one shared view. If the data must not leave your infrastructure, you need self-hosting and no hosted tool will satisfy the requirement, however good its paperwork.

Piwik PRO is built for precisely this buyer and includes consent management, granular retention and anonymisation controls and enterprise access management. Matomo self-hosted gives total control at the cost of operating it. Most of the cookieless field offers SSO and audit logs only on negotiated enterprise arrangements rather than on published tiers, so if you need them, ask before you plan around them.

The cheapest governance is not collecting it

Every control above exists because data exists. Remove the data and most of the controls stop being necessary.

A tool that never writes an IP address has nothing to anonymise, nothing to expose in a breach and nothing to retrieve for a subject access request. A tool with no cross-day identity has no visitor profile to delete. A tool that sets no cookie has no consent record to keep, no preference centre to maintain and no evidence of consent to produce if somebody asks for it.

This is not an argument against governance. It is an argument for making the governance surface as small as the job allows, and then governing what is left properly. The organisations that struggle here are usually the ones running a tool that collects far more than they will ever analyse, and then building policy to control the excess.

The rest of the field

Common questions

Related guides