Two Live GA4 Properties Reporting on the Same Signup Funnel

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

It looked like redundant but usable history. We had data, two current-looking properties, and a legacy property we could ignore. In fact nobody had decided which property was the authority.

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

Adding events right away would have been easy. We stopped and audited the existing state first, because 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 anyone opening the account could still see it. That is enough to start a bad downstream workflow.

Someone pulls a report from the property with the familiar name. Someone else builds a dashboard against the other live property. An old view gets pulled into a new analysis because it still exists. Later the team debates a conversion change without realizing the numbers came from different systems.

Inherited analytics can look operational before anyone has established what is authoritative.

Our audit ran in a fixed sequence:

1. Identify the one real GA4 property.
2. Set up proper read and edit API access, so we could inspect and manage it directly.
3. Map the signup funnel against what that property actually recorded.
4. Only then, open the build for the missing instrumentation.

Each step 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 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 disappear without anyone seeing it.

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

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

Shortcuts we left alone

Three shortcuts were available, and each 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 becomes a decision input.

The second was to build a report before correcting access. Reports are comforting because they produce a visible artifact. They are a liability if the underlying property is not one the team can safely inspect and manage. We needed a way 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. We did not do that. We 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

Auditing existing analytics gets framed as cleanup, which makes it sound optional, like renaming folders before the real engineering begins. Here the cleanup was the engineering work.

The first pass produced 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 and two were live. The next thing we built was certainty about which data deserved to be believed.

Before any new tracking

Confirm which analytics property is authoritative and that your team has read and edit access to it. Map the signup funnel against what that property recorded, because without the map a list of new events is a guess. Hold new tracking in draft until event names and step boundaries are settled, since they become dependencies once they reach production.

dxdev LESSON · paste into your AI coding agent
LESSON: Three analytics properties pointing at one site are an unresolved authority problem, not redundant data
SOURCE: dxdev.com/blog/inherited-analytics-messy-state
WHAT HAPPENED: Taking over 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), we 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. We explicitly rejected three shortcuts: 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.