One Two Three Send

Author: onetwothreeadmin

  • ConvertKit visual automation editor: when to use it vs. raw rules

    ConvertKit offers two ways to build automations: the visual automation builder, which looks like a flowchart, and the rule-based editor, which reads like a spreadsheet of conditions. They produce identical results—subscribers get tagged, moved between sequences, or removed from lists based on triggers you define—but they’re built for different kinds of thinking.

    Most operators default to whichever interface they first learned. That costs time. Each editor has situations where it’s faster, clearer, and less error-prone than the other.

    Visual builder: when branches multiply

    The visual automation builder excels when you need to see multiple paths diverging from a single trigger. If a subscriber opens an email, clicks a specific link, and has a tag, send them down path A. If they open but don’t click, path B. If they ignore it entirely, path C after 72 hours.

    This is hard to parse in a list of rules. The visual editor makes it obvious: you see the fork, the wait periods, and where paths rejoin or terminate. When you’re debugging, you can trace a subscriber’s journey by eye instead of reading line-by-line conditional logic.

    The visual builder also handles time-based delays more intuitively. You drag a “Wait” block between actions and set the interval. In the rule editor, you’re specifying when conditions are checked, which requires you to think about the automation’s internal clock rather than the subscriber’s experience.

    Where it breaks down: complex tag logic. If you’re checking for the presence or absence of five tags before taking action, the visual builder forces you to nest condition blocks in ways that become unreadable fast. You end up with a spiderweb.

    Rule editor: when conditions stack

    The rule-based editor is a vertical list of “if this, then that” statements. It’s less visual, but it’s faster to write and easier to audit when you’re working with multiple overlapping conditions.

    Example: you want to tag subscribers who’ve been on your list for more than 30 days, opened at least three emails in the last two weeks, clicked a link in your last broadcast, and don’t already have a “high-engagement” tag. In the visual builder, that’s four nested condition blocks. In the rule editor, it’s four lines with AND logic. You can scan it in three seconds.

    The rule editor also makes bulk edits faster. If you need to change a tag name across ten automations, you can copy the rule set into a text editor, find-and-replace, and paste it back. The visual builder requires clicking into each block individually.

    Non-obvious tip: use the rule editor to prototype, then rebuild in the visual editor if you need to present it to a client or team member. Rules are faster to write; visuals are faster to explain.

    What both editors hide

    Neither interface shows you automation timing conflicts. If two automations try to add conflicting tags to the same subscriber at the same moment, ConvertKit processes them in the order they were created—not the order you’d expect from looking at the flowchart or rule list.

    You won’t know this happened unless you manually check the subscriber’s activity log. There’s no error message, no warning in the editor. The automation runs; one tag wins. If you’re using tags to trigger downstream actions (like segment splits or sequence enrollment), this silent conflict can route subscribers incorrectly.

    The workaround: add a one-minute delay between automations that might overlap. It’s invisible to the subscriber, but it forces ConvertKit to process actions sequentially.

    Which to use today

    If you’re building a welcome sequence with multiple paths based on engagement, start in the visual builder. If you’re setting up a tagging system based on purchase history or content preferences, use the rule editor. If you’re not sure, default to rules—they’re faster to write and easier to fix when you realize you misconfigured something.

    And if you’re managing automations for clients or a team, keep a text file with a plain-English description of what each automation does. Neither editor exports documentation, and six months from now, you won’t remember why you added that three-day wait or what “engaged-2026-Q3” was supposed to mean.

    Got a question about how your email platform handles something specific? Reply and tell us—we’ll dig into it and write it up if it’s something other operators are hitting too.

  • Social media analytics export limits: what you lose at the CSV wall

    Social media analytics export limits: what you lose at the CSV wall

    Social media analytics export limits: what you lose at the CSV wall
    Photo: Saleemkce via Wikimedia Commons (CC BY-SA 4.0)

    Most social media platforms let you export analytics as CSV or Excel files. What they don’t tell you is that the export has hard limits—and those limits usually cut off exactly the data you need.

    If you’re running content experiments, tracking attribution over time, or building reports for sponsors, you’ve probably hit the wall where the download button gives you a fraction of what the dashboard shows. Here’s what’s actually happening behind the export, and how to get the data you need.

    The common export caps by platform

    LinkedIn Page analytics exports cap at 365 days of data, but only return the first 500 posts by chronological order. If you published daily, that’s roughly 16 months of history—except you only get the oldest 500, not the best-performing or most recent.

    Instagram Insights exports through Meta Business Suite limit you to 90 days and 1,000 rows. If you’re running multiple posts per day or analyzing Stories separately, you’ll hit the row limit before the date range expires. The export also excludes Reels data entirely in some account configurations—it shows in the dashboard, but doesn’t appear in the file.

    Twitter’s (now X) analytics dashboard lets you filter by date range, but the CSV download ignores your filter and gives you the last 90 days regardless. Video view breakdowns, link clicks by referrer, and reply-thread depth don’t export at all.

    TikTok Creator Analytics exports limit you to 7 or 28 days depending on your follower count. If you’re under 10k followers, you get 7 days maximum. No cumulative exports. No historical comparison. If you didn’t download it last week, it’s gone.

    What gets excluded even when you’re under the cap

    Beyond row and date limits, platforms exclude specific metrics from exports even when they appear in the web interface.

    Engagement rate calculations don’t export as a column—you get likes, comments, and shares, but not the derived percentage. If the platform changed its denominator (some use followers, others use reach), your historical spreadsheet won’t match the dashboard retroactively.

    Follower demographic breakdowns—age, location, gender—rarely make it into post-level exports. You can see them in aggregate in the dashboard, but if you want to know which posts performed best with a specific segment, you’re stuck screenshotting.

    Referral sources and UTM parameters are stripped in most exports. You can see that a post drove 1,200 clicks, but not where those clicks came from or which UTM campaign they matched. That data lives in a separate, often inaccessible table.

    Workarounds that actually work

    The most reliable fix is to pull data via API instead of relying on dashboard exports. Most platforms offer a free-tier API that returns more rows and longer date ranges than the CSV button.

    For LinkedIn, the Marketing Developer Platform API gives you up to 2 years of organic post analytics with no row cap. You’ll need to register an app and handle OAuth, but once you’re set up, you can pull JSON and transform it however you need.

    Instagram’s Graph API returns post-level insights going back one year for Business and Creator accounts. You can query by media ID and get metrics that never appear in exports—like saves, profile visits from post, and follows attributed to individual posts.

    If API setup feels heavy, use a third-party dashboard tool that auto-syncs daily. Publer, for example, archives your post data as you publish and lets you export the full history without platform caps. The tradeoff is you only get data from the day you connected the tool forward—no backfill.

    For historical data you’ve already lost, check if your platform offers a formal data archive request under GDPR or CCPA. Meta and LinkedIn both provide full account archives that include metrics not available in standard exports. The file takes 48 hours to generate and arrives as a multi-gigabyte ZIP, but it’s complete.

    When to stop exporting and start logging

    If you’re hitting export caps monthly, it’s time to set up automated logging instead of manual downloads. A simple workflow: once a week, pull your top 50 posts by engagement via API (or manually note the URLs and metrics), then append them to a Google Sheet with a timestamp.

    This gives you a running log that’s immune to platform export limits, retroactive metric changes, and post deletions. When a sponsor asks for Q3 performance data in December, you’ll have it.

    Export limits aren’t going away—if anything, platforms are tightening data access as they push users toward paid analytics tiers. The operators who win are the ones who treat social metrics like any other business data: log it, own it, and don’t trust the platform to remember for you.

    Have a question about data exports, analytics, or running your online business? Reply to this email—we read every one, and your question might become next week’s deep-dive.

    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.

  • WordPress cache plugins flush differently—and it costs you traffic

    WordPress cache plugins flush differently—and it costs you traffic

    WordPress cache plugins flush differently—and it costs you traffic
    Photo by Justin Morgan on Unsplash

    You hit publish on a post, flush your cache, and check the front end. Half the time, the old version is still there. Or worse: the homepage updated but the category archive didn’t. Or the mobile cache cleared but desktop didn’t.

    Most solo operators assume cache plugins work the same way. They don’t. The three most popular WordPress caching solutions—WP Rocket, W3 Total Cache, and LiteSpeed Cache—handle purge logic, CDN sync, and object invalidation completely differently. And if you’re running a content site where every minute of stale cache costs you click-through or ad impressions, those differences matter.

    Here’s what actually happens when you click “clear cache,” broken down by plugin.

    WP Rocket: instant page cache, delayed object cache

    WP Rocket clears page cache immediately when you publish or update a post. That means the single post URL, homepage, and any archive that post appears on get purged within seconds.

    But if you’re using Redis or Memcached for object caching, WP Rocket doesn’t touch it. Object cache stores database query results, widget output, and navigation menus. If you update a menu item or change a widget, the page cache clears but the object cache doesn’t—so your navigation still shows the old link until the object cache TTL expires (usually 12–24 hours by default).

    The workaround: manually flush object cache from your hosting dashboard or install a separate plugin like Redis Object Cache and set a shorter TTL (3–6 hours). WP Rocket won’t do it for you.

    WP Rocket also integrates with Cloudflare’s API to purge CDN cache automatically. It works, but there’s a 30–90 second delay between WordPress purge and Cloudflare purge. If you’re checking your site immediately after publish, you’ll see stale content. Wait two minutes, or purge Cloudflare manually from their dashboard.

    W3 Total Cache: granular control, manual overhead

    W3 Total Cache gives you separate toggles for page cache, object cache, database cache, browser cache, and CDN. That’s powerful, but it also means nothing clears unless you’ve configured it to.

    By default, publishing a post clears that post’s page cache and the homepage. It does not clear category archives, tag archives, or related post widgets unless you enable “purge all caches on post publish” in settings. That setting works, but it’s overkill—it nukes the entire page cache, including evergreen pages that didn’t change.

    Better approach: enable selective purge for post archives, categories, and tags. You’ll find this under Performance > Page Cache > Purge Policy. Check the boxes for “front page,” “post page,” “categories,” and “tags.” Skip “all pages” unless you’re running a small site (under 100 pages).

    For object cache, W3 Total Cache will clear Redis or Memcached—but only if you enable “flush object cache on post publish” in the same purge policy menu. It’s off by default.

    CDN purge is manual unless you’re using a supported CDN like Cloudflare, StackPath, or BunnyCDN. You’ll need to enter API credentials under Performance > CDN and enable automatic purge. Even then, expect 60–120 second lag.

    LiteSpeed Cache: instant everywhere, but only on LiteSpeed servers

    LiteSpeed Cache is the fastest of the three—if you’re on LiteSpeed web server hosting (like BigScoots, Hostinger, or A2 Hosting). It uses server-level cache instead of PHP-based cache, so purges happen in under five seconds.

    When you publish a post, LiteSpeed Cache clears the post itself, homepage, relevant archives, and any widget areas that reference the post. It also purges object cache (if enabled) and triggers CDN purge via API (Cloudflare and Quic.cloud supported).

    The catch: it only works on LiteSpeed servers. If you’re on NGINX or Apache, the plugin installs but doesn’t cache anything. You’ll see “LiteSpeed Cache is not running” in the dashboard. In that case, switch to WP Rocket or W3 Total Cache.

    One non-obvious LiteSpeed quirk: mobile cache is separate from desktop cache. If you enable mobile-specific caching (recommended for ad-heavy sites), you need to manually flush mobile cache from the LiteSpeed dashboard. It won’t auto-purge on post publish unless you enable “purge all on publish,” which—again—is overkill.

    What to do if cache won’t clear

    If you’ve flushed cache and the old version persists, check these in order:

    • Browser cache. Hard refresh (Cmd+Shift+R on Mac, Ctrl+Shift+R on Windows). Your browser caches pages locally even if server cache is clear.
    • CDN cache. Log into Cloudflare, BunnyCDN, or your CDN dashboard and purge manually. Most cache plugins don’t purge CDN by default.
    • Object cache TTL. If Redis or Memcached is enabled, check your TTL setting. Anything over 12 hours is risky for frequently updated sites.
    • Hosting-level cache. Some hosts (WP Engine, Kinsta, Flywheel) run their own server cache layer that sits above your plugin. You need to purge it from their dashboard or WP Admin bar.

    Which plugin to use

    If you’re on LiteSpeed hosting: use LiteSpeed Cache. Nothing else is faster.

    If you’re on shared hosting or VPS with Apache/NGINX and want zero config: use WP Rocket. It’s $59/year, but it works out of the box.

    If you want granular control and don’t mind spending 20 minutes in settings: use W3 Total Cache. It’s free, and once configured, it’s rock-solid.

    Whatever you pick, test it. Publish a draft post, flush cache, and check the homepage, category page, and post URL on desktop and mobile. If any of them show stale content after two minutes, your purge logic isn’t working.

    Got a caching quirk that’s costing you traffic? Reply to this email—I’ll dig into it for a future piece.

  • Newsletter referral programs: tracking who sent whom and when credit hits

    Newsletter referral programs: tracking who sent whom and when credit hits

    Newsletter referral programs: tracking who sent whom and when credit hits
    Photo by sue hughes on Unsplash

    Most newsletter platforms now offer built-in referral programs: a subscriber shares a unique link, someone signs up through it, and the original subscriber earns credit toward a reward tier. Simple in theory. Messy in practice.

    Referral systems sit at the intersection of email deliverability, user attribution, and reward fulfillment—and each piece introduces lag, edge cases, and silent failures that can frustrate both you and your readers.

    How referral attribution actually works

    When a subscriber shares their referral link, the platform appends a unique identifier to your signup page URL—usually a query parameter like ?ref=abc123 or a subdomain like abc123.yoursite.com. When someone clicks through and subscribes, the platform writes that relationship to a database table linking the new subscriber ID to the referrer’s ID.

    The credit doesn’t always post immediately. Most platforms batch-process referral credit overnight or on a fixed interval—anywhere from 15 minutes to 24 hours. Beehiiv and MailerLite both delay credit assignment until the new subscriber confirms their email address and survives an initial engagement window, typically 48 to 72 hours. If the new subscriber never opens an email or unsubscribes within that window, the referral credit may never materialize.

    This delay exists to prevent abuse—bot signups, disposable emails, and bulk fake referrals—but it also means your top referrers won’t see their reward progress update in real time. If you promise instant gratification in your referral landing page copy, you’re setting yourself up for support emails.

    Forwarded emails break the chain

    Here’s the silent failure mode nobody warns you about: when a subscriber forwards your email to a friend instead of using the referral link, the new signup loses all attribution. Email clients strip or mangle query parameters when forwarding, and even if the link survives intact, the recipient often lands on your generic signup page without the referral token.

    Some platforms try to salvage this with browser fingerprinting or cookie-based fallback attribution, but those methods fail when the recipient opens the forwarded email on mobile and then subscribes later on desktop. You end up with organic signups that should have been credited referrals, and no clean way to retroactively assign them.

    The workaround: make your referral link the only subscribe path in emails sent to existing subscribers. Remove generic “Subscribe” CTAs from your standard email template and replace them with dynamic referral links. Every platform that supports referral programs offers a merge tag for this—MailerLite uses {$refer_link}, Beehiiv uses {{rlink}}.

    Reward tiers and cap logic

    Most platforms let you define reward tiers—5 referrals earns a free ebook, 25 earns a paid course, 100 earns a one-on-one call—but the backend logic for tier fulfillment varies wildly.

    Some platforms auto-deliver digital rewards via email trigger when a subscriber crosses a threshold. Others flag the subscriber and wait for you to manually fulfill. A few—MailerLite included—require you to export a CSV of referrers above a certain count and handle fulfillment entirely outside the platform.

    Watch for referral caps. Beehiiv lets you set a maximum number of credited referrals per subscriber per month, which prevents a single power-referrer from monopolizing your reward budget. But if you don’t communicate that cap clearly, you’ll face angry emails from someone who sent 50 friends your way and only got credit for 25.

    Check whether your platform counts confirmed subscribers or just signups. ConvertKit’s referral system credits any email address submitted through a referral link, even if it never confirms. That inflates your referral leaderboard with dead emails and costs you rewards you’ll never see ROI on.

    What to check before you launch

    Run a test loop with at least three dummy subscribers before you announce your referral program publicly. Use different devices, browsers, and email clients. Forward the email. Click the link 48 hours later. Unsubscribe one of the dummy signups immediately and see if the credit reverses.

    Document the actual credit delay in your referral landing page FAQ. “Credit typically appears within 48 hours after your friend confirms their subscription” is honest and sets correct expectations.

    Set up a monthly export of your referral leaderboard and cross-check it against your subscriber growth CSV. If you see signups with no attribution but identical signup timestamps and IP geolocation clusters, you’ve got forwarding attribution loss—and you’ll need to decide whether to manually credit those or let them slide.

    Referral programs work, but they’re not fire-and-forget. The mechanics behind them are quieter and slower than the landing page promises, and the edge cases multiply as soon as real humans start sharing links in ways you didn’t script for.

    Want more breakdowns of how newsletter tools actually work under the hood? Subscribe to One Two Three Send—we explain one feature, process, or hidden cost every week.

    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 Search Console data delay: what updates daily vs. weekly

    Google Search Console shows you what keywords are working, which pages rank, and how often people click through from search results. But the data doesn’t all update at the same pace—and if you’re making decisions based on yesterday’s numbers, you’re probably looking at incomplete information.

    Understanding the refresh cadence matters when you’re tracking a new post’s indexing speed, debugging a traffic drop, or measuring the impact of a title change. Here’s what updates when, and how to work around the lag.

    Performance reports: the 2–3 day rule

    The Performance tab—where you see queries, pages, countries, and devices—runs on a 2–3 day delay. If you published a post on Monday and check Search Console Tuesday morning, you won’t see Monday’s impressions yet. They’ll appear Wednesday or Thursday.

    This isn’t a bug. Google aggregates billions of search events, and the processing pipeline takes time. The delay is consistent across all views: queries, pages, countries, devices, search appearance filters. If you’re comparing date ranges, make sure you’re ending at least three days before today, or you’ll be working with partial data that shifts as the backfill completes.

    One exception: if you filter by a specific page URL and see zero impressions for recent dates, that might mean the page isn’t indexed yet—or it might just mean the data hasn’t landed. Wait 72 hours before you panic.

    URL Inspection: near real-time for index status

    The URL Inspection tool tells you whether a specific page is indexed, when Google last crawled it, and whether any issues blocked indexing. This updates much faster than Performance data—usually within a few hours of a crawl.

    If you request indexing for a new post, you’ll typically see the crawl timestamp update within 10–30 minutes. But indexed status can still take a day or two, especially if your site has crawl budget constraints or the URL is deep in your architecture.

    One gotcha: the “Live Test” option in URL Inspection fetches the page in real time, but it doesn’t guarantee that version will be the one Google indexes. If you’re debugging a caching issue or testing a robots meta tag change, the live test shows what Googlebot can see right now—not what it has indexed.

    Sitemaps and coverage reports: weekly batch updates

    The Coverage report—showing indexed, excluded, and error URLs—updates in batches, often once a week. If you submit a new sitemap or fix a batch of 404s, you won’t see the Coverage chart shift for several days.

    Sitemap processing is similarly slow. After you submit or update a sitemap, the “Last read” timestamp might update within hours, but the “Discovered URLs” count can lag by a week. If you’re waiting to confirm that Google found your new posts via the sitemap, check URL Inspection instead—it’s faster and more definitive.

    The Coverage report also aggregates by issue type, which means individual URL changes don’t always surface immediately. If you fix a canonical tag on one page, that page might move from “Excluded” to “Indexed” in the next batch cycle, but the chart won’t reflect it until Google recrawls enough of your site to recompute the bucket sizes.

    How to work with the lag

    Set a standing rule: when you’re checking Search Console for decision-making, end your date range three days ago. If today is October 21, filter Performance data through October 18. This avoids the partial-data problem where you think traffic dropped 40% yesterday, but really the last day just hasn’t backfilled yet.

    For new posts, use URL Inspection to confirm indexing, then wait four days before you check Performance data for impressions. If a post published Monday still shows zero queries by Friday, then you have a problem—either it’s not ranking for anything, or there’s an indexing issue URL Inspection should reveal.

    If you’re debugging a sudden traffic drop, compare week-over-week data with at least a three-day buffer. A drop that appeared “yesterday” in Performance data is usually from three days ago—meaning the cause happened four or five days ago, once you account for the delay.

    For high-frequency publishing—daily posts or multiple updates per day—consider exporting Performance data weekly and storing it locally. The Search Console UI caps exports at 1,000 rows per query dimension, and the API gives you more headroom, but either way, regular exports let you track trends without fighting the rolling 16-month retention window.

    Want more operator-focused breakdowns of the tools you use every day? Subscribe to One Two Three Send for weekly deep dives on the mechanics behind newsletter platforms, AI tools, hosting, traffic, and monetisation.

  • Zapier storage: where task data lives and when it disappears

    Zapier storage: where task data lives and when it disappears

    Zapier storage: where task data lives and when it disappears
    Photo by Growtika on Unsplash

    Zapier sits at the center of most solo operators’ workflows, shuttling data between apps and triggering actions. But once a Zap runs, where does that data actually live—and for how long?

    The answer matters more than you’d think. If you’re relying on Zapier to store task history, delay queues, or custom data structures, you need to know what persists, what expires, and what vanishes without warning.

    Here’s what actually happens to your data inside Zapier’s infrastructure.

    Task history: 30 days, then gone

    Every time a Zap runs, Zapier logs the task. You can review inputs, outputs, and errors in your task history dashboard. This is essential for debugging—until it isn’t.

    Task history is retained for 30 days on all plans, including paid tiers. After that, it’s deleted permanently. You can’t extend this window. You can’t export a year’s worth of logs. If you need historical task data for compliance, auditing, or long-term analysis, you have to pipe it somewhere else—a Google Sheet, Airtable, or your own database.

    For most operators, 30 days is enough to catch and fix broken Zaps. But if you’re running financial workflows, customer onboarding sequences, or anything that might need a paper trail six months later, plan accordingly.

    Storage by Zapier: persistent but limited

    Storage by Zapier is a built-in key-value store that lets you save and retrieve small pieces of data across Zap runs. It’s useful for counters, flags, or temporary state—like tracking how many times a user has triggered an action, or storing a reference ID to match records later.

    Unlike task history, data in Storage by Zapier persists indefinitely. You create a key, write a value, and it stays there until you overwrite or delete it. No expiration timer.

    But there are hard limits. On the free plan, you get 50 storage slots. Paid plans bump that to 500. Each value is capped at 1 MB, and keys are limited to 256 characters. If you’re storing JSON objects or concatenated strings, you’ll hit those ceilings faster than expected.

    Storage by Zapier is not a database. It’s a scratch pad. If you need relational data, joins, or anything resembling a query, use Airtable, Google Sheets, or an actual database with a Zapier integration.

    Delay queues: scheduled but not guaranteed

    When you use Zapier’s Delay action—either “Delay For” or “Delay Until”—the task enters a queue. The data payload is stored temporarily, waiting for the delay period to expire before the Zap continues.

    This works reliably for delays up to a month. After 31 days, delayed tasks are automatically cancelled and dropped from the queue. You don’t get a warning. The task just never resumes.

    If you’re building drip sequences, follow-up reminders, or time-based workflows, keep delays under 30 days. For anything longer, use a scheduler (like Airtable automations with a date field, or a dedicated tool like Calendly webhooks) that triggers a new Zap when the time comes.

    Webhooks and Catch Hook data: 7-day rolling window

    If you’re using a Webhook by Zapier trigger with “Catch Hook” mode, Zapier temporarily stores incoming webhook payloads so you can configure your Zap without losing test data.

    These payloads are retained for 7 days. After that, they’re purged. Once your Zap is live, this doesn’t matter—webhook data passes through in real time. But if you’re troubleshooting a Zap that hasn’t fired in over a week, you’ll need to send a fresh test payload.

    What to do about it

    If you’re running mission-critical workflows through Zapier, treat it as a router, not a data store. Route task outputs to a system you control—Airtable, Notion, Google Sheets, a Postgres database, or even a simple CSV export triggered weekly.

    For task history, set up a “log all Zap runs” automation that writes task ID, timestamp, and key inputs to a sheet. It costs one extra task per Zap run, but gives you indefinite audit trails.

    For delays longer than a month, offload scheduling to a tool with native calendar logic or a database with a “trigger date” column and a daily check.

    And if you’re using Storage by Zapier for anything permanent—don’t. Migrate it to a real database or spreadsheet before you hit the 500-slot ceiling.

    Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools solo operators actually use.

  • Affiliate link attribution windows: when credit expires

    You send someone to a product through your affiliate link in January. They bookmark the page, think about it, and buy in March. Do you get paid?

    Usually not. Most affiliate programs use a fixed attribution window—a clock that starts ticking the moment someone clicks your link. If the purchase happens after that window closes, the commission disappears. No pro-rating, no partial credit, no notification.

    If you’re running a content site, newsletter, or course with affiliate revenue, you need to know how long your windows are and what happens when they expire. Here’s what actually determines whether you get paid.

    How attribution windows work

    When someone clicks your affiliate link, the merchant (or network) drops a cookie or session identifier in their browser. That token tracks two things: which affiliate sent the traffic, and when the click happened.

    If the user completes a purchase before the window closes, you get credited. If they return after the window expires—even if they use the same browser—the system treats them as a direct visitor. The sale goes unattributed, or worse, it gets attributed to the last affiliate link they clicked.

    Most SaaS and digital-product programs use one of three standard windows:

    • 30 days: Common for low-ticket or high-volume products. Examples include MailerLite, Brevo, and many WordPress plugin marketplaces.
    • 60 days: Mid-range. Used by tools with longer consideration cycles, like project management or analytics platforms.
    • 90 days: Rare, but not unheard of. Some enterprise SaaS and high-ticket course platforms extend this far.

    A few programs—usually those with recurring subscriptions—use a hybrid model: a 30-day window for the first purchase, then lifetime commission as long as the customer stays subscribed. Beehiiv and some hosting affiliate programs work this way.

    What resets the clock and what doesn’t

    Here’s where it gets messy. Attribution windows don’t always behave the way you’d expect.

    Clicking your link again resets the timer. If someone clicked your link in January, then clicked it again in February, the window starts over from February. This is why retargeting the same audience—through follow-up emails, retargeting ads, or repeated social posts—can extend your effective window.

    Visiting the site directly does not reset it. If they click your link once, then return via bookmark or organic search, the original clock keeps running. The merchant’s system doesn’t know they came back unless they click another tracked link.

    Clearing cookies kills the attribution immediately. Most affiliate tracking relies on browser cookies. If the user switches devices, uses incognito mode, or runs a cookie cleaner, the link between your referral and their session disappears. This is more common than most affiliates realize—especially among privacy-conscious audiences.

    Why long consideration cycles hurt affiliate revenue

    If you’re promoting a $500/year tool or a $2,000 course, your audience isn’t buying on impulse. They’re comparing options, reading reviews, waiting for budget approval, or just procrastinating.

    The problem: a 30-day attribution window assumes a fast buying cycle. If your content attracts researchers who take 60 or 90 days to decide, you’ll send plenty of traffic and see weak conversion numbers—not because your audience isn’t buying, but because they’re buying outside your window.

    I’ve seen this play out with hosting referrals. Someone reads a performance comparison in October, sets a calendar reminder to migrate in January when their current plan renews, and buys direct. The affiliate who did the research gets nothing.

    What you can do about it

    You can’t change the attribution window, but you can work around it.

    Track your own click timestamps. Use a link shortener or UTM parameters that log to your analytics. Compare your click dates against conversion dates reported by the affiliate network. If you see a pattern—lots of clicks in month one, conversions spiking in month three—you know your window is too short for your audience.

    Retarget clickers before the window closes. If you’re promoting a product with a 30-day window, send a follow-up email at day 20. Frame it as a reminder, a case study, or a bonus resource. The goal is to get them to click again and reset the timer.

    Focus on products with longer windows or lifetime cookies. If your content naturally attracts slow decision-makers, prioritize affiliate programs that offer 60- or 90-day windows, or those that credit you for the lifetime of the subscription. Postmark and some WordPress hosting programs lean this way.

    Build an email list and nurture before promoting. If someone joins your list and you send them an affiliate link six weeks later, the 30-day clock starts fresh. You’re not racing against a window that started when they first discovered you.

    One more thing: last-click attribution

    Even if your window is still open, you can lose credit if the customer clicks another affiliate’s link before buying. Most programs use last-click attribution, meaning the most recent referrer wins.

    This is why you see affiliates aggressively retargeting the same audience, running comparison posts that link to competitors, and sending discount reminders. They’re not just trying to convert—they’re trying to be the last click.

    If you want a larger share of your affiliate revenue to stick, treat your links like a checkout flow: keep the path short, reduce the time between click and purchase, and don’t assume a single mention will carry you through a 60-day consideration cycle.

    Want more breakdowns of how online-business infrastructure actually works? Subscribe to One Two Three Send and get one operator-focused article like this every day.

    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.

  • AI prompt version control: tracking what worked last month

    AI prompt version control: tracking what worked last month

    AI prompt version control: tracking what worked last month
    Photo by Alexander Sutton on Unsplash

    If you’re running prompts through Claude, ChatGPT, or any other AI assistant more than a few times a week, you’ve probably rewritten the same prompt four different ways in the last month—and forgotten which version actually gave you the output you wanted.

    Most solo operators treat prompts like scratch paper. You tweak, you run, you tweak again. If it works, great. If it doesn’t, you start over. But six weeks later, when you need that same task done again, you’re back to square one because you didn’t save the prompt that worked.

    Prompt version control isn’t about building a fancy system. It’s about keeping a simple log of what you changed, when, and why it mattered. Here’s how to do it without adding another tool to your stack.

    Why prompts drift faster than you think

    Unlike code, prompts don’t break loudly. They degrade quietly. You change one instruction, and the output shifts just enough that you don’t notice—until three iterations later, when the AI is giving you something completely different from what you originally wanted.

    Common drift triggers:

    • You add a constraint to fix one edge case, and it breaks the normal case.
    • You switch models (GPT-4 to Claude, or vice versa) and forget to adjust tone instructions.
    • You copy a prompt from a Slack thread and lose the context that made it work.
    • You refine phrasing for clarity, but the AI interprets the new wording differently.

    Without version control, you can’t roll back. You just keep tweaking forward, hoping you stumble back onto something that works.

    The simplest version control setup

    You don’t need Git. You don’t need a prompt management SaaS. You need a text file with dates and a notes field.

    Create a file called prompts.txt or ai-log.md in your notes app, Dropbox, or Google Drive. Every time you land on a prompt that works well enough to reuse, paste it in with three pieces of metadata:

    • Date: when you last used or updated it.
    • Task name: a short label like “newsletter intro rewrite” or “SEO meta description generator.”
    • What changed: one sentence on what you tweaked and why.

    Example entry:

    2026-10-15 | Newsletter intro rewrite
    Prompt: “Rewrite the following intro in 2–3 sentences. Use active voice. Open with a specific detail, not a general statement. Audience: solo online-business operators.”
    Changed: removed “engaging” from instructions—it was making tone too informal.

    That’s it. No tagging system. No nested folders. Just a running log you can Cmd+F when you need to find the version that worked three months ago.

    When to snapshot a prompt

    You don’t need to log every single run. Snapshot a prompt when:

    • You use it successfully for the first time and plan to reuse it.
    • You make a meaningful change that improves output quality.
    • You switch models or tools and need to adjust instructions.
    • Someone on your team asks how you got a specific result.

    If you’re running 10+ prompts a day, you’ll probably log 2–3 per week. That’s enough to build a reusable library without turning it into a chore.

    A shareable library beats a private one

    If you work with a VA, contractor, or co-founder, move your prompt log into a shared doc. Google Docs, Notion, or a private GitHub gist all work.

    The benefit isn’t just collaboration—it’s accountability. When someone else might read your prompt log, you write better notes. You explain why you changed something instead of just pasting a new version. That clarity helps future-you more than anyone else.

    For teams using Claude heavily, consider keeping a dedicated #prompts Slack channel where anyone can drop a working prompt with a sentence of context. It’s searchable, timestamped, and doesn’t require anyone to remember to update a doc.

    Track results, not just prompts

    A prompt log gets more useful when you add one line about what happened after you ran it. Not a full analysis—just a quick note.

    • “Used for 8 newsletter intros this month, 6 needed minor edits.”
    • “Switched to this version after the old one started overusing em dashes.”
    • “Output quality dropped when I moved from GPT-4 to 3.5—reverted.”

    This turns your log from a static archive into a decision-making tool. When you’re deciding whether to tweak a prompt or leave it alone, you can look back and see whether your last round of changes actually improved anything.

    Most solo operators don’t need enterprise prompt-management software. You need a text file, a habit of pasting what works, and enough discipline to write one sentence about why it mattered. Start today with a single file and three logged prompts. By the end of the month, you’ll stop rewriting from scratch.

    What’s one prompt you’ve rewritten five times this year? Reply and let us know—we might feature your setup in a future issue. And if you’re not subscribed yet, join the list for more operator-to-operator breakdowns like this every week.

    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.

  • WordPress admin user roles expose more data than you think

    WordPress admin user roles expose more data than you think

    WordPress admin user roles expose more data than you think
    Photo: Matinbeigi via Wikimedia Commons (CC BY-SA 4.0)

    Most solo operators running WordPress sites hand out Editor or Author accounts without thinking twice. A guest contributor needs to draft a post. A VA needs to schedule content. A designer needs to tweak a page. You create the account, pick a role from the dropdown, and move on.

    But WordPress user roles aren’t just about what someone can publish—they control what someone can see. And the default permissions expose more than most site owners realize.

    What each role actually accesses

    WordPress ships with five default roles. Here’s what each one can see and do, with the gaps that catch people off guard:

    Administrator: Full control. Installs plugins, changes themes, deletes users, accesses all post types, sees all custom fields. No surprises here.

    Editor: Can publish and manage all posts and pages—including other users’ drafts. Can moderate comments. Can see private posts. Cannot install plugins or change site settings. But here’s the catch: Editors can see all content across the site, including unpublished work from other authors. If you’re working on a product launch post in draft mode, your Editor can read it.

    Author: Can write, edit, and publish their own posts. Can upload media. Cannot see other users’ drafts or private posts. Cannot edit pages. This is the role most operators think they’re assigning when they want someone to “just write posts.” But Authors can still delete their own published posts after the fact, and they can upload files to your media library with no size or type restrictions unless you add a plugin to lock it down.

    Contributor: Can write and edit their own posts, but cannot publish them. Cannot upload files. Drafts stay in draft mode until an Editor or Admin publishes them. This is the safest role for guest writers, but it adds friction—every post needs manual review and publishing.

    Subscriber: Can log in and manage their own profile. That’s it. This role exists mostly for membership sites or comment systems that require login. It doesn’t grant access to the WordPress admin dashboard in any meaningful way.

    Where exposure happens in practice

    The most common leak: Editors seeing subscriber data.

    If you’re running a membership site or using a plugin like MemberPress, Restrict Content Pro, or Paid Memberships Pro, Editors can often view the full subscriber list—names, emails, membership levels, and payment history. The plugins don’t always respect WordPress’s user role boundaries. They assume anyone with Editor-level access is trusted with customer data.

    Same problem with form plugins. If you’re collecting emails via WPForms, Gravity Forms, or Fluent Forms, an Editor can usually export the entire entry database as a CSV. That means every lead magnet signup, every contact form submission, every quiz result.

    Another gap: Authors seeing plugin settings they shouldn’t touch.

    Some plugins—especially SEO tools like Yoast or RankMath—let Authors edit meta descriptions and schema markup on their own posts. That’s fine. But if the plugin doesn’t scope its settings properly, Authors might also see site-wide SEO settings, analytics tokens, or API keys in the plugin’s dashboard. They can’t change them, but they can see them. If you’ve pasted a Google Analytics measurement ID or a Mailchimp API key into a plugin settings page, check whether your Author-level users can view it.

    How to audit what your users can see

    Log out of your admin account. Create a test user for each role you’ve assigned to real people—Editor, Author, Contributor. Log in as each test user and click through the dashboard.

    Check these areas specifically:

    • Posts → All Posts: Can they see drafts from other users?
    • Users → All Users: Can they see the subscriber list and export emails?
    • Plugin settings pages: Can they view API keys or third-party credentials?
    • Media library: Can they see all uploaded files, or just their own?
    • Custom post types (if you use them): Can they access posts they shouldn’t edit?

    If you find something you don’t like, you have two options: switch to a more restrictive role, or install a role management plugin like PublishPress Capabilities or Members. Both let you fine-tune permissions at the capability level—”edit_others_posts,” “view_users,” “upload_files”—without writing code.

    One non-obvious fix

    If you need someone to publish posts but not see other users’ drafts, create a custom role. Use PublishPress Capabilities or Members, duplicate the Author role, and add the “publish_posts” capability. Name it something like “Publisher.” This gives them the ability to publish their own work without exposing them to the full Posts list that Editors see.

    For most solo operators, this setup works better than Editor access. You avoid the draft-exposure problem, and you keep tighter control over who sees subscriber data.

    Before you hand out the next Editor account, log in as that role and see what you’re actually sharing. It’s more than you think.

    Got a WordPress question you’d like answered? Reply to this email—we cover operator problems every week.

  • Stop fearing churn—track subscriber tenure instead

    Stop fearing churn—track subscriber tenure instead

    Stop fearing churn—track subscriber tenure instead
    Photo by Adi Goldstein on Unsplash

    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.

Powered by CookieAdmin