-
My tracking plan looked perfect on paper. Then we tried to build it.
Posted by on April 23, 2026 at 9:01 amIt took me a week and a half to create this beautiful spreadsheet. All events are named in a proper way. All trigger conditions recorded. Page groups based on business objective. I was even proud of it. I Forwarded it to the dev who does our GTM work. He spent ten minutes or so looking at it, and returned with three questions which I was unable to answer. First, he inquired about what to do to distinguish between clicking the add to cart button on a product page and the same button on a quick-view modal. I had not even realized that the modal was there. Second, he indicated that one of my page view events did not have a distinct URL pattern since the site is on hash routes that do not reload the page. I was not aware that it was a thing. Third, he inquired what to do when a user makes a submission to a form but the submission fails to pass validation. I had just been following successful submissions. So my ideal plan was not perfect since I had holes in it that I could not see since I was simply clicking through the site as a regular user, not examining the actual code or edge cases. And now we are constructing tags anyhow and finding more holes each day, so the plan is practically useless and we are just making it up as we go. Has anybody ever prepared a tracking plan that has ever been in touch with actual development? Or do we all simply believe that the spreadsheet is a draft and the actual plan is to be written in GTM? I felt that I spent a lot of time doing something that did not seem to be useful and looked professional.
-
1 Reply
-
Comments for reading later
-
You’re not alone. Based on what I’ve seen people discuss in analytics Slack groups, most tracking plans are treated as a “blessed draft” rather than a spec. The real plan gets written directly in GTM as you debug. A few teams have started using analytics-tracking-automation Skill (GitHub search for that exact phrase) to flip the workflow. It generates the plan from the live site hash routes, modals, validation states included then builds the GTM container. The install is npx skills add jtrackingai/analytics-tracking-automation. No spreadsheet heroics required upfront.
-
One thing that jumps out from your post is that you built the spreadsheet by clicking through the site as a normal user, and that is exactly where the gap lives. A tracking plan really needs to be built from what the DOM actually does, not from what the happy path looks like. Next time you sit down to do this, try opening DevTools and looking at the Event Listeners tab before you write a single row. That will show you every click handler, modal trigger, and form submit listener on the page, including the ones that fire on validation failures. You will also see that for hash routes which do not trigger a full page reload, standard page view tracking based on URL changes will not work, and you will need to figure out how the site is pushing history states instead. Those are not things you would ever catch by just browsing the site like a regular user, but they are the first things a developer or a tag implementation tool will trip over.
-
The three questions your developer asked you are actually a fantastic checklist for your next tracking plan, and if you add them to your template you will catch most of the holes before you ever hand it off. First, always verify whether the same button or UI element appears in multiple contexts, such as both on a product page and inside a quick-view modal, because those will need different trigger conditions even if the button label is identical. Second, check how the site handles navigation, and if it uses hash routes or the History API for client-side transitions, you will need custom event triggers for page views rather than relying on URL changes. Third, for any form, track both the submission attempt and the successful submission separately, because a validation failure still represents user effort and intent, and if you only track successes you will significantly undercount how many people tried to complete the action and failed. Add those three sections to your planning template and you will save yourself and your developer a lot of back and forth.
-
Honestly, the most successful tracking plans I have seen people share in analytics forums treat the spreadsheet as a draft rather than a final deliverable. The real plan tends to emerge during GTM setup, when the person doing the implementation inevitably finds mismatches between what the business wanted to track and what the site actually fires under real conditions. A better workflow that avoids the situation you are in now is to start with a very lightweight event list that only includes event names and rough trigger descriptions, then build a minimal GTM container in Preview Mode as quickly as possible, and only after that go back and document what actually worked. That way your documentation becomes a record of reality rather than a wish list, and you are not spending a week and a half polishing a spreadsheet that falls apart ten minutes into a developer’s review.
-
I think you’re overcomplicating it. And this is something most people do.
You don’t need to go through every action and click. You need to figure out what is valuable, what KPIs you will be optimizing on, and rank actions on usefulness.
So you probably need to start in reverse, from where you want to get to.Are you going to build a funnel? Figure out what actions you need for it and what the funnel steps are.
Are there forms? Then you just need form submits (ideally through the datalayer and a trigger that only fires when the form is validated) and add what data you consider necessary in your reports.
Adding everything you can will make everything too complicated and a nightmare to maintain. Don’t set up tags or send data you’re not going to use.
Log in to reply.