Last Updated on: September 17, 2026
Contents
Key Takeaways
- Tools pass through what you give them. CDPs route incoming data with complete efficiency, meaning bad event naming pollutes your warehouse, CRM, and ad platforms immediately.
- Standardize event naming. Use the object_action format across every team without exception.
- Separate user traits from group traits. Keep individual attributes isolated from company metadata to prevent broken identity resolution downstream.
- Divide team responsibilities clearly. Marketing defines business needs, analytics validates the schema, and engineering implements the code.
- Automate schema enforcement. Use your CDP to block or quarantine invalid payloads in flight instead of relying on spreadsheets that no one reads.
Why do most CDP implementations fail?
Teams buy a Customer Data Platform with grand ambitions. They drop in the SDK, start streaming events, and let engineers and growth marketers invent properties on the fly.
Six months in, the dashboard is a graveyard: 47 distinct variations of page_viewed, 12 flavors of button_click, and zero usable cross-functional audiences.
Naturally, leadership blames the tool.
The CDP did not deliver on the full customer view.
The tool didn’t fail you. The absence of a tracking plan did.
What does schema rot actually look like?
When governance doesn’t exist, chaos doesn’t announce itself with a loud error code. It creeps into your operations quietly:
- Analytics runs a critical conversion funnel and gets three wildly different conversion rates depending on whether an analyst queried signed_up, User Registered, or account_created.
- Lifecycle Marketing fires an onboarding sequence to users who already upgraded three weeks ago because someone changed a user trait key in code without telling downstream consumers.
- Marketing requests an audience of high-intent product evaluators. The data team cannot build it because no two teams agreed on what constitutes high intent in the event payload.
The CDP is a pipe and a router. If you feed it sewage, it distributes sewage to your data warehouse, your CRM, and your email automation platform with ruthless efficiency.
After dozens of enterprise CDP implementations, the pattern is predictable: Teams that design governance before connecting sources get clean, reliable data in weeks. Teams that skip it spend the next year cleaning up technical debt instead of driving revenue.
What belongs in a CDP tracking plan: events, properties, and traits
A tracking plan is not a suggestions document. It is a contractual agreement between Product, Engineering, Marketing, and Analytics.
It dictates what gets tracked, how it is named, what metadata travels with it, and what happens when a payload breaks the rules.
Core architecture
- Behavioral Events: object-action syntax
- Event Properties: Contextual payload and data types
- User Traits: Individual-level attributes via identify calls
- Group Traits: Account or organization context via group calls
Event naming: the object_action standard
Consistency here is binary: you either have it, or your analytics are useless.
Standardize on lowercase object_action format.
| Standard (object-action) | Forbidden Examples |
| form submitted | submit_form, Form Submit, lead |
| product viewed | viewProduct, User Saw Product |
| subscription upgraded | upgrade, clicked_upgrade_button_v2 |
No exceptions.
No promises to clean this up in the warehouse with dbt later.
Warehouse transformations should model business logic, not apologize for sloppy tracking.
Properties: context and typings
Events without structured context are meaningless. If form_submitted fires without the form identifier, downstream destinations cannot route the lead.
- Required Properties: The event payload fails validation if missing (such as form_id or form_name).
- Optional Properties: Helpful context that will not break downstream logic if null (such as form_location or referral_source).
- Strict Typings: A property named revenue must always be a float or integer, never a string formatted as $49.00. Timestamps must strictly follow ISO-8601 formatting.
Identity separation: user traits vs. group traits
One of the fastest ways to corrupt identity resolution is mixing user-level attributes with account-level attributes in your identify calls.
- User Traits: Attributes unique to the human behind the screen (email, first_name, role, lifecycle_stage).
- Group Traits: Attributes that belong to the tenant or organization (account_name, plan_tier, arr, seat_count).
Treat your namespaces with discipline. A user can switch organizations; tying company metadata directly to the user record breaks multi-tenant analytics.
Who owns data governance: marketing, analytics, or engineering?
Governance breaks down when teams disagree on ownership, not because of technical API limits.
A sustainable data pipeline requires distinct ownership across three pillars:
- Marketing and Product own the why and what. They identify what customer actions represent business value, define the required context, and document the use case.
- Analytics and Data Ops own the standard. They ensure the proposed event follows the global schema, does not duplicate existing telemetry, and adheres to naming and typing rules.
- Engineering owns execution. They instrument the code, write the unit tests, verify payload emissions in staging, and maintain the delivery pipeline.
The 15-minute approval workflow
Before any new event reaches production, it runs through a lightweight approval loop:
- Request: Marketer or PM submits event spec with business justification and payload mockup.
- Review: Data owner signs off on schema compliance within 24 hours.
- Deploy: Engineer instruments the tracking and tests against the schema validator.
If this takes more than 15 minutes of review time per request, your process is too heavy. If you skip this step entirely, your schema will collapse within two quarters.
In practice, each review takes about 15 minutes. That 15 minutes is the difference between a tracking plan that holds and a schema that becomes fiction within a quarter.
Without a formal approval step, events accumulate without governance. One team adds button_clicked. Another adds click_button. A third adds cta_click. All three mean the same thing. None of them are usable together.
How do you scale a tracking plan beyond the core schema?
A common mistake is trying to track every button click, hover, and scroll depth on Day 1. That is not a tracking plan; that is noise.
Phase 1: The core 10
Start with the 10 foundational milestones that define your customer lifecycle:
- Account Created or Signed Up
- User Authenticated
- Core Value Action Completed (such as dashboard_created or file_uploaded)
- Checkout or Upgrade Started
- Subscription Created or Modified
- Workspace Member Invited
Phase 2: Lifecycle deprecation and archiving
As your product evolves, tracking must evolve with it. You need an explicit lifecycle for retired events:
- Deprecate: Flag the event as inactive in your tracking repository. Instruct engineering to remove the trigger from new code paths. Leave the historical definition intact for legacy reporting.
- Quarantine: After 60 to 90 days of zero ingress volume, remove the event from active real-time schema validation.
- Never Hard Delete: Keep the historical schema documentation accessible. Analysts running multi-year cohort comparisons will need that context.
How do you enforce a tracking plan automatically?
A tracking plan living exclusively inside a spreadsheet or documentation page is an aspiration, not an enforcement mechanism.
Modern CDPs, whether you run Segment or Hightouch, allow you to turn documentation into automated security gates:
- Upload the Contract: Convert your tracking plan into a machine-readable JSON schema within your CDP.
- Block or Quarantine Violations: Configure the CDP to intercept malformed events in flight. Prevent bad data types or unregistered events from ever polluting your CRM, ad platforms, or data lakehouse.
- Set Up Real-Time Alerts: Route validation failures directly to a dedicated communication channel so the team that introduced the regression can patch it immediately.
How do you fix a broken tracking plan in three weeks?
If your current CDP implementation is already overrun with dirty data, you do not need to burn it down and start from scratch. You need a systematic sprint.
- Week 1: The Raw Audit. Run the same kind of stack audit you would run on any tool. Export every unique event name and property key firing in your production stream. Map them against real business needs. You will likely find that 40% to 60% of your current event volume is either broken, duplicated, or consumed by nobody. Kill the dead weight immediately.
- Week 2: The Contract Build. Lock the cross-functional team in a room. Define the global object_action conventions, map required user and group traits, and build the approval workflow.
- Week 3: Automated Enforcement. Upload the new schema to your CDP validation engine. Set up violation alerts, configure destinations to only ingest approved events, and run your first team-wide review on a real product feature.
Clean pipes, reliable revenue
The gap between companies that extract massive ROI from their customer data platforms and those that view them as expensive line items isn’t budget, headcount, or vendor selection.
It is governance.
When your schema is treated as production code, versioned, tested, and guarded, your analytics deliver truth, your campaigns trigger precisely, and your engineers stop wasting sprint cycles fixing broken pipelines.
Frequently asked questions about CDP data governance
What is a CDP tracking plan?
A CDP tracking plan is the written contract that defines every event your customer data platform is allowed to collect, how each event is named, and what properties travel with it. It sits between your product and your CDP, so marketing, analytics, and engineering all read the same definitions.
What is the object_action event naming convention?
The object_action convention names an event after the thing acted on, then the action taken, in lowercase: form submitted, product viewed, subscription upgraded. It keeps every team writing the same event name instead of inventing submit_form, Form Submit, and lead for the same behavior.
What is the difference between user traits and group traits?
User traits describe the person, like email, role, and lifecycle_stage. Group traits describe the account or organization, like account_name, plan_tier, and arr. Mixing them breaks identity resolution the moment a user moves between organizations.
Who should own data governance for a CDP?
Ownership splits three ways. Marketing and product decide which customer actions carry business value, analytics and data ops enforce the naming and typing standard, and engineering instruments the code and tests the payloads.
How long does it take to build a tracking plan?
Three weeks is enough for most teams. Week 1 audits what is already firing, week 2 locks the naming conventions and the approval workflow, and week 3 uploads the schema to the CDP and turns on validation.
Can you fix schema rot without reinstrumenting everything?
Yes. Start by killing the 40% to 60% of event volume that is broken, duplicated, or unused, then apply the new schema to what survives. Deprecate retired events rather than hard deleting them, so multi-year cohort reporting still works.
About the author
Dan McGaw is the founder and CEO of McGaw.io, and was head of marketing at Kissmetrics before that. He is one of the original growth hackers, and he has spent the last decade building CDP, attribution, and analytics stacks for companies that got tired of guessing. Everything above is the tracking plan his team runs on real implementations.
Ready to fix your CDP data? McGaw builds CDP governance frameworks that scale. Get a free tracking plan audit.
Leave a Reply