Category: Analytics

You check Google Analytics 4 on Monday morning. Your email campaign drove twelve conversions over the weekend. You screenshot it, add it to your monthly report, feel good about the numbers.

You check again on Friday. Those same conversions? Now it says nine.

GA4 didn’t glitch. It’s working exactly as designed—and if you don’t understand why, you’re probably making decisions on data that’s still moving.

How GA4’s attribution window actually works

Google Analytics 4 uses a default attribution window of 90 days for most conversion events. That means when someone converts, GA4 looks back up to 90 days to find the traffic source that should get credit.

But here’s the part that catches people: that window runs in both directions.

If someone clicks your email link on May 1st, then converts on May 15th, GA4 assigns that conversion to email. Simple enough.

But if someone clicks a Google ad on May 20th and converts on May 22nd, GA4 will reassign that conversion to paid search—even though it already showed up in your email report two weeks ago.

The conversion doesn’t disappear from your total count. It just moves from one source to another. GA4 applies last-click attribution by default, so the most recent traffic source within that 90-day window wins.

This is why your historical reports shift. Numbers you exported last week might not match what you see today, because conversions are still being reattributed as new sessions come in.

What this means for your reporting

If you’re tracking channel performance—especially for email, social, or content campaigns—you need to wait longer than you think before calling a campaign’s results final.

A newsletter you sent two weeks ago might still be gaining or losing conversions as readers click other sources before they buy. If you report on it immediately, you’re only seeing part of the story.

Here’s what changes:

• Email campaigns look better early, worse later. People click your email, browse, then return via organic search or a retargeting ad. Email gets the early credit, but loses it when they convert through a different channel.
• Paid ads look worse early, better later. Someone discovers you organically, clicks around, then converts after seeing a Facebook ad. The ad gets the conversion—even though organic did most of the work.
• Organic and direct traffic gain conversions over time. These are the channels people use when they’re ready to buy. They’ll pick up conversions that were initially attributed to email, social, or referral traffic.

If you’re exporting monthly reports, wait at least 7–10 days after the month ends before pulling final numbers. For high-consideration products or longer sales cycles, wait 30 days.

How to change the attribution window (and when you should)

You can adjust the conversion attribution window in GA4’s admin settings. Go to Admin → Data display → Attribution settings, then change the lookback window for acquisition and engagement.

Your options are 30, 60, or 90 days.

Shorten it to 30 days if:

• You sell low-ticket digital products where people decide quickly
• You run time-sensitive promotions and need faster, more stable reports
• You want your reports to settle sooner, even if it means losing some cross-channel context

Keep it at 90 days if:

• You have a longer sales cycle (courses, coaching, SaaS with trials)
• You want to see the full path people take before converting
• You’re okay with reports shifting for a few weeks after a campaign ends

There’s no universally correct answer. The right window depends on how long it typically takes someone to go from first visit to conversion in your business.

How to work with this, not against it

Stop treating GA4 reports as static. They’re not. Conversions move between sources as attribution updates, and that’s not a bug—it’s how the system is designed to give you a fuller picture over time.

If you need stable, immediate numbers—say, for a weekly team check-in or a sponsor report—pull data from your payment processor or CRM instead. Stripe, Gumroad, and ConvertKit all give you transaction data that doesn’t shift retroactively.

Use GA4 for what it’s actually good at: understanding patterns across traffic sources over weeks or months, not locking down exact counts two days after a campaign.

And if you’re comparing performance across channels, compare them at the same point in their attribution lifecycle. Don’t judge an email campaign’s results after three days and a Facebook ad’s results after thirty. Wait the same amount of time for both, or you’re not comparing the same thing.

Want more pieces like this? One Two Three Send breaks down the tools, tactics, and trade-offs that solo operators actually deal with. No fluff, no filler. Subscribe here.

Most operators treat Google Analytics like a black box. You drop the tracking code on your site, events fire, and you trust the dashboard to tell the truth. But when conversion data goes missing or attribution breaks, you’re stuck guessing what happened three weeks ago.

GA4’s debug mode solves this. It’s a real-time event inspector that shows you exactly what’s being tracked, what’s broken, and what’s being ignored — before bad data compounds into bad decisions.

What debug mode actually does

Debug mode is a testing layer that sits between your site and GA4’s servers. When enabled, it pipes all event data into a dedicated real-time report called DebugView, where you can see:

• Every event as it fires, with full parameter details
• User properties being set or updated
• Validation errors (missing required fields, malformed values)
• Events that aren’t configured to show up in standard reports

It doesn’t change what gets tracked — it just makes the tracking visible while you’re testing. Once you turn it off, everything reverts to normal collection.

This matters because GA4 silently drops events that don’t meet its schema. If you’re firing a custom event with a parameter name longer than 40 characters, GA4 won’t tell you — it’ll just ignore it. Debug mode surfaces these failures immediately.

How to turn it on

There are three ways to enable debug mode, depending on your setup.

If you’re using Google Tag Manager: Open your GA4 configuration tag, expand “Fields to Set,” and add a field called debug_mode with the value true. Publish the container. This enables debug mode for all users, so only do this in a staging environment or with a separate GTM container.

If you’re using gtag.js directly: Add debug_mode: true to your config call:
gtag('config', 'G-XXXXXXXXXX', { debug_mode: true });

If you want to test without changing code: Install the Google Analytics Debugger extension for Chrome. It enables debug mode for your browser session only, so you can test on a live site without affecting real user data.

Once enabled, open GA4, go to Admin → DebugView (under the Property column), and interact with your site in another tab. Events should appear within seconds.

What to check first

Start with your conversion events. If you’re tracking newsletter signups, course purchases, or affiliate clicks as conversions, fire each one manually and watch DebugView.

Look for:

• Missing parameters. If your purchase event is supposed to include value and currency, but DebugView shows them as absent, GA4 won’t report revenue correctly.
• Wrong data types. If you’re sending value: "29.00" as a string instead of a number, GA4 will reject it. DebugView flags type mismatches.
• Events firing multiple times. If a single button click triggers three sign_up events, you’re inflating your conversion count. DebugView’s timestamp column makes duplicates obvious.
• Events that never fire. If you expect to see a scroll event at 90% but it never appears, your trigger is misconfigured.

One non-obvious thing: DebugView also shows you the engagement_time_msec parameter on every event. If this is always zero, it means GA4 thinks users aren’t engaging with your content — which can suppress your pages in Search Console’s performance reports.

When to leave it on (and when not to)

Debug mode is a diagnostic tool, not a permanent setting. Leaving it enabled in production clutters your DebugView report with noise and creates a false sense that everything’s being tracked (it is — for you, but not necessarily for users without the flag).

Turn it on when:

• You’re testing a new event or parameter
• Conversion counts suddenly drop and you suspect a tracking break
• You’re migrating from Universal Analytics and validating parity
• You’re onboarding a new developer and want to show them what “correct” looks like

Turn it off once you’ve validated the setup. If you need ongoing monitoring, use GA4’s standard real-time report instead — it’s less granular, but it reflects what actual users are sending.

One more thing: debug mode doesn’t work with the GA4 measurement protocol (server-side tracking). If you’re sending events from your backend, you’ll need to validate those with GA4’s event builder or by checking the raw HTTP response codes.

Want more operator-focused breakdowns of the tools that actually matter? Subscribe to One Two Three Send — one article like this, delivered weekly, no fluff.