Tracking an e-commerce with no access to the code
Google Tag Manager is used to add and manage a website’s tracking without changing its source code every time. Put like that it sounds like a technical detail, but the truth is far more human: in web projects, the people who need to measure results and the people who hold the keys to the site’s code often live in two separate worlds. They have different timelines, different priorities and, at times, they work for companies that have never crossed paths. This tool exists precisely to bridge those two sides.
What follows is the story of a project in which that distance looked like an insurmountable obstacle, and of how, back in 2015, we found our own way to make things work without bending the rules of the game.
Table of Contents
The constraint
IperDrive is the online grocery service of Iper La Grande i: customers order on the website and collect in store. It was launched in October 2015, when Italian grocery retail was experimenting with online shopping very cautiously. The real growth of online food retail would only come with the pandemic, in 2020.
The catalogue was that of a hypermarket, with thousands of products, on a platform built entirely to measure by another agency. ARvis, an Italian SEO agency, handled SEO and conversion optimisation.
We needed complete event tracking: product views, add-to-cart, checkout steps, purchases, order value. Without that data, every change to product pages and to the purchase flow would have been made blindly.
The obvious route was to ask the development team to add tracking code event by event. Within the project’s timeline it was not feasible, and the reason was not the relationship between suppliers but dependency: every change to the measurement plan would have queued behind product development, and in the first months a measurement plan changes often. We would have tied the pace of our work to someone else’s priorities.
The choice
We built the entire tracking from the outside, with Google Tag Manager, reading what the custom code already did instead of asking it to declare it.
The principle is simple. While it works, a page leaves observable traces: the structure of the document, the attributes of its elements, clicks, URL changes, values on screen. If you establish a reliable correspondence between those traces and the commercial events you care about, the tracking can sit on top of the site instead of inside its code.
It is not the most elegant solution, but it worked, and when the alternative was to postpone measurement, it was the right one.
The project had Valerio Amendolagine as technical lead and project manager. We built our Tag Manager expertise specifically on this job, and it has become one of the things we do for our clients.
The outcome
Complete e-commerce event tracking was delivered entirely in Tag Manager, without a single line of code added by the development team.
The most useful result, however, is another one: from then on, the people responsible for measurement could change the measurement plan on their own, without opening a request to the developers. That is what made the subsequent conversion work possible.
In practice, in a case where we could not touch the site’s engine, we learned to use Tag Manager for parametric tracking and turned what looked like an impassable wall into our strength.
Once the emergency of the start-up phase was over, Tag Manager was properly restructured around the dataLayer and according to the criteria of conventional design. The solution we used gave the development team the time it needed to build a solid, reliable implementation, which is, after all, standard practice for any good analytics setup.
The reusable method
That project left us with a scheme we still use whenever timing and logistics leave no other option.
1 – First decide what to measure, then how. The list of events is written with the people who sell, not with the people who build. If nobody knows which decision will depend on a piece of data, that data should not be collected.
2 – Look for the most stable anchors. A product identifier or a structural attribute holds up over time. A CSS class or an element’s position does not: at the first redesign the tracking breaks silently, and that is the worst kind of failure, because data keeps arriving, only wrong.
3 – Work by families, not by pages. On a large catalogue you do not configure the single product page: you recognise the type of page and apply the same rule to all of them. That way the tracking holds even when new products come in.
4 – Verify against real data. Tag Manager’s preview tells you the event fires. To know whether it fires correctly you have to compare tracked orders with recorded orders, on real numbers, over a period of time, and repeat the check.
5 – Document it. Tracking built from the outside works well, but from the outside it cannot be understood: whoever comes next must be able to know why a rule is written the way it is. And whoever comes next, more often than not, is us a few months later!
When this approach should not be used
Of course, we tell this story as a special case: a project with a pioneering side, in which speed of implementation took priority over the solidity of the tracking structure. This method cannot always be used, and it has precise limits. Here are the main ones.
It is more fragile, because it depends on the structure of the page: if the site changes often and nobody says so, the tracking degrades.
It does not see everything: what happens only on the server, such as an order confirmed after an asynchronous payment, a refund or a return, cannot be observed from the outside.
It does not replace a dataLayer: if the development team can expose data in a structured way, that remains the better road: sturdier, more legible, easier to maintain. And it is the road we consolidated on IperDrive, once the start-up phase was over.
The practical rule: build from the outside when access to the code is the bottleneck, and move to the dataLayer as soon as the bottleneck clears.
Frequently asked questions
Does Google Tag Manager replace Google Analytics?
Google Tag Manager does not replace Google Analytics: Tag Manager decides which data to send and when, Analytics is where the data arrives and is read. They are usually used together, but they do different jobs.
Do you need to know how to code to use Google Tag Manager?
You do not need to code for the basic configuration of Google Tag Manager. To track an e-commerce on a custom-built site, as a rule you do: you need JavaScript and the ability to read a page that was not written to be measured.
Does Google Tag Manager slow a site down?
Google Tag Manager can slow a site down if it is loaded badly or full of tags that are not needed. A well-kept setup weighs little, and the impact should be measured anyway. Every tag needs a reason, and the reasons need reviewing periodically.
Can Google Tag Manager track an e-commerce on a standard platform without changing the site’s code?
On a standard e-commerce platform it is simpler, because mainstream platforms already expose data in a structured way and Google Tag Manager reads it from there. Building the tracking by reading the page is needed when that structure is missing, as on custom-built sites.
How long does e-commerce tracking built with Google Tag Manager by reading the page last?
Tracking built by reading the page lasts as long as the structure it rests on. It must be reviewed after every major change to the site, which is why it has to be documented: whoever comes next must be able to understand why each rule is written the way it is.
We have been working on e-commerce data since the days when tracking was built by hand. If you run a site that sells and you do not trust your tracking, the first thing to do is check whether the numbers you read match the orders you receive.
→ Talk to us about your data







