TagEasy

Tracking plan

A tracking plan is a declaration: this is what each event's payload is supposed to look like. TagEasy compares it against the events it actually sees on your site (captured in observe mode and on each tracked event's verification sample) and tells you when reality drifts from the plan.

Three kinds of drift TagEasy catches

  • Missing required fields. Your purchase event is supposed to carry transaction_id, but some recent samples don't — you'll see the count and example payloads.
  • Wrong types. value was supposed to be a number but came through as a string — flagged with the actual observed type.
  • Unexpected fields. A new key appeared in the payload that's not in the plan. Could be a desired new dimension (add it to the plan) or accidental drift from a developer's side change.

How to set one up

  1. On a website's detail page, open the Tracking Plan tab.
  2. Click Add schema, give it an event name (e.g. purchase), and list the fields you expect — each with a type (string / number / boolean / object / array) and whether it's required.
  3. Click Run drift scan. TagEasy checks every captured payload for that event against your schema and shows findings inline.

What it scans

Two sources of captured event data:

  • The live observe-mode buffer — a rolling window of every dataLayer event seen on your site over the past ~15 minutes. Populated by the TagEasy snippet you installed during setup.
  • The verification samples stored on each tracked event — one example payload TagEasy keeps for each event in your Events & Tags list, refreshed on each verification round.

That's your test corpus. The more traffic, the more samples, the more reliable the drift signal.

Undeclared events

Events that fire on your site but have no schema in the plan show up in a separate list. They're not failures — they're the starting list of things you might want to declare next. Add a schema for one and it moves into the main tracking-plan list on the next scan.

Org-wide policies (Business tier)

On top of per-event schemas, you can declare policies that apply across every schema in your tracking plan. Three built-in kinds in v1:

  • Required field on every event. Common: a client_id or session_id on every event. Every schema must mark the named field as required, or the drift scan flags it.
  • Event-name pattern (regex). Common preset: snake_case (^[a-z][a-z0-9_]*$). Any schema whose eventName doesn't match the pattern is flagged.
  • Forbidden field-name pattern (regex). Common preset: PII keys like (email|phone|password|ssn|card). Any field with a matching name is flagged.

Manage policies under Settings → Tracking Policies. The next drift scan on any website surfaces policy violations alongside the per-event drift findings.

Plan

The tracking plan editor is a Pro-tier feature. Policies are Business+ (they enforce rules across the whole org). See pricing or, for the broader monitoring picture, health monitoring.