Today, we’re going to dig into the topic of data governance and its related preoccupations: data stewardship and data design. 

Before you scroll away, please know this is more likely to be connected to questions you’ve had before than you may realise. Keep reading if you’ve ever asked yourself one (or several) of these questions: 

• Could I access some sweet user data on {something}?

• Why does it seem like two different parts of the data for {something} are describing the same thing? Or another version of this: Wait, I thought {this thing} was called {something else}.

• Why does {Team A} have a data definition for {name} while {Team B} seems to use another definition? 

• How could I get someone to add some dimension to our data, because I’d like for us to collect {new information}?

All these questions connect with data governance, stewardship, and design. 

And the difference between a young data organisation and a more established one is whether they have enshrined some best practices about these matters and have a process for how to move through these questions — a repeatable, accountable, documented process.

To my left: The young data organisation where, in service of a faster time-to-market, new data points are added as needed wherever they seem to best fit; and anyone with a good presenting reason could get whatever data they need (provided, of course, they know who to ask or how to get the data themselves).

To my right: The mature data organisation that did once enjoy the more flowing operation they used to have but realised it was a liability in terms of data privacy, in terms of data quality, and in terms of scalability. And so, eventually, got to formalising its governance.

Data governance matters if:

1. You want to control the protocol and verification for getting access to data — only users or services that need certain sensitive data have access to it — and enshrine objective criteria for getting access. In a media organisation, sensitive data information can include things beyond just payment or user info — someone’s reading usage on your site is more sensitive than you may appreciate.

In fact, in the U.S. there has long been some legal protection for this kind of data being accessed: The 1988 Video Privacy Protection Act prevents the release of a patron’s video club rental records to just anyone who asks. Consider it an early example of data governance for media! 

(Sidebar: This law still does get used in our digital media world. Some interesting modern-day cases rested on it.)

2. Have a pathway to stop the flow of data to users or services that should no longer have access to it. In media, we usually tend to have technology stacks that bring in various levels of vendor tech, and, particularly in advertising, there are third-party exchanges happening all over the place. So we can’t just open a data pipe over to a system without a manner to end it.

3. Have a way to audit who and what data is being used. In media, this one is particularly important in case of breaches, since one aspect of laws like GDPR is that the breached organisation has a requirement to inform the specific affected users (so, audit needs right there) and to convey what data was stolen. 

But generally speaking, and even beyond the compliance need that rests on the ability to audit data systems and pipelines, there is also an efficiency issue: It is, alas, rather easy for a data-requesting system to make a lot of greedy requests down from another data-giving system. The flow of data can quickly balloon and incur either unreasonable costs (all that flow of data usually racks up a bill) or stress such systems. So it’s in the organisation’s interest to have ways to observe data flows to be able to improve them to “just” what is needed.

Data stewardship matters if:

1. You want to make sure the data you are creating is coherent even as it evolves. 

2. The data is able to serve stakeholders across a variety of organisation goals — even if this data is primarily created or collected by a more limited part of the organisation. For example, subscription data may be created and collected by a team close to subscription engineering, but many teams across the organisation will be using this data. So the way we create this data is of interest largely beyond the data’s creator stakeholder.

Data design matters if:

1. You want to make sure we agree on the overall principles for how we describe things in our data: how granular we are, whether we take object-driven approaches or action-driven approaches.

2. We standardise how we call things so that what is called “an active user” by one part of our data is also the same definition for an active user in other areas.

If you’d like to subscribe to my bi-weekly newsletter, INMA members can do so here. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .