Category: Analytics

You add your office IP to Google Analytics 4’s exclusion filter, click save, and assume your internal visits stop polluting your traffic reports. Then you check a few days later and your test sessions are still showing up—or worse, they disappear from one report but linger in another.

GA4’s IP exclusion doesn’t work the way Universal Analytics did. It doesn’t reject traffic at the door. It logs everything, applies a filter tag, and suppresses matching hits in most—but not all—standard reports. That distinction matters when you’re trying to get clean data or debug why your numbers don’t match what you see in server logs.

How GA4’s IP filter actually works

When you define an IP exclusion filter in GA4’s data stream settings, you’re not blocking requests. You’re telling Google to apply an internal_traffic parameter to any hit that matches your IP range. That parameter gets attached to the event payload and flows into BigQuery exports and debug logs, but it’s excluded from most GA4 interface reports by default.

The key word is “most.” Explorations, custom funnels, and any report built with unfiltered dimensions can still surface internal traffic if you don’t manually apply a segment or filter. Real-time reports often show excluded IP hits for several minutes before suppression kicks in, because the tagging happens asynchronously.

If you’re running a low-traffic site and testing conversion flows yourself, a single internal session can skew daily conversion rates by 20% or more—even if you think you’ve filtered it out.

Why your IP still appears in some reports

Three common reasons:

• Dynamic IP assignment: If your ISP rotates your IP every few days, your exclusion rule goes stale. GA4 doesn’t notify you when this happens. You have to check your public IP periodically and update the filter manually, or use a broader CIDR range if your provider allocates from a known block.
• Mobile and VPN traffic: Your phone’s carrier IP and any VPN endpoint won’t match your home or office range. If you test email links on mobile or browse your site through a VPN, those sessions aren’t tagged as internal unless you’ve added every possible IP.
• Server-side GTM or Measurement Protocol hits: If you’re sending events via server-side Google Tag Manager or the GA4 Measurement Protocol, the IP GA4 sees is your server’s IP, not the end user’s. Your exclusion filter won’t match unless you explicitly pass the user’s IP in the payload and your server is on the excluded list.

When to use IP exclusion vs. other filtering methods

IP filtering works well for small teams working from fixed locations—a home office, a coworking space with a static IP, or a single cloud server sending backend events. It’s lightweight, doesn’t require changing your tagging code, and applies retroactively to all future hits.

But if your team is distributed, remote, or frequently mobile, IP exclusion becomes a maintenance burden. A better approach: set a first-party cookie or localStorage flag when someone logs into your CMS or admin panel, then use Google Tag Manager to check for that flag and not fire the GA4 tag at all. This method blocks the hit entirely rather than tagging and suppressing it.

For agencies or consultants who work across dozens of client sites, browser extensions like “Block Yourself from Analytics” (available for Chrome and Firefox) inject a query parameter or disable the GA4 script on sites you specify. You don’t have to ask every client to add your IP to their exclusion list.

One non-obvious gotcha

GA4’s IP exclusion filter doesn’t apply to Google Signals data or any cross-device user stitching. If you’re logged into a Google account on your work machine and browse your own site, Google may still associate that session with your broader user profile for audience building and attribution modeling, even though the session is tagged as internal traffic. The data won’t appear in your standard reports, but it can influence remarketing audiences and conversion credit if Google Signals is enabled.

To fully exclude yourself from tracking and modeling, you need to either disable Google Signals in your property settings or browse in an incognito window while logged out of all Google accounts.

IP exclusion in GA4 is not a firewall—it’s a post-collection label. If you need truly clean data and you’re testing frequently, combine IP filtering with client-side tag blocking and regular audits of your Realtime and Exploration reports. And if your IP changes more than once a month, automate the filter update or switch to a cookie-based exclusion method before your internal traffic becomes your largest segment.

What’s your internal-traffic filtering setup? Reply and let us know what’s working—or what’s leaking through.

Most analytics platforms charge you for tracking the things that actually matter. Google Analytics 4 is free but floods you with data you’ll never use. Fathom charges per site. Plausible charges per pageview—but custom event goals, the signals that tell you whether your site is working, come at no extra cost.

That pricing structure changes how you instrument your site. Instead of rationing events or paying per conversion, you can track everything that moves the needle: newsletter signups, affiliate clicks, video plays, PDF downloads, scroll depth. The limit is your traffic volume, not your event count.

How custom event goals work in Plausible

Plausible’s custom events are triggered client-side via a snippet of JavaScript. You fire an event by calling plausible('Event Name') anywhere in your code. Common use cases: button clicks, form submissions, file downloads, outbound link tracking.

Once you’ve fired an event, you create a goal in the dashboard. Navigate to Settings → Goals → Add goal → Custom event, type the event name exactly as it appears in your code, and save. Within minutes, that event starts appearing in your dashboard’s goal report.

You can attach custom properties to events—things like path, source, or plan—to segment conversions. For example, track which blog post drove the most newsletter signups or which pricing tier gets the most clicks. Properties don’t cost extra either.

When to use custom events instead of pageview goals

Pageview goals are simpler: you specify a URL, and Plausible counts every visit to that page. Use them for thank-you pages, confirmation screens, or any conversion that lands the user on a predictable URL.

Custom events shine when the action doesn’t trigger a page load. If your newsletter signup is a modal, an inline form, or an AJAX submission, a pageview goal won’t fire. Same goes for clicks on external affiliate links, downloads that open in a new tab, or interactions buried inside a single-page app.

The tradeoff: custom events require you to write (or paste) JavaScript. Pageview goals don’t. If you’re not comfortable editing your theme or plugin code, stick to pageview goals or use a plugin like Plausible Analytics WP that wraps common events for you.

The non-obvious tip: use events to throttle tracking overhead

Because Plausible doesn’t charge per event, you can track granular user behavior without worrying about cost. But every event fires an HTTP request, and on high-traffic pages, that adds up.

Instead of firing an event on every scroll increment, fire it once when the user crosses 75% depth. Instead of tracking every video second, track play, 50%, and complete. Batch similar actions into a single event with custom properties instead of creating twenty separate goals.

This keeps your dashboard readable and your page performance clean. Plausible’s script is only 1 KB, but firing dozens of events per session still adds latency. The goal isn’t to track everything—it’s to track what changes your decisions.

What it costs and when the model breaks

Plausible’s pricing tiers are based on monthly pageviews: 10,000 views for $9/month, 100,000 for $19/month, 1 million for $69/month. Custom events count as pageviews in your quota. A page load plus two custom events equals three billable pageviews.

That pricing works in your favor if you track selectively. A site with 50,000 monthly pageviews and 5,000 conversion events stays well under the 100k tier. But if you’re firing five events per session across 50,000 sessions, you’ll hit 300,000 billable views and jump to the next tier.

The model breaks when you instrument everything. If you’re tracking scroll depth, clicks, hovers, video plays, and form field focus events across every page, you’ll blow through your pageview allowance. At that point, you’re better off self-hosting Plausible (which is open-source and free if you run your own server) or moving to a tool that charges per site instead of per event.

For most solo operators and small teams, though, the sweet spot is three to five high-value events per user journey. That’s enough to measure what matters without paying for noise.

If you’re running a content business and want to track conversions without surveillance, Plausible’s custom event pricing is one of the cleanest deals in privacy-first analytics. Just don’t confuse “unlimited events” with “track everything”—your dashboard and your invoice will both thank you.

What conversion events are you tracking right now? Hit reply and let me know—I read every response.

If you’re running a content site that pulls 500,000+ sessions a month, you’ve probably noticed something strange: your GA4 reports don’t always match. Run the same custom report twice, and the numbers shift. Filter by a specific page or traffic source, and suddenly your totals don’t add up.

You’re not imagining it. You’ve hit GA4’s sampling threshold.

Sampling means Google is analysing a subset of your data—not all of it—then extrapolating the results. It’s faster for Google to process, but it quietly erodes the accuracy of every decision you make based on those numbers.

When sampling kicks in (earlier than you think)

Google’s documentation says GA4 standard properties support up to 10 million events per month before sampling applies. That sounds like plenty of headroom.

But sampling doesn’t wait until you hit 10 million events. It starts much earlier—often around 500,000 sessions—when you build custom reports, apply filters, or request data outside the standard date range.

Standard reports (the pre-built ones GA4 ships with) use aggregated data tables and rarely sample. But the moment you:

• Add a secondary dimension
• Apply a segment or filter
• Build an exploration report
• Request data older than 14 months

…GA4 switches to on-the-fly querying, and sampling kicks in if your property is processing enough events.

You’ll see a green badge in the top-right corner of your report that says “This report is based on X% of sessions.” If that number is below 100%, your data is sampled.

What gets lost in sampled data

Sampling doesn’t affect every metric equally. High-level numbers—total sessions, pageviews, users—tend to hold up reasonably well even at 20–30% sampling rates.

But the more specific your question, the worse sampling performs. If you’re trying to:

• Identify which blog post drove the most newsletter signups from organic search last quarter
• Compare conversion rates across traffic sources for a specific product page
• Measure how a site-speed optimisation affected bounce rates on mobile

…sampling can distort the answer enough to reverse your conclusions.

I’ve seen sampled reports show a 15% conversion rate on a landing page when the unsampled data (pulled via BigQuery export) showed 11%. That’s not a rounding error—that’s a different business decision.

How to reduce or avoid sampling

If you’re consistently hitting sampling in GA4, you have four options.

Option one: Narrow your date range. Instead of analysing the last six months, break it into monthly or bi-weekly segments. Smaller queries are less likely to sample. You’ll need to stitch the data together manually, but at least it’s accurate.

Option two: Use the Data API. GA4’s Reporting API gives you access to unsampled data if your query stays within certain limits. Tools like Google Sheets (via the GA4 add-on) or Looker Studio can pull data this way. It’s slower, and there are still daily quotas, but it bypasses the sampling you see in the GA4 interface.

Option three: Export to BigQuery. GA4 offers a free BigQuery export (up to 1 million events per day). Once your data is in BigQuery, you can query it without sampling. The trade-off: you need to learn SQL, and you’re managing your own data warehouse. But if you’re making six-figure decisions based on this data, it’s worth it.

Option four: Upgrade to GA4 360. The enterprise tier starts at $50,000/year (sometimes negotiable to $150,000 depending on scale) and raises sampling thresholds significantly. Unless you’re running a seven-figure media operation, this isn’t realistic.

When sampled data is good enough

Not every report needs to be unsampled. If you’re checking whether traffic went up or down this week, or whether your top-performing post is still your top-performing post, a 70% sample is fine.

But if you’re deciding whether to double down on a traffic source, kill a product, or restructure your content strategy, don’t trust a sampled report. Pull the data via API or BigQuery, or narrow your query until the sampling badge disappears.

The costliest analytics mistake isn’t picking the wrong tool—it’s trusting incomplete data and not knowing it.

Using GA4 for attribution or conversion tracking? Subscribe to One Two Three Send and get one operator-focused article like this every day.

If you’ve decided Google Analytics is overkill—or you just want to stop dealing with cookie banners—you’ve probably narrowed your shortlist to Plausible and Fathom. Both are privacy-first, cookieless, and built for operators who want clean dashboards instead of data warehouses.

But they’re not interchangeable. One prioritises speed and price. The other prioritises polish and brand positioning. Here’s what matters when you’re deciding where to send your $14–$24 per month.

Pricing: same until you scale

Both charge based on monthly pageviews, and both start at $14/month for up to 10,000 pageviews.

Plausible: $14/mo for 10k pageviews, $24/mo for 100k, $69/mo for 1M. Annual billing gets you two months free.

Fathom: $15/mo for 100k pageviews (yes, 10× more volume at nearly the same price), $25/mo for 250k, $55/mo for 1M. Discounts for annual.

At low volume, they’re equivalent. Once you cross 50,000 pageviews per month, Fathom becomes meaningfully cheaper. If you’re running a single content site doing 200k pageviews a month, Fathom saves you $100+ per year.

But if you track multiple properties—say, a main blog, a documentation site, and a landing page—Plausible’s $14/mo entry tier can feel punitive. You’ll pay per site unless you consolidate under roll-up reporting (more on that below).

Interface and speed

Plausible’s dashboard loads faster. That’s not subjective—it’s lighter on JavaScript and renders in under a second on most connections. The layout is spartan: one page, collapsible cards for top sources, pages, countries, devices. No tabs, no sub-navigation.

Fathom’s interface is more polished. It has tabs for current visitors, uptime monitoring (included free), and event funnels. The design feels more considered, but it’s also heavier. On slower connections or mobile, you’ll notice the lag.

If you check analytics daily and want instant feedback, Plausible wins. If you check weekly and want a bit more UI personality, Fathom feels nicer to open.

Features: where they diverge

Both handle the basics—pageviews, referrers, devices, goals, custom events. But the extras differ.

Plausible includes email reports (daily, weekly, monthly), shared dashboards, and Google Search Console integration. It also offers a self-hosted option if you want to run your own instance (starts at $0 for self-hosters, but you handle the server).

Fathom includes uptime monitoring (checks your site every 30 seconds from multiple regions), EU isolation (useful for GDPR-strict clients), and better event funnel visualisation. It also lets you import historical Google Analytics data, which Plausible doesn’t.

Neither tool offers heatmaps, session replay, or A/B testing. If you want those, you’re looking at Hotjar or Microsoft Clarity (free, privacy-questionable) as a separate layer.

Roll-up reporting and multi-site operators

Both let you combine multiple properties into one dashboard, but the UX differs.

Plausible calls this “roll-up reporting.” You pay for total pageviews across all sites, but you can view aggregate stats or drill into individual properties. It’s clean, but the setup requires manually grouping domains.

Fathom doesn’t have native roll-up views. You track each site separately and flip between them in a dropdown. If you want combined stats, you export CSVs and merge them yourself. For operators running 5+ properties, this gets tedious fast.

When to pick Plausible

• You’re starting out and want the lowest entry price for a single site.
• You value dashboard speed and minimal UI chrome.
• You want Google Search Console integration baked in.
• You’re open to self-hosting (or already run your own infrastructure).

When to pick Fathom

• You’re doing 100k+ pageviews per month and want better per-pageview pricing.
• You need uptime monitoring without adding another tool.
• You want to import your GA history before making the switch.
• You prefer a more polished interface and don’t mind the weight.

What neither tool solves

Both are great if you want top-line traffic numbers and respect visitor privacy. But if you need user-level attribution—knowing which blog post led to a purchase three weeks later—you’ll need something heavier. Fathom and Plausible don’t track users across sessions. That’s the tradeoff for being cookieless.

If you monetise via ads, neither integrates with ad networks. You’ll still need Google Analytics or a dedicated ad analytics layer. If you monetise via products or subscriptions, you can wire custom events to both tools and get conversion counts—but you won’t get cohort analysis or LTV breakdowns.

For most solo operators and small content teams, that’s fine. You’re not optimising funnels at scale. You just want to know what’s working.

Want more tool breakdowns like this? Reply and tell us which category you want compared next—hosting dashboards, AI writing assistants, or social schedulers all qualify.

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.