Category: Analytics

Privacy-first analytics platforms sell themselves on the same pitch: no cookies, no GDPR banners, fast scripts, and clean dashboards. Plausible, Fathom, and Simple Analytics dominate the category, but they differ in meaningful ways once you’re past the landing page.

If you run a content-driven business and you’re tired of Google Analytics bloat—or you need to ditch cookie banners without losing visitor insight—here’s what each tool does well, where it falls short, and who should pick which.

Pricing and visitor thresholds

All three charge based on monthly pageviews, but the tiers and caps differ.

Plausible starts at $9/month for up to 10,000 pageviews. You pay $19/month for 100,000 views, $29/month for 200,000, and pricing scales from there. If you exceed your plan, Plausible emails a warning and asks you to upgrade—it doesn’t cut off tracking.

Fathom starts at $15/month for 100,000 pageviews. The entry tier is higher, which means if you’re sub-50,000 views per month, you’re overpaying compared to Plausible. Fathom counts by pageviews across all sites on your account, so multi-site operators hit limits faster.

Simple Analytics starts at €19/month (roughly $20 USD) for 100,000 pageviews. Pricing is similar to Fathom but billed in euros. Simple Analytics offers a “business” tier that includes mini-websites—embedded public dashboards you can share without login—which the other two don’t bundle at the base level.

If you’re under 50,000 pageviews per month, Plausible wins on cost. Above that threshold, all three converge, and the decision shifts to features and interface preference.

Feature differences that matter

All three tools show you top pages, referrers, devices, browsers, and countries. The gaps appear when you need goals, funnels, or custom dimensions.

Plausible supports custom event goals at no extra cost. You can track button clicks, form submissions, or file downloads by adding a JavaScript snippet or using their API. Plausible also offers a custom properties feature that lets you attach metadata to events—useful if you want to track blog post category performance or product variant clicks. The dashboard is fast, and the filter UI is clean. Plausible is open-source and offers a self-hosted option if you want to run it on your own infrastructure.

Fathom keeps the interface even simpler. Custom events exist, but Fathom doesn’t support event metadata or properties—you get event names and counts, nothing more granular. That’s fine if you’re tracking basic conversions (newsletter signups, link clicks), but limiting if you need segmentation. Fathom’s uptime monitoring feature sends you alerts if your site goes down, which is a nice bundled extra the others lack. Fathom is closed-source and cloud-only.

Simple Analytics falls between the two. It supports events and metadata, similar to Plausible. Simple Analytics also has a built-in automated events feature that tracks outbound links and file downloads without manual setup. The dashboard lets you create multiple views and share them publicly via mini-websites, which is useful if you want to show traffic stats to sponsors or partners. Simple Analytics is open-source like Plausible, but its self-hosted version requires more technical setup.

Script size and page speed impact

All three advertise sub-1KB scripts. In practice, Plausible’s script is around 1KB, Fathom’s is 1.4KB, and Simple Analytics is 3KB. The difference is marginal—none will tank your Core Web Vitals—but if you’re optimizing aggressively, Plausible has the smallest footprint.

All three scripts are proxy-friendly, meaning you can serve them from your own domain to avoid ad blockers. Plausible and Fathom document this clearly; Simple Analytics requires a bit more config work.

Who should pick which

Pick Plausible if you’re under 50,000 pageviews per month, you want custom event properties, or you value open-source software and self-hosting optionality. Plausible’s pricing scales cleanly as you grow, and the event tracking flexibility covers most operator needs without requiring a migration later.

Pick Fathom if you want the simplest possible dashboard, you’re already above 100,000 pageviews, and you value the uptime monitoring extra. Fathom’s lack of event metadata keeps the interface uncluttered, which some operators prefer. It’s also the most polished UI of the three—if aesthetics matter to your daily workflow, Fathom feels the most refined.

Pick Simple Analytics if you need public dashboard sharing (for sponsors, clients, or transparency pages), you want automated event tracking without manual setup, or you’re already comfortable with euro billing. Simple Analytics sits in the middle on features and pricing, which makes it a safe default if you’re unsure.

One thing all three miss

None of these tools track individual user journeys or session replays. If you need to see how a single visitor navigated your site—or you want heatmaps—you’ll need a separate tool or a hybrid setup. That’s by design: privacy-first analytics don’t fingerprint users. But it’s a tradeoff worth naming if you’re migrating from Google Analytics and expect session-level data.

If you’re running a newsletter or content site and you just need clean traffic numbers without the compliance headache, any of these three will work. The decision comes down to pageview volume, whether you need event metadata, and how much you care about dashboard aesthetics.

Want more tool breakdowns like this? Reply and tell us which category to compare next—we’ll prioritize reader requests.

Most analytics platforms don’t show you every visitor. On free and starter plans, tools like Google Analytics 4, Fathom, and Plausible apply data sampling once you cross certain thresholds—sometimes without telling you clearly in the dashboard.

Sampling means the platform processes a subset of your traffic and extrapolates the rest. For solo operators running content sites or newsletters, this can distort the metrics you’re optimizing for: which posts drive signups, which UTM sources convert, and how long readers stay.

Here’s what sampling looks like in practice, when it kicks in, and how to tell if your numbers are directionally wrong.

What gets sampled and what doesn’t

Sampling typically applies to custom reports, segments, and date-range queries—not the default real-time or overview dashboards. If you filter traffic by UTM campaign, landing page, or device type over a trailing 90-day window, you’re more likely to hit sampling.

Google Analytics 4 samples when a query touches more than 10 million events in the selected property and date range. For a site logging 50,000 monthly sessions with typical event instrumentation (page views, scrolls, clicks), you’ll cross that threshold in about six months of retained data.

Plausible and Fathom don’t sample on their paid plans, but their free tiers and trials cap total event volume. Plausible’s free plan allows 10,000 monthly page views before sampling or blocking; Fathom’s trial is capped at 30 days and 100,000 page views, after which data stops flowing entirely unless you convert.

The metrics most affected: conversion funnels, cohort retention, and multi-touch attribution. Sampling drops edge-case paths—your highest-intent visitors often behave differently from the median, so a 10% sample may miss the behavior that matters most.

How to spot sampling in your reports

Google Analytics 4 shows a green checkmark or yellow warning icon at the top of exploration reports. The yellow icon means your query was sampled; the percentage shown (e.g., “based on 8.3% of sessions”) tells you how much data was used.

If you’re running a custom segment—say, traffic from a specific referrer with a conversion event—and the icon shows sampling, your funnel metrics are modeled estimates, not raw counts.

Plausible and Fathom don’t display sampling warnings because they don’t sample on paid plans. If you’re on a free or trial tier and your traffic exceeds the cap, you’ll see a hard cutoff: events stop logging, or the dashboard shows partial days.

Other platforms—Mixpanel, Heap, Amplitude—offer generous free tiers but throttle or sample retroactively once you exceed event limits. Mixpanel’s free plan caps at 20 million monthly events; past that, older data gets archived and queries slow down or return incomplete results.

When sampling breaks your decisions

Sampling matters most when you’re optimizing for conversion rate, attribution, or cohort behavior. If you’re A/B testing two landing pages and your analytics tool samples the traffic, a 2% lift in conversions might be noise, not signal.

Example: You’re tracking newsletter signups from three UTM sources—organic search, Twitter, and a paid Facebook campaign. GA4 samples your 90-day report at 12%. The dashboard shows Twitter driving 40 signups and Facebook driving 38. In reality, Facebook drove 52 and Twitter drove 29—but the sample skewed toward a few high-traffic Twitter days.

You reallocate budget based on bad data. Two weeks later, your cost per signup doubles.

Sampling also hides outlier sessions: your longest time-on-page visits, your highest scroll depths, and your multi-page readers. These are your most engaged users, and they’re statistically rare. A 10% sample has a lower chance of capturing them.

How to avoid or reduce sampling

The simplest fix: narrow your date range and segment size. Instead of querying 90 days of traffic with five filters, query 30 days with two. If GA4 still samples, break the report into weekly chunks and aggregate manually in a spreadsheet.

If you’re on Google Analytics 4 and sampling is chronic, consider exporting raw event data to BigQuery. GA4’s BigQuery export is free for up to 1 million events per day on the free tier, and queries run on unsampled data. The learning curve is steep—you’ll need SQL and a basic understanding of GA4’s event schema—but it’s the only way to guarantee complete data at scale.

For operators who don’t want to manage SQL, switching to a paid analytics plan eliminates sampling. Plausible starts at $9/month for 10,000 monthly page views with no sampling. Fathom starts at $14/month for 100,000 page views, also unsampled. Both platforms count page views, not events, so instrumentation is simpler.

If you’re running a high-traffic site (500,000+ monthly page views), expect to pay $50–$100/month for unsampled analytics. That’s the floor for tools that process every session.

One more thing: sampling isn’t always disclosed

Not every platform tells you when data is modeled or incomplete. If your dashboard shows a suspiciously round conversion rate—exactly 5.0%, not 4.87%—or if your funnel drop-off percentages don’t add up to 100%, you’re probably looking at sampled or aggregated data.

Test this by exporting a raw event log (if your tool supports it) and comparing totals to the dashboard. If the counts don’t match, ask support whether sampling is applied and at what threshold.

For newsletter operators and solo founders, unsampled data isn’t perfectionism—it’s the difference between knowing which traffic source pays for itself and guessing based on a model that drops your best readers.

Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and tactics that run online businesses.

Open Google Analytics, Plausible, or Fathom right now. You’ll see pageviews, sessions, bounce rate, referrers. Clean charts. Tidy numbers. Everything you need to know about your traffic.

Except you’re looking at a summary of a summary of a summary. The dashboard is a lossy compression algorithm designed to make patterns visible—and in doing so, it hides the outliers, the edge cases, and the signal buried in the noise.

If you’re running a content business, those hidden details are where the decisions live.

What the default view doesn’t show you

Most analytics dashboards aggregate by default. They show you total sessions, average time on page, top landing pages. That’s fine for a monthly report, but it flattens the distribution.

Here’s what vanishes:

• Single-page sessions that converted. A reader lands on your pricing page, scrolls to the bottom, clicks “subscribe,” and leaves. Bounce rate: 100%. Value: high. The dashboard flags it as a failure.
• Referrer context beyond the domain. You see “twitter.com” in your referrer log. You don’t see which tweet, which reply thread, or whether it came from a quote-tweet with 800 impressions or a reply buried three levels deep.
• Time-on-page outliers. Your median time on page is 1:20. One reader spent 22 minutes. Another spent four seconds. The average says nothing about either.
• Entry and exit paths that don’t follow your funnel. You assume readers land on your homepage, browse, then subscribe. Half of them land on a three-year-old post, read two paragraphs, and subscribe from the inline CTA. Your dashboard doesn’t highlight that path unless you go looking.

Default dashboards are built for SaaS companies with linear funnels. Content businesses don’t have linear funnels. Readers enter from anywhere, stay as long as they want, and convert when something clicks. The dashboard doesn’t map that.

The data you need to export manually

If you want to see what’s actually happening, you need to pull raw session logs or build custom reports. Here’s what to look for:

Session duration distribution, not average. Export time-on-site data and chart it as a histogram. You’ll see three clusters: under ten seconds (accidental clicks or bots), 30 seconds to two minutes (skimmers), and five minutes-plus (engaged readers). The third group is your real audience. The dashboard average blends all three into a number that describes no one.

Conversion paths, not just conversion rate. Most analytics tools let you build a funnel report. Set it to show all paths, not just the primary one. You’ll find readers who convert after visiting your about page, your uses page, and a random blog post from 2023. That’s not a broken funnel—it’s how trust builds in a content business.

Referrer URLs, not referrer domains. If you’re using GA4, enable the full referrer URL in your data stream settings. If you’re using Plausible or Fathom, export your referrer data and sort by frequency. You’ll see which specific tweets, Reddit threads, or Hacker News comments are sending traffic. That tells you what to do more of.

Exit pages for engaged sessions only. Filter your exit-page report to sessions longer than two minutes. You’ll see where your best readers leave. If they’re exiting from your pricing page, your CTA might be unclear. If they’re exiting from a post with no CTA, you’re leaving conversions on the table.

When to ignore the dashboard entirely

Sometimes the dashboard is wrong in a way that matters.

If you’re running a small operation—under 10,000 sessions a month—your sample size is too small for statistical patterns to emerge. A single Reddit post can double your traffic for a day and skew your monthly average. The dashboard will show a spike, then a drop, and suggest you’re losing momentum. You’re not. You just had one good day.

If you’re publishing sporadically, your traffic will look like a sawtooth. The dashboard will show declining engagement because it assumes consistent output. It doesn’t know you took two weeks off.

If you’re testing a new traffic channel—say, you’re experimenting with Pinterest or Threads—the dashboard will bury it under “other” until it hits 5% of total traffic. You won’t see early traction unless you filter for it.

In all three cases, the dashboard is technically accurate. It’s just not useful.

What to do instead

Set up three custom reports and review them monthly:

• A session-duration histogram, filtered to organic and referral traffic only.
• A conversion-path report showing all routes to subscription, not just the top funnel.
• A referrer-URL export, sorted by engaged sessions (two minutes or longer).

These three views will tell you more about your audience than any pre-built dashboard. They take ten minutes to set up and five minutes to review. The insight-to-effort ratio is better than anything else in your analytics stack.

Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep dives on the tools and tactics that actually move the needle for solo operators.

Most analytics platforms promise to tell you exactly where your traffic came from. Google Analytics 4 shows you a tidy funnel with source, medium, and campaign labels. You see “organic search” or “Facebook / cpc” and assume you know what’s working.

But if you’re running more than one acquisition channel at the same time—SEO content, a Google Ads campaign, and a LinkedIn presence, for example—your attribution data is almost certainly lying to you.

The problem isn’t the tools. It’s that attribution models can’t handle the way real people behave online.

Why multi-touch attribution falls apart

Attribution models try to assign credit for a conversion across multiple touchpoints. GA4 offers data-driven attribution by default, which sounds sophisticated until you realize it’s still guessing.

Here’s what actually happens: someone finds your site via organic search, reads a post, leaves. Three days later they see your LinkedIn post, click through, subscribe. Two weeks after that, they click a retargeting ad and buy your course.

GA4 will credit the last non-direct click—the retargeting ad—even though the organic post did most of the work. If you switch to first-click attribution, you overweight SEO and ignore the fact that your ad closed the deal. Data-driven attribution tries to split the difference, but it’s still modeling behavior it can’t fully see.

Cross-device journeys make it worse. If someone reads your newsletter on their phone and later converts on desktop, most analytics platforms treat those as two separate users unless you’re running a logged-in experience with user IDs.

The result: you look at your attribution report and think Facebook is outperforming SEO, so you cut your content budget. Three months later, your paid campaigns stop converting because there’s no top-of-funnel content feeding them.

What to track when attribution breaks

Instead of trusting last-click or data-driven models, track channel performance in isolation and watch for correlation, not causation.

Segment by landing page source. If most of your organic traffic lands on blog posts and most of your paid traffic lands on a dedicated landing page, you can compare conversion rates by entry point. It’s not perfect, but it’s more honest than pretending GA4 knows which click “caused” the sale.

Use UTM parameters religiously, but don’t over-rely on them. Tag every link you control—social posts, email campaigns, guest articles. But remember that UTMs only tell you where the last click came from. If someone clicks your LinkedIn post, browses, leaves, and returns via direct traffic, the UTM is gone.

Track assisted conversions separately. GA4’s “Advertising” workspace has an assisted conversions report that shows which channels appeared earlier in the funnel, even if they didn’t get last-click credit. It’s buried, but it’s one of the few reports that acknowledges multi-touch reality.

Run channel blackout tests. This is the only way to measure true incrementality. Pause one channel completely for two weeks and watch what happens to your overall conversion volume. If you turn off paid ads and conversions drop by exactly the amount those ads were generating, they were working. If conversions stay flat, your paid traffic was cannibalizing organic visits that would have converted anyway.

When to stop caring about attribution

If you’re a solo operator pulling in less than $10K/month, attribution modeling is probably a distraction. You don’t have enough traffic or conversions to make statistical inferences, and you’re better off focusing on channel-level metrics: CPM for paid ads, click-through rate for email, time-on-page for SEO content.

Attribution matters when you’re spending enough that a 10% efficiency gain is worth the analytical overhead. For most indie operators, that threshold is somewhere north of $5K/month in paid acquisition spend.

Below that, track what you can measure cleanly—email open rates, organic impressions, ad spend per signup—and accept that the handoff between channels is a black box. Your job is to keep all the channels healthy, not to perfectly allocate credit between them.

A better question than “which channel converted?”

Instead of asking which channel gets credit for the sale, ask: which channels would cause revenue to drop if I turned them off?

That’s a harder question to answer, but it’s the one that actually matters. It forces you to think in terms of systems, not funnels. Your SEO content feeds your email list. Your email list warms people up for your paid retargeting. Your retargeting closes deals that started with a Twitter thread six weeks ago.

Attribution reports want to collapse that system into a single “winning” channel. In reality, the system only works when all the parts are running.

If you want to get serious about measuring incrementality, set up holdout groups, run A/B tests at the channel level, and accept that you’ll never have perfect data. If you just want to grow your business, watch revenue per channel over time and invest more in whatever’s trending up—even if you can’t prove exactly why.

Got a question about tracking, attribution, or analytics for your online business? Reply to this email—we read everything and answer the best questions in future issues.

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.