Category: Analytics

Most solo operators inherit analytics event-naming advice from enterprise playbooks: pick a consistent schema, document it in a spreadsheet, enforce it across every tool. The promise is clarity—one event name, one definition, one source of truth.

The reality is messier. When you track the same event across Google Analytics 4, a CRM, an email platform, and a payment processor, identical labels often mean subtly different things. GA4’s purchase event fires on confirmation-page load. Your payment processor’s purchase webhook fires when funds clear. Your CRM’s purchase tag triggers when a deal stage changes. None of them happen at the same moment, and none of them count the same subset of transactions.

Forcing a single name across all four systems doesn’t unify your data—it hides the gaps.

Where naming consistency helps

Event schemas make sense within a single platform. If you’re routing custom events into GA4, a predictable structure—category_action_label or verb_noun—keeps your reports readable and your segments reusable. The same applies to customer-data platforms that ingest events from multiple sources but store them in one database.

Consistency also helps when you’re debugging. If every button click follows the same pattern—click_cta_header, click_cta_sidebar—you can filter by prefix and catch tracking gaps faster.

But once you cross tool boundaries, the schema starts working against you.

The multi-tool attribution gap

Here’s the common scenario: you run a content site with a paid membership tier. A reader lands via organic search, opens three articles, clicks a paywall CTA, enters their email on a lead-magnet landing page, receives a nurture sequence, clicks a checkout link in email four, and completes payment.

GA4 sees the paywall click and the checkout page view. Your email platform (MailerLite, Postmark, ConvertKit) sees the email opens and link clicks. Your payment processor (Stripe, Lemon Squeezy) sees the transaction. If you name every conversion point conversion, your attribution report shows three separate conversions with no shared context.

You can’t merge them retroactively because the timestamps don’t align—GA4 logs in the user’s timezone, your email platform logs in UTC, and Stripe logs when the webhook fires, which might be seconds or minutes after the charge.

Naming every step conversion or purchase makes your dashboard look unified. But when you try to calculate cost-per-acquisition or attribute revenue to a specific traffic source, you’re double- or triple-counting.

Namespace by tool, not by intent

A better approach: prefix event names with the tool or surface that generated them. Instead of purchase everywhere, use:

• ga4_purchase for client-side page tracking
• stripe_charge_succeeded for payment webhooks
• crm_deal_closed for CRM pipeline updates
• email_checkout_click for link tracking in transactional sequences

This naming convention makes the gaps explicit. When you run a report and see four different revenue events for the same order, you know immediately which one to trust (usually the payment processor) and which ones are proxies.

It also makes it easier to build rollup metrics. If you want a single “conversion” event that fires once per paying customer, you write a rule: count stripe_charge_succeeded, ignore everything else. You’re not guessing which purchase event is the real one.

When to break the namespace rule

There’s one case where tool-agnostic naming still makes sense: when you’re using a customer-data platform like Segment, RudderStack, or Hightouch to route events from a single source to multiple destinations.

In that setup, the CDP is the source of truth. You send one Order Completed event with a structured payload, and the CDP forwards it to GA4, your CRM, your email tool, and your data warehouse. Each destination interprets the same event in its own way, but you’re starting from a single canonical definition.

Even then, you’ll want to add destination-specific properties—GA4 needs transaction_id, Stripe needs payment_intent, your CRM needs deal_id—but the top-level event name can stay consistent.

What this means for your reporting stack

If you’ve been wrestling with attribution models that don’t add up, check your event-naming layer first. Open your GA4 events list, your email platform’s link-tracking log, and your payment processor’s webhook history. Look for overlapping names. If you see the same label in three places, assume they’re counting different things until you prove otherwise.

Then decide which tool owns the metric. Revenue attribution? That’s your payment processor. Email engagement? That’s your ESP. Page-level behaviour? That’s GA4. Name your events to reflect ownership, not aspiration.

The goal isn’t a beautiful schema—it’s a reporting stack where every number has one clear source and every query returns the same answer twice.

Got a question about analytics, attribution, or tooling for solo operators? Reply to this newsletter—we read every response and use the best ones for future deep-dives.

You fire a custom event in Google Analytics 4. You check DebugView. Nothing. You check the real-time report. Still nothing. Three days later, the event count sits at zero.

Custom events in GA4 fail more often than platform defaults, and the diagnostic trail is deliberately obscure. If you run a content business that tracks signups, downloads, or affiliate clicks through GA4 events, silent failures cost you attribution data you can’t recover.

Here’s where custom events break, how to trace the failure, and what to fix before you file a support ticket or hire a developer to rebuild your entire tracking stack.

The four places custom events disappear

1. The event never fires in the browser. Your tag manager condition is wrong, the trigger element doesn’t exist on the page, or JavaScript errors block execution. Open your browser’s console, filter by “gtag” or “dataLayer,” and watch for the push. If you see nothing when you click the button or load the page, the event isn’t leaving the client.

2. The event fires but GA4 rejects it. Event names longer than 40 characters get dropped. Parameter names with spaces, hyphens, or uppercase letters get silently ignored. If your event is called affiliate_link_clicked_homepage_sidebar_cta, GA4 truncates it. If your parameter is link-URL, it’s gone. Check the naming rules and test with a simplified version.

3. The event arrives but DebugView doesn’t show it. DebugView only displays events from sessions where debug mode is active—either through the GA4 DebugView Chrome extension, a debug_mode parameter in your gtag config, or a query string flag. If you’re testing in an incognito window without the extension, you won’t see anything even if the event is logging correctly in production. Switch to the real-time report or wait 24–48 hours for the event to appear in the standard reports.

4. The event logs but doesn’t appear in reports. GA4 has a 500-event-name limit per property. If you’ve already registered 500 custom events (common in properties that auto-track every button click or scroll depth), new events get dropped. You won’t get a warning. Check your event list under Configure → Events and archive unused events to free up slots.

What to check first

Start with the browser console, not DebugView. Log in as a test user, trigger the event, and confirm the dataLayer.push fires. If it does, check the payload for naming violations—no spaces, no capitals, no special characters except underscores.

Next, verify the event reaches Google. Open the Network tab in your browser’s developer tools, filter by “collect,” and look for a request to google-analytics.com/g/collect with your event name in the query string. If you see it there, the event left your site. If GA4 still doesn’t show it, the rejection happened server-side.

Finally, check your property’s event quota. Go to Configure → Events and count how many are marked as custom. If you’re near 500, you’ve hit the ceiling. Archive old events or consolidate similar actions under a single event name with dynamic parameters.

Common silent failures

Measurement Protocol events submitted without a valid client_id get logged but attributed to no user. If you’re sending server-side events from a backend script, make sure you’re passing the same client_id that the client-side gtag generated. Mismatched IDs orphan the event.

Events fired before the GA4 config tag loads get lost. If you’re triggering a custom event on page load and your tag manager fires it before the GA4 initialization completes, the event won’t attach to a session. Add a delay or fire the event only after gtag('config') resolves.

Cross-domain tracking breaks event attribution if the _ga cookie doesn’t transfer. If you’re tracking affiliate clicks that redirect to an external domain and back, make sure your linker parameter is appended correctly. A missing or malformed linker drops the session context, and the returning event lands in a new session with no history.

When to rebuild vs. patch

If fewer than 10% of expected events are missing, patch the specific failure—usually a naming issue or a trigger condition. If more than half your custom events don’t log, your implementation is structurally broken. Start over with a fresh tag manager container, test each event in isolation, and document the client_id and session flow.

GA4’s error messages are deliberately vague. The platform won’t tell you which parameter failed or why an event didn’t register. Build your own logging layer—either a server-side event collector that mirrors GA4 calls or a Google Sheets endpoint that receives a copy of every dataLayer push. When GA4 goes silent, your backup log will show what actually fired.

Got a GA4 event that refuses to log? Reply with the event name and trigger setup—I’ll tell you where to look.

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.