Data governance for a marketing stack, without the policy document

Data governance is the set of agreements about who may create, change, see and delete which data, and what that data is called.

In large organisations it turns into a forty-page document nobody opens. In a marketing and data environment you can get the same result from a handful of agreements, as long as you enforce them at the moment someone wants to change something.

Anything you only check afterwards erodes within a quarter.

One document that states which events you collect and which parameters they carry. Per event: the name, when it fires, the parameters with their type and an example value, and where it lands in GA4 and your warehouse.

That document is the source of truth, not your GTM container. Anyone adding an event edits the plan first. Only then does someone build the tag.

The reason is dull and unforgiving: GA4 accepts almost anything you send it. A typo in a parameter name produces no error, only an empty field in a report that someone notices weeks later.

Four agreements that remove most of the pain:

• snake_case, lowercase. GA4 treats event names as case-sensitive, so Purchase and purchase become two separate events in your reports.
• English, no spaces. add_to_cart, not Add To Basket. You stay aligned with GA4's own events and with what you can type in SQL.
• Names you do not invent per campaign. An event is called form_submit with a form_name parameter, not form_submit_summer_sale_2024. The campaign is a value, not a name.
• Short. GA4 truncates: event and parameter names at forty characters, parameter values at a hundred. Names that only differ at the end arrive identical in your reports.

Keep in mind that the number of event-scoped custom dimensions per property is capped, at fifty in a standard GA4 property. Every separate parameter you register costs one. That alone is a reason to keep parameters generic.

GTM has permissions at two levels: the account and each container. At container level you choose between read, edit, approve and publish. Hand out edit rights generously and publish rights to a few people. That single split means someone reviews a change before it goes live.

GA4 uses the roles viewer, analyst, editor and administrator, and you can set them per property. Invite someone as administrator only when they also need to hand out access.

In BigQuery, grant access per dataset rather than on the whole project. Marketing reads the marts, the data team writes the models, and the raw layer stays closed.

Write down what happens when someone leaves. People who move on often sit in GTM, GA4, your Cloud project and your ad accounts for months afterwards, and sometimes a scheduled export still runs under their personal account. Put service accounts and shared ownership on the organisation, not on a person.

Start with which data you want in the first place. An email address or a full postal address in a data layer is data you then have to secure, restrict and clean up. Store only what you use in a report or an activation.

In GA4 the retention setting for user and event data sits under Admin, Data settings, Data retention. Standard properties offer two months or fourteen months there. Switch on the BigQuery export and your history lands in your own project, where that GA4 window no longer applies to the copy.

Which makes retention in BigQuery your own decision. Set an expiration on datasets or partitions that matches what you use the data for, and record which tables can contain personal data.

Where all this lands contractually is the data processing agreement. Who processes which data, for what, for how long and under which terms belongs there, including towards your vendors. We wrote earlier about what a data processing agreement should cover.

• Make the measurement plan the place a change starts. No line in the plan, no tag in the container.
• Write your naming rules in one paragraph at the top of that plan, where nobody can miss them.
• Split edit from publish in GTM, and keep the publisher list short.
• Grant BigQuery access per dataset, with raw data closed and marts open.
• Review the user lists in GTM, GA4, Google Ads and your Cloud project every quarter and remove whoever left.
• Choose retention deliberately in GA4 and in BigQuery, and note per table whether it can hold personal data.
• Check that your processing agreements match what you actually send, especially once you tag server-side.