HOW TO CREATE A TRACKING PLAN FOR A NEW WEBSITE
If you want to go directly to the template I created, click here.
1. Make sure someone responsible for tracking
My first advice - before jumping into the topic - would be to make sure that someone takes care of the tracking of this new website.
It sounds stupid but it's often overlooked by everyone.
It is too technical for Marketing.
And Tech doesn't necessarily think about tracking:
They have already a lot on their plate, a website can operate without and they don’t work with the collected data anyway.
So be the one to push the topic if needed.
I hope I don’t have to convince you that you need someone to work on this BEFORE the website goes live.
If I do have to convince you, here are a few points what WILL happen if no one gives a sh*t:
- No conversions sent to performance marketing campaigns. First MASSIVE spend because the algorithm pushes to get the conversions it usually gets. Then 0, nothing, nada. No more users from your paid activity, as the algorithm can’t reach the target you set.
- No clue how your new website performs: better user engagement, better conversion rate? No idea…
- I'm sure, everyone wants to avoid this kind of discussion with the management:
- "Was this website relaunch worth it?"
- “Well look I love the new design”.
- “Ok but does it bring more leads in?”
- “Ah that? No idea…”
2. What to track? What NOT to track?
The main challenge of a tracking plan is to know what to include and what NOT to include.
To be honest, I used to say “let’s track everything and we’ll have it somewhere”.
But I’m no longer part of this club 🙂
Here some cons of this approach:
- There is an overflow of data: no one uses it, not even the relevant data, since it is drowned by useless data that makes its visualisation and interpretation difficult.
- Websites evolve with time and some events will stop being tracked in the future. If no one uses it, no one will notice. Why track it then?
- Data governance: we should track what’s relevant for us and what we use. We should have a reason why we track something.
So what I did is the following:
I took what we were tracking and using already from the current website and cleaned up events we were not using. For the events we want to keep, I then asked the dev team to call them the same way for our future website (or to utilise the same trigger elements that we were using).
I've sat down with my UX, Marketing and Product teams to find out how they worked and if they wanted to track new features.
I adopted a critical attitude. I've constantly asked them what they needed the data for.
I wanted to avoid tracking data just for the sake of tracking it.
It needs to bring value to the business.
Once I collected the info from everyone, I created 2 entities: pages and features.
Pages
Usually websites have custom pages with different templates that UX colleagues spend a lot of time on. This is what I call "corporate" pages.
I checked each single one to see if they had specific stuff to track.
Let's take an example from Zolar’s website (Eigensonne’s website no longer exists 😢):
The homepage (https://www.zolar.de/) is obviously unique.
But other pages such as https://www.zolar.de/ueber-zolar or https://www.zolar.de/partner are also unique.
On this last page, I’d probably check clicks from users that want to become partner (see screenshot below)
After the "corporate" pages, I started working on pages such as blog posts, landing pages. Pages with templates and similar layouts inside their own category.
And I added the list of events to track for each page category.
Features
On a website there are elements you can add to many pages.
It is the same element but you can add it (as a widget for example) to many pages.
It was important to me that these could be tracked independently, regardless of where they are located on the site.
A typical feature would be a registration form that could be found on the homepage, on some landing pages and maybe on another “corporate” page.
Let's take another example from Zolar website:
This widget is on the homepage but could easily be integrated to other pages of zolar’s website.
I’d probably track some user behaviour, like clicks on “zocietey” and “zolar heroes” or on “Rückruf anfordern”.
3. Creation of a document and communication
Another challenge was the communication with the development team, which is primordial. I definitely needed them to track specific events.
It is important to create a common document that will be the guide of your tracking.
A document that both parties will update before, during and even after the relaunch, as the website will evolve and so will the tracking.
We want a document that describes clearly what we need and what is expected.
I therefore created a “readMe” tab to start the document with. This tab explains the structure of the doc and how different tabs are connected to each other. I also wrote down instructions to the developers.
After that I created 2 tabs summarising all events and all event parameters that we want to track.
These are good overviews. But the negative point of an overview is that it is not really precise.
Now we enter into the details of the tracking plan.
I wrote earlier that I split between pages and features.
For each "corporate" page or page category, I created a tab in my document. Same for each feature.
In each tab I listed the events and event parameters we wanted to track.
And I wrote a precise definition in plain English of when this event should be fired.
👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇
👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆👆
And watch the video for explanations:
4. Test before release date
This article is already quite long and the testing process can vary. I would say one thing though:
Plan time to test before the big release date.
Communicate about it.
Once the website is ready, no one should hurry to release it.
After months and months of work, I could feel the pressure to release the website as soon as possible.
But communicate clearly that you'll need time to verify your part. And that it can't be done at an earlier phase.
The risks are high (check above ☝️).
In my case - and I think it will happen most of the time - not every event was working.
I therefore created priorities:
- Blocker - the super important ones that block the release.
- Major - don't block but will need to be tackled just after the release
- Minor - would be nice to have but let's see when we can get them
Your dev team needs to deal with the blockers as soon as possible.
Once they're good to go, you can give the green light!
It's party time 🎉
But it's only the beginning of a new adventure.
Your dev team still needs to work on the bugs or missing events.
And you have a new playground to run lots of optimisation to improve metrics 📈
