Most dataLayer implementations start clean. Someone designs a sensible event schema, documents it, and ships it. Six months later, three different developers have each pushed events using their own naming conventions, nobody remembers what half the parameters mean, and your GA4 event reports are a mix of form_submit, formSubmitted, and submit_form all meaning slightly different things.
This isn’t a tooling problem. It’s a convention problem – and it’s entirely preventable with a schema that’s actually enforced, not just documented once and forgotten.
Pick one case convention and enforce it everywhere
snake_case or camelCase – it genuinely doesn’t matter which you pick, but pick one and make it non-negotiable across every event name and every parameter name. Mixing conventions is the single most common source of dataLayer drift we see during audits. GA4’s own built-in events use snake_case (page_view, form_start), so we default to snake_case for consistency with what GTM and GA4 expect natively – but a well-enforced camelCase schema works just as well.
Use a verb_noun pattern for event names
Consistent structure matters more than the specific words you choose. We use {verb}_{noun}: submit_form, click_cta, view_pricing, start_checkout. This makes event names predictable enough that a new developer can guess the correct name for a new event without checking documentation first – which is exactly the point.
Namespace parameters that are page or feature-specific
Generic parameters (page_type, user_status) can stay flat. But parameters specific to one feature or one team’s area of the site should be namespaced to avoid collisions: checkout_step, checkout_payment_method, rather than a bare step or payment_method that could mean something different in a different part of the dataLayer six months later when someone else builds a different feature.
Version your schema changes, don’t silently mutate them
If you need to change what a parameter means or restructure an event, don’t just change it in place – that silently breaks historical data comparability with no warning. Either add a new event/parameter alongside the old one during a transition period, or explicitly document the change date in your SDR (Solution Design Reference) so anyone querying historical data knows exactly when the definition changed.
The SDR isn’t optional busywork – it’s the thing that prevents this entire problem
A Solution Design Reference documenting every event, every parameter, its type, its accepted values, and which team owns it is the single highest-leverage thing you can do to prevent dataLayer drift. Not because documentation is inherently valuable, but because a well-maintained SDR is what a new developer actually checks before pushing a new event – if it doesn’t exist, they’ll just guess, and guessing is exactly how you end up with three different names for the same action.
A minimal practical schema to start from
{
event: 'submit_form',
form_name: 'contact_page',
form_location: 'footer',
form_destination: 'sales_team'
}Predictable verb_noun event name, flat parameters where generic, namespaced where feature-specific, and every field has an obvious, guessable purpose without needing to open documentation to understand what’s happening. That predictability is the entire goal – a dataLayer schema succeeds when a new team member can extend it correctly without being told how.