The value of analytics data depends on its accuracy, consistency, and governance. A maintained data dictionary can be an appropriate approach where multiple teams, platforms, websites or applications must use the same measurement definitions. It does not, however, resolve incorrect tagging, incomplete journey coverage, unsuitable consent controls or weak operational ownership by itself.
A data dictionary documents the intended meaning, structure and use of marketing data. It can provide a common reference for analytics practitioners, marketing teams, product owners, developers and privacy specialists.
Its value depends on its connection to implementation specifications, testing and change control. A static spreadsheet that is not used during delivery may become another source of ambiguity rather than a control for data quality.
1. Rationale and limits
Marketing data often develops across several systems. A website may use Google Tag Manager, Tealium iQ or Adobe Launch, while reporting takes place in Google Analytics, Adobe Analytics, Matomo, a CRM, a customer data platform and advertising platforms.
Each system may use different terminology for similar concepts. One team may refer to a completed form as a lead, another as a conversion, and a third as a submission. A purchase may be counted from a confirmation page, a backend transaction, a payment response or an advertising platform import.
A data dictionary establishes the intended meaning before those differences become embedded in reporting. It can define:
- What an event represents.
- Which parameters provide supporting context.
- How a dimension differs from a metric.
- Which audience conditions should apply.
- What a consent state permits or restricts.
- Who owns the definition and its ongoing maintenance.
The approach has clear limits. It does not automatically make an implementation accurate, prevent tags from firing twice, identify every missing event or decide whether a particular processing activity is lawful. It also does not reconcile platform differences in attribution, identity, processing windows or reporting logic.
The dictionary should therefore be treated as a governance reference rather than a substitute for a tracking specification, implementation review or data quality monitoring. This distinction is consistent with the wider principles of analytics data quality, where documentation is one part of a broader control environment.
Recommended action:
- Record the intended meaning of each important data element before documenting its technical implementation.
- State explicitly which problems the dictionary is intended to address.
- Link each entry to the specification, implementation and QA evidence where possible.
- Review whether the dictionary remains useful to delivery teams rather than maintaining it as an isolated document.
2. Scope: what belongs in a marketing data dictionary
A marketing data dictionary should cover the data elements that are needed to understand, activate or govern marketing measurement. The precise scope may depend on the organisation’s platforms, customer journeys and reporting requirements.
The following categories are typically relevant.
Events
Events represent discrete interactions or system occurrences, such as:
- view_item
- add_to_cart
- generate_lead
- form_submit
- purchase
- login
- subscription_start
An event entry should describe the business occurrence, not only the technical name. For example, generate_lead may mean a successfully completed contact form, rather than every click on a form submission button.
Parameters
Parameters provide context about an event. A purchase may include a transaction identifier, value, currency, product details and payment method. A form submission may include the form type, page location, market and lead category.
Google Analytics describes event parameters as additional information about user interactions and distinguishes them from the event itself. Custom parameters may need to be registered as custom dimensions or metrics before they become available for analysis in standard reporting environments (Google Analytics event parameters).
Dimensions
Dimensions describe attributes, classifications or categories. Examples may include:
- Product category.
- Content type.
- Market.
- Device category.
- Form type.
- Customer status.
- Consent state.
The dictionary should indicate whether a dimension is event-scoped, user-scoped, item-scoped or associated with another level of analysis.
Metrics
Metrics are numerical values or calculated measures. Examples may include:
- Revenue.
- Quantity.
- Leads.
- Orders.
- Conversion rate.
- Average order value.
- Video completion percentage.
A metric entry should specify the calculation, unit, source and aggregation method. “Leads” may mean the count of accepted form submissions in one report and the count of qualified CRM records in another. The distinction needs to be explicit.
Audiences
Audiences may be defined through combinations of events, dimensions, metrics, time windows and exclusions. A cart abandonment audience, for example, could include users who triggered add_to_cart within seven days but exclude users who triggered purchase during the same period.
The dictionary should document the business purpose, inclusion conditions, exclusions, activation channels and consent requirements. Google Analytics provides separate guidance for creating and managing audiences, which can be referenced when mapping business definitions to a particular platform (Google Analytics audiences).
Consent states
Consent states may include:
- No consent recorded.
- Analytics consent granted.
- Advertising consent granted.
- Personalisation consent granted.
- Consent withdrawn.
- Consent unavailable or expired.
These states should be described in business and technical terms. A dictionary can record which tags, events and audiences are affected by each state. It should not be treated as a replacement for a consent management platform configuration, privacy notice, DPIA or legal assessment.
Recommended action:
- Start with the data elements that support material decisions, conversions, revenue or regulatory controls.
- Include web, app, server-side and CRM sources where they contribute to the same measurement process.
- Document consent states alongside events and audiences rather than treating privacy as a separate technical concern.
- Distinguish business definitions from vendor-specific field names.
3. Entry structure: definition, source, format, example, owner and status
Each dictionary entry should contain enough information to support interpretation, implementation and maintenance. A compact structure may be more effective than a large template that teams do not complete consistently.
A core entry can include the following fields:
For example, an entry for form_type might specify that it is an event-scoped string parameter, required for generate_lead, with permitted values such as contact_sales, callback and brochure_download. Its source might be the website data layer, with a marketing operations owner and an analytics implementation mapping.
The definition should also identify what the field does not mean. If generate_lead represents a successfully accepted form submission, a button click should not be considered an equivalent occurrence.
Google Analytics distinguishes between events, event parameters and user properties, and supports different types of custom dimensions and metrics. A dictionary should preserve these distinctions even where several systems use different labels (Google Analytics custom dimensions and metrics).
Recommended action:
- Make business definitions mandatory for all active entries.
- Record examples that demonstrate the expected structure and value format.
- Include negative definitions where similar concepts may be confused.
- Mark entries as deprecated rather than deleting them when historical reports may depend on them.
4. Naming conventions and vocabulary control
Naming conventions reduce ambiguity, but naming alone does not create a coherent measurement model. A standard such as lowercase snake case may support technical consistency, while a controlled vocabulary supports consistency in meaning.
A naming policy may define:
- Whether event names use verbs, nouns or a prescribed combination.
- Whether parameters describe the event object, location or outcome.
- Whether abbreviations are permitted.
- How markets, languages, products and customer types are represented.
- Whether singular or plural terms are used.
- Which words are reserved or prohibited.
- How versions and deprecations are represented.
For example, an organisation may approve generate_lead and reject a mixture of lead_created, form_complete and submit_lead where all three represent the same business action.
The dictionary should distinguish a canonical term from platform mappings. A canonical business concept such as “product viewed” may map to view_item in GA4, Product View in Adobe Analytics and a custom event in another platform. The mapping should be documented rather than allowing each implementation team to create its own interpretation.
Google Analytics provides naming rules and reserved names for events and parameters. These rules are platform-specific and should be referenced when technical names are approved (Google Analytics event naming rules).
Vocabulary control may also include an approved list of values. If a market dimension accepts UK, IE and FR, an implementation should not introduce United Kingdom, GB or uk without a documented reason. The dictionary can identify whether values are case-sensitive, translated or sourced from a master data system.
Recommended action:
- Separate the canonical business term from each platform’s technical representation.
- Maintain controlled lists for high-use values such as market, product category and customer type.
- Add validation rules for spelling, case, format and permitted values.
- Review new names against existing entries before approving them.
5. Ownership model and change control
A dictionary requires ownership at several levels. One role may not have sufficient knowledge or authority to maintain all definitions.
A workable ownership model may include:
- Business owner: accountable for what a metric, event or audience means.
- Analytics owner: accountable for how the definition is measured and reported.
- Implementation owner: accountable for the tag, data layer, SDK or server-side configuration.
- Privacy owner: accountable for consent requirements and data use restrictions.
- Data quality owner: accountable for monitoring, exceptions and remediation.
Assign ownership to roles or teams rather than named individuals where possible. Named contributors may change, while accountability needs to continue through organisational changes.
A change process should define when approval is required. A new event, a changed calculation, a modified consent dependency or a renamed parameter may affect historical comparisons, dashboards, audiences and advertising integrations.
Each approved change should record:
- The requested change.
- The reason for the change.
- The affected data elements and platforms.
- The requestor and approver.
- The implementation date.
- The expected effect on reporting.
- The rollback or deprecation approach.
Google Analytics notes that modified and newly generated events do not apply to historical data. This is one reason why a dictionary should record effective dates and version changes rather than presenting the current definition as if it applied to all historical data (Google Analytics event modifications).
Recommended action:
- Define approval thresholds for new, changed and deprecated entries.
- Assign a business owner and technical owner to each material data element.
- Record effective dates and reporting implications for approved changes.
- Include privacy review where a change affects consent, personal data or audience activation.
6. Tooling options and their trade-offs
The tool should reflect the size, complexity and maturity of the measurement environment. There is no single suitable repository for every organisation.
Spreadsheets
Spreadsheets may be appropriate for an initial inventory or a small implementation. They are familiar, inexpensive and easy to distribute.
Their limitations may include weak version control, unclear approval history, duplicated copies and limited integration with implementation workflows. A spreadsheet can also become difficult to navigate when events, parameters, destinations and mappings expand across several properties.
Wikis and collaborative documentation
Tools such as Confluence, Notion or SharePoint can provide searchable documentation and support wider collaboration. They may be suitable where teams already use the platform for delivery specifications and decision records.
The main risk is that a page can appear authoritative without having a defined owner, review date or approval process.
Data catalogues
A data catalogue may provide stronger metadata management, lineage, stewardship and search capabilities. It can be appropriate where marketing data is part of a broader enterprise data management programme.
The additional configuration and administration may be disproportionate for a small measurement operation. The catalogue may also require technical integration before it can represent tag management, consent and activation workflows accurately.
Tagging governance platforms
Specialist governance platforms may connect requirements, specifications, implementation details, testing evidence and change requests. They can support larger environments with multiple sites, applications, regions and delivery teams.
The value depends on adoption. A platform that is not used in implementation planning and release processes may provide a more expensive version of static documentation.
Recommended action:
- Select a repository that supports search, ownership, history and controlled access.
- Avoid choosing a tool solely because it can store metadata.
- Test whether implementation and analytics teams can use the dictionary during delivery.
- Define the minimum information that must be maintained before introducing more complex tooling.
7. Linking the dictionary to tracking specifications and QA processes
The dictionary describes what the data means. A tracking specification describes how that meaning is implemented.
The two artefacts should be linked at event and parameter level. A tracking specification may add:
- Trigger or collection condition.
- Data layer path or application field.
- Tag, trigger or rule configuration.
- Destination property and stream.
- Parameter mapping.
- Consent dependency.
- Required and optional fields.
- Expected firing frequency.
- QA test case and acceptance criteria.
For example, a dictionary entry may define purchase as a completed transaction recorded once per order. The tracking specification may then state that the event is sent from a server-side order confirmation service, includes transaction_id, value, currency and items, and is blocked or altered according to the applicable consent and processing model.
The implementation must then be tested against the specification. QA may include:
- Confirming that the event fires under the intended condition.
- Checking that required parameters are present.
- Validating parameter types and allowed values.
- Testing duplicate, refresh and failure scenarios.
- Confirming consent-dependent behaviour.
- Comparing event counts with a suitable source of truth.
- Checking that reports and audiences receive the expected data.
Google recommends using Realtime and DebugView to inspect events and parameters as they arrive. These tools can support implementation checks, but they do not replace broader data quality testing or reconciliation (Google Analytics event verification).
A data dictionary can also support automated QA. Required fields, permitted values and expected relationships can become validation rules. For instance, a purchase event without a transaction identifier may be flagged, while a currency value outside the approved list may fail a test.
Recommended action:
- Add a dictionary identifier or version to the tracking specification.
- Connect every material entry to at least one implementation and one QA case.
- Test both positive and negative conditions, including consent denial and duplicate firing.
- Use automated checks where validation rules are stable and measurable.
8. Measuring adoption and keeping the dictionary current
A dictionary is current only when changes in the implementation and reporting model are reflected in it. Currency should therefore be measured through practical indicators rather than document size.
Useful measures may include:
- Percentage of active events with an approved definition.
- Percentage of parameters with owners and data types.
- Percentage of implementation tickets linked to dictionary entries.
- Number of unapproved event or parameter names detected in QA.
- Number of entries overdue for review.
- Time taken to approve a material change.
- Number of production defects caused by undocumented changes.
- Percentage of active audiences with recorded consent requirements.
These measures should be interpreted carefully. A high completion rate may indicate administrative activity rather than accurate documentation. Periodic sampling can compare dictionary entries with live payloads, tag configurations and report outputs.
Review frequency may depend on change volume. A high-change ecommerce estate may require monthly review, while a stable corporate website may use a quarterly or release-based process. Reviews should also be triggered by platform migrations, rebranding, new markets, new consent requirements or changes to core customer journeys.
The dictionary should identify entries that are proposed, approved, active, deprecated or retired. This prevents inactive concepts from being reused and preserves enough history to explain reporting changes.
Recommended action:
- Set review dates according to implementation change and business risk.
- Compare selected dictionary entries with live data during each review cycle.
- Track undocumented production changes as governance exceptions.
- Archive deprecated definitions without removing useful historical context.
9. When a formal data dictionary is likely to be appropriate
A formal data dictionary is likely to be appropriate where one or more of the following conditions apply:
- Multiple websites, apps or customer journeys contribute to common reporting.
- Several analytics, tag management or advertising platforms are in use.
- Different teams create, consume or interpret the same marketing data.
- Core metrics such as revenue, leads or conversions are disputed.
- A platform migration or tracking redesign is planned.
- The implementation contains a substantial number of custom events or parameters.
- Consent states affect the collection, reporting or activation of data.
- External agencies, suppliers or distributed development teams contribute to delivery.
- Frequent changes have created duplicated, inconsistent or deprecated tracking.
- Auditability, data lineage or change history is a material requirement.
A formal dictionary may be less urgent where there is one simple website, a small number of stable events, one accountable implementation team and limited reporting complexity. Even in that situation, a concise measurement reference can reduce dependency on individual knowledge and support future changes.
The appropriate level of formality depends on risk, scale and change. A structured spreadsheet may be sufficient at one stage, while a governed catalogue or integrated platform may become appropriate as the estate expands.
10. A practical approach
A proportionate implementation can be organised into the following stages.
Stage 1: Inventory existing data
List current events, parameters, dimensions, metrics, audiences and consent states. Use implementation exports, analytics reports, data layer inspection, application documentation and stakeholder interviews.
The initial inventory should record uncertainty rather than conceal it. Mark entries as confirmed, unclear, duplicated, or requiring investigation.
Stage 2: Define the template
Create a standard entry structure covering definition, scope, source, format, examples, ownership, status, consent and technical mappings. Keep required fields limited to information that teams can maintain consistently.
Stage 3: Establish canonical terminology
Resolve duplicates and near-duplicates. Agree on the approved business terms, naming conventions and value lists. Record platform mappings separately so that vendor terminology does not become the only definition.
Stage 4: Assign owners
Assign business, analytics, implementation and privacy responsibilities according to the type of entry. Establish who can approve changes and who is responsible for review.
Stage 5: Publish and connect
Publish the dictionary in the chosen repository. Link entries to tracking specifications, implementation tickets, QA cases, dashboards and relevant privacy documentation.
A dictionary is more likely to remain useful when it is part of the normal delivery workflow. New tracking requirements should begin with a dictionary entry, proceed to specification and implementation, and conclude with QA evidence.
Stage 6: Review and improve
Review active entries against live data and current business requirements. Deprecate unused definitions, investigate exceptions and update the dictionary after platform or consent changes.
Recommended action:
- Begin with the most important customer journeys and business metrics.
- Complete a reliable core dictionary before attempting full historical coverage.
- Integrate dictionary review into release and change-management processes.
- Use QA findings and reporting discrepancies to identify missing or ambiguous definitions.
- Increase the level of tooling only when the operating model requires it.
Conclusion
A marketing data dictionary can provide a durable reference for shared definitions, consistent vocabulary and controlled change. Its capability does not remove the need for precise specification, implementation testing, consent control, governance and operational ownership.
It does not, by itself, improve data quality or fix inconsistent implementations. Those outcomes depend on connecting the dictionary to delivery processes, validating live data and maintaining accountability as platforms, journeys and privacy requirements change.
If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant.
