We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.

Web Analytics and Tag Management for Beginners

Introduction to web analytics

The role of a technical web analyst is, by nature, multi-disciplinary. They will find themselves straddling the boundaries of their organisation’s data teams, IT function, privacy team and the digital marketing team, all with competing requirements and demands coming to them from all angles. Early recognition of this, as well as the critical role your data will have to the decision-making of these groups, will be key to your success in the role and in amplifying the value of web analytics to your business.

It is key as it guides you away from unstructured and ad hoc work in tag management interfaces with a view only to answering the pressing question of the day or getting the next tag, towards strategic thinking about how your website and business functions, towards what data points will offer sustained value over time and to building out of a robust, reliable and rich data set that anticipates questions and helps your business to quickly make good decisions and tailor the customer experience with confidence.

In web analytics then, as with much else, planning and stakeholder communication is key. We therefore recommend that that is where all web analysts start out – with a robust needs analysis process - whether they’re designing an implementation for a new website or they’re inheriting a solution that is underdelivering on the insights and reliability front.

Analytics needs analysis and planning

Here at Merkle, we adopt a ‘goal tree’ based approach to help our clients decide what to track. This approach recognises that whilst most clients only have one or two key goals that they want their users to achieve when visiting their site, a business cannot effectively understand or optimise the experience with only information on whether a user has achieved the intended goal. Instead we recommend that you think about the tens or hundreds of smaller interactions that users will take on the site, that build up to that end goal, and think about those in the first drafts of your measurement plan.

To illustrate this point, consider a standard ecommerce website. It’s trivial to say that the key goal for most will be the placing of an order. If you were only tracking those orders, alongside the pageview or sessions that come of the box with web analytics solutions, it would not be so trivial to find where there was room for improvement. Is it your checkout funnel that is the problem? Or is it your product pages? Do you know whether there even is opportunity in your conversion rate and whether the easiest next dollar would come from focusing on improving average order value?

Example goal tree

By considering these types of questions in advance, you can find the levers that will be at your disposal for future optimisations and, crucially, you can anticipate many of the questions that will come down the line, while also prioritising what to collect.

Once you’ve decided what will be key for your analytics implementation, you need to stop and consider what other functional requirements you’ll need to satisfy. It could be that your IT team will expect to use the web analytics tool to detect JavaScript errors on the site, and to monitor page loading performance. You’ll need to speak to them and clarify what they’re expecting and capture it in your implementation design.

It could also be that your marketing function will expect you to manage their media pixels for them. These usually come with bespoke tracking requirements and typically expect different data formats and, on occasion, personal identifiers like email addresses and phone numbers to be passed to them. Again, you’ll need to speak to these stakeholders and confirm upfront what they’ll require.

At this stage, it’s time to distil your requirements – with associated business cases – down to something more tangible in the form of a data layer design, and get this implemented.

Using the data layer

Your data layer will serve as the origin of the data that flows from your website out to the various platforms onto which you are responsible for feeding data. This is why it’s important to produce robust documentation that is both easy for your developer team to take away and implement, but also for other team members to understand what’s available and find the data they personally need.

This ease of use means that your documentation must be specific about when data must be available, as well as the exact format and the exact type in which the data should be available. It also means your documentation should become a living, breathing document, current with what’s on the website as you should expect it to outlive the implementation phase and be in use for the duration of your site’s lifespan. 

Example data layer

With your design available, you will need to collaborate with your developers to make sure that they get it right and there is no misunderstanding. You will also need to set expectations with your developers and their managers that implementing a data layer is rarely a last-minute job. As such, it’s important at the early stages of any implementation that you’re getting buy-in from the stakeholders so that they can plan the work in to their sprints and so that they can produce effort estimates, but also so that they see the value in the work. If this isn’t done, you will undoubtedly find the work deprioritised in the site’s core functionality as the launch date approaches, and it’s rare that the work ever gets reprioritised when go-live bugs are being caught and squashed later on. As such, missing the boat at this stage can mean spending months without good quality data and, ironically, make it harder to identify and prioritise the exact bugs that are ahead of the data layer in the priority list.

Tag manager and analytics set up

Once you get to the stage where the data layer is substantively complete, it is then time to turn to the user interface of your tag manager to set up the collection of the data to your analytics, and marketing tools. In many ways this is the ‘easy’ bit, as you could in theory start working independently without involving your stakeholders around the business. We caution you against this approach though.

If you want to keep your new-found friends over in the Privacy and IT teams, it’s especially important to keep them in the loop at this stage. For the former, it will be important that you keep them aligned on, for example, how you’re technically incorporating use consent in to your set up as well as when finalising the list of technologies that will be installed on the site. In all likelihood, any contract review stages will have included a privacy review for each technology but it’s important to keep them in the loop in case any specific controls were agreed that have been lost somewhere along the way.

For your IT team, their involvement is important as you will want to coordinate any code releases on to your site. While the risk from using a TMS and established technology vendors is very low, you will want to know that they’re on hand in case anything goes wrong and that you’re also not making changes when other business critical processes are being updated. It may also be that you’re working on a site with strict content security policies and, in that case, you’ll need IT involved to allow-list any recent technologies before publishing them live.

Example flowchart

At this stage it’s also common to fall into a few implementation pitfalls. The most widespread problem is when working with media pixels or similar tools where you’re provided with implementation guides to ‘copy and paste’ into the page. While most tag management solutions support this – for example with Custom HTML tags in Google Tag Manager or Custom JavaScript Tags in Ensighten – we recommend you take the time with each tag to check there aren’t templated tags available within your tag manager for the tool you’re implementing. These templates, as well as standard built-in variables and – as opposed to custom coded solutions - will make your implementation more robust and more maintainable.

Another widespread problem is in failing to get the sign-off from the stakeholder requesting the implementation. We recommend you help your team understand how to test their tool to meet the acceptance criteria of the end requester and that you get your IT team to QA the release prior to go-live.

Ongoing maintenance of your tag manager set-up

Once your main implementation project is complete, you need to make sure you have robust processes in place to maintain your solution properly. This covers many things, but one of the easiest things to overlook is the continuation of the relationships you built up over the implementation project. If you stay connected with your IT teams, you’ll be able to steal a march on any new analytics or implementation work required for new features or areas on your site. These relationships will also be helpful in making sure that future site changes don’t break your data layer and in agreeing reasonable processes for releasing new versions through your TMS.

Besides just new features, you should consider how you’ll keep your container fresh by establishing processes for removing tags when your marketing teams no longer require them as well as ways of working where your privacy team can easily audit and request changes to keep your set up compliant.


In summary, running and maintaining the analytics and tag manager infrastructure for your site effectively and in the way that adds the most value is going to require you to speak to many stakeholders across your business. Not only that, but it will require you to maintain shareable documentation so that the many teams you work for can ‘self-serve’ and access the data they need; understanding what will be possible, as well as advocating strongly for yourself and inserting yourself in to ways of working, to make sure your implementation remains complete and valuable, and your tag manager remains slim and privacy safe.  Once you’ve done this you can move on to helping the team to get the most out of the data, tackling projects like site optimisation, audience segmentation, or more sophisticated reporting via BigQuery and automation tools

If you would like to discuss how we might be able to help you to meet your analytics needs, do reach out and contact us.