The symptom

You took over the account a few weeks ago, the client wants a report on Monday, and you have opened GA4 three times looking for numbers you would put your name on.

Google Ads and GA4 disagree about the same month. Several conversion actions carry near-identical names, more than one is still counting, and nobody can tell you which one was being reported. Tags fire, events arrive, nothing throws an error, and that is the hard part: there is no red flag to point at.

Then the part that is not technical. Nobody asked you to audit anything. They asked you to continue a story told in quarterly reviews for two years, using numbers you cannot defend.

Why it happens

You did not inherit a tracking setup. You inherited the residue of a few hundred small decisions, almost none of which were written down.

Nobody recorded what the events were supposed to mean

Somebody once decided that a newsletter signup counts as a conversion, that a phone click counts too, that the purchase event should fire on the confirmation page rather than the payment callback. Each was probably defensible on the day. Undocumented and stacked on each other over several years, they become a measurement system nobody can explain, which is less wrong than unaccountable. That is the ordinary condition of an account that has changed hands, not proof of negligence.

It matters for how you talk to the client, because part of what looks broken is not. Between 15-30% of conversions go uncaptured on setups built competently, because consent refusals, ad blockers and browser restrictions remove a share of events no configuration recovers. Call the whole thing incompetent and you will be wrong about a large piece of it, in the meeting where that costs you the diagnosis.

The account remembers more than the people do

The most useful thing about an inherited setup is that it keeps its own records, and almost nobody opens them. In Analytics, change history "provides a record of changes made to an account over the last 2 years" and logs "Changed by: Which Analytics user performed the activity", though you need the Editor role to see it, per Google's change history documentation. Google Ads keeps the same window, listing "the changes made to your account, campaigns, and ad groups during the past 2 years" with the email address of whoever made each change through the interface, per Google Ads Help.

That is often enough to reconstruct the story without anyone's cooperation: the week a conversion action was duplicated, the day someone switched attribution, the month the container stopped being republished. Two years is also a hard edge, and on an older setup the decisions that matter most are usually the oldest ones.

Some settings reach backwards, and collection never does

This is the part the audit checklists skip. Fixing the tracking is not one action with one date attached.

Google documents both behaviours on the same screen. Changing the reporting attribution model "applies to historical and future data", so pulling that lever rewrites conversion numbers already sitting in last quarter's deck. Change the lookback window instead and it "applies going forward", leaving history untouched. Two adjacent settings, opposite temporal footprints, both in Google's attribution documentation.

Collection is the strict case: an event that was never sent is not in the dataset, and no configuration change puts it there afterwards. The account splits into two problems, what it measures from now on, which you can fix, and what it measured before you arrived, which you cannot.

The evidence may already have expired

Before you promise an investigation into the past, check the retention setting. On a standard property, user-level data can be kept for 2 months or 14 months, with 50 months on 360 only. The nuance most posts have backwards: it "does not affect standard aggregated reports (including primary and secondary dimensions)" and "only affects explorations and funnel reports", per Google's data retention documentation. Monthly totals survive, the ability to interrogate them does not. You can see that leads fell off in March without being able to explore who those users were. Raising the setting helps from that point on, since an increase "is applied to data that you have already collected and that you have not already deleted", but it resurrects nothing already deleted.

You may not control it yet

Then the unglamorous blocker. In Tag Manager, "at the container level, users can be granted read, edit, approve, or publish rights", and publish means "full rights to create versions, workspaces, make edits, and publish", per Google's container access documentation. If the container lives in the previous agency's account and your access stops at edit, you can build a fix you cannot ship.

What good looks like

The instinct is to rebuild clean, and sometimes that is right. The order matters more than the choice.

Take a baseline before you touch a tag. Record what the setup measures today, with the date on it. It is free now and impossible to reconstruct later, and it is the only thing that separates "the number moved because we fixed the measurement" from "the number moved because we changed the campaigns".

Decide repair or rebuild on continuity, not tidiness. A rebuild gives you a setup you understand and a clean break in the client's year-over-year reporting. A repair keeps the reporting comparable and keeps assumptions you will never fully trust. Which one wins depends on how hard the client leans on year-over-year, whether a bidding strategy is learning from the existing conversion actions, and whether anyone can still explain what the current events mean. If nobody can, the comparability you are protecting is already an illusion.

Announce the break before it lands. A shift you predicted is competence. The same shift found by the client in a report is an accusation, and it lands on you. Our piece on how to explain a tracking problem to a client has the version that does not throw the previous agency under a bus.

Then fix what decides how much arrives at all. Archon Signal is the server-side collection layer we build for this position: events collected first-party, so consent handling, ad blockers and browser restrictions take a smaller bite than from a standard browser-side setup. It does not repair the history, nothing does, and it does not get you to the whole truth either, roughly 95% is the honest ceiling.

On the performance agency we did this for, tracking prevention was affecting 38% of client traffic, now recovered. Measured conversions rose 26% once collection was rebuilt, and reporting work that cost 14 hours per project stopped needing a person. Which part of the mess was structural and which part was a forgotten decision is what a tracking audit covers.

FAQ

Should we rebuild from scratch or repair what is there?

It depends on whether the historical comparison is worth protecting. Repair first if a bidding strategy is learning from the existing conversion actions, rebuild if nobody can explain what the current events measure. The middle path is underrated: leave the existing events untouched, build the correct ones alongside, and run both until the overlap explains the difference.

Do we tell the client the previous agency got it wrong?

Tell them what the setup measures and what it misses, with dates, and let the conclusion form itself. You have to separate the two causes anyway, because some of the gap is structural and would exist under any agency, and some is a decision made once and never revisited. Blaming your predecessor also invites the client to wonder what you will look like to the next agency.

The client already pays for server-side tracking. Does that mean the setup is fine?

Not on its own. Server-side infrastructure is straightforward to buy, and a container configured once and never validated fails in the same ways a browser-side setup does, just less visibly. Check whether events actually reach it, whether consent state travels with them, and whether the ad platforms receive what the container thinks it is sending. Having the tool is not the same as having it set up right.

How long before we can trust the numbers?

Getting to a documented answer about what is broken is fast, usually days rather than weeks, because the account's change history does much of the work. Having a dataset you trust takes as long as your reporting period, because you need a full cycle on the fixed setup before any comparison means something.

If you have taken over an account and cannot tell which half of it to trust, a free tracking audit gives you that answer in writing before your next client report.