Add the new tag without removing the old one. They do not conflict, they will report different numbers because they count differently, and the parallel period is what makes the eventual comparison possible.

Why run both

Because the new version starts with no history and the old one has yours.

Running them together means the new property accumulates data while you continue reading the reports you already understand.

It also means that when you do move across, there is a period where both were collecting, which is the only way to understand how the two relate for your own site.

Without that overlap, a switch produces a step change in every number and no way to tell how much of it was the change in measurement.

Do they conflict

No, and this is the question everybody asks first.

Two analytics tags on the same page collect independently. Each sees the page load and records it in its own property.

Neither knows about the other and neither interferes.

The cost is one additional script on the page, which is a small weight and one more request, and worth being aware of on a site already carrying a lot.

What is not a problem: duplicate counting, confused attribution, or anything breaking. Those concerns come from a misunderstanding of how the tags work.

Why the numbers will differ

Which means comparing the two properties and finding a discrepancy is the expected result rather than evidence that one is broken.

Differences of ten or twenty percent on ordinary metrics are normal and not worth investigating.

A worked example

A business that added the second tag and immediately noticed the new property reporting fewer sessions than the old one.

They spent an afternoon assuming something was misconfigured.

Nothing was. The two count sessions differently, and the gap was consistent month to month, which is the signal that both are working correctly.

What they should have checked, and eventually did, was whether the trend lines moved together.

They did, which is the only comparison that means anything between two systems measuring differently.

The absolute numbers were never going to match and were never supposed to.

Which one to report from

The one you understand, which for now is the existing one.

Changing the measurement system and the reporting at the same time makes every subsequent number ambiguous, because a change could be the business or could be the tool.

Keep reporting from the familiar property, note the date the second one started, and leave it accumulating.

When the time comes to switch, you will have a period of overlap, which lets you state the relationship: our new property reports roughly this proportion of the old figure.

That single sentence is what makes a year of history still usable after a switch, and it only exists if both ran together.

Setting the second one up

Roughly an hour, and less if a tag manager is already in place.

Create the new property, get its measurement identifier, and add the tag alongside the existing one.

Where a tag manager is in use, that is a new tag firing on all pages, which is the tidiest arrangement.

Where tags are placed directly in the site, both go in the same place, one after the other.

Then confirm collection in both, using the real-time view, by visiting the site from a phone.

How long to run them together

Longer than feels necessary, and there is no deadline forcing a decision.

A year of overlap gives a full seasonal cycle in both, which is what makes any comparison between them meaningful for a business with any seasonality.

Six months is workable. Three months tells you the ratio between the two and not much about how they behave across a year.

There is also no requirement to stop. Running both indefinitely costs one script, and a business with no pressing reason to choose can simply keep both.

The decision point arrives when the newer reporting does something you need, or when the older one stops serving, and neither has happened yet.

Where running both is not worth it.

A site whose page weight is already a problem, where one more script matters and the analytics is barely used anyway.

A business that does not look at analytics at all, for whom the honest answer is that neither property is doing anything and the effort belongs elsewhere.

And a brand new site with no existing property, which should simply start on the newer version rather than running two.

The parallel arrangement is specifically for businesses with history worth protecting and a reporting habit worth not disrupting.

What to do about events

A practical question that arises immediately.

Any goals or events configured in the existing property do not carry across, and the new version handles them differently.

Which means form submissions and phone taps need setting up again in the new property if you want them there.

That is worth doing at the same time as the tag, because those are the only measurements that matter commercially and starting to collect them now is the same argument as starting the property now.

Half an hour, once, and the new property has the two numbers you would actually use.

Privacy settings on the new property

Worth setting deliberately at creation rather than accepting the defaults.

Data retention, which controls how long individual-level records are held, has a default that may be shorter than you expect.

Whether data is shared with Google for product improvement and benchmarking, which is optional and worth a decision rather than a default.

And the same considerations that apply to your existing property: what you tell visitors in your privacy policy needs to describe what you actually run, and it now needs to describe two things rather than one.

Updating that policy at the same time takes ten minutes and prevents a document that has quietly become inaccurate.

Anything unusual about your sector or your visitors is worth checking properly rather than assuming the defaults suit you.

Getting it running

  1. Create the new property.
  2. Add its tag without touching the old one.
  3. Confirm both collect, from a phone.
  4. Add form and phone tap events to the new one.
  5. Write down the date you started.
  6. Carry on reporting from the old one.

The fifth matters more than it looks. In two years, knowing exactly when parallel collection began is what lets anybody interpret the overlap.

What the announcement actually changed is covered in Google released a new analytics this month.


Frequently asked questions

Why run both?

The new version starts with no history. Running them together lets it accumulate while you keep reading the reports you already understand.

Do two tags conflict?

No. They collect independently, neither knows about the other, and neither interferes. The cost is one extra script on the page.

Why do the numbers differ?

Sessions are defined differently, the event model counts differently, and filtering differs. Ten or twenty percent apart is normal.

Which should I report from?

The one you understand, which for now is the existing one. Changing measurement and reporting at once makes every number ambiguous.

What is the overlap period for?

It lets you state how the two relate for your own site, which is what keeps a year of history usable after an eventual switch.

Do my goals carry across?

No. Form submissions and phone taps need setting up again in the new property, and doing it now is the same argument as starting the property now.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Worried two tags will conflict?

They will not. They will report different numbers, which is expected, and the overlap is what makes the eventual switch interpretable.

Start a Conversation