From Google Analytics to Cloudflare Web Analytics: why I switched and what you really lose

For years I installed Google Analytics on almost every site, mine included, almost by reflex. Then I asked myself how many of those statistics I actually looked at, and at what price: a consent banner on arrival, a heavy script, incomplete data because of visitors who decline, and visitors' browsing data sent to a third party. That is why I am migrating to Cloudflare Web Analytics, starting with this site. Here is why, how it works technically and what you lose, without pretending it comes for free.

The problem with Google Analytics

Cookies, consent and missing data

Google Analytics 4 identifies the browser with its own cookies (_ga and the property ones) and builds an identifier that links visits together. In Europe this in practice requires the visitor's prior consent: data protection authorities, including the Italian one, have repeatedly challenged the use of Analytics and the transfer of data outside the Union. The result is a banner everyone sees as soon as they land on the site.

The banner is not just an aesthetic nuisance: it skews the numbers. Visitors who decline are not counted, or are estimated with statistical models through Consent Mode. I was making decisions on partial data, collected at the cost of a worse experience for everyone.

Weight and complexity

The Google Tag script is one of the heaviest JavaScript resources on a lightweight site, and the consent banner adds another, often with its own library. On a site built to load fast (I explain it in React or Vue, which one? Nuxt.js) that meant two layers of third-party code for a tool I used at ten per cent.

An oversized tool

GA4 is designed for marketing: events, conversions, audiences, campaign attribution. For a portfolio site or a blog the questions are much simpler: how many visits, where they come from, which pages work, how fast the site is for the people actually using it.

How Cloudflare Web Analytics works

No cookies, no identifiers

Cloudflare Web Analytics writes no cookies or local storage in the browser and, according to Cloudflare's documentation, does not use fingerprinting based on IP address or user agent. There is no visitor identifier: a visit is counted from arriving on a page (from another site or a direct access), not from recognising the person. Data is presented in aggregate form: page views, visits, referrers, country, device and browser.

Two ways to install it

If the domain goes through the Cloudflare proxy, analytics is switched on from the dashboard and injected into pages on the fly. Otherwise you use a small script with a token, loaded asynchronously. This site is deployed on Netlify, so I use the second option: in nuxt.config.ts the script is added to the head only in the production build, so local development and previews do not pollute the data.

It works with a single-page app

A Nuxt.js site, after the first load, changes page in the browser without reloading. Cloudflare's script follows these page changes through the History API, so the supported navigations can be measured without adding a second tracker by hand. I check the behaviour on the site's real routes.

Core Web Vitals from real visitors

This is the part I use most. The same script measures LCP, INP and CLS on visitors' devices and shows them per page, with the elements responsible for the worst values. It is real data, not a lab simulation, and it arrives without waiting for the site to have enough traffic to show up in Chrome's data.

What you lose, plainly

• Events and conversions. There are no custom events or goals: no "button click", no funnels. I count enquiries from the forms I receive, which is the number that matters anyway.
• Per-user analysis. No individual visitor paths, cohorts or returning users: that is exactly what makes the tool privacy-friendly.
• Google Ads integration. Anyone measuring the return on paid campaigns needs Analytics or an equivalent tool, with a banner done properly.
• Sampling. At high volumes Cloudflare samples the data: trends are reliable, the exact count down to the single visitor is not.
• Ad blockers. Some block this script too. No browser-side tool counts one hundred per cent of visits.

How to migrate

1. Check what you actually use in Analytics: if it is visits, pages and referrers, Cloudflare is enough.
2. Add the Cloudflare script and let it run in parallel for a few weeks, to compare trends.
3. Remove Google Tag. Before removing the banner, check the whole site, including scripts, embedded content and other tracking tools, even without cookies.
4. Update the privacy policy: the tool still has to be declared, as I did on this site's privacy page.
5. Keep Search Console, which does not depend on Analytics and remains the source for searches, impressions and clicks from Google.

Checks on the Nuxt.js configuration

The production mode of the build alone does not tell the public site apart from previews: even a preview is normally compiled for production. Including the script must depend on the publishing context, or on a variable set explicitly for the public site only.

In the Network tab I check that the preview does not send the beacon and that production loads it only once. Then I try direct access, internal navigation and the Back button, checking the requests without adding a second manual count. For SPAs Cloudflare uses, depending on browser support, the Soft Navigations API, the Navigation API or an integration with the History API.

The absence of cookies must be kept separate from the overall assessment of the processing and of the site's other tools.

References: Cloudflare and SPAs, Italian data protection authority guidelines.

My take

It is part of the same way of working I apply to code: few tools, each with a clear job, no dependency added out of habit. This site is built with Nuxt.js, generated ahead of time and published with GitHub and Netlify with a preview for every change (I explain it in Deploying a site with GitHub and Netlify): adding a banner and a heavy tracking script for numbers I did not look at would have gone the opposite way. The same principle leads me, for sites that do not need a rich admin panel, to suggest leaving WordPress and its chain of plugins, as I describe in From WordPress to Nuxt.js, GitHub and Netlify. Google Analytics remains the right tool when paid campaigns are at the centre of the project; for everything else, today I choose less data and cleaner data.

Why work with me

Since 1999 I have delivered more than 300 projects and measured many sites for more than 30 agencies, from Rome and remotely. I set up visitor analytics together with the site: the right tool for the project, configured so it does not weigh on speed and respects visitors' privacy.

If you want to review how you measure your site, get in touch: in a call of about 20 minutes we can work out what you really need. The service is under Technical SEO and site speed.