TLDR: The audit hands you a list of everything wrong. That list is not a to-do list, it is raw material for a decision about what to fix first. Prioritise on two axes: how much a fix unblocks, and how feasible it is. The feasibility line is drawn by one question, whether the data is already on the page, which splits the work into quick tag-manager wins and slower developer builds. Fix what unblocks a real decision, ship the cheap wins immediately, and turn on your raw data import today.
Click to discuss this article with your favourite AI
At the end of an audit you have a list of everything that is broken, ranked by severity, each item tied to a decision it blocks. The instinct, a good and tidy instinct, is to go and fix all of it.
If you have the developer capacity and the budget to do exactly that, go ahead, fix the lot. But almost no business I meet actually does. There is a product roadmap already full, a small team and a finite number of developer hours that everything competes for. In the real world, trying to fix everything just means the important fixes queue behind the trivial ones and the trust you were rebuilding arrives late, or never.
So the list from the audit is not a work order. It is the raw material for a prioritisation, and that prioritisation runs on two questions at once: how much does this fix unblock, and how hard is it to do.
Impact and feasibility, not one or the other
Impact you already have, because every finding is tied to a decision from the very first step. A fix that finally lets you answer “which of our homepage banners actually drives a sale, and which one we should pull” is worth more than renaming a channel that comes through as “email” in one report and “Email” in another, even though the rename is the easier job. Start from the decisions and the important fixes sort themselves.
But feasibility is the axis people forget, and it changes the plan completely, because some of these fixes take an afternoon and some take a quarter. Treat them as one undifferentiated list and the afternoon fixes get stuck behind the quarter-long ones, and nothing ships. So before you sequence anything, you split the work by who has to do it.
The line between a tag-manager fix and a developer build
There are two lanes, and exactly one question decides which lane a fix goes in: is the data already on the page.
A tag manager can only work with what the site already hands it. If the information you need is sitting in the page’s data layer, the tag manager can catch it, reshape it and send it on, no developer or release required. Fixing a channel name that comes through inconsistently, firing an event when someone reaches the payment step, tracking whether people use the filters, these are tag-manager jobs. Fast, cheap, and often shippable inside a week. This is the lane I can clear myself or assist your team with.
The moment the data is not on the page, the tag manager is helpless, and no amount of cleverness changes that. Say you want every report split by loyalty tier, gold, silver and bronze. If the platform already pushes each customer’s tier into the data layer, that is a tag-manager job I can do in an afternoon: read it, register it, done. If it does not, there is nothing to read. The tier is simply not there, and it cannot be conjured. Now it is a developer build, because someone has to make the platform expose the data before anything downstream can use it.
That single question, is the data on the page, is the honest divide between a quick win and a project. It is also why “just add tracking for X” is sometimes an afternoon and sometimes a sprint, and why anyone who quotes you the same effort for both has not looked.
The two lanes get prioritised differently
The tag-manager lane is self-contained. Either I do the work directly, or someone on your side with access to the tag manager does. Either way it sits outside the engineering roadmap entirely, which is exactly what makes it quick. It still needs someone to review, test and publish each change, so it is not quite effort-free, but these are small jobs measured in days, not sprints.
The developer lane is a different game entirely, because those fixes do not compete with each other. They compete with the whole product roadmap. Your tracking change is one card in a backlog that also holds the checkout redesign, the search overhaul and the feature marketing already announced. It will not win a slot by being tidy. It wins by being tied to a decision the business actually cares about, which is exactly why the work started with decisions and not metrics. Part of my job at this stage is not filing a ticket. It is making the case that answering a specific question is worth more than whatever it would displace on that roadmap.
Ship the cheap wins, queue the rest
So the plan almost writes itself. The tag-manager fixes ship first, because they are nearly free, not because they are the most important. You take the easy trust back straight away. The developer builds get ordered by the value of the decision each one unblocks and taken into the roadmap conversation as candidates, not commands.
Two things not to do. Do not hold a free fix hostage to a big one, waiting to do it all together. And do not pretend a build will happen just because you put it on a list. A fix sitting on a backlog nobody has prioritised is not a plan, it is a wish.
The one thing to do today, regardless
There is a single item that ignores all of this prioritising, and I raise it with every client on day one: turn on the raw data export to BigQuery.
It is not really a fix. It is insurance. It costs almost nothing to run, it takes a few minutes to switch on, and here is the part that matters, it is not retroactive. It only captures data from the day you enable it forward. Every day it stays off is a day of raw, event-level history you can never get back. You may not need it for six months, until the day someone asks whether the customers who bought a discounted title ever came back and bought at full price, a question GA4’s own reports cannot answer. Turn it on today, so that when you do need it, six months of raw history is already sitting there instead of a standing start. It is the cheapest high-value thing on the entire list, and it has nothing to do with priority. Just do it.
Then the numbers are worth watching
Ship the quick fixes, queue the builds by the decisions they unblock, and start banking the raw data, and something shifts. The numbers stop being suspect. Slowly, the reporting you were right not to trust becomes reporting you can. Which is the point at which it is finally worth building something that watches those numbers for you and tells you when to look. That is next.at is next.
Finding it hard to prioritise?
If your team keeps saying it will “fix the tracking” and never does, the problem is usually that the list was never prioritised. I sort the quick wins from the developer work, ship what I can myself and make the case for the rest.