How to Check If Google Analytics Is Working

Check Google Analytics by opening the correct GA4 property's Realtime report, visiting your public website and looking for that visit. Then use Google Tag Assistant and DebugView to confirm the events and their parameters. A tag appearing in the page source proves installation, but you also need evidence that the intended activity reaches the right property once.

Test an outcome that matters to your business, too. If Niwa helps visitors choose products or services, inspect the resulting enquiry, booking or purchase separately from the conversation itself. A working page view does not establish that those outcomes are measured correctly.

Start with a controlled visit

Note the GA4 property and web stream you intend to use. In the stream details, check the measurement ID against the configuration on your site. If you maintain several client sites, this prevents testing a tag that sends perfectly valid data to the wrong business.

Open a test browser with WordPress logged out. Disable an ad blocker for this controlled test, record the time, and follow the site's consent flow normally. Visit two distinctive pages so you can recognize the sequence. Do not change consent behavior for ordinary visitors just to make a test appear.

Open Realtime in the correct property. Check the reported activity and page information, using a stream comparison where needed. On a busy site, a random user snapshot may belong to someone else. Realtime gives a quick collection check; a controlled DebugView device gives more precise evidence.

Inspect the browser with Tag Assistant

Open Google Tag Assistant, enter the site address and connect. Follow the resulting test session through the same two pages. Inspect the Google tag destination and the events sent as you navigate.

If your implementation uses Google Tag Manager, its Preview mode helps show which tags fired and which did not. Check the event that caused a tag to run, not just the total number of fired tags.

Look for a normal page_view on a page load. Investigate two unexpected page views for the same navigation. The theme, Site Kit and a second analytics plugin may each contain overlapping installations. Dynamic sites can also produce intentional virtual page views, so compare the events with the actual navigation before deciding that every extra event is wrong.

Use DebugView for one device

Google's DebugView instructions describe enabling debug mode through Tag Assistant or preview mode. In GA4, open Admin, Data display and DebugView, then select the relevant debug device.

Repeat the controlled actions. Open an event and inspect its parameters. A purchase test needs the correct currency, amount, transaction ID and items. A lead test needs the intended form identifier and a real success signal.

If DebugView stays empty, check that debugging is enabled, the selected device is yours, the tag destination is correct and consent permits the expected collection. Google notes that client-side privacy controls and consent choices can affect DebugView visibility. A successful network response alone does not prove that your event will appear as expected in reports.

Test business events and failure cases

Choose one important workflow. Submit a valid contact form, complete a permitted test booking or make a test order using your store's approved testing method. Confirm the record in the underlying system and the corresponding analytics event.

Then deliberately test the unsuccessful path. Submit an invalid form or abandon the booking before confirmation. These should not produce the same completion event. Refresh the confirmation page and verify that it does not turn one result into repeated results.

For Niwa website booking, the measurement boundary is the saved appointment. A calendar opening, selected time or WhatsApp link click has a different meaning. This distinction gives you a report you can compare with the actual schedule.

Google's ecommerce validation guide also recommends checking required parameters and transaction identifiers. Do not judge a purchase implementation solely by seeing the word purchase in the event list.

Interpret missing data in the right order

If nothing arrives, investigate property selection, tag placement, consent, browser blocking, cache and filters. If page views arrive but purchases do not, move to the ecommerce integration and completion trigger. If DebugView works but yesterday's report looks empty, consider processing time and the report's date range.

Google says many reports and explorations take 24 to 48 hours to process. That is a reason to use live testing first, not a reason to ignore an event that never fires.

Site Kit can also exclude logged-in users. An owner's missing visit may therefore be expected. Check its Analytics settings before treating your own administrator session as the definitive test.

Keep a small verification record

Record the test date, device, consent choice, measurement ID, pages visited, completed action and event count. Store test transaction details privately. Repeat the relevant check after analytics, consent, checkout or booking changes.

You can ask Niwa about your WordPress workflow using that record: explain what the visitor completed, what the business system saved and what Analytics received. Those three observations make a useful troubleshooting request and avoid guessing from a dashboard alone.