The symptom
Someone asks a reasonable question in a Monday meeting. How many of our clients are still losing conversions on Safari? Nobody can answer it, because answering means opening thirty accounts and remembering what to look for in each.
The thirty setups are not broken. They are just not the same. One client's purchase event is called purchase, the next one's is Purchase, a third fires conversion with the revenue in a parameter nobody registered. Two clients run server-side collection, four have consent handling that predates the banner on the site, and one has a warehouse export nobody looks at.
So every portfolio-level question becomes a project, and new people cannot be trusted with an account for weeks, because the knowledge sits per client instead of per method. When someone finally checks, the problems are in the accounts everybody assumed were fine.
Why it happens
Nothing decided this. Thirty accounts were onboarded over several years by different people, each doing sensible work on the day, on websites redesigned twice since. Drift is the default state of a portfolio, and the tools do nothing to slow it down.
The platforms work per account, and they never object
Naming is the clearest case. Per Analytics Help, there is no limit on the number of distinctly named events for web data streams. Nothing objects when the thirtieth account invents a thirtieth vocabulary. Consistency is not a setting you switch on, it is a discipline imposed from outside the tool.
Where the platform does set limits, they are per property, which quietly penalises bespoke work. The same page puts the ceiling at 25 event parameters per event, and Analytics Help allows a standard property 50 event-scoped custom dimensions. Registration is per property too, so anything you compare across clients has to carry the same name in each account before the data is collected, not after somebody asks.
What counts as a conversion is per property as well. Analytics defines a key event as an event that measures an action that is particularly important to the success of your business, and a Google Ads conversion can be created from one, per Analytics Help. Thirty properties can each hold a defensible answer, and the portfolio still has no number you can add up.
Copying a container is not the same as standardising
The usual first fix is one good Tag Manager container, imported everywhere. That mechanism is real, but read what it does. Tag Manager Help documents two import modes: Overwrite creates a new container version and then replaces the existing tags, triggers and variables with the ones in the file, and Merge keeps the current configuration while asking you to resolve each conflict by overwriting or renaming. The same page warns that exporting selected items without their dependencies removes references to the missing tags and triggers.
How well a copy lands depends on how similar the sites are. Conventions travel well: naming, folder structure, the data layer you ask developers for. Site-specific plumbing does not, and that is the part that breaks. Standard Tag Manager also allows up to three concurrent workspaces per container, a default plus two custom ones, where 360 is unlimited, per Tag Manager Help. Rollouts across thirty containers queue behind that, and drift returns while they wait.
Some drift is recoverable, and some is permanent
Retention is recoverable, within limits. On a standard property, event-level data can be kept for 2 or 14 months, the windows of 26, 38 and 50 months are 360 only, and Analytics Help states that when you increase the retention period it is applied to data that you have already collected. Which one a client property sits on is a choice somebody made. Raising it later covers what you still hold, which is not the same as recovering what was already deleted.
Cookie lifetime is not recoverable. Chrome for Developers documents a 400 day cap on cookie expiry from release M104 in August 2022, with longer values reduced to 400 days rather than rejected. WebKit states that in Safari all persistent client-side cookies, meaning persistent cookies created through document.cookie, are capped to a seven day expiry. Every month an account collects that way, its returning Safari visitors arrive as strangers, and no later fix restores the history. On a standard setup 15-30% of conversions go consistently uncaptured, and that share applies per account, not once across the portfolio.
Scale changes the answer too. Analytics Help puts the daily BigQuery export limit for standard properties at 1 million events. Identical configuration, different outcome: your largest client is where a setup that works elsewhere quietly stops being enough.
What good looks like
The target is not thirty tidy accounts. It is one standard, and thirty accounts held against it. In practice that is five things.
One event contract. Event names, required parameters, and what qualifies as a key event, written once and applied per client. Not a spreadsheet of suggestions, the definition each implementation is checked against.
A baseline that is not allowed to vary. Keep it to roughly ten items: where collection happens, how consent is handled, retention at the ceiling the property allows, the warehouse export on from day one, key events marked, revenue passed as a number. Everything outside that list may differ per client.
One state table for the portfolio. A row per client with what is live, which baseline items pass, and when it was last verified. This is what answers the Monday question in a minute rather than a week.
Enforcement in the interfaces, not in a document. Google documents the mechanisms: the Tag Manager API manages containers, workspaces, tags, triggers, variables and versions, and the Analytics Admin API manages properties, data streams, custom dimensions and the retention setting. A convention that is applied survives staff turnover. One that is only written down does not.
Change tied to releases, and watched. Releases are the most common moment for a working setup to stop working, so attach a check there and monitor in between, rather than sweeping thirty accounts by hand each quarter.
Applying one pattern across a portfolio instead of maintaining thirty is what Archon Signal is for: the same server-side collection design in each client's own accounts, the same event contract, cookie lifetime running to 400 days instead of 1-7 days, and 15-40% more conversions recovered where they were leaking. One method, thirty implementations, each documented so the next person does not have to reverse engineer it.
Be honest about the ceiling. A consistent portfolio is faster to work in and easier to trust, and it still does not produce whole numbers. Consent refusals, ad blockers and network failure remove a share of events in each account, and roughly 95% is the realistic ceiling, a ceiling rather than a promise. What consistency buys is comparability: when two clients show different numbers, the difference is the client and not the setup.
FAQ
Do we have to rebuild thirty accounts to fix this?
No, and that order is how the project stalls. Inventory first, then sort by what is permanent: accounts still collecting client-side lose history every week, so they go first, while a retention setting or an unregistered parameter can wait. New accounts adopt the standard at intake, the cheapest place to apply it, along the lines of what to check in the tracking before you onboard a new client.
Can we not just copy our best container into every client?
Partly, and it depends on how alike the sites are. On similar sites, a shared container plus a per-client configuration layer works well. On thirty platforms with thirty data layers, the reusable part is the convention rather than the container, and each import still has to be checked rather than trusted.
Would an in-house hire solve the consistency problem?
It depends on how many accounts you run and how alike they are, not on how good the hire is. One person can hold a standard across a handful of similar accounts. Across thirty, the work is less about hours than about a method repeated identically and maintained through everyone's release cycles, which is the trade-off in an in-house data hire versus an external specialist.
Is a cross-account reporting tool the answer?
It answers a different question. A dashboard over thirty vocabularies needs a mapping layer per client, which is another thing to maintain and another place to drift. It surfaces inconsistency faster, but the inputs decide whether the output is comparable. Fix the contract first and the roll-up is close to free.
If you want the portfolio view without opening thirty accounts, that inventory is where a free tracking audit starts, on whichever accounts you pick.