Data Standards: What They Are and How to Apply Them

A data standard specifies what a given field is allowed to contain — its permitted values, its format, and who is authorised to add to that list. It is narrower than a policy, which states an intention, and different from a dictionary, which records what fields mean. A standard is the thing a system can check against.

Publicly, “data standards” usually means an interoperability standard published by a body (ISO, HL7, a government schema) so that separate organizations can exchange data. Inside a company, the same word means something more immediate: the agreed set of values your own teams must use when they create a record, so that the record can be joined to every other record later.

Both senses are real, and most guides only cover the first. This page covers both, then spends most of its length on the second — because that is the standard a marketing or data team actually has to author, agree and enforce, often on people who do not work for them.

What is a data standard?

A complete standard answers five questions about every field it covers, and a specification that cannot answer all five is not yet a standard.

• Which fields you collect, and which are mandatory rather than optional.
• How those fields relate to each other: which is the key, which are attributes of it.
• What type each field holds: a key, a date, free text, an integer, a value drawn from a list.
• What validation rules apply: must be unique, must match a date pattern, must appear in the allowed list.
• Where and how each field maps to the other systems that will receive it.

That last point is what separates a standard from a preference. A field definition that exists only in the system where it was written has not been standardized. It has been documented. Standardization is the part where the same field means the same thing, and carries the same permitted values, in every system that touches it.

Two meanings of the term

“Data standards” describes two different artifacts, and which one someone means depends entirely on where they work.

The public, interoperability sense is a standard published by a body so that separate organizations can exchange data reliably. The US federal data-standards guidance describes these as the shared conventions that make data usable beyond the system that produced it — the shared conventions that let one organization’s output become another’s input. ISO standards, HL7 in healthcare and the IAB’s advertising specifications are all this kind. You adopt them; you do not write them.

The internal sense is a standard a single organization authors for its own data. Nobody publishes it. Its scope is one company’s fields and its allowed values are that company’s vocabulary. Its purpose is not exchange with strangers but consistency between its own teams and the agencies and platforms they work through.

The Data Foundation’s “Explainer: What makes a data standard a standard?” (accessed 2026-09-11) is useful here, because it sets out the criteria that qualify something as a standard rather than a convention. Those criteria are identical in both senses. What differs is who agrees, and who has to comply.

Most organizations need both. You adopt the published standards your industry runs on, and you author the internal ones that describe the data only you create — your campaigns, your creative, your audiences.

Standard, taxonomy, dictionary, policy

Four artifacts are routinely used interchangeably and do four different jobs. Getting them confused is the most common reason a “data standards project” produces a document nobody uses.

Read in that order they build on each other. The taxonomy decides that channel is a dimension worth recording. The dictionary defines what channel means and names its owner. The standard fixes the allowed values (paid_search, paid_social, display) and the format they take. The policy says every campaign must carry one.

A project that produces only a policy has an intention. One that produces only a dictionary has documentation. Neither can be checked by a system. This is the layer a machine can enforce, which is why it is the one that changes behavior.

Go deeper on the layer underneath: what a data dictionary is and how to build one — the artifact that records what each field means.

What a standard looks like in practice

A real standard is a short, specific artifact: a field, its allowed values, its owner, and the moment it is checked.

For marketing data, standards are built to capture a consistent set of fields and metadata at every point where data is created. A typical core set covers:

• Brand or company identifier
• Channel
• Campaign
• Creative
• Publisher
• Audience
• Device
• Behavior

Each of those then carries its own allowed-value list, and most organizations break them down further for the nuances of a team, region or channel: placement, content type, asset size. Too coarse and nobody can slice the result; too fine and nobody fills it in correctly.

The unifying field matters most. In marketing that is usually the campaign ID, though it can be the creative ID, the brand identifier or the channel. Whichever it is, it is the value that lets a record in one platform be recognized as the same campaign as a record in another — and it is the field where an unenforced standard costs the most.

Enforcing a standard

A rule nobody can violate is enforced at entry. One that is only reported on afterwards is a suggestion with a spreadsheet attached.

This is the distinction that decides whether a standards program works, and it is almost never the part that gets designed. Inconsistent naming across teams and systems is the problem we hear most often, across 101 enterprise accounts. Teams spend the effort on agreeing the values and almost none on the moment those values are typed. So it ends up living in a document. Agencies and channel managers apply it from memory under deadline, and somebody audits it weeks later when two dashboards disagree.

The practical difference is where the check runs. Validation applied at the point of creation, in the form or workflow where the campaign is actually built, can reject a wrong value while correcting it is still free. The same check applied in the warehouse can only flag a value that has already been used to buy media, and the record it flags may belong to an agency that has moved on.

That is also why enforcement has to reach outside your own systems. A large share of marketing data is created by people who do not work for you, in platforms your data team does not administer. A rule that can only be applied to internal users is not applied to most of the data.

Colgate-Palmolive’s ad operations team described what changed once the enforcement moved into the setup step itself.

“With these integrations in place, our agency teams can confidently set up campaigns, knowing that every element aligns seamlessly with Colgate’s taxonomy requirements.” — Eric Kirtcheff, Global Head of Ad Operations, Measurement, and Data Integrity, Colgate-Palmolive

The agency teams did not become more careful. The setup step stopped accepting values that broke the standard, which is a different and far more durable mechanism than asking people to remember a document.

How to create data standards

Authoring one is a cross-team exercise rather than a documentation exercise, and the sequence matters more than the template. These eight steps are the ones that survive contact with a real organization.

1. Determine your goals. Decide what you are trying to achieve with the data you want to capture, then work back to the technical impact.
2. Identify key stakeholders. Name every data owner, including external partners such as agencies and vendors, so decisions about metadata fields include the people who will populate them. Bring in the analysts who currently clean this data by hand, because they know which fields are already broken.
3. Schedule discovery sessions. Meet stakeholders to discuss the data they have and the data they need. The power of a standard depends on adoption, so buy-in is not a formality.
4. Define core business fields. Look for the consistencies that can serve as core fields across the business — a common Campaign Name, for instance, and separate them from channel-specific fields such as Keyword for paid search.
5. Create a data dictionary. Document what each field means and who owns it, before arguing about its values.
6. Define the standards themselves. Fix the allowed values, formats and validation rules for each field.
7. Apply the standards to teams and workflows. A standard applies where work happens, not where it is filed.
8. Connect and activate the standards in your stack. Push the agreed values into the systems that consume them, so the standard travels with the data. Which platform you use to do this is a separate evaluation — see the comparison of data standardization tools.

Most organizations never author their own standards, for three consistent reasons: requirements are hard to pin down while business and technology needs keep moving; silos make it difficult to access the formats that already exist; and tools that do not talk to one another limit how far any standard can travel. None of those are reasons not to start — they are reasons to start with one data area rather than all of them.

Standards inside a governance program

A governance framework says a standard must exist and names who owns it. The standard says what the value must be. They are not competing artifacts and neither substitutes for the other.

Getting stakeholders aligned on naming conventions and who governs them is its own distinct obstacle, raised across 80 enterprise accounts — separate from, and usually harder than, deciding what the values should be. That is the problem governance exists to solve. Governance is the wider discipline: it covers ownership, definitions and quality expectations, plus the mechanism that enforces them. A framework without standards produces a well-documented program with no operational effect, because there is nothing specific for a system to check. Rules without governance are owned by nobody, and decay the moment their author changes role.

Implementing governance in practice usually means starting with one data area. Agree its standard, enforce it at creation, then widen the scope. The programs that start with an enterprise-wide framework and work down tend to be still designing when the first one is already catching errors.

The framework that surrounds the standard: what a data governance framework contains — ownership, definitions and the enforcement point.

Where standards apply beyond reporting

Reporting is the most visible use of a standard and the least demanding one. Three others depend on the same agreed values and break more expensively without them.

Integration. Passing data between systems requires agreement on what each field contains, not just what it is called. Integration standards exist precisely because two systems with matching field names and mismatched value sets will connect successfully and produce nonsense. The regulated end of this is instructive. CMS’s measure-specification guidance treats data standards as a precondition of the measurement itself, not an administrative layer on top of it.

Asset reuse. Finding a creative asset you already own depends on it having been tagged to a standard at production. An asset library without enforced values is a folder.

AI-readiness. A model or assistant retrieving your marketing data inherits every inconsistency in it. Asked which campaigns performed, it will answer confidently over five differently-named records of one campaign, and nothing downstream can detect that the answer is wrong.

In each case the failure has the same shape. The data is present and correctly stored, and it is not comparable.

Frequently asked questions

Sources

Outbound citations, named and dated:

• resources.data.gov, “data standards concepts” (accessed 2026-09-11) — the public, interoperability sense of the term and the conventions that make data usable beyond its source system.
• Data Foundation, “Explainer: What makes a data standard a standard?” (accessed 2026-09-11) — the criteria that qualify a specification as a standard rather than a convention.
• CMS Measures Management System, “Data Standards” (accessed 2026-09-11) — data standards as a precondition of measurement in a regulated context.