GA4 sampling starts at 500k sessions—here's what you lose
The spreadsheet sits open on your second monitor, pivot tables refreshing while your coffee goes cold. Someone on your team asks why yesterday’s conversion data doesn’t match the dashboard you screenshotted this morning. You refresh the report. Different numbers.
Google Analytics 4 starts sampling your data at 500,000 sessions—and hides it
Cross half a million sessions in your query window and GA4 silently switches to estimates.
Google Analytics 4 doesn’t warn you when it starts sampling. The green badge appears in the corner of your report—”This report is based on 22% of sessions”—and suddenly your funnel metrics, your device breakdowns, and your landing-page attribution are built on extrapolations, not logs. The threshold is consistent: 500,000 sessions in the date range you’ve selected. Go beyond that and GA4 picks a subset, analyses it, then multiplies the results back up to simulate the full data set.
The problem isn’t the sampling itself—most operators will never notice a three-point swing in aggregate conversion rate. The problem is what sampling obscures: outlier behaviour, low-volume segments, and anything that only appears in the unsampled portion. If you’re running split tests, auditing referral fraud, or diagnosing a sudden spike in bot traffic, sampled data becomes a liability. You’re debugging a model, not your actual logs.
The fix is to export raw event data to BigQuery before you hit the threshold, or to tighten your query window so you stay under 500,000 sessions per report. GA4’s BigQuery export is free for the standard tier and writes every event, unsampled, to your own data warehouse. You’ll need to write SQL to query it, but you’ll have the full record—no estimation, no green badge, no second-guessing your own metrics.
RELATED READING
Google Search Console’s ‘last crawled’ timestamp lags reality by days
Search Console shows you when Google last crawled a URL, but that timestamp doesn’t reflect when the crawl data landed in your dashboard—or when Google actually indexed the page. The lag varies by site authority and server response time, and there’s no API field that tells you the true freshness of the data you’re reading. If you’re monitoring indexing speed after a site migration or trying to diagnose why a new post isn’t ranking, the ‘last crawled’ column becomes a source of confusion, not clarity.
TACTIC
WordPress incremental backups skip tables that changed mid-cycle
Incremental backup plugins compare timestamps to decide what’s new since the last snapshot. If a database table was modified after the comparison ran but before the backup job finished, that change gets skipped—it’s too new for this cycle, too old for the next. The risk is highest on high-traffic membership sites and WooCommerce stores where orders and user meta update constantly. Most operators assume incremental means complete; it doesn’t. You need a secondary full backup on a slower cadence to catch what falls between the gaps.
OPERATIONS
Transactional email breaks when you route it through your marketing ESP
Password resets, order confirmations, and login codes need different infrastructure than your weekly newsletter. Marketing ESPs throttle sends, batch deliveries, and share IP reputation across your entire subscriber base. One spam complaint from a promotional campaign can delay a customer’s order receipt by minutes—or send it to spam entirely. Operators who split transactional email onto a dedicated service like Postmark or AWS SES see faster delivery, cleaner logs, and no cross-contamination between marketing reputation and critical user flows.
Know someone who would like this? Forward today’s email—every operator we reach is one closer to running an online business with a little less friction.