Category: Analytics

Every analytics dashboard—Google Analytics, Plausible, Fathom, WordPress stats—drops you into a default date range the moment you open it. Most offer the same list of presets: Last 7 Days, Last 30 Days, This Month, Last Month, Quarter to Date, Year to Date.

These shortcuts exist to save clicks. But they also shape what you see—and what you miss. A preset that works for one question will bury the answer to another. Here’s how to match the range to the question, and when to ignore the dropdown entirely.

Rolling windows vs. calendar blocks

Presets fall into two families: rolling windows (Last 7 Days, Last 30 Days) and calendar blocks (This Month, Last Quarter).

Rolling windows always include today (or yesterday, depending on when the tool refreshes). They slide forward every day. Last 7 Days on a Tuesday covers the prior Tuesday through Monday. On Wednesday, it shifts to cover Wednesday through Tuesday.

Calendar blocks snap to the first and last day of a period. This Month runs from the 1st to today. Last Month is the full prior month, start to finish.

Rolling windows smooth out weekly spikes—paydays, weekends, batch-send days. Calendar blocks make month-over-month comparisons clean, but they break mid-month: comparing This Month (9 days) to Last Month (31 days) produces noise, not signal.

If you want to spot a traffic drop or a spike in unsubscribes, use a rolling window. If you’re preparing a report or reconciling revenue, use a calendar block after the period closes.

When Last 30 Days hides a two-week slump

Last 30 Days is the most common default. It’s long enough to dampen daily noise but short enough to feel recent. The problem: it averages over a full month, so a bad week gets diluted by three good ones.

Say traffic tanks on November 1st because a hosting issue takes your site offline for six hours. By November 9th, Last 30 Days still includes October 10th–31st—three weeks of normal performance. The total looks fine. The trend chart shows a dip, but the summary metric undersells it.

If you suspect a recent change, shrink the window. Last 7 Days or Last 14 Days will surface the drop faster. Then compare that range to the same span one cycle earlier (week-over-week or fortnight-over-fortnight) to confirm it’s not seasonal.

Quarter to Date and the mid-quarter blind spot

Quarter to Date runs from the first day of the current quarter (January 1st, April 1st, July 1st, October 1st) to today. It’s useful if you report quarterly or run campaigns that reset every three months.

But early in a quarter—say, the first two weeks of October—you’re comparing 14 days of data to 90 days last quarter. The percentage-change figure is meaningless. Wait until at least six weeks in, or compare the first N days of this quarter to the first N days of the prior quarter using a custom range.

Most dashboards let you set two custom ranges side by side. In Google Analytics, click the date picker, choose your range, then toggle Compare and pick “Previous period” or manually enter the matching span from the prior quarter (checked November 2026, Google Analytics Help: Date comparisons).

When to build a custom range

Presets fail when your question doesn’t match a calendar or a round number of days. A few scenarios where custom ranges win:

• Campaign attribution: You ran a seven-day promotion that started on a Thursday and ended the following Wednesday. Last 7 Days won’t line up unless you check on exactly the right day. Set the range to match the campaign start and end.
• Platform migration: You moved from one newsletter platform to another on a specific date. Compare the 30 days before the switch to the 30 days after, using that migration date as the boundary.
• Seasonal comparison: You want to know if November 2026 traffic is up year-over-year. Set the range to November 1st–30th, 2026, then compare it to November 1st–30th, 2025.
• Partial-week data: It’s Saturday, and you want to see Monday–Friday performance without weekend noise. Custom range: last Monday to yesterday.

The extra two clicks pay off when the default range would mix apples and oranges.

One rule: always compare to something

A single number—4,203 visitors, 18.2% open rate—means nothing without context. Presets make it easy to add a comparison: most tools let you toggle “Compare to previous period” or “Compare to previous year.”

But “previous period” isn’t always apples-to-apples. If you’re looking at Last 30 Days on a Monday, the comparison period ends on a different day of the week, and day-of-week effects (newsletter sends, weekend dips) can skew the delta.

When precision matters, set both ranges manually so they cover the same days of the week. That way, a Monday-to-Sunday span compares to another Monday-to-Sunday span, not Monday-to-Saturday.

If your analytics tool doesn’t support dual custom ranges—some simpler dashboards don’t—export the data to a spreadsheet and calculate the comparison there.

Want more breakdowns like this? Subscribe to One Two Three Send for one operator-focused article every day—no fluff, no generic listicles, just the tooling details that matter when you’re running the show solo.

If you run an online business on scheduled analytics exports—weekly traffic reports, monthly revenue snapshots, subscriber growth CSVs—you’ve probably assumed those files live forever. They don’t. Most platforms auto-delete exports after a retention window, and that window varies wildly by tool.

Miss the download window, and you lose historical granularity. Wait too long to pull a quarterly comparison, and the raw data is gone. Here’s how export schedules actually work, where data disappears, and how to keep what matters.

Retention windows by platform type

Google Analytics 4 stores raw event data for 2 or 14 months depending on your retention setting (checked November 2026). Once that window closes, aggregated reports persist, but user-level and event-level exports disappear. If you export a custom exploration today and try to re-run it 15 months later with 14-month retention, the underlying data won’t exist.

Plausible Analytics keeps all dashboard data indefinitely, but CSV exports depend on your plan. The Growth and Business tiers (checked November 2026) allow unlimited historical exports; the free tier does not guarantee export retention beyond the visible dashboard range.

For email platforms, MailerLite retains campaign reports indefinitely but limits bulk subscriber export history. ConvertKit keeps subscriber activity logs, but automated export URLs generated via Zapier or Make expire after 30 days unless you store the file externally.

Payment processors differ too. Stripe keeps transaction data indefinitely in the dashboard, and API access stretches back to account creation, but scheduled payout reports in the Dashboard only go back 12 months (checked November 2026) unless you use the Sigma reporting add-on.

Scheduled exports vs. on-demand pulls

Scheduled exports—daily summary emails, weekly Slack digests, monthly CSV drops—usually generate a file once and store it temporarily. If the platform emails you a link, that link often expires. Google Analytics 4 scheduled email reports don’t include raw data; they’re summary PDFs. To get the CSV, you need to run the exploration manually or use the API.

On-demand exports give you control but require discipline. If you wait until the end of a quarter to pull subscriber growth data and your platform only retains 90 days of granular activity, you’ll get aggregated counts but lose the daily breakdown you need for trend analysis.

For operators running content businesses, this gap shows up when you try to correlate a traffic spike with a specific campaign six months later. The campaign report exists, but the session-level data—landing page, referrer, time on page—has expired.

What to export and when

Pull event-level or user-level data monthly if your platform has a retention limit. For Google Analytics 4, export custom explorations with user or event scope at least once per retention period. Store these as dated CSVs in a dedicated folder—cloud storage works, but name the files with ISO dates (2026-11-01) so they sort chronologically.

For email platforms, export your full subscriber list with custom field data and engagement scores monthly. Even if the platform keeps the list live, historical snapshots let you reconstruct churn cohorts and identify when engagement patterns shifted.

Revenue data from Stripe, PayPal, or Gumroad should be pulled quarterly at minimum. Use the platform’s native export or API to grab line-item transaction detail, not just summary totals. If you’re using Stripe, the Reporting API (checked November 2026) gives you access to all transactions, but you need to query it—scheduled reports don’t include everything.

Where automated exports fail

Zapier and Make can schedule exports, but both have storage limits. Zapier’s task history keeps run logs for 30 days on paid plans (checked November 2026), and attached files disappear with the logs. If your Zap emails you a weekly GA4 export and you delete the email, the data is gone.

Make stores execution history for 30 days on the free tier, longer on paid plans, but file attachments are not archived indefinitely. Route exports to Google Drive, Dropbox, or an S3 bucket instead of relying on the automation platform’s storage.

Email-based exports—platforms that send you a CSV link via email—expire fast. Most links are pre-signed URLs with 7- to 14-day lifespans. Download immediately or set up a filter that auto-saves attachments to cloud storage.

For operators managing multiple income streams or traffic sources, centralising exports matters. A single missed monthly pull can break year-over-year comparisons. Set calendar reminders, or build a monthly export checklist that covers analytics, email, payments, and any API-fed dashboards.

Want more infrastructure breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives into the tools and workflows that keep online businesses running.

A reader asked: “Apple Mail Privacy Protection means half my list shows 100% opens. How do I know what’s actually being read?”

Short answer: you can’t track individual opens reliably anymore. Apple’s Mail Privacy Protection (MPP), rolled out in 2021 and now used by roughly 50% of email clients according to Litmus data (checked November 2026), prefetches and caches emails—including tracking pixels—before the recipient ever opens them. Gmail and other providers have followed with similar privacy features.

But you’re not flying blind. You just need to shift what you measure and how you interpret it.

What still works: aggregate engagement and click behavior

Open rates are now a ceiling, not a floor. If your newsletter platform reports 65% opens, that tells you at most 65% of your list received the email in an inbox that loaded images. It doesn’t tell you who read it.

Click-through rate (CTR) becomes your primary engagement signal. Clicks require intentional action—a privacy feature can’t fake them. Track total unique clicks per send, and watch the trend over time. If CTR drops while reported opens stay flat or rise, you know engagement is softening even if the open number looks healthy.

Most newsletter platforms—Beehiiv, MailerLite, ConvertKit, Buttondown—report clicks with full attribution. Focus there. A 3–5% CTR on a content newsletter is typical; above 8% suggests strong relevance.

Segment by domain and client when possible

Not all subscribers are affected equally. MPP primarily impacts users on Apple Mail (iOS, macOS, iCloud.com). Gmail users on the web client or Android app generally don’t trigger prefetch behavior in the same way.

If your platform lets you segment by email domain or client, compare engagement across groups. Look at click rates for @gmail.com vs. @icloud.com vs. @hey.com addresses. You’ll often find that non-Apple domains still show meaningful open-rate variation, while Apple domains cluster near 100% or show erratic patterns.

This won’t give you individual-level certainty, but it helps you understand where your data is cleanest and where it’s noisiest.

Use reply rate and conversion events as ground truth

If you include a question, poll, or call to reply in your newsletter, track how many people respond. Reply rate is unambiguous—someone had to read enough to hit send.

Similarly, if you link to a landing page, product, or signup form, your analytics platform (Google Analytics, Plausible, Fathom) will show referral traffic from your email. Cross-reference newsletter send time with a spike in email referrals. That’s real engagement.

For monetised newsletters, track attributed revenue or conversions per send. If you’re promoting an affiliate link, course, or sponsorship landing page, measure downstream outcomes instead of trying to back-solve from open data.

Stop optimising subject lines for open rate alone

Pre-MPP, A/B testing subject lines against open rate made sense. Now, that metric is too noisy to trust for statistical significance unless your list skews heavily toward non-Apple clients.

Test subject lines against click rate or reply rate instead. Pick two variants, send to a small segment, wait an hour, and see which drove more link clicks. That’s the version that got people to engage, regardless of whether the pixel fired honestly.

Better yet: test entire email concepts—topic, format, CTA—rather than marginal wording tweaks. The signal-to-noise ratio is higher.

What to tell stakeholders or sponsors

If you sell sponsorships or report metrics to a team, don’t bury the MPP caveat. Explain that opens are directional, not precise, and provide click data and conversion tracking as the verified engagement layer.

Most sponsors in 2026 understand this. If they don’t, point them to the Apple Privacy Features page (checked November 2026) and any of the dozens of trade articles published since 2021. Open rate inflation is now industry-standard context.

Offer attributed traffic (UTM-tagged links), conversions, or reader survey data instead. These are harder to game and more closely tied to sponsor ROI.

One last thing: if your newsletter platform still highlights open rate as the top-line metric on your dashboard, dig into the settings. Many now let you reorder or hide it. Put clicks, growth rate, and reply rate up front instead. What you look at every morning shapes what you optimise for—make sure it’s a number that still means something.

Got a question about running your online business? Hit reply or send it our way—we’ll answer it in a future edition.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Every analytics dashboard relies on referrer headers to tell you where traffic came from. When someone clicks a link from Twitter, Reddit, or a newsletter archive, their browser sends a Referer HTTP header that tells your server which page sent them. Your analytics tool logs it, and you see “twitter.com” or “reddit.com” in your traffic sources report.

Except when you don’t. Because referrer headers disappear under a growing list of conditions, and most solo operators have no idea how much of their attribution data is missing.

When referrer headers get stripped

Browsers suppress referrer information in three common scenarios. First, when a visitor moves from HTTPS to HTTP, most browsers send no referrer at all—a security measure that’s been standard since 2020. If you’re still serving any pages over plain HTTP, every inbound link from a secure site shows up as “direct” traffic.

Second, browser privacy settings. Safari’s Intelligent Tracking Prevention and Firefox’s Enhanced Tracking Protection both limit referrer detail. A visitor clicking from a social media site may send only the domain (twitter.com) instead of the full URL, or nothing at all if they’ve tightened their privacy settings. Chrome’s privacy modes do the same.

Third, referrer-stripping extensions and VPNs. Tools like uBlock Origin, Privacy Badger, and many commercial VPNs actively remove referrer headers to prevent tracking. A meaningful slice of your audience—often the most engaged, privacy-conscious readers—will never show a referrer, no matter where they came from.

There’s also the Referrer-Policy header, which the sending site controls. If the platform linking to you sets Referrer-Policy: no-referrer or same-origin, your analytics will see nothing. Some email clients and messaging apps strip referrers by default when opening external links.

What you lose

The immediate loss is attribution. When referrer data is missing, analytics platforms categorise the visit as “direct” or “(none)”. That bucket balloons, and you lose visibility into which guest posts, which social threads, or which link placements are actually sending traffic.

For content-driven businesses, this makes it nearly impossible to measure the ROI of off-site work. You write a guest article, it gets published, you see a small traffic bump—but half of it lands in “direct” because readers came via email newsletters or apps that don’t pass referrers. You can’t tell which publications are worth pitching again.

It also skews A/B test results if you’re running experiments on landing pages. If one variant attracts more privacy-conscious visitors (say, via Hacker News vs. Facebook), referrer suppression will make that variant look like it has more “direct” traffic. You might conclude the wrong page is performing better.

Workarounds that actually work

The most reliable fix is UTM parameters. Append ?utm_source=twitter&utm_medium=social (or similar) to every link you control—guest post bios, social media profiles, email signatures. UTM tags survive referrer stripping because they’re part of the URL itself, not an HTTP header. Google Analytics, Plausible, and Fathom all parse them by default.

This only works for links you can edit. You can’t add UTM parameters to organic social shares or inbound links from other people’s sites. For those, you’re reliant on referrer headers, and you’ll have a blind spot.

Another option: server-side analytics that log more than just the referrer. Tools like Plausible and Fathom record the full request path, including query strings, so even if the referrer is blank, you can still see if someone arrived via a UTM-tagged URL. They also respect Do Not Track and privacy regulations, which matters if your audience skews technical or European.

Some operators use link shorteners (Bitly, Short.io) as a middle layer. Every link you share publicly goes through the shortener, which logs the click before redirecting to your site. You lose some speed and add a dependency, but you gain click-level attribution even when referrers vanish. The trade-off is worth it if you’re doing a lot of outbound promotion and need precise source tracking.

What to expect in the months ahead

Referrer suppression isn’t reversing. Apple, Mozilla, and Google have all moved toward stricter privacy defaults over the past two years, and third-party tracking is only getting harder. The shift to server-side analytics and first-party data collection is accelerating, which means more operators will need to rely on UTM discipline and direct measurement instead of passive referrer logging.

If you haven’t audited your “direct” traffic bucket recently, do it this week. Filter your analytics by landing page and see which URLs show up most often under “direct”. If they’re deep content pages—posts, guides, resources—you’re almost certainly losing referrer data. Those visits came from somewhere, and your dashboard just doesn’t know where.

Start tagging your links. Build a simple UTM template (source, medium, campaign) and use it everywhere you can edit a URL. It’s the only attribution method that survives modern privacy tooling, and it’s free.

One Two Three Send breaks down the infrastructure that online businesses run on—traffic, tools, and the mechanics that matter. Subscribe to get one focused piece like this every day.

When you launch your first newsletter, every platform dashboard puts open rate front and centre. It’s big, it’s visible, and it feels like the number that matters. Click-through rate sits right next to it. Both feel urgent—how many people opened, how many clicked.

But neither metric tells you whether your email reached the inbox in the first place.

Delivery rate—the percentage of sent emails that were accepted by the recipient’s mail server—is the first number you should check every time you send. If your delivery rate drops, nothing else matters. Your brilliant subject line, your perfect call-to-action, your segmented list: all invisible if the email bounced or never left the queue.

What delivery rate actually measures

Delivery rate counts how many emails were accepted by the receiving server. It does not tell you whether the email landed in the inbox, the promotions tab, or the spam folder—only that the server didn’t reject it outright.

Most email platforms calculate it as: (total sent − bounces) ÷ total sent. A hard bounce (invalid address, domain doesn’t exist) counts against you. A soft bounce (mailbox full, temporary server issue) may retry, but repeated soft bounces eventually become hard bounces.

According to Postmark’s email deliverability guide (checked October 2026), a healthy delivery rate sits above 95%. Below that, you have list-hygiene problems, authentication issues, or you’re hitting spam traps.

Why it breaks before open rate does

Open rate can look fine even when your delivery infrastructure is failing. Here’s how: if 100 emails bounce but 400 reach the inbox and 80 of those open, your open rate is 20%—reasonable on paper. But your delivery rate is 80%, which means one in five emails never arrived.

Platforms like Beehiiv and MailerLite surface delivery rate in their analytics dashboards, but it’s often tucked below the fold or inside a secondary report. You have to choose to look at it. Open rate and click rate update live; delivery rate might only refresh after the send completes, so it feels less immediate.

The gap widens when you clean your list based on engagement. You remove subscribers who haven’t opened in 90 days, and your open rate climbs. But if those subscribers were valid addresses—just disengaged—you’ve done nothing to fix the bounces that hurt your sender reputation. Delivery rate would have told you the real problem.

When to investigate a drop

Check delivery rate after every send, especially if you’ve changed list sources, import methods, or authentication records. A drop of more than 2–3% between sends means something structural shifted.

Common causes: you imported a purchased or scraped list (don’t), your SPF or DKIM records broke during a DNS migration, your sending domain was flagged by a blocklist, or your platform’s shared IP pool got penalised by another sender.

Most platforms let you export bounces with reason codes. RFC 3463 defines the standard SMTP status codes: 5.x.x codes are permanent (hard bounce), 4.x.x are temporary (soft bounce). If you see a surge in 5.1.1 (user unknown) or 5.1.2 (domain not found), your list quality collapsed. If you see 4.2.2 (mailbox full) or 4.4.1 (connection timeout), it’s usually transient—but watch for patterns.

What to do when delivery rate falls

First: segment your most recent import or sign-up cohort and check its delivery rate separately. If new subscribers bounce at 15% but your core list delivers at 98%, the problem is your acquisition source, not your infrastructure.

Second: verify your email authentication. Google’s DMARC, DKIM, and SPF setup guide (checked October 2026) walks through the DNS records every sender needs. If you migrated hosting or changed your sending service, these records may have been orphaned or overwritten.

Third: remove hard bounces immediately. Every platform auto-suppresses them, but if you’re exporting lists between tools or using a secondary CRM, you may be re-importing dead addresses. One send to a known-bad address can trigger spam-trap alerts.

Fourth: if delivery rate is healthy but inbox placement feels low (opens are down but bounces aren’t up), you’re likely landing in spam or promotions. That’s a separate problem—content, sending frequency, and engagement history—but delivery rate rules it out as a DNS or list-quality issue.

Here’s the workflow: Before you obsess over subject-line A/B tests or click-map heatmaps, make delivery rate your first dashboard check. Set a threshold—95% minimum—and investigate any send that falls below it. Fix authentication, clean your list, and isolate bad acquisition sources. Only then does open rate tell you anything useful.

If you want to dig deeper into email infrastructure and why some platforms handle bounces better than others, reply and let us know—we’ll compare how Postmark, MailerLite, and Beehiiv surface delivery diagnostics in a future piece.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Most analytics dashboards default to auto-refresh. Open Google Analytics 4, Plausible, or Fathom, and the page updates itself every few minutes—sometimes every few seconds. It feels modern. It feels like you’re watching your business in real time.

But for solo operators and small teams, live-updating dashboards introduce three quiet problems: they can inflate session counts, they obscure attribution windows, and they train you to make decisions on incomplete data.

Here’s what actually happens when your dashboard refreshes itself, and when you should turn it off.

Auto-refresh inflates your own sessions

Every time your analytics dashboard pulls new data, it may register as a pageview or session—depending on how the tool tracks its own interface. GA4, for example, treats the dashboard UI as a separate property, so you won’t pollute your site metrics. But self-hosted tools like Matomo or Umami can log dashboard visits as traffic if you haven’t excluded your IP or set up a separate view.

Even if the tool filters you out by default, anyone on your team who leaves a dashboard open in a pinned tab will trigger repeated data fetches. If your analytics rely on server-side logs or API calls, each refresh costs a request—and depending on your plan, that can mean hitting rate limits or incurring overage fees.

Plausible and Fathom both auto-refresh every 60 seconds when a dashboard is in focus. If you’re on a metered API plan and you’ve embedded a stats widget in Notion or a Google Doc, that widget is polling every minute, all day. On a 30-day month, that’s 43,200 requests per embed.

Live data hides attribution lag

Most analytics platforms batch and reconcile data every few hours. GA4’s real-time report shows visits from the last 30 minutes, but it doesn’t show completed conversions, referral sources that require a second-party handshake, or UTM parameters that get resolved server-side.

If you’re running a content funnel—blog post to lead magnet to email to product—your conversion path crosses multiple systems. The blog pageview logs instantly. The email click might take 15 minutes to sync from your ESP. The purchase event can take an hour to flow from Stripe to your analytics via webhook.

Auto-refresh dashboards make you think you’re seeing the full picture, but you’re watching a half-rendered frame. A visitor who arrived via a Twitter link might show as “direct” in the real-time view because Twitter’s referrer stripping hasn’t been back-filled yet. If you screenshot that data for a decision or a client report, you’ve locked in incomplete attribution.

When to disable auto-refresh

Turn off dashboard auto-refresh if you’re:

• Reviewing weekly or monthly trends. Refreshing a 30-day report every 60 seconds doesn’t change the numbers enough to matter. You’re just burning CPU and API quota.
• Comparing attribution sources. Let the data settle for at least four hours after a campaign launches. Referral reconciliation, email open tracking, and server-side event logging all introduce lag.
• Embedding dashboards in documentation or internal wikis. A static snapshot is clearer than a live ticker that changes while someone reads.
• Using metered or rate-limited analytics APIs. Plausible’s API allows 600 requests per hour on the standard plan. If you’re embedding live widgets, you’ll hit that cap by mid-morning.

GA4 lets you pause real-time updates by switching to the “Reports” view instead of “Realtime.” Plausible and Fathom don’t offer a toggle, but you can disable auto-refresh in your browser: in Chrome, open DevTools (F12), go to Network Conditions, and throttle to “Offline” when you want a static view. Refresh once manually when you need updated data.

What to do instead

Set a daily or twice-daily check-in cadence. Open your dashboard, let it load once, then screenshot or export the data you need. If you’re running a launch or a promotion and need tighter feedback, refresh manually every two hours—but wait at least 90 minutes after a traffic spike before treating the numbers as final.

For client reports or internal documentation, export CSV or PDF snapshots instead of embedding live iframes. Tools like Fathom and Plausible both offer scheduled email reports; configure those to send at end-of-day, when attribution has settled.

If you’re self-hosting and your dashboard is logging its own traffic, add an exclude rule for your team’s IPs or set up a separate analytics property for internal tools. Matomo and Umami both support IP exclusion lists and user-agent filters.

Live dashboards look sharp in a pitch deck, but they’re built for ops teams watching uptime and fraud, not solo operators reviewing content performance. For most online-business decisions, day-old data is more accurate than minute-old data—because it’s actually finished processing.

Want more deep-dives on analytics tooling and workflow mechanics? Subscribe to One Two Three Send—one operator-to-operator article every day, no fluff.

Most operators obsess over monthly churn rate. It’s the metric that arrives in your dashboard like a report card: 3.2% unsubscribed this month, 4.1% the month before. You watch it tick up after a product pivot or a format change, and you panic.

But churn rate is a lagging indicator that hides more than it reveals. A 5% churn rate tells you nothing about whether your best subscribers are leaving or your worst. It doesn’t distinguish between someone who unsubscribed after two emails and someone who stayed for eighteen months before moving on.

Subscriber tenure does. It measures how long people stay subscribed before they leave—and it’s a far better early-warning system for content-business health.

Why tenure beats churn for solo operators

Churn rate is an average. If you lose 50 subscribers in a month and you have 1,000 on your list, that’s 5%. But if 45 of those unsubscribes came from people who joined in the last 30 days, and only five were long-term readers, your problem isn’t retention—it’s onboarding or acquisition quality.

Tenure reveals that distinction. When you track how long subscribers stay before leaving, you can spot patterns:

• If median tenure drops from 11 months to 6 months over a quarter, your content stopped resonating with the audience you built.
• If 60% of unsubscribes happen in the first two weeks, your welcome sequence or initial content promise is broken.
• If tenure for paid subscribers is 18 months but free subscribers churn at 4 months, you know exactly where to focus monetization effort.

Churn tells you someone left. Tenure tells you when—and that timing is the diagnostic.

How to calculate subscriber tenure

Most newsletter platforms don’t surface tenure directly. You’ll need to export your subscriber data and calculate it yourself.

Pull two fields: subscribe date and unsubscribe date. For active subscribers, use today’s date as the endpoint. Calculate the difference in days, then convert to months. If you’re working in a spreadsheet, the formula is simple:

=DATEDIFF(subscribe_date, unsubscribe_date, "D") / 30

Once you have tenure in months for every subscriber—active and churned—calculate the median, not the mean. Median tenure is resistant to outliers (the subscriber who’s been around since day one skews the average). It tells you how long a typical subscriber sticks around.

Track this monthly. If median tenure for churned subscribers is rising, your content is getting stickier. If it’s falling, something changed—and you need to figure out what.

Segmenting tenure by acquisition source

The real power of tenure analysis comes when you segment by where subscribers came from. Export your list with a third column: acquisition source or UTM campaign.

You’ll often find that subscribers from organic search have higher tenure than those from paid ads. Referrals from a specific partner might churn fast, signaling audience mismatch. A lead magnet that worked in 2025 might be pulling in low-tenure subscribers in 2026 because the market moved.

One operator I know tracks tenure by lead magnet. She discovered that her “10-day email course” attracted subscribers who stayed an average of 14 months, while her “free template library” pulled in readers who left after 3 months. She killed the template funnel and doubled down on courses. Revenue per subscriber jumped 40% in two quarters.

That insight doesn’t show up in a churn-rate dashboard.

When to intervene

If you see median tenure dropping, don’t wait for churn rate to confirm it. Tenure is the canary. Act early:

• Audit the last 8–12 pieces of content. Did your tone shift? Did you stop solving the problem people subscribed for?
• Check your welcome sequence. If early-stage churn is spiking, the first three emails aren’t matching the signup promise.
• Survey recent unsubscribes. Ask one question: “What would have kept you subscribed?” You’ll get better answers than any engagement metric.

Churn rate will catch up eventually. But by the time it moves, you’ve already lost the subscribers. Tenure gives you a month or two of runway to fix the problem before it compounds.

Want more operator-focused metrics breakdowns? Subscribe to One Two Three Send—we dissect one tool, tactic, or number every day.

Tooling note

If you’re on Beehiiv, MailerLite, or ConvertKit, you can export subscriber lists with timestamps. For platforms that don’t include unsubscribe dates in the export (Mailchimp’s default CSV skips it), you’ll need to pull from their API or request a full data export under account settings.

Postmark includes granular event logs if you’re using it for transactional sends—useful if you’re tracking tenure on behavior-triggered sequences, not just broadcast lists.

Set a monthly calendar reminder. Pull the data, calculate median tenure, note any major changes. It takes fifteen minutes and surfaces problems your dashboard will miss for weeks.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

If you publish an RSS feed alongside your newsletter or blog, you’ve probably wondered how many people actually subscribe to it. The answer is: you almost never know, and the number you do see is usually wrong.

RSS was built in an era when privacy meant something different. Readers pull your feed; your server logs the request. That’s it. There’s no mandatory ping-back, no central registry, no “subscribe” event that fires when someone adds your feed to their reader.

Here’s what actually happens when someone subscribes, where the data lives, and how to get a realistic picture of your RSS audience.

What your server sees

Every time an RSS reader checks your feed, it makes an HTTP request. Your web server logs that request with a timestamp, IP address, and user agent string. That’s the raw material.

If you run WordPress, those logs live in your hosting provider’s control panel or via SSH at /var/log/apache2/access.log or /var/log/nginx/access.log. Most shared hosts archive or rotate logs after 7–30 days, so anything older than that is gone unless you explicitly save it.

User agents tell you which app fetched the feed: Feedly, Inoreader, NewsBlur, Apple Podcasts (if it’s a podcast feed), or a custom-built scraper. They don’t tell you how many people subscribed via that service—just that the service itself requested your feed.

Feedly, for example, fetches your feed once and caches it for all its users who subscribe to you. One request might represent 500 subscribers, or five. You can’t tell from the log.

What FeedBurner used to show (and why it stopped working)

FeedBurner was the go-to solution for RSS analytics until Google effectively abandoned it in 2021. It acted as a proxy: you pointed your feed URL to FeedBurner, and it served a wrapped version of your feed while counting requests and estimating subscriber counts.

It worked—barely—by analyzing user agent strings and request patterns, then applying heuristics to guess unique subscribers. But those heuristics broke as RSS readers changed how they cache and poll feeds. By 2023, most FeedBurner stats were flatlined or wildly inaccurate.

If you still use FeedBurner in 2026, the subscriber count you see is almost certainly stale. It hasn’t been maintained in years, and major readers like Feedly have changed their polling behavior multiple times since.

Where subscriber counts actually live

Some RSS services do report subscriber counts—but only if they choose to, and only for their own platform.

Feedly shows you how many Feedly users follow your feed if you claim it via their publisher tools. Log in at feedly.com, search for your feed, and look for the “Claim this feed” option. Once verified, you’ll see a follower count under the feed’s public page. It’s accurate for Feedly, but tells you nothing about Inoreader, NetNewsWire, or any other reader.

Substack and Beehiiv both offer RSS feeds for newsletters, but neither exposes a public subscriber count for the feed itself—only for email subscribers. If someone adds your Substack RSS to their reader, you won’t see that in your Substack dashboard.

WordPress plugins like Jetpack Stats will show you feed views in aggregate, lumped together with other traffic. You can filter by /feed/ in your stats panel, but again, it’s requests, not subscribers.

How to measure RSS readership in 2026

If you need real numbers, track clicks instead of subscriptions. Embed a unique UTM parameter in every link inside your RSS feed:

https://yoursite.com/article?utm_source=rss&utm_medium=feed&utm_campaign=main_feed

Then measure those clicks in Google Analytics, Plausible, or Fathom. This tells you how many people read and acted on your feed content, which is more useful than a theoretical subscriber count anyway.

You can also set up a redirect link for one high-value post per week and track how many RSS readers click through. Tools like Bitly or your own URL shortener will give you exact click counts.

Another option: if you run a podcast feed, most podcast hosting platforms (Transistor, Captivate, Buzzsprout) report per-app download stats. They can’t tell you subscriber counts either, but they break down listens by Apple Podcasts, Spotify, Overcast, etc., which gives you a clearer picture than a blog RSS feed ever will.

What to do if you need proof for sponsors

Sponsors usually don’t care about RSS subscribers—they care about reach. If you monetize via sponsorships and someone asks for RSS metrics, give them:

• Total feed requests per month (from server logs or a plugin like Jetpack)
• Click-through rates on UTM-tagged links in recent feed posts
• Feedly follower count (if you’ve claimed your feed)
• Email subscriber count as the primary metric, with RSS as a bonus

No sponsor expects RSS to be your main channel in 2026. If they do, they’re either very niche (developer tools, open-source communities) or haven’t updated their media kit requirements in a decade.

Want more operator-focused breakdowns like this? Subscribe to One Two Three Send and get one article like this every day, covering everything from newsletter tools to WordPress hosting to AI prompts that actually work.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Open your analytics dashboard, watch a visitor land on your site, and see… nothing. Refresh the page five minutes later and suddenly three sessions appear. The “real-time” label sits right there in the interface, but the data doesn’t match what’s happening right now.

Most analytics platforms advertise real-time dashboards, but very few update continuously. The refresh interval—the gap between when an event happens and when it appears in your dashboard—varies wildly depending on what you’re measuring, which plan you’re on, and how the platform processes data behind the scenes.

If you’re making decisions based on dashboard numbers, you need to know what’s actually current and what’s been batched, sampled, or delayed.

What “real-time” actually means in analytics platforms

Google Analytics 4 is the clearest example. The Real-Time report updates every few seconds and shows activity from the last 30 minutes. But the moment you leave that report and open Acquisition or Engagement, you’re looking at data that’s between 24 and 48 hours old. GA4 processes most reports in daily batches, not continuously.

Plausible and Fathom refresh their main dashboards every 60 seconds. If you’re watching live, you’ll see new pageviews appear roughly once a minute. That’s fast enough for most use cases, but it’s not instant—if you’re running a launch and want to know whether traffic spiked in the last ten seconds, you’re still guessing.

Matomo’s live widget updates every few seconds when you’re on a self-hosted instance, but their cloud version throttles refresh rates on lower-tier plans to reduce server load. If you’re on the cheapest plan, expect updates every 60 to 90 seconds.

Mixpanel and Amplitude update event streams within seconds, but their funnel and cohort reports recompute on a schedule—usually every 15 minutes to an hour, depending on data volume. If you’re tracking a funnel and refresh the page expecting new conversions, you might be looking at stale totals.

Dashboard widgets vs. raw event logs

Most platforms separate their real-time event stream from their aggregated dashboards. The event stream is fast—often sub-10-second latency—because it’s just appending rows to a log. The dashboard, on the other hand, has to query, filter, and aggregate that data, which takes time.

If you need to confirm that a tracking event fired, check the event log or debugger, not the dashboard. GA4’s DebugView updates within seconds. Mixpanel’s live view shows events as they arrive. Plausible doesn’t have a separate event stream, so you’re waiting for the dashboard refresh no matter what.

For solo operators, this split matters when you’re testing campaigns or debugging tracking. If you fire a test event and immediately check the dashboard, you might think tracking is broken when it’s actually just queued.

Refresh intervals by metric type

Not all metrics update at the same speed, even within the same platform.

Pageviews and sessions: These usually update within 60 seconds on most platforms. Plausible, Fathom, and Matomo all refresh these quickly because they’re simple counters.

Conversion goals and funnels: These can lag by 5 to 15 minutes because the platform has to check whether a session completed a multi-step sequence. GA4 conversions often take 24 hours to appear in standard reports, even though they show up faster in the Real-Time view.

Revenue and e-commerce data: Expect delays of 15 minutes to several hours. Platforms batch these queries to avoid hammering payment APIs. If you’re tracking Stripe revenue through a Zapier webhook, the event might fire instantly, but your analytics dashboard might not recompute totals until the next scheduled job runs.

Attribution reports: These are almost never real-time. Attribution models require matching sessions across days or weeks, so most platforms run these overnight. If you’re checking which campaign drove yesterday’s signups, you’re probably looking at data that’s 12 to 36 hours old.

When refresh speed actually matters

For most content-driven businesses, real-time updates don’t change decisions. Checking traffic once or twice a day is enough. But there are a few cases where refresh intervals matter:

During a launch or campaign: If you’re running a ProductHunt launch or a limited-time promo, you want to know within minutes whether traffic is spiking and whether conversions are happening. A 24-hour delay in GA4 means you’re flying blind.

When debugging tracking: If you just installed a new analytics snippet or updated a conversion goal, you need fast feedback to confirm it’s working. Waiting an hour to see if a test event fired wastes time.

If you’re running paid ads: Ad platforms like Facebook and Google Ads update their dashboards every few minutes. If your analytics platform lags by an hour, you can’t cross-check whether the traffic you’re paying for is actually landing on your site.

For everything else—weekly traffic trends, month-over-month growth, cohort retention—real-time refresh doesn’t matter. A daily batch report is fine.

How to work around slow dashboards

If your analytics platform is too slow for your needs, you have a few options:

Use the platform’s event debugger or live view instead of the main dashboard when you need instant feedback. GA4’s DebugView, Mixpanel’s live feed, and Matomo’s visitor log all update faster than their aggregated reports.

Set up a separate real-time dashboard using a tool like Geckoboard or Databox, pulling from your analytics API. These tools query your data every few minutes and display it in a single view. It’s overkill for most solo operators, but if you’re coordinating a launch with a team, it helps.

Accept that some metrics will always lag and plan around it. If you’re checking conversion rates, don’t expect up-to-the-minute accuracy. Check once in the morning, make decisions, and move on.

Most platforms won’t tell you their exact refresh intervals unless you dig through their docs or ask support. If you’re evaluating a new analytics tool, test it during signup: fire a few test events, note the time, and see how long it takes for them to appear in each report.

If you’re running a content business and want more breakdowns like this, subscribe to One Two Three Send. One email a day, no fluff, just the infrastructure details that solo operators actually need.

Real-time analytics dashboards feel like the future. You refresh, numbers update instantly, and you watch visitors flow through your site like water through a pipe. But after running content businesses for years, I’ve stopped using them—and the operators I respect most have done the same.

The thesis is simple: real-time analytics create more anxiety than insight for solo operators, and the decisions that actually move your business don’t require sub-minute data refresh cycles.

Real-time data answers questions you shouldn’t be asking

When you can see live visitor counts, you start checking obsessively. A post goes out, you refresh every two minutes to see who clicked. Traffic drops at 2pm, you wonder if something broke. A spike appears, you hunt for the source before it even registers as statistically meaningful.

None of this changes what you do next. You’re not running a newsroom with breaking stories or a SaaS product where downtime costs thousands per minute. You’re writing, publishing, and building an audience over weeks and months. The question “how many people are on my site right now” has no useful answer for that work.

Compare that to page-refresh analytics—the kind where you load a report, see yesterday’s or last week’s data, and close the tab. You check once a day, maybe twice. You look for patterns across days, not fluctuations across minutes. The data is old enough that you’ve already moved on to the next piece of work, so you’re not tempted to react to noise.

Decision latency matters more than data latency

The best operators I know make big changes slowly. They publish consistently for a month, then look at aggregate traffic. They run a campaign, wait a week, and review conversions. They don’t pivot based on an hour of data because an hour teaches you almost nothing.

Real-time dashboards seduce you into thinking fast data enables fast decisions. It doesn’t. It just makes you refresh more often and second-guess choices that need time to prove out.

Here’s the test: name the last time real-time data changed what you did that day. Not what you worried about—what you actually changed. For most solo operators, the answer is never, or close to it.

What page-refresh analytics look like in practice

I use Google Analytics 4, but I’ve turned off all real-time reports. I check the dashboard once in the morning, usually while coffee brews. I look at the prior day’s traffic, top pages, and referral sources. That’s it. The data is 12 to 36 hours old, and that’s exactly the latency I want.

When I’m testing something new—a headline format, a topic cluster, a traffic source—I set a calendar reminder to check results in seven days. Not tomorrow. Not in an hour. A week. That’s the minimum window where patterns separate from randomness for a site getting a few hundred visits a day.

For conversion tracking, I use the same rhythm. I look at email signups, affiliate clicks, and product sales once a week. I export the numbers into a spreadsheet, compare them to the prior week, and only act if I see a trend across three weeks or more.

This isn’t laziness. It’s discipline. Real-time data makes you react to everything. Time-delayed data forces you to react to things that matter.

When real-time actually matters

There are exceptions. If you’re running a live launch—a webinar, a cart-open window, a time-sensitive campaign—real-time data helps you catch technical failures fast. A broken payment link, a redirect loop, a missing email confirmation. Those need immediate fixes, and real-time dashboards catch them.

But even then, you’re not watching the dashboard continuously. You’re checking it at planned intervals: right after the email sends, an hour later, then at the end of the day. You’re still batching your attention, not streaming it.

For day-to-day operations—publishing posts, growing an email list, optimizing evergreen content—real-time data is a distraction dressed up as a feature.

How to turn off real-time (or just stop looking)

Most analytics platforms default to real-time views because they look impressive in demos. Google Analytics 4 has a “Realtime” report in the left nav. Plausible and Fathom show live visitor counts on the homepage. You don’t have to use them.

In GA4, bookmark the “Reports > Traffic acquisition” page instead of the overview. In Plausible, go straight to the “Top pages” view. In Fathom, click through to “Top sources” first thing. Make the stale, batched data your default landing page, and you’ll stop checking the live feed by accident.

If you’re using a custom dashboard or a tool that forces real-time views, set a recurring calendar block once a day labeled “check analytics.” Train yourself to only open the tab during that window. The rest of the day, the dashboard doesn’t exist.

You’ll feel anxious the first week. You’ll wonder if you’re missing something important. You’re not. You’re just breaking the refresh addiction, and on the other side is calmer, better decision-making.

Want more like this? Subscribe to One Two Three Send for weekly tactics on running a calmer, more profitable online business—no real-time dashboard required.