You Installed GA4. Now Prove That It’s Actually Tracking.

There is a particular kind of confidence that comes with pasting a Google Analytics tag into a website.

You copy the code, put it where Google tells you to put it, save everything, and assume the job is finished.

Then you open Google Analytics and it says: No data received.

The website is live. The Measurement ID is there. You are pretty sure you did everything correctly. Yet Google is sitting there telling you that nothing is happening.

This is where a lot of people get stuck, because they treat GA4 installation as a single task. It isn't.

Creating the property is one task. Installing the tag is another. Getting the website to send data is another. Then there is verifying that Google is receiving the data and, for ecommerce stores, making sure the data actually describes what customers are doing.

That distinction matters because a website can have a perfectly created GA4 property and still have broken tracking.

The Measurement ID isn't the tracking

When you create a GA4 property, you eventually create a Web data stream for the website. Google gives that stream a Measurement ID beginning with G-.

That ID is important because it identifies where the data should go.

But copying the ID does not magically connect the website to Google Analytics.

The website has to load the Google tag and send information back to the correct property.

This is where the installation method becomes important.

If you are using a platform such as Shopify or WordPress, there may be a built-in integration, plugin, app, or other supported method for connecting Analytics. If you control the site's HTML directly, you can install Google's gtag.js code in the site's <head>.

And if you are using Google Tag Manager, the process is different again.

The mistake is treating all of these as interchangeable.

They aren't.

You can have the correct Measurement ID sitting inside your Analytics account while the actual website is doing absolutely nothing with it.

The first test should happen in Realtime

Once the tag has been installed, don't immediately start worrying about the main reports.

Test the website.

Open the site in your browser and then open the Realtime report inside GA4. Visit a few pages. If the tracking is working, your visit should appear as an active user.

This is one of the simplest ways to separate an installation problem from a reporting delay.

It is also why the GA4 interface can be confusing when you are setting up a new property.

You might see a warning saying that data collection isn't active while Realtime is already showing an active user.

That happened during the setup documented in the source material. The Analytics interface was still displaying a "No data received" message, while Realtime showed one active user. The important evidence was the actual incoming activity, not the warning sitting at the top of the screen.

In other words, don't let one message inside Analytics make the diagnosis for you.

Test the thing you are trying to measure.

If you don't see yourself, start with the website

When Realtime shows nothing, the next question isn't "Why is Google Analytics broken?"

It is much simpler:

Is the tag actually on the website?

One quick check is to open the page source and search for the Measurement ID.

If the site's source contains the expected G- ID, at least some version of the tracking code has made it onto the page. If the ID isn't there at all, you have probably found the problem.

You also need to consider how the code was installed.

A tag pasted into a page's content is not the same thing as a tag installed in the site's header. A tag entered into the wrong platform setting may never load. A tag installed twice through different methods can create another set of problems.

And your own browser can interfere with testing. Ad blockers, privacy settings, consent systems, and browser extensions can prevent analytics requests from being sent.

That is why a clean test matters.

Open the website without extensions interfering, visit a few pages, and watch Realtime. If the user appears, the basic connection is working.

If they don't, work backwards from the website rather than randomly changing settings inside Analytics.

Ecommerce tracking is where this gets more serious

For a normal website, knowing that someone visited a page can be useful.

For an ecommerce store, it isn't nearly enough.

Imagine someone visits a perfume store.

They land on a product page. They look at the product. They add it to their cart. They start checkout. They purchase.

If GA4 only knows that somebody visited the website, you are missing most of the information that actually matters to the business.

Ecommerce tracking uses events such as view_item, add_to_cart, and purchase to describe those actions.

Now the analytics starts becoming commercially useful.

You can investigate which products receive attention but fail to convert. You can look at where customers drop out of the buying process. You can compare traffic sources against purchases instead of simply comparing them against visits.

That is a very different use of analytics.

The goal isn't to collect more numbers.

The goal is to collect the right numbers.

This is where Google Tag Manager can help

As a website grows, tracking can become a collection of little pieces of code scattered across the site.

One script for Analytics. Another for an advertising platform. Something for form submissions. Another event for an important button. More tracking for ecommerce actions.

Eventually someone needs to change something.

Now the developer is being asked to edit the website because the marketing team wants to track a new event.

Google Tag Manager can make this easier by giving you a central place to manage many of those tags and tracking configurations.

That doesn't mean every website needs an elaborate GTM setup.

A small brochure site may need very little tracking.

An ecommerce store running Google Ads, Meta Ads, email campaigns and multiple conversion events has a different problem.

The tracking system should reflect the business.

Bad tracking creates good-looking mistakes

This is the part that tends to get overlooked.

A broken website is usually obvious.

A broken analytics setup can look perfectly healthy while quietly giving you the wrong answer.

Suppose your advertising platform says it generated a certain number of purchases, while GA4 records something completely different. Or ecommerce events fire twice. Or a purchase event isn't firing at all.

You can still open a report. You can still make a chart. You can still discuss the numbers in a meeting.

The problem is that the numbers may not describe reality.

That can affect decisions about advertising budgets, product performance, landing pages, SEO and conversion rate optimization.

This is why analytics setup should be treated as part of the business infrastructure, not as a piece of code you install once and forget.

The installation is finished when you trust the data

A proper GA4 setup is not:

Create property → paste code → done.

It is closer to:

Create the property → create the data stream → install the tag correctly → test the website → verify Realtime → configure the events that matter → check that those events are recording correctly.

That last part is particularly important for ecommerce.

Getting one active user to appear in Realtime proves that something is working. It does not prove that your purchase event is correct, that revenue is being recorded properly, or that your entire measurement system is ready for decision-making.

Those are separate questions.

And that is probably the most useful way to think about GA4.

Don't ask, "Did I install Google Analytics?"

Ask, "Can I trust what Google Analytics is telling me?"

Those are two very different questions.

Installing the tag gets data moving.

Verification tells you whether it is moving correctly.

And good measurement begins when you stop treating those as the same thing.