Browse the docs
Creating a tracking plan
Last updated on July 14, 2026
A tracking plan is the single reference that describes every event your site should send, plus the properties and parameters each one must carry. In Tag Insight, the plan lives inside your project and drives your data quality work: Audits compare what your site actually sends against what the plan says it should. This guide covers creating a plan, defining events, and keeping it accurate over time.
Create your plan
Open your project and go to the Tracking plan module in the sidebar, then to the Tracking plans submenu. This is where all the plans for your project live: create a new plan here and give it a name your whole team will recognise.
If tracking is already running on your site, you do not have to start from a blank page. The Detect tracking plan submenu runs a Reverse Tracking Plan: it generates a plan from your existing site, which you can then review and clean up instead of documenting everything by hand. The Chrome extension includes Reverse Tracking Plan too, so you can capture from your site while browsing, even without a TMS.
Define events, properties and parameters
Each entry in the plan describes one event: its name, its event type, and the properties and parameters it must include. Be precise here, because an audit can only flag what the plan defines. If a property is required, say so; if a parameter has expected values, document them.
Use consistent, human-readable naming. A plan that developers, analysts and marketers all read the same way is the one that actually gets followed.
Reuse definitions with the Library
Instead of redefining the same event or property in every plan, build them once in the Library. The Library holds reusable definitions shared across projects: events, properties, parameters, event types, JS function templates and solutions. You will find it as a submenu of the Tracking plan module, and at the organisation level under Workspace settings.
When your plans reference Library definitions, a naming convention or a property spec is corrected in one place and stays consistent everywhere it is used.
Keep the plan as your source of truth
A plan only pays off if it matches reality. Use Audits, under the Tracking plan module, to check your dataLayer against the plan: the Overview and Error distribution views show where implementation drifts from the spec, and the results list tells you exactly which events failed. Set up schedules so audits run regularly rather than only when something looks wrong; audits are unlimited on every plan.
Make it a team rule: when a tracking change is requested, update the tracking plan first, implement second, then run an audit to confirm the site now matches the plan. That order is what keeps the plan, not tribal knowledge, as the source of truth.
Was this helpful?
Ready to try it yourself?
Start a free 14-day trial and run your first audit today.
Get started for free