Category: Analytics

Attribution windows determine how long after someone clicks a link you still get credit for their conversion. Most platforms default to 30 days for clicks, 1 day for views. That sounds generous—until you realize it’s hiding the signal you actually need.

For content-driven online businesses, the gap between click and conversion tells you more than the conversion itself. A 30-day window lumps together immediate intent and vague awareness. A 7-day window isolates the traffic sources that drive action, not just browsing.

What attribution windows actually control

An attribution window is the lookback period a platform uses to assign credit. If someone clicks your affiliate link on Monday and buys on Wednesday, you get the commission—as long as Wednesday falls within the window.

Google Analytics 4 defaults to 30-day click, 1-day view. Meta Ads uses 7-day click, 1-day view. Amazon Associates gives you 24 hours for most products, 90 days for a few categories. Stripe’s attribution tracking (if you’re using UTM parameters) doesn’t enforce a window at all—it’s first-touch forever unless you configure otherwise.

The mismatch creates confusion. Your analytics might show 200 conversions attributed to a blog post, while your payment processor shows 80. The difference isn’t missing data—it’s window drift.

Why shorter windows surface better decisions

A 30-day attribution window inflates the value of top-of-funnel content. Someone reads your SEO guide in July, bookmarks it, forgets about it, then subscribes in August after seeing a LinkedIn post. The guide gets credit. That’s not wrong, but it’s not actionable.

When you tighten to 7 days, you see which content drives near-term intent. A tutorial that converts within a week is fundamentally different from an evergreen pillar post that nudges people over months. Both have value, but if you’re deciding what to write next, the 7-day data tells you what creates momentum.

I tested this on a niche WordPress hosting comparison site. At 30 days, my top post by attributed revenue was a 4,000-word “ultimate guide.” At 7 days, it was a 600-word troubleshooting article about a specific plugin conflict. The guide brought awareness. The troubleshooting post brought buyers. I wrote six more troubleshooting posts. Revenue per publish hour tripled.

Where to adjust attribution settings

Google Analytics 4: Admin → Data display → Attribution settings. Change “Reporting attribution model” from default (usually data-driven, 30-day click) to any custom window. You can set click and view windows independently. I run 7-day click, 1-day view for most clients.

Meta Ads Manager: doesn’t let you change the window in reporting after the fact, but you can toggle between 1-day and 7-day views in the attribution dropdown above your campaigns table. The data’s stored for both; you’re just filtering the view.

Affiliate dashboards (Amazon, Impact, CJ): you can’t change the window—it’s set by the merchant. But you can export raw click and conversion timestamps, then calculate your own 7-day attribution in a spreadsheet. I do this monthly. It shows which content is worth updating versus which is just coasting on old backlinks.

Stripe or other payment processors: if you’re passing UTM parameters into metadata fields, you control attribution logic in your own reporting layer. Most operators don’t bother. If you’re doing $5k+/month in subscriptions, it’s worth the two hours to set up a Zapier flow or custom script that logs source + timestamp, then pivots by window in a Google Sheet.

When 30 days still makes sense

Brand-new sites benefit from longer windows early on—you don’t have enough conversions to segment cleanly, and you want to reward any content that contributes. Once you’re above ~50 conversions per month, tighten to 7 days for operational decisions, but keep a 30-day dashboard around for investor updates or year-end reviews.

High-ticket products or B2B services genuinely have longer consideration cycles. If you’re selling $2,000 courses or SaaS annual plans, a 30-day (or even 90-day) window reflects reality. But even then, I’d run both: 7-day to find high-intent content, 30-day to credit awareness plays.

Content syndication or guest posts often show delayed conversions—someone discovers you on Medium, then subscribes two weeks later via your site. A 30-day window captures that. But if most of your traffic is owned (SEO, email, direct), shorter windows cut through the noise faster.

One thing to try this week: Pull your top 10 attributed traffic sources in Google Analytics at 30-day click attribution. Then switch to 7-day and compare. Anything that drops out of the top 10 is awareness, not conversion. Anything that stays is working. Double down there.

Want more analytics breakdowns like this? Subscribe to One Two Three Send—we dig into the tooling decisions solo operators actually face, one focused article at a time.

ConvertKit’s broadcast analytics dashboard updates in real time—sort of. Opens appear within minutes of sending. Link clicks take longer. Sometimes hours longer. If you’ve ever sent a broadcast, refreshed obsessively, and wondered why you’re seeing 400 opens but only 12 clicks an hour later, you’re not imagining things. The delay is real, and it’s not a bug.

Why opens report faster than clicks

Email opens are tracked with a tiny invisible image embedded in every message. When a recipient’s email client loads that image, ConvertKit logs an open. Most modern email clients—Gmail, Apple Mail, Outlook—preload images as soon as the email arrives in the inbox, even before the recipient actually opens it. That means ConvertKit sees the open event almost immediately, whether or not anyone’s reading.

Link clicks are different. They require the recipient to actually click a URL in your email. ConvertKit wraps every link with a tracking redirect, so when someone clicks, the request hits ConvertKit’s servers first, gets logged, then redirects to your destination. That’s a real human action, not a preloaded asset. It takes time—and it only happens if someone’s genuinely engaged.

The lag isn’t just about recipient behavior. ConvertKit processes click data in batches. Opens are logged instantly because they’re high-volume and low-cost to write. Clicks trigger additional database writes—subscriber activity logs, segment recalculations, automation triggers—so they’re processed in queues. Depending on send volume and server load, that queue can take 15 minutes to two hours to fully flush.

When the lag matters (and when it doesn’t)

If you’re sending time-sensitive content—a flash sale, a webinar reminder, a product launch—you need to know whether people are clicking, not just opening. But checking analytics five minutes after send is premature. The first wave of opens will arrive fast. Clicks won’t stabilize for at least 30 minutes, often longer.

Here’s the timing pattern I’ve seen across dozens of broadcasts to lists between 2,000 and 50,000 subscribers: opens plateau around 60–90 minutes post-send. Clicks plateau around 90–120 minutes. If you’re making a decision—resend to non-openers, adjust your landing page, kill an underperforming link—wait at least two hours. Earlier than that, you’re reading incomplete data.

One edge case: if you’re using ConvertKit’s link triggers to start an automation (e.g., someone clicks “Download the guide” and gets tagged or moved to a sequence), those triggers fire in real time. The click gets logged for automation purposes immediately, but the analytics dashboard number lags behind. So your automation might run before the dashboard reflects the click. That’s intentional—ConvertKit prioritizes subscriber experience over reporting speed.

How to read early-stage broadcast data correctly

Don’t calculate click-through rate in the first hour. The denominator (opens) inflates faster than the numerator (clicks), so your CTR will look artificially low. If you see 8% CTR at the 30-minute mark, it’ll likely settle closer to 12–15% by hour three. I’ve watched this pattern repeat across hundreds of sends.

Instead, track absolute click volume early on. If you’re expecting 200 clicks based on past performance and you’re seeing 40 after 30 minutes, you’re probably on track. If you’re seeing 4, something’s wrong—your subject line didn’t match your content, your link isn’t visible, or your CTA is buried.

One non-obvious tactic: compare your current broadcast’s early click volume to a similar past broadcast at the same elapsed time. ConvertKit doesn’t surface this view natively, so keep a simple spreadsheet: broadcast name, list size, clicks at 30 min, clicks at 60 min, final clicks at 24 hours. After five or six sends, you’ll have a reliable benchmark. If today’s 30-minute number is significantly lower than your average, you can troubleshoot before the send is fully delivered.

When stale data becomes a problem

The lag compounds if you’re running paid traffic to a landing page mentioned in your broadcast. You send the email, check ConvertKit 20 minutes later, see weak click numbers, panic, and spin up a Facebook ad to the same page. Then the ConvertKit clicks catch up an hour later, your ad spend overlaps with organic email traffic, and you can’t tell which source drove conversions. If you’re mixing email and paid on the same day, give email at least 90 minutes to report fully before you activate paid.

ConvertKit’s reporting delay is also why A/B subject line tests sometimes feel inconclusive. The platform splits your list, sends both variants, and declares a winner based on open rate after a set window (usually 4 hours). But if clicks are your real goal, the winner might not be the variant with the highest open rate—it’s the one with the best click-through. You won’t know that until hours after ConvertKit has already sent the winning variant to the remainder of your list.

If click-through matters more than open rate for your business, skip ConvertKit’s built-in A/B test. Manually split your list into two segments, send both variants as separate broadcasts, and wait 3–4 hours to compare click data. It’s more work, but the data’s accurate.

Got a ConvertKit analytics question we should cover? Reply to this email—we read every one and use reader questions to shape future articles. If you found this useful, forward it to another operator who’s probably refreshing their dashboard right now.

Google Analytics 4 gives you almost unlimited flexibility to track custom events. You can fire anything: lead_form_submit, coupon_applied, video_watched. But there’s a hard constraint most solo operators don’t discover until it’s too late: GA4 only indexes 25 custom event parameters per property.

After that, new parameters still get logged in the raw event stream—but they won’t appear in standard reports, Explore, or Looker Studio. You can’t dimension or filter by them. They’re effectively invisible unless you’re pulling BigQuery exports, which most small operators aren’t.

This isn’t a bug. It’s a design decision Google made to keep the product performant. But it catches people by surprise because GA4’s interface doesn’t warn you when you’re approaching the limit, and old Universal Analytics didn’t have this restriction in the same way.

How the 25-parameter limit actually works

When you send a custom event to GA4—say, newsletter_signup with parameters like source, landing_page, referrer, and email_domain—those parameters need to be manually registered as custom dimensions in the GA4 admin panel before they show up in reports.

GA4 gives you:

• 25 custom dimensions (event-scoped)
• 25 custom dimensions (user-scoped)
• 50 custom metrics (numeric values)

Event-scoped dimensions are what most operators burn through first. These are things like button_label, video_title, product_category—anything that describes a single interaction.

Once you hit 25 event-scoped dimensions, you’re done. You can’t add more without archiving an existing one. And archiving doesn’t free up the slot—it just stops collection. Historical data stays, but the dimension becomes read-only.

What breaks when you hit the ceiling

Let’s say you’re tracking newsletter signups across six different lead magnets. You’ve been sending lead_magnet_name as a parameter for months. Then you launch a new sponsored post tracking setup and add five more parameters: sponsor_name, placement_type, cta_variant, reader_segment, and content_topic.

You go to GA4 Explore to build a report. The new parameters don’t show up in the dimension picker. You check the raw event in DebugView—it’s firing correctly. The data is being sent. But it’s not indexed, so it’s not queryable.

Here’s what you lose:

• You can’t segment audiences by that parameter
• You can’t build Explore reports around it
• You can’t use it in Looker Studio dashboards
• You can’t create conversion funnels that filter by it

The only workaround is BigQuery, which requires a GA4 360 subscription (starting at $50,000/year) or a manual export setup most indie operators won’t bother with.

How to plan your parameter budget

The fix isn’t technical—it’s editorial. You need to treat custom dimensions like a finite resource and plan what you track before you start sending events.

Start by auditing what you’re already using. Go to Admin > Data display > Custom definitions in GA4. You’ll see a list of every registered dimension and metric. Count them. If you’re above 20, you’re in the danger zone.

Then ask: Which of these dimensions do I actually query? Most operators register parameters “just in case” and never look at them again. Archive anything you haven’t used in a report in the last 90 days.

For new tracking, consolidate where you can. Instead of separate parameters for lead_magnet_name, lead_magnet_category, and lead_magnet_format, use a single lead_magnet_id and map it to a lookup table in your reporting layer. Instead of tracking button_color, button_size, and button_position separately, combine them into one button_variant string like blue_large_sidebar.

This isn’t elegant, but it works. And it keeps you under the limit.

The non-obvious tip: namespace your parameters early

If you’re starting fresh or still have slots available, prefix your custom parameters by category. Use form_name, form_step, form_source instead of generic names like name, step, source. It makes your dimension list easier to scan, reduces the chance of accidental overwrites, and helps you spot redundant tracking before you register a new dimension.

And when you do hit the limit? Don’t panic and start archiving things randomly. Export your current Explore reports first, note which dimensions they depend on, and only archive parameters that aren’t load-bearing.

Want more breakdowns like this? Reply with the analytics edge case that’s been tripping you up—we’ll cover it in a future issue.

Google Search Console is the one traffic source most operators check daily. But the data you’re looking at isn’t live—and the lag isn’t consistent across all metrics.

If you published something Monday and check GSC Tuesday morning hoping to see clicks, you’ll usually find nothing. The delay isn’t a bug. It’s how Google batches and processes impression and click data across billions of queries. Understanding the lag helps you avoid premature conclusions and know when a traffic change is real.

What updates when

Search Console breaks down into two reporting areas: Performance (clicks, impressions, CTR, position) and Index Coverage (crawl status, indexing errors).

Performance data—the clicks and impressions you care about most—typically lags 24 to 48 hours. If you’re checking data for July 27, expect it to stabilize by July 29. The most recent day in the chart will show partial data and often updates throughout the day, but it won’t be complete until the following day.

Index coverage updates faster. New pages submitted via sitemap or manually requested usually appear within hours. But even here, the last crawled timestamp can lag by a day.

The Performance tab also separates Discover and Google News traffic into separate reports. These update on similar schedules, but Discover data in particular can take up to three days to fully populate—especially if your content spiked in a geography outside your primary market.

When partial data misleads

The most common mistake: seeing a spike in yesterday’s clicks, assuming it’s real, and writing about it—only to watch the number shrink the next day as the data finalizes.

This happens because Google processes high-volume queries faster than long-tail ones. If your content ranks for a competitive term, early click data may show up within 24 hours. But if most of your traffic comes from hundreds of tiny queries, those clicks trickle in over 48 hours.

The inverse is also true. A sudden drop in clicks for “yesterday” might just mean the data hasn’t loaded yet. Wait a full two days before diagnosing a traffic problem.

One tell: if the impressions number is suspiciously low compared to the prior week’s average, the data isn’t done processing. Impressions and clicks populate together, but impressions are a higher-volume signal and tend to fill in first.

What this means for your daily routine

If you check GSC every morning, set your date filter to end two days ago—not yesterday. That gives you complete data and eliminates false positives.

For real-time traffic signals, use Google Analytics 4 instead. GA4’s realtime report updates within minutes. It won’t tell you which queries drove the traffic, but it will confirm whether a spike is happening. Then return to GSC two days later to see the query breakdown.

If you’re running a time-sensitive campaign—a product launch, a news piece, or a seasonal promo—don’t rely on GSC to measure day-one performance. Use GA4, your server logs, or a third-party rank tracker that pings hourly. GSC is for post-mortems, not live monitoring.

When the lag stretches longer

Occasionally, GSC data lags beyond 48 hours. This usually happens during Google algorithm updates, when the system is recalculating rankings and re-processing impression data across the index.

If you notice a three- or four-day gap, check the Google Search Status Dashboard. Google rarely announces processing delays publicly, but operator communities on Reddit and Twitter will surface it quickly.

Another edge case: if your site has fewer than a few hundred impressions per day, GSC sometimes batches your data less frequently. Small sites may see 72-hour lags as normal. The threshold isn’t documented, but anecdotally, sites under 500 daily impressions see slower updates.

One workaround: the Search Console API sometimes surfaces data slightly faster than the web UI, especially for bulk queries. If you’re pulling GSC data into a dashboard or spreadsheet, the API’s freshness can beat the UI by a few hours—but you’re still looking at a 24-hour minimum lag.

Want to catch these operator tips earlier? Subscribe to One Two Three Send—one focused article every morning, no fluff.

The short version: treat Search Console as a lagging indicator. It’s authoritative, but it’s not fast. For daily decisions, pair it with GA4. For weekly analysis, let the data settle before you draw conclusions.

Most solo operators install analytics pixels the same way: copy the snippet, paste it into a header tag manager or WordPress plugin, and move on. But the order those scripts execute changes which events get tracked, how sessions are attributed, and whether conversions appear at all.

Load order isn’t a hosting quirk—it’s a silent filter on your data. When a payment confirmation fires before your analytics library finishes initializing, that conversion never gets logged. When a UTM parameter gets stripped by a redirect before your tracking pixel reads it, attribution breaks. And because these failures happen in milliseconds, you won’t notice until you’re reconciling Stripe revenue against reported conversions and the numbers don’t match.

What happens when pixels fire out of sequence

Most analytics platforms—Google Analytics 4, Plausible, Fathom, Mixpanel—need their base library loaded before any event tracking calls execute. If a custom event fires while the library is still downloading, it gets dropped. No error. No retry. The event just doesn’t exist in your dashboard.

This happens most often on single-page apps, checkout flows, and any page where a conversion event fires on page load rather than user action. A typical failure case: you use a Zapier webhook to log a new subscriber in your CRM, and that webhook triggers a thank-you page redirect. If the redirect happens before GA4’s gtag('event', 'conversion') call completes, the conversion never reaches Google’s servers.

Even when the base library loads in time, the order pixels fire relative to each other determines what data each one sees. If a Facebook Pixel fires before a UTM-stripping redirect, it captures source attribution. If it fires after, it logs the visit as direct traffic. Neither setup is “wrong”—but one gives you attribution data you can act on, and the other doesn’t.

Where load order gets decided

If you’re using a tag manager—Google Tag Manager, Matomo Tag Manager, or a WordPress plugin like Site Kit—load order is controlled by trigger rules and priority settings. Most operators leave these at default, which means tags fire in the sequence they were added. That’s fine until you add a new pixel six months later and it fires last, missing fast-loading events.

GTM lets you set a “tag firing priority” number. Higher numbers fire first. If your GA4 base tag has priority 10 and a custom conversion event has priority 5, the event will try to fire before the library exists. Set the base tag to a higher number than any dependent event, and the problem goes away.

In WordPress, most analytics plugins inject scripts into wp_head or wp_footer hooks. The order depends on plugin load sequence, which is alphabetical by folder name unless you force a specific order with a plugin like Code Snippets or a custom functions.php entry. If two plugins both hook into wp_head with default priority (10), the one whose folder name comes first alphabetically loads first.

That’s why renaming a plugin folder or switching from “Google Analytics for WordPress” to “Site Kit by Google” can silently change your tracking setup.

What breaks when checkout flows redirect too fast

Payment processors and course platforms almost always redirect immediately after a transaction. Stripe Checkout, Gumroad, and most hosted course tools send the buyer to a confirmation URL within milliseconds of payment. If your analytics pixel hasn’t finished sending the conversion event by the time that redirect fires, the event is abandoned mid-request.

The fix is to delay the redirect until tracking calls return a success callback—but most platforms don’t expose that hook. Stripe Checkout’s success_url is a hard redirect; there’s no “wait for analytics” option. The workaround is to fire the conversion event on the confirmation page itself, not the checkout page. That way, even if the redirect is instant, the event fires after the user lands on a stable URL.

This also means your conversion tracking needs to deduplicate. If someone refreshes the thank-you page, the event fires again. GA4 handles this with a client ID and session timestamp; other tools require a transaction ID parameter you pass through the URL and check against a cookie or localStorage flag.

How to audit what’s actually firing

Open your browser’s network tab, filter by “analytics,” “gtag,” “pixel,” or the domain of your tracking provider, and reload the page. Watch the order requests appear. If a conversion event request fires before the base library’s analytics.js or gtag.js, you’ve found the problem.

For checkout flows, test with network throttling enabled (Chrome DevTools lets you simulate slow 3G). If your conversion event only fires on fast connections, it’s a timing race you’ll lose on mobile networks.

If you’re using Postmark or another transactional email service to send purchase confirmations, compare the timestamp of the email sent against the timestamp of the conversion event in your analytics dashboard. If the email consistently arrives before the event logs, your tracking is firing too late—or not at all.

Want more operator-to-operator breakdowns of what actually works? Subscribe to One Two Three Send—one article daily, no fluff, no affiliate spam unless the tool genuinely fits the topic.

You tag every link with UTM parameters. You check Google Analytics. Half your traffic shows up as “direct” even though you know it came from email or social.

The problem isn’t your tagging discipline—it’s that platforms strip UTM parameters before the user ever reaches your site. Email clients do it for privacy. Social apps do it to hide referral data. Link shorteners do it by accident when they redirect through multiple hops.

If you’re running a content business and relying on UTM tags to measure what’s working, you need to know what actually survives the trip from send to click.

What strips UTM parameters and when

Email clients are the worst offenders. Apple Mail Privacy Protection, Gmail’s link scanner, and Outlook’s Safe Links feature all rewrite URLs before a human clicks them. Sometimes the UTM parameters survive the rewrite. Sometimes they don’t.

Apple Mail strips them inconsistently—if the recipient opens the email on iOS with tracking protection enabled, parameters often vanish. Gmail’s link scanner preserves them most of the time, but if the email gets forwarded or opened in a third-party client, all bets are off.

Social platforms strip them deliberately. LinkedIn removes UTM tags from outbound links in posts (not ads) to prevent attribution leakage to competitors. Twitter used to preserve them but now strips utm_source and utm_medium on mobile app clicks. Facebook Messenger rewrites URLs entirely and drops everything after the ? unless you’re using a Facebook pixel.

Link shorteners compound the issue. Bit.ly and TinyURL preserve parameters if you paste the full tagged URL into their interface. But if you use their browser extensions or API without explicitly appending the parameters after shortening, the UTM tags get truncated. Redirect chains—where one short link points to another short link—drop parameters at each hop.

What this looks like in your analytics

You send a newsletter with utm_source=newsletter&utm_medium=email&utm_campaign=july tagged on every link. You check Google Analytics 4 the next day. Traffic shows up, but 40% is labeled “direct / none” instead of “newsletter / email.”

The same thing happens with social posts. You share a link on LinkedIn with full UTM tagging. Analytics shows a spike in traffic, but the source reads “direct” or gets misattributed to Google if someone Googled your brand name after seeing the post.

This isn’t a tracking bug. It’s parameter stripping in action. The user clicked your link, but the UTM tags didn’t survive the platform’s URL rewrite, privacy scanner, or redirect logic.

How to track attribution when UTM tags fail

First option: use campaign-specific landing pages instead of UTM parameters. If you’re promoting a guide, create /guide-linkedin and /guide-newsletter as unique URLs that 301 redirect to the real page. You lose some SEO link equity with redirects, but you gain reliable source tracking even when parameters get stripped.

Second option: append a custom parameter that platforms ignore. Instead of utm_source, use ref=newsletter or via=linkedin. These aren’t standard tracking parameters, so email clients and social platforms don’t recognize them as privacy risks and leave them alone. You’ll need to configure your analytics tool to read these custom parameters as traffic sources—Google Analytics 4 lets you do this with custom dimensions, and most self-hosted tools like Plausible or Fathom support query parameter tracking out of the box.

Third option: track at the application layer instead of the URL. If someone clicks through from your newsletter and immediately signs up or downloads something, log the referrer in your database at the moment of conversion. This doesn’t help with anonymous traffic, but it gives you attribution for actions that matter—subscribers, buyers, trial signups.

Fourth option: accept that some traffic will always be misattributed and focus on channel-level trends instead of click-level precision. If you send a newsletter on Tuesday and see a 300% traffic spike on Tuesday afternoon, you don’t need perfect UTM tracking to know the newsletter worked. Same with social posts—watch for correlated traffic increases within an hour of posting.

When UTM parameters still work

Paid ads preserve UTM tags more reliably than organic links. Facebook Ads, Google Ads, and LinkedIn Ads all pass UTM parameters through their tracking pixels without stripping them, because the platforms want attribution data for their own dashboards.

Direct website embeds work, too. If you link from your own blog post to another page on your site, UTM tags survive because there’s no intermediary platform rewriting the URL.

SMS links preserve parameters as long as you’re not using a link shortener. Twilio, SimpleTexting, and most SMS platforms send the raw URL without modification.

The key is knowing which channels strip parameters and planning around them instead of assuming your tagging strategy works everywhere.

Have a question about tracking, attribution, or analytics for your online business? Reply to this email—we answer reader questions every Sunday.

Open question: how many browser tabs do you have pinned right now for analytics tools?

Google Analytics 4. Plausible or Fathom. Your newsletter platform’s dashboard. Stripe for revenue. Maybe a social media scheduler with engagement stats. Maybe a WordPress stats plugin.

You’re swimming in data, but you still can’t answer basic questions without cross-referencing three platforms and doing the math in a spreadsheet.

The problem isn’t that your analytics tools are bad. It’s that you’re using too many of them.

The dashboard creep problem

Every tool you add promises one thing it tracks better than the rest. Fathom gives you clean pageview data. GA4 tracks events and funnels. Your newsletter platform counts opens and clicks. Stripe tells you MRR.

None of them talk to each other.

So you end up with this: a reader clicks a link in your newsletter, lands on a blog post, scrolls to a paywall, and converts to a paid subscriber. That’s one journey. But you’re tracking it in four places:

• Newsletter click-through in MailerLite or Beehiiv
• Pageview and scroll depth in GA4 or Plausible
• Conversion event in Stripe
• Subscriber count in your membership plugin or Substack dashboard

Want to know your true conversion rate from email to paid? You’re exporting CSVs and building pivot tables.

Most solo operators don’t have time for that. So they stop looking. They check revenue once a week, glance at traffic when it spikes, and ignore everything else.

Consolidation is a feature, not a compromise

The knee-jerk response is to buy a better integration tool. Zapier, Make, or a dedicated analytics warehouse like Segment.

That works if you’re running a team with a data analyst. For a solo operator, it’s just another dashboard to maintain.

Here’s the alternative: pick one source of truth per question you actually need to answer, and delete the rest.

If you run a paid newsletter, your newsletter platform’s dashboard is your primary metric. Revenue, open rates, churn—it’s all there. You don’t need GA4 tracking the same pageviews unless you’re also running a separate blog with ad revenue.

If you run a content site with affiliate income, your traffic analytics tool (GA4, Plausible, Fathom) is the anchor. Stripe is secondary—you check it when payouts arrive, not daily.

If you sell a course or productised service, Stripe or your payment processor is the single source of truth. Traffic is context, not the core metric.

One dashboard per business model. Everything else is noise.

What to delete right now

Start with anything that duplicates a metric you already track elsewhere.

If your newsletter platform shows subscriber count and growth rate, you don’t need a separate spreadsheet updating those numbers weekly. If Stripe shows MRR and churn, you don’t need a SaaS metrics dashboard calculating the same figures with a two-day delay.

Delete any tool you haven’t logged into in the last 30 days. If you’re not checking it, you’re not using the data. And if you’re not using the data, the tool is just spending CPU cycles and cluttering your mental model.

Delete any analytics layer that requires manual export to be useful. If you have to download a CSV, open Excel, and join two tables to answer a question, that tool isn’t serving you—it’s creating work.

The one dashboard you actually need

Here’s what works for most solo operators:

One real-time traffic dashboard (Plausible, Fathom, or GA4 if you’re already fluent in it). One revenue dashboard (Stripe, or your newsletter platform if you’re subscription-first). One weekly export of the metric that matters most to your business model—usually traffic sources, conversion rate, or churn.

That’s it. Three views, not six. You can check all three in under five minutes, and you’ll have enough context to make decisions without second-guessing the data.

If you can’t make a decision with the data a tool provides, the tool isn’t solving a problem—it’s becoming one.

Want more operator-to-operator breakdowns like this? Subscribe to One Two Three Send and get one article like this in your inbox every week—no fluff, no filler, just the infrastructure decisions that matter.

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.

Google Analytics 4 lets you attach up to 25 custom parameters to each event. That sounds generous until you realize that half of them might never show up in your reports—and the platform won’t tell you which ones got dropped until you go looking.

If you’re running a content business and relying on GA4 to track subscriber behavior, link clicks, or content engagement, this matters more than you think. Parameters that don’t fire mean attribution you can’t trace and conversion paths you can’t rebuild.

Why parameters get dropped

GA4 has three silent filters that strip parameters before they hit your data stream:

Character limits. Parameter names max out at 40 characters. Values cap at 100 characters. Cross either threshold and the entire parameter vanishes. No error message, no warning in the real-time view—it just doesn’t arrive.

Reserved parameter names. GA4 reserves roughly 50 parameter names for its own use. If you accidentally name a custom parameter something like page_location, session_id, or user_id, your value gets overwritten by GA4’s automatic collection. The list isn’t published in one place; you have to cross-reference the automatically collected events documentation to catch conflicts.

Data type mismatches. GA4 infers parameter types from the first value it sees. If your first event sends article_id as a string and the second sends it as an integer, one of them won’t register as a custom dimension. The platform doesn’t reconcile types retroactively, so you’re left with partial data and no alert.

How to audit what’s actually firing

Most operators check the real-time report and assume everything’s working. That view only shows the last 30 minutes and doesn’t surface parameter-level failures.

The better approach: open the DebugView panel in GA4. It requires enabling debug mode in your Google Tag Manager container or adding ?debug_mode=true to your site URL if you’re using gtag.js directly. DebugView shows every event and parameter as it arrives, including which ones GA4 accepted and which ones it ignored.

Run a test session where you trigger each custom event you care about—newsletter signups, affiliate link clicks, content unlocks, purchase completions. Watch the parameter list for each event. If a parameter you sent isn’t listed, it got dropped.

Once you know which parameters aren’t firing, check their names against the reserved list, confirm their character counts, and verify that your tag configuration isn’t sending mixed data types.

When to use event-scoped vs. user-scoped parameters

GA4 parameters come in two flavors: event-scoped and user-scoped. Event-scoped parameters attach to individual actions—link_url, video_title, form_id. User-scoped parameters attach to the visitor across sessions—subscription_tier, signup_source, customer_ltv.

The distinction matters because GA4 limits you to 50 custom event-scoped dimensions and 25 custom user-scoped dimensions per property. If you’re tracking a membership site or a newsletter with multiple tiers, user-scoped parameters let you segment reports without burning through event slots.

But user-scoped parameters don’t populate immediately. GA4 only attaches them after the first event in a session fires. If you need to filter reports by subscription_tier and a visitor’s first event is a page view, the tier parameter won’t be available until the second event. That creates reporting gaps if you’re trying to attribute conversions by tier.

The workaround: send a silent user_properties_set event on page load with all your user-scoped parameters, then fire your standard events afterward. It’s an extra event in your tag setup, but it ensures parameters are available from the first interaction.

One non-obvious fix

If you’re sending parameters through Google Tag Manager and they’re still not showing up in GA4, check your tag’s Fields to Set configuration. GA4 tags in GTM have two places to define parameters: the “Event Parameters” section and the “Fields to Set” section. Event parameters go to GA4. Fields to Set go to the Google tag itself and don’t always pass through to GA4 reports.

Most operators fill out Fields to Set by mistake and wonder why their custom dimensions stay empty. Move everything to Event Parameters unless you’re explicitly configuring a Google Ads conversion tag.

If you’re running attribution reporting across multiple tools—GA4, your newsletter platform, and a course LMS—make sure your parameter names stay consistent. GA4 doesn’t auto-map source to utm_source or email to user_email. Pick a naming convention and enforce it across every tag, webhook, and API call.

Want more breakdowns like this? Reply with the analytics setup you’re trying to debug—I’ll cover it in a future issue.

Attribution windows define how long a platform remembers where a visitor came from before they convert. Google Analytics defaults to 90 days for most models. Facebook Ads dropped to 7-day click, 1-day view in 2021 and hasn’t budged. Most affiliate networks sit at 30 days. And if you’re running a content business with a considered purchase—a course, a yearly subscription, a high-ticket consulting package—there’s a good chance your actual sales cycle is longer than every attribution window you’re using.

When that happens, you stop seeing where revenue actually comes from. You start making decisions on incomplete data. And you end up over-investing in channels that look good on a short clock while starving the ones that drive long-term growth.

What attribution windows actually control

An attribution window is the trailing period during which a platform will connect a conversion back to a traffic source. If someone clicks your Facebook ad, thinks about it for eight days, then subscribes, Facebook won’t count that conversion—because its click attribution window is seven days. The sale still happened. You just can’t see what caused it.

This matters less for impulse purchases. If you’re selling a $19 ebook and most people buy within an hour of landing on the page, a 7-day window is fine. But if you’re selling a $500 course, and your average buyer reads four articles, downloads a lead magnet, gets three emails, and converts 18 days later, that 7-day window is functionally useless.

The result: you see “direct” or “none” as your top conversion source, because the original referral aged out. You assume organic works. You double down on SEO. Maybe it does work—but you’re guessing, because the system threw away the breadcrumb trail halfway through.

How to audit your funnel against your windows

Pull your actual time-to-conversion data. In Google Analytics 4, go to Reports > Engagement > Conversions, then add a secondary dimension for “Days to conversion.” Export it. Calculate the median and 75th percentile. That’s your real sales cycle.

Now compare it to every attribution window you rely on:

• Google Analytics 4: 90 days for data-driven attribution by default, but many operators still use last-click models with shorter windows
• Facebook/Instagram Ads: 7-day click, 1-day view
• LinkedIn Ads: 90-day click by default, but viewthrough is much shorter
• Affiliate platforms: typically 30–90 days depending on the network
• Email platforms: effectively infinite if you’re tracking via UTM, but many operators rely on platform-native conversion tracking that resets on re-engagement

If your 75th percentile time-to-conversion is longer than your shortest attribution window, you’re losing signal. And because short-window platforms tend to be the ones with the biggest budgets (paid social), you’re probably misallocating spend.

Fixing it without ripping out your stack

You can’t change Facebook’s attribution window. But you can layer your own. The simplest fix: use a dedicated attribution tool that tracks first touch, last touch, and everything in between with a custom window. Tools like Hyros, Attributer, and Wicked Reports let you set windows as long as you want and tie them to actual revenue, not just platform-reported conversions.

If you’re not ready to pay for another SaaS layer, extend your own tracking. Use UTM parameters religiously, store them in a cookie or your CRM with a long expiration, and tie conversions back manually in a spreadsheet or your database. It’s not elegant, but it works. Set your cookie to expire at 180 days if your real sales cycle is 60–90. Give yourself margin.

Another option: shift budget toward channels with longer native windows. Google Search and SEO have effectively infinite attribution if someone converts in-session. Email works the same way. Organic social is harder to track, but if you’re using link shorteners with your own UTMs and a long cookie, you control the window.

The worst move is to keep running paid social, see “direct” conversions climb, assume brand is working, and never connect the dots. That’s not brand lift. That’s attribution collapse.

When to care and when to ignore it

If your median time-to-conversion is under 7 days and you’re running straightforward offers, this doesn’t matter. Optimize in-platform, trust the numbers, move on.

But if you’re selling anything that requires consideration—courses, memberships, coaching, SaaS annual plans—or if you’re seeing a growing share of “direct” traffic that converts better than named sources, your attribution windows are probably lying to you. Fix the measurement before you fix the marketing.

Want more breakdowns like this? Subscribe to One Two Three Send and get one operator-focused deep-dive in your inbox every week.

If you’re running an online business solo or with a small team, there’s a good chance you’re paying for at least two analytics tools. Maybe Google Analytics for traffic, a heatmap service for behavior, and whatever your newsletter platform includes. You check them weekly, feel vaguely informed, and move on.

Here’s the problem: most of those metrics don’t connect to money. Pageviews don’t pay invoices. Session duration doesn’t predict churn. Bounce rate tells you almost nothing about whether someone will subscribe, buy, or share.

After working with dozens of operators who’ve scaled past $10k/month, the pattern is clear: the ones who move fastest track three metrics obsessively and ignore almost everything else.

The three metrics that actually matter

Metric one: new email subscribers per week. Not total list size—new additions. This number tells you whether your acquisition engine still works. If it drops two weeks in a row, you have a traffic problem, a conversion problem, or both. Track it in a spreadsheet, not buried in a dashboard. Write it down every Monday.

Metric two: revenue per subscriber per month. Take last month’s revenue and divide by average list size. For a course creator with 2,000 subscribers who made $4,000 last month, that’s $2 per subscriber. For a sponsored newsletter with 8,000 readers earning $3,200, it’s $0.40. This number tells you whether you’re monetizing or just growing a list. If it’s under $0.50 and you’re trying to make this a business, you need to sell something.

Metric three: unsubscribe rate per send. Not the pretty monthly average your ESP shows you—the raw number every time you hit send. ConvertKit, Beehiiv, and MailerLite all surface this in the broadcast report. If your rate jumps above 0.5% on a single send, you either wrote something polarizing (sometimes worth it) or your content drifted off-topic (never worth it). Track it per email, not per month, because monthly averages hide the problem sends.

What to stop tracking

Pageviews, unless you sell ads that pay CPM. Time on page, unless you’re debugging a specific UX problem. Heatmaps, unless you’re actively A/B testing a landing page this week. Social media follower count, unless a brand is paying you per impression and auditing your reach.

These aren’t bad metrics. They’re just not decision metrics. They don’t tell you what to do next. And if a number doesn’t change your behavior, it’s decorative.

The tool stack that actually works

You don’t need a $500/month analytics suite to track three numbers. Here’s what works:

• A spreadsheet. Google Sheets, Excel, Notion database—doesn’t matter. One row per week. Three columns. Update it Monday morning.
• Your email platform’s native dashboard for subscriber and unsub data. You’re already paying for it.
• A single revenue tracker. Stripe’s dashboard if you sell digital products. A bookkeeping tool like Wave (free) if you mix income sources. One source of truth for the revenue number.

If you’re currently paying for Heap, Mixpanel, Hotjar, or a similar tool and you’re under $5k/month in revenue, cancel it. Put the $50–$200/month toward a better welcome sequence or a freelance editor. Those will move the three metrics. Another dashboard won’t.

When to add a fourth metric

Once you’re past $10k/month and you have a repeatable acquisition channel, you can afford to track one lever inside that channel. If SEO drives 60% of your traffic, track keyword rankings for your top ten posts. If Twitter drives your growth, track link clicks per post (not likes—clicks). If you run a paid funnel, track cost per subscriber.

But don’t add a fourth metric until the first three are in a spreadsheet you update every week without thinking about it.

Why operators resist this

Cutting your analytics stack feels like flying blind. You’ll worry you’re missing something. You’re not. You’re missing noise.

The operators who grow fastest are the ones who know their three numbers cold, can recite them in a conversation, and make every strategic decision by asking: “Will this move one of the three?”

If the answer is no, they don’t do it. If the answer is yes, they do it this week.

Want more operator tactics like this? Subscribe to One Two Three Send for weekly breakdowns of what actually works when you’re building an online business without a team.

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.