Google Analytics 4 is now the default property

Last week Google renamed its App + Web properties to Google Analytics 4 and made them the default. Create a new property today and that is what you get, unless you go looking for the old option. Every owner who saw a headline about it has asked us the same thing: do we have to move?

No. Not this year, and not in a hurry. There is one job worth doing this month, and it takes about twenty minutes.

What actually changed

This is not a new coat of paint on the reports you already read. It is a different way of counting.

• The model is events, not sessions. In the old properties a pageview is a pageview and a goal is a goal. In the new ones everything is an event, including the pageview, and you decide which events count as conversions.
• It is the default for anything new. Existing properties are untouched and still collecting exactly as they were. Nothing broke on your site last week.
• It does not bring your history with it. A new property starts counting the day you create it. There is no import of the last three years.
• The reporting is thinner today than what you are used to. Some of the reports an office manager opens every Monday are either missing or live somewhere unfamiliar. Google is clearly still building.
• The pitch is about measurement with fewer cookies. Google has been saying for most of this year that browsers are closing off cross-site tracking, and this is the product built for that.

That last point is the one that matters for the long run. Chrome said in January it plans to phase out third-party cookies within two years. Apple’s tracking prompt is coming to iPhones early next year after the delay announced in September. Measurement is going to get harder, not easier.

Why we are not moving reporting yet

A dental practice or a plumbing company asks analytics four questions. How many calls and form fills came in. Where they came from. Which pages produced them. How that compares to last month.

Universal Analytics answers all four today, in a setup your team can already read, with two years of context behind it. The new properties do not, yet. Rebuilding your monthly reporting on a product that is still filling out its report library is work you would do twice.

We are also leaving Google Ads conversion tracking alone. Conversions in the ads account stay on the Google Ads tag and the call reporting inside it, not on an analytics import. Fewer moving parts between a phone call and the number the bid strategy is optimizing toward.

The dual-tagging setup we are using

The argument for acting now is the history. A property created in January starts with nothing. A property created this week has a full season of data by the time the reporting is worth using. So we are collecting into both.

1. Keep the existing property as the source of truth. Monthly reports do not change. Nobody on the client side has to learn anything.
2. Create the new property from inside the old one. The setup assistant in the admin panel makes it for you and offers to reuse the site tag already on the page. For most sites running gtag.js, that means no new code.
3. If the site runs through Tag Manager, add a configuration tag. New measurement ID, fires on all pages, publish. Ten minutes on a site we built, a little longer on one we inherited.
4. Mark two or three things as conversions. Phone tap, form submit, and the click into the booking widget if you have one. Not fifteen events. Two or three, matching what you already call a lead.
5. Push data retention to the longest setting offered. The default is short and the longest available is fourteen months. Change it the day you create the property, because it is not retroactive.
6. Then leave it alone. Look at it once a quarter to confirm it is still collecting. Do not rebuild reports on it.

If you run an old analytics.js snippet rather than gtag.js, this is also a decent excuse to get the tagging on your site cleaned up, because the newer tag is what everything else will expect.

What tagging both does not fix

Plenty of owners believe analytics is the measurement problem. On a local business site it usually is not.

• Calls. No version of analytics knows who called, whether anyone answered, or whether the caller booked. That needs tracking numbers and recordings, and it is the single biggest reporting gap we find in new accounts.
• Embedded forms and booking widgets. If your form or scheduler lives on another domain inside an iframe, analytics sees the click into it and then goes blind. The submission record lives in the CRM, and the CRM has to be the count you trust.
• What happened after the lead. Booked, showed up, spent money. That is the only chain that tells you which campaign was actually worth running, and it comes out of your own systems, not a tag.

The businesses that will handle the next two years of browser changes well are the ones whose records live in their own CRM and phone system. Analytics becomes a directional check on top of that, rather than the only source.

What to do this month

• Create a new property alongside your existing one this week and set data retention to fourteen months.
• Confirm the site is tagged with gtag.js or Tag Manager, and fix it if there is a decade-old snippet in the footer.
• Mark phone taps, form submits and booking clicks as conversions in the new property. Nothing else.
• Leave your monthly reporting exactly where it is. Do not move the report the office reads.
• Get call tracking in place if you do not have it, because that gap costs you more than any analytics version will.
• Write down what a lead means to you in one sentence, and make sure every tool counts the same thing.

The short version: collect now, report later, and put your effort into the parts of measurement that analytics was never going to cover. If you want a hand with the tagging, it is part of how we build and maintain local business websites, and it feeds the conversion tracking behind every Google Ads account we run. Owners doing this themselves can see how we work with businesses directly.