I Inherited Multiple GA4 Properties and Dead UA: The Analytics Audit Pattern

At 3:21 PM, I found three analytics properties collecting data for the same site: two live GA4 properties and one dead Universal Analytics property.

At first glance, that looked like redundant but usable history. We had data, two current-looking properties, and a legacy property that could be ignored. It was actually an unresolved authority problem.

The question we needed to answer was simple: where do prospective customers disappear between starting signup and paying? The onboarding middle was invisible. That is exactly the kind of gap that turns product decisions into educated guessing.

It would have been easy to start adding events immediately. Instead, I stopped and audited the inherited state. An event plan built on the wrong property is only a more organized way to produce bad data.

Three properties, no authority

Two GA4 properties were live. The UA property was dead, but it was still visible to anyone opening the account. That is enough to create a bad downstream workflow.

Someone can pull a report from the property with the familiar name. Someone else can build a dashboard against the other live property. An old view can get included in a new analysis simply because it still exists. Later, the team can debate a conversion change without realizing the numbers came from different systems.

The failure mode is not that GA4 is difficult. Inherited analytics can look operational before anyone establishes what is authoritative.

My audit had a fixed sequence. First, identify the one real GA4 property. Second, set up proper read and edit API access so we could inspect and safely manage it directly. Third, map the signup funnel against what that property actually recorded. Only then did I open the build for the missing instrumentation.

The order narrows the next decision. Without a canonical property, access attaches to an unresolved target. Without access, a tracking fix becomes somebody else’s future manual job. Without a funnel map, a list of new events is just a guess about where the business problem lives.

The invisible middle

The audit ended with one real GA4 property and a mapped signup funnel. The beginning of the flow was tracked. The payment endpoint was tracked. The entire setup and onboarding middle was not.

That is where customers can quietly disappear.

We could not distinguish a customer who started setup and left from one who reached a particular step, got stuck, completed onboarding, or failed to convert later. Those are different product problems. They deserve different fixes. Without the middle, they collapse into the same useless statement: some users did not pay.

That changed the engineering task. This was not a request to add a generic signup_completed event and call the funnel done. The build needs to preserve the sequence through setup and onboarding, so we can distinguish entry, progress, abandonment, completion, and the handoff to payment. A funnel is not a total at the end. It is the ordered record of the steps that lead there.

What did not get built first

Three shortcuts were available, and all three would have preserved the bad state.

The first was to leave both live GA4 properties in play and choose one later. That might have made the tracking work move faster for a day. It would also have kept the ambiguity that made the audit necessary. A metric needs one source of truth before it can become a decision input.

The second was to build a report before correcting access. Reports are comforting because they produce a visible artifact. They are liabilities if their underlying property is not the one the team can safely inspect and manage. We needed a path to verify the implementation and change it without treating analytics as a locked cabinet.

The third was to push tracking live as soon as the gap was identified. I did not do that. I opened the build with the design settled, then left it in a draft state where nothing goes live yet. Once event names and step boundaries reach production, they become dependencies for dashboards, experiments, support investigations, and future migrations. The cheap time to make the event model coherent is before it starts generating history.

Certainty before automation

Inherited analytics work gets framed as cleanup. That makes it sound optional, like renaming folders before the real engineering begins. In this case, the cleanup was the engineering work.

The output of the first pass was not a chart. It was a canonical GA4 property, an access model we can use safely, a funnel map, and a bounded build waiting in draft. Those are the conditions that make the next event trustworthy.

Three properties pointed at one site. One was dead. Two were live. The next thing we built was not a dashboard. It was certainty about which data deserved to be believed.

dxdev LESSON · paste into your AI coding agent
LESSON: Three analytics properties pointing at one site is not redundant data, it is an unresolved authority problem
SOURCE: dxdev.com/blog/2026-08-22_inherited-analytics-messy-state
WHAT HAPPENED: Inheriting a site's analytics setup surfaced three properties collecting data for the same site, two live and one dead but still visible to anyone with account access. That created a real risk of different people building reports or dashboards against different properties and later debating a conversion number without realizing it came from a different system entirely. Rather than immediately add instrumentation to close the actual visibility gap, the entire onboarding middle between signup and payment was untracked, the work paused for a fixed-order audit: identify the one canonical property, establish safe, verified access to inspect and manage it specifically, then map the existing funnel against what it actually recorded, and only after that design any new events. Three shortcuts were explicitly rejected: leaving both live properties in play to choose one later, which preserves the exact ambiguity that caused the problem; building a report before fixing access, which is comforting but rests on an unverified foundation; and pushing new tracking live immediately, since event names and step boundaries become permanent dependencies for dashboards and experiments the moment they start generating history, making the event model cheap to get right only before it goes live.
THE RULE: Inherited tracking or analytics infrastructure that looks operational, multiple properties actively collecting data, can be an unresolved authority problem in disguise; before adding any new instrumentation, establish which single source is canonical and get verified access to it, because a new event plan built on an ambiguous or wrong property is just a more organized way to produce data nobody can trust.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any analytics or tracking setup with more than one property, workspace, or data source apparently covering the same thing, with no explicit, recorded decision about which one is canonical.
      2. Any new instrumentation or event plan being designed before establishing verified access to inspect and manage the actual system of record.
      3. New tracking events pushed live to close a visibility gap without first mapping the existing sequence of steps, risking a single completed event that collapses genuinely different outcomes, abandoned, stuck, or completed, into one meaningless total.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.