Written by Ram Kr Shukla, SEO and growth consultant, Google Analytics certified.

Here’s the dashboard that started this post. A D2C beauty brand on Shopify, a Last 28 days view, comparison set to the previous period. Transactions: up 803.5%. Purchase revenue: up 789.0%. Add to carts: no percentage at all, just “No data” where the comparison should be.

Nobody had a sale on. Nothing went viral. What happened was that ecommerce tracking went live partway through the previous window, so the baseline was almost empty. The percentages measured the tracking fix, not trading.

That’s the whole problem in one screen. Any time you fix tracking, add a tag, migrate a platform or change a consent banner, the arrows move. Every period over period comparison in GA4 and Looker Studio reports the change as if the business did it. Sometimes up, sometimes down. This post covers how to spot it, how to work out the exact day the arrows become honest again, what to report until then, and how to write the change down so nobody falls for it twice. Want someone to fix the tracking and set up the reporting around it? That’s my GA4 conversion tracking work.

What a Broken GA4 Comparison Looks Like

A comparison is two totals and a division. Current window over previous window, minus one. If the tracking was different in the two windows, you’re dividing two different measurements, and the answer is noise with a percent sign.

Three tells give it away. You only need one.

1. The comparison says No data

When a metric was zero or missing for the whole previous window, there’s nothing to divide by. Looker Studio showed “No data” on the add to carts scorecard in the dashboard above, because add_to_cart had been broken for the entire previous period. Other tools draw a zero baseline differently, so treat any blank, dash or missing comparison the same way. That blank is the tool telling you the baseline doesn’t exist.

2. The percentage is impossible for your business

Ask whether anything you know about could explain the number. A store doesn’t grow transactions ninefold in four weeks without someone noticing in the warehouse. Check the finance numbers, the order count in the store admin and the ad spend. If they all look normal and GA4 says +800%, GA4 is wrong about the baseline. The same goes for a sudden 40% drop that nobody else can see.

3. The daily line has a step on one date

Switch the line chart to daily and look for a cliff. Real demand ramps. Seasonality curves. A tracking change makes a vertical step on the exact day something shipped, then a new flat level. If the step lines up with a release, a GTM publish or a consent banner going live, you’ve found day 0.

Two related checks help. If page views or events per session roughly double overnight, a second tag is probably counting the same action. If an event goes from near zero to thousands in a day, it was broken before and fixed on that day. The Shopify GA4 funnel audit covers how to prove which events fire and where, so I won’t repeat it here.

The +803.5% Case: What Actually Happened

Here’s the timeline on that store, with day 0 as the first day ecommerce tracking was live. The dashboard was read on day 34. Its Last 28 days window ran from day 6 to day 33. The previous period started 22 days before day 0 and ended on day 5.

So the previous window had six days of working ecommerce tracking and 22 days from before ecommerce tracking was live. The current window had 28 full days. Of course the arrow went green. It was comparing four weeks of measured orders against six days.

Add to carts was worse. The add_to_cart event had been broken for that entire previous window, so its comparison had no baseline at all. That’s where “No data” came from. If you want the full story of how the cart event was broken and how it was proven, it’s in the funnel audit write-up.

The rule we set for that client was short. Report absolute numbers and ignore the arrows until a full 28 day window sits clear of the fix. On paper that’s day 56. We called it at roughly day 58 to leave room for processing.

And the comparisons stayed on the dashboard. That was deliberate. Removing them means someone has to remember to put them back, and they fix themselves with time. A broken arrow you’ve explained is less dangerous than a missing one somebody re-adds without the context.

Why a Partly Tracked Window Makes Such Big Numbers

You’d expect a tracking fix to show +100% at most. It doesn’t, and the arithmetic explains why.

Say your store sells the same number of orders every day, and the old setup recorded none of them. If the previous 28 day window had tracking live for 14 of its days, it holds half the orders the current window does. The arrow reads +100%. If tracking was live for 7 days, the arrow reads +300%. For 3 days, +833%. Your business didn’t change at all in any of those cases.

The formula is 28 divided by the tracked days, minus one. Real numbers drift from it in both directions. If the old setup recorded some orders, the arrow comes in lower. The store above landed at +803.5% with six tracked days in its baseline, well above the +367% the formula gives. That gap could come from the first tracked days being partial, from genuine trading changes in the current window, or both. The arrow can’t tell you which. Once the baseline is contaminated, the percentage can’t be split into “tracking” and “real” after the fact.

The same logic runs in reverse. Launch a consent banner that blocks tags until people accept, and the current window loses visitors the previous one had. The arrow goes red by roughly the share of people who don’t accept. Nothing happened to demand.

The Changes That Break Comparisons

Ecommerce fixes are the loudest case, but not the only one. Anything that changes what gets counted, from a given date onward, breaks every comparison that straddles that date. Here are the usual ones, with the direction they push the arrow.

Change	Arrow	What you’ll see	Source
Ecommerce or event tracking fixed	Up, often by hundreds of percent	An event goes from near zero to normal levels on one day	Client evidence above
A second Google tag added	Up, close to +100% on duplicated events	Events per session roughly double overnight	General practice
Consent banner with tags held until consent	Down	Users and sessions fall on launch day while store orders don’t	Google: consent mode
Behavioral modeling starts, or reporting identity set to Blended	Users up	Google notes reports with modeled data can show higher user counts	Google: behavioral modeling
A data filter activated (for example internal traffic)	Down	Filtered data is gone from that day, and history isn’t touched	Google: data filters
An event newly marked as a key event	Up from zero	Key events count only from the day you mark them	Google: key events
Site migration, new theme or new checkout	Either	Tag missing on new templates, or events renamed	General practice
Changes on Google’s side	Either	A system-generated annotation on GA4 line charts	Google: annotations

A few of these need a word more.

Consent. Google’s consent mode page says that when analytics storage is denied, GA4 won’t read or write its cookies. In the basic setup, tags don’t load at all until a visitor accepts. In the advanced setup, tags load first and send cookieless pings that Google can use for behavioral modeling. Modeling has thresholds: Google lists at least 1,000 events per day with analytics storage denied for at least 7 days, and at least 1,000 daily users with it granted for at least 7 of the previous 28 days. So a consent change can produce two steps, one when the banner goes live and another later when modeling kicks in. Each is its own day 0.

Key events and filters. Neither is retroactive. Google’s help page on key events says marking one “affects reports from time of creation” and doesn’t change historic data. A key event you marked on day 0 will show a huge increase against a previous period where it didn’t count as one, even if the underlying event fired the whole time.

Migrations. On Shopify, GA4 is usually connected through the Google & YouTube app. Moving from an older setup to the app, or from the app to a Tag Manager container, changes which events fire and how they’re named. Treat the switch day as day 0. If the migration also moved URLs, the rankings side has its own recovery plan: what to do after a redesign loses rankings.

When Is the First Honest Comparison?

Here’s the rule. For a reporting window of W days, the first honest period over period comparison arrives on day 0 plus W plus W.

The first W covers one full window of the new setup. The second W covers another full window after that. Only then do both the current and the previous period sit wholly after the change. Before that, the previous period has at least one day measured the old way. If you’d rather not count days by hand, the GA4 comparison window calculator works out the honest date for every window you report.

Then add a buffer. Google’s data freshness page says GA4 processing can take 24 to 48 hours, and data in reports may change during that time. Two days is enough for most standard properties.

Comparison you report	Window (W)	First honest day	With 2 day buffer
Last 7 days vs previous period	7	Day 14	Day 16
Last 28 days vs previous period	28	Day 56	Day 58
Last 90 days vs previous period	90	Day 180	Day 182
Calendar month vs previous month	about 30	Second full month after day 0	Read it a couple of days into the third
Last 28 days vs same period last year	28	Day 393 (365 plus 28)	Day 395

Two details trip people up.

First, day 0 has to be a full day. If a developer published the fix at 4 pm, the first afternoon is half one setup and half the other. Start counting from the next morning.

Second, year over year is slower than it looks. A “Previous year” comparison needs the same window last year to sit after day 0 as well. So for any metric a tracking change touched, a clean year on year comparison needs at least a year plus one window. Until then, year over year on that metric is measuring the setup change.

A tip if your stakeholders like a Monday to Sunday rhythm. GA4 offers Previous period (match day of week) as a comparison option. Over 28 day windows it makes no difference, because 28 is four whole weeks. That’s one reason 28 days is a cleaner reporting window than 30.

What to Report Until the Arrows Are Honest

You can’t pause reporting for eight weeks. You don’t need to. Four kinds of numbers stay trustworthy through a tracking change.

Absolute numbers

Transactions, add to carts, sessions. Report the count for the current window and say plainly that the comparison is invalid until a given day. A store doing several thousand transactions in four weeks is a perfectly useful fact without an arrow attached.

Comparisons between windows that both sit after day 0

Shorter windows clear faster. On day 21, Last 7 days versus the previous 7 days is already honest, because both weeks sit after day 0. Week over week can carry the trend while the 28 day view waits. In Looker Studio you can also set a fixed comparison range that starts on day 0, though it goes stale and someone has to remember to switch it back.

Search Console

Search Console’s Performance report counts clicks from Google Search results and impressions in them. None of it depends on your GA4 tag, your consent banner or your Tag Manager container, so a tracking change doesn’t move it. For organic trend through a tracking change, it’s the cleanest source you’ve got. It has its own rare logging problems, which Google publishes on its data anomalies page, so check that before reading a step there.

Split it by brand and non-brand before you present it, because branded clicks mostly track demand that already existed. The method is in branded vs non-branded traffic, and a few reports most people skip are in the Search Console reports most marketers never open.

The store’s own order count

Your ecommerce platform records orders whether or not a GA4 tag fired. It won’t tell you about channels, but it settles the one question that matters during a tracking change: did sales actually move? If the store admin is flat and GA4 says +800%, you’re looking at a measurement change.

Ratios inside one window also survive, as long as every metric in the ratio was tracked the same way for the whole window. Add to cart rate in the current window, for instance, is fine once add_to_cart is working. Comparing it to the broken window isn’t.

Should You Remove Comparisons From the Dashboard?

Usually no. On the store above, the comparisons stayed on, because they fix themselves with time. What changed was how they were read and reported.

What helps is a visible note. In Looker Studio, put a text box beside the scorecards that says which metrics are affected and the day the arrows become valid. GA4 annotations sit on GA4’s own line charts, and a Looker Studio report is a separate document, so don’t rely on the GA4 note being seen by people who only open the dashboard.

Only report editors can change the comparison date range in Looker Studio. In GA4 itself, the comparison anyone picks in the date picker is personal: Google’s date range help page notes that date changes don’t carry over to other users. So a colleague can open the same report, switch on a comparison and see +803.5% with no warning at all. That’s the strongest argument for annotations.

If you’re building the dashboard from scratch, the layout I use for Search Console and GA4 side by side is in the Looker Studio SEO dashboard guide. For what a monthly SEO report should contain once the numbers are clean, see what a real Shopify SEO report contains.

How to Document a Tracking Change

Most teams fix the tag and move on. A quarter later someone pulls a quarter on quarter view and asks why everything tripled.

GA4 annotations

GA4 now supports annotations. According to Google’s help page, you open a report with a line graph, right click a data point and choose Add annotation. Each one takes a title of up to 60 characters, an optional description of up to 150, a single date or a date range, and a colour. You need the Analyst role or above to create one, Viewers can see them, and a property holds up to 1,000. Annotations can also be created through the Admin API, and GA4 adds its own system-generated ones when something on Google’s side affects your data.

Write the annotation for the person reading it in six months. “Ecommerce tracking live, comparisons invalid until day 58” is better than “GTM fix”. Google suggests single-date annotations when you expect a lot of overlapping ranges, and for a tracking change a single date on day 0 is exactly right.

GA4 change history

GA4 keeps a property change history covering the last two years, with who changed what and when. It’s useful for admin changes like filters, key events and reporting identity. It won’t show changes made in your site code or in Tag Manager, so it doesn’t replace a log.

A change log

A shared sheet is enough. One row per change, written on the day it ships.

Field	What goes in it	Example
Day 0	First full day the change was live	The date, in your own log
Change	What shipped, in plain words	Ecommerce events moved to the Google & YouTube app
Metrics affected	Every metric whose counting changed	Transactions, revenue, add to carts
Expected direction	Up, down or unknown	Up
Honest from	Day 0 plus 2W, per window reported	7 day: day 16. 28 day: day 58
Verified by	How you confirmed it worked	Test order in DebugView, four funnel events present
Annotated	Yes or no, and where	GA4 annotation, dashboard text box

It also helps with the harder conversations. When someone asks why last quarter’s report said +800% and this one says +4%, you can point at a row instead of reconstructing the story from memory. For the broader version of that argument, how to read an e-commerce SEO report without being fooled covers the other numbers that flatter.

How to Handle GA4 Comparisons After a Tracking Change, Step by Step

Here’s the sequence, in order. Most of it happens on the day the change ships, plus one calendar reminder for the honest date.

GA4 Comparison FAQ