Common Data Mistakes to Avoid

Not filtering out internal and bot traffic

Every visit you, your team, or your developer makes to the site gets recorded exactly like a customer's, unless you explicitly exclude it. On a low-traffic site, a handful of internal visits during a redesign or a testing session can visibly distort weekly numbers — inflating pageviews, skewing bounce and engagement rates, and in the worst case, accidentally triggering key events during testing that then get counted as real conversions. A week spent actively testing a new checkout flow, for example, can generate several "purchases" in the data that were never real customers, and if nobody remembers to exclude that traffic, that week's conversion numbers become simply unusable for comparison.

GA4 supports internal traffic rules, defined by IP address, in its Admin settings — set one up for your office or home IP once, and use a filtered "Testing" data view when you know you will be actively working on the site. Bot and automated traffic is a related but separate problem: GA4 has some built-in bot filtering, but it is not perfect, and unusually large one-day spikes with no clear source — especially spikes in raw sessions with almost no engagement — are worth investigating before you draw any conclusion from a "great week."

It is worth remembering that internal traffic is not only a problem during obvious testing periods. Anyone on the team who regularly checks the site from their own computer, or shares the homepage link internally for an unrelated reason, is adding small amounts of noise continuously — usually not enough to distort monthly trends dramatically, but enough that it is worth having the filter running permanently rather than only during active development work.

Tracking code installed twice

This is one of the most common and easiest-to-miss setup errors, covered briefly in Chapter 2 but worth repeating here because of how often it happens: the same GA4 property gets connected two different ways — pasted directly into the theme's code and installed again through a plugin, or added via Google Tag Manager while an old direct tag is never removed. Each page load then fires two events for a single pageview, silently doubling (or worse, if it happens inconsistently across pages) every count downstream: pageviews, sessions, users, conversions, all inflated in ways that do not cancel out cleanly.

The fix is simple but requires deliberately checking, not assuming: view your site's page source or use a tag-checking browser extension, and confirm exactly one GA4 configuration tag with your Measurement ID is firing per page. Do this once after any major site change — a new plugin, a theme update, a migration to a new platform — since these are the moments duplicate tracking most often gets introduced without anyone noticing, often because whoever made the change did not know a tag was already installed somewhere else and added a second one to be safe.

Duplicate tracking is particularly dangerous because it does not look broken. Reports still populate, numbers still move up and down in response to real changes, and nothing about a doubled pageview count looks obviously wrong unless you already have a rough sense of what the real number should be. This is one of the strongest arguments for the verification habit from Chapter 2 — checking Realtime immediately after any setup change, rather than assuming it worked because the reports are not empty.

Confusing correlation with causation

Analytics is very good at showing you that two things happened around the same time, and says nothing on its own about whether one caused the other. Traffic rose the same week you posted more on social media — did the posts cause it, or did something else (a seasonal pattern, a mention elsewhere, an algorithm change on a platform you do not control) happen to coincide? Conversions dipped the week you changed the homepage — was it the redesign, or a slower week that would have happened regardless?

The only reliable way to separate the two is a genuine before/after comparison with as few other variables changing at the same time as possible, ideally run over a long enough window to rule out normal noise — not a single week glanced at right after a change. Where the stakes are high enough to justify it (a significant redesign, a pricing change), a proper A/B test settles the question far more convincingly than eyeballing a trend line ever will. Absent that, hold conclusions loosely, and look for the pattern to repeat before treating it as proven.

A related trap worth naming explicitly: when several things change at once — a new homepage, a new ad campaign, and a seasonal shift in demand all landing in the same month — it becomes genuinely impossible to isolate which one drove any change in the numbers, no matter how carefully you look at the report afterward. Where practical, changing one significant thing at a time, and giving it a few weeks to show a trend before changing the next thing, makes cause and effect far easier to read later.

Chasing traffic instead of conversions

• Rising traffic with flat conversions usually means the new visitors are the wrong audience, or a top-of-funnel channel is bringing volume without intent — worth investigating rather than celebrating on its own.
• A page with heavy traffic and no conversions is not automatically a success story just because the visitor count looks good on a report — check what that traffic actually does once it arrives before treating the page as a win.
• Optimising purely for pageviews or session count pushes decisions toward whatever generates clicks — which is not reliably the same thing as whatever generates business, and can actively pull effort away from lower-traffic pages that quietly convert well.
• The fix is structural, not just attitudinal: put conversions, not traffic, at the top of every dashboard and every report you actually review (Chapter 6), so the wrong number is never the first thing anyone sees.

A final, quieter mistake worth naming: ignoring seasonality when comparing periods. A business with a predictable slow season will always show a conversion "decline" comparing that month against the month before it, regardless of anything the marketing team did — and comparing against the same month a year earlier, where that data exists, is usually a far more honest read than comparing against last month. Where a full year of history is not yet available, at minimum stay aware that some of the swing in any given month may simply be the calendar, not a change in performance.