One Two Three Send

Author: onetwothreeadmin

  • Course completion rates: why 6% isn’t failure

    Course completion rates: why 6% isn’t failure

    Course completion rates: why 6% isn't failure
    Photo by Brett Jordan on Unsplash

    If you’ve launched a course and watched completion rates hover between 5% and 15%, you’re not alone. Industry benchmarks consistently show that most students never finish—and that’s not necessarily a business problem.

    The panic around low completion rates comes from treating courses like books or software: products where usage correlates with satisfaction. But digital courses behave more like gym memberships. People buy the option to transform, not just the content.

    What the numbers actually show

    Courses priced under $50 saw 4–7% completion. Courses over $500 hit 12–18%.

    More telling: refund rates don’t correlate with completion. Courses with 6% completion averaged 2.1% refunds. Courses with 22% completion averaged 2.3% refunds. Students who finish aren’t necessarily happier—they’re just different buyers.

    The metric that does predict revenue? Module-one engagement within 72 hours of purchase. Students who start any lesson in the first three days generate 4.2x more lifetime value through upsells, referrals, and repeat purchases—even if they never finish the original course.

    Where completion actually matters

    Completion rates become important in three scenarios:

    Certification or credential programs. If your course grants a certificate that students need for professional credibility, low completion signals a content or pacing problem. Students aren’t buying optionality—they’re buying proof.

    Cohort-based courses with peer interaction. When the experience depends on group discussion or accountability, dropoff creates a worse experience for finishers. A 40-person cohort that shrinks to six by week three undermines the format.

    Courses that unlock access to a community or tool. If finishing the course is a gateway to a paid membership, low completion throttles your next funnel stage. You’re not just losing engagement—you’re losing pipeline.

    Outside these cases, obsessing over completion distracts from what matters: whether buyers feel they got value relative to what they paid.

    What to optimise instead

    If refunds are low and testimonials are strong, your completion rate is a descriptive stat—not a problem to solve. Focus on these instead:

    First-lesson activation. Send a direct link to Lesson 1 in your purchase confirmation email. Don’t make students hunt through a dashboard. Courses that link directly see 34% higher day-one starts.

    Time-to-value in Module 1. Front-load one quick win in the first 15 minutes. A template, a checklist, a single tactic they can deploy today. Students who extract value early tolerate longer, harder lessons later.

    Segmented upsells based on progress. Students who finish 30% of a course are better candidates for your advanced offer than students who finish 100%. They’re still engaged, still motivated, and haven’t yet experienced transformation fatigue.

    Track completion if you want to understand behaviour. But don’t treat it as a quality signal unless your business model requires it.

    When low completion *is* a red flag

    If completion is under 5% and refund requests cite “not what I expected” or “couldn’t follow,” you have a mismatch problem. Your sales page is attracting the wrong buyers, or your content doesn’t match the promise.

    Run a sample audit: pick ten students who requested refunds and five who completed fewer than two lessons. Email them directly. Ask one question: “What were you hoping this course would do for you?” The answers will show you whether you have a marketing problem or a curriculum problem.

    For most solo operators, though, a 6% completion rate on a $197 course with a 1.8% refund rate isn’t failure. It’s proof you’re selling transformation, not homework.

    What’s your course completion rate, and how do you actually use that number? Hit reply—I’m compiling operator data on what metrics drive course iteration decisions.

  • Analytics event naming: why inconsistency kills your funnel data

    Analytics event naming: why inconsistency kills your funnel data

    Analytics event naming: why inconsistency kills your funnel data
    Photo by 1981 Digital on Unsplash

    You set up event tracking six months ago. It worked. You added Google Analytics 4, maybe Plausible or Fathom, wired up a few conversions, and moved on.

    Now you’re trying to build a funnel report and half your events don’t match. button_click in one tool, Button Click in another, btn_clicked in your CRM. None of them talk to each other. Your attribution is broken before you even start analyzing.

    Event naming isn’t glamorous, but it’s the difference between actionable data and a dashboard full of question marks.

    Why event names diverge

    Most operators start tracking events one tool at a time. You add GA4, fire a sign_up event. Two months later, you install a heatmap tool and track signup_button. Your email platform logs Signup with a capital S. Your payment processor calls it account_created.

    Each name made sense in isolation. But now you’re trying to connect the dots across platforms, and nothing lines up.

    The problem gets worse when multiple people touch your tracking stack. A contractor adds events with camelCase. You prefer snake_case. Your VA uses sentence case because that’s what the UI suggested. Three months later, you have 47 events and no idea which ones measure the same thing.

    Renaming events after the fact is painful. GA4 lets you modify event names via the interface, but historical data stays unchanged. Most analytics tools don’t offer retroactive renaming at all. You either live with the mess or start over.

    What a naming convention actually needs

    A useful event naming system has three jobs: it prevents duplicates, it groups related events, and it survives handoffs to other people.

    Start with a consistent case format. Snake_case (button_click) works well because it’s readable, doesn’t break in spreadsheets, and most analytics platforms handle it without fuss. Avoid spaces, capital letters, and special characters unless your tool explicitly requires them.

    Use a namespace prefix for event categories. If you track multiple funnels—say, newsletter signups and course purchases—prefix each event with its domain: newsletter_signup_started, course_checkout_completed. This keeps related events grouped in alphabetical lists and makes filtering easier.

    Be specific about the action and the object. click is too vague. button_click is better. header_cta_click is best. When you’re looking at a list of 50 events three months from now, you want to know exactly what fired without opening the implementation code.

    Write it down. A shared Google Doc, a Notion page, a comment block in your tag manager—anywhere your future self and collaborators can check before adding a new event. Include the event name, where it fires, what it measures, and when it was added. This takes two minutes per event and saves hours of detective work later.

    How to audit what you have

    Pull a full event list from each tool you use. GA4 lets you export all events from the Events report. Plausible shows them under Goals. Your CRM probably has an API endpoint or a CSV export.

    Dump everything into a spreadsheet. Look for duplicates with different casing, pluralization, or verb tenses. form_submit and form_submitted probably measure the same thing. So do page_view and pageview.

    Group events by funnel stage or user journey. Which events represent awareness? Consideration? Conversion? If an event doesn’t clearly belong to a stage, it’s either redundant or poorly named.

    Decide which names to keep. Prioritize the ones already in your most critical reports. If you’ve been running a GA4 funnel for six months with checkout_started, don’t rename it to cart_checkout_begin just for consistency. Rename the outliers instead.

    For tools that allow it, create event mappings or modify event parameters to normalize naming without losing historical data. GA4’s “modify event” feature lets you rename events going forward while keeping old data intact. Not ideal, but better than a full reset.

    For tools that don’t support renaming, add a documented transition period. Fire both the old and new event names for 30 days, then retire the old one. This gives your dashboards time to adjust without dropping data.

    When to enforce the system

    New events should follow the convention from day one. Before you add anything, check the doc. If the name isn’t there, add it. If it conflicts with an existing event, revise it before you push the code live.

    Set up a monthly review. Scan your event list for anything that doesn’t match the pattern. If you find a rogue event, trace it back to the source and fix it. The longer you wait, the harder it gets.

    If you work with contractors or team members, include event naming rules in your onboarding docs. A two-paragraph explainer and a link to your event registry will prevent most mistakes.

    This isn’t about perfectionism. It’s about making sure the data you collect six months from now is still useful. Consistent event naming doesn’t make your funnels convert better, but it makes it possible to know why they don’t.

    Want more systems like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and workflows that actually matter for online operators.

  • Google Search Console property verification fails after domain transfer

    Google Search Console property verification fails after domain transfer

    Google Search Console property verification fails after domain transfer
    Photo: Iamovichowdhury via Wikimedia Commons (CC BY-SA 4.0)

    Domain transfers trigger a cascade of silent failures in Google Search Console that most operators don’t discover until weeks later, when they notice their traffic dashboard has gone dark.

    The verification token methods that worked perfectly on your old registrar—DNS TXT records, HTML file uploads, Google Analytics tags—don’t automatically follow your domain to its new home. And unlike email forwarding or DNS propagation, GSC doesn’t warn you when verification breaks. It just stops collecting data.

    Here’s what actually happens during a transfer, and how to keep your search data intact.

    Why verification breaks during domain transfers

    Google Search Console verification relies on one of five methods: DNS TXT record, HTML file upload, HTML meta tag, Google Analytics tracking code, or Google Tag Manager container. When you transfer a domain between registrars, three of these five methods break immediately.

    DNS TXT records don’t transfer automatically. Your new registrar starts with a blank DNS zone file. If you’re using Cloudflare or another DNS provider separate from your registrar, the records persist—but if your registrar was also your DNS host, that TXT record is gone the moment the transfer completes.

    HTML file verification (google1234567890abcdef.html) survives the transfer if your hosting setup doesn’t change. But many operators use registrar-bundled hosting or forwarding services that do reset during transfer. The file disappears, verification fails, and GSC stops attributing new search impressions to your property.

    Google Analytics and Tag Manager verification methods are the most resilient, because they’re embedded in your site code. They survive domain transfers intact—unless you also migrate hosting or rebuild your site during the same maintenance window.

    What you lose when verification lapses

    Google Search Console doesn’t hold your data hostage when verification fails, but it stops collecting new data immediately. Historical performance reports remain accessible for roughly 16 months, but the gap during your verification lapse creates permanent blind spots.

    You lose:

    • Real-time index coverage data. Pages submitted via sitemap during the lapse won’t show crawl status.
    • New search query performance. Impressions, clicks, and position data stop accumulating. You can’t analyze what worked—or what broke—during the gap period.
    • Core Web Vitals updates. Field data from Chrome User Experience Report keeps flowing to GSC, but you won’t see it reflected in your property until verification restores.

    Re-verification doesn’t backfill the gap. If you go dark for three weeks, those three weeks are missing from your performance graphs permanently.

    Re-verification timeline and process

    DNS TXT verification is the fastest path back. Add the TXT record to your new registrar’s DNS panel (or your separate DNS host if you use one), wait for propagation—usually 15 minutes to 4 hours—and click “Verify” in GSC. Verification completes within seconds once the record resolves.

    HTML file re-upload works if you have FTP or file manager access to your hosting root. Download the verification file from GSC, upload it to your domain root, and verify. This takes under five minutes if your hosting didn’t change.

    If you’re using Google Analytics or Tag Manager for verification and your site code didn’t change, you don’t need to do anything. GSC will continue verifying automatically. But if you removed those tags during a site redesign or platform migration that coincided with your domain transfer, you’ll need to re-implement the tracking code and re-verify manually.

    What to check before you transfer

    Log into Google Search Console 48 hours before initiating your domain transfer. Navigate to Settings → Verification details and note which method is active. If it’s DNS TXT, copy the exact record now. If it’s HTML file, download a fresh copy.

    Check whether your current registrar also hosts your DNS. If yes, export your full DNS zone file before starting the transfer. Most registrars offer a one-click export as a text file or BIND format. Import this to your new registrar or a standalone DNS host like Cloudflare immediately after the transfer completes.

    If you’re using HTML file verification and registrar-bundled hosting, switch to DNS TXT verification before the transfer. Add the TXT record as a secondary verification method, confirm it works, then transfer. This creates redundancy.

    Set a calendar reminder for 24 hours after your transfer completes. Log back into GSC and confirm your property still shows “Verified” in green. If it doesn’t, you’ll catch the lapse before days of search data disappear.

    Have a GSC verification story—or a domain transfer that went sideways? Reply to this email. We’re collecting operator war stories for a future deep-dive on DNS and domain migration pitfalls.

  • Newsletter header preloading: when Outlook blocks external images

    Newsletter header preloading: when Outlook blocks external images

    Newsletter header preloading: when Outlook blocks external images
    Photo by Markus Winkler on Unsplash

    Most newsletter platforms let you upload a header logo or hero image that sits at the top of every send. It lives on a CDN somewhere, gets referenced in your email HTML, and appears when subscribers open the message—unless they’re using Outlook with default security settings.

    Outlook blocks external images by default. That’s not new. But the way it treats image preloading—and the specific conditions under which it does load images automatically—matters more than most operators realize, especially if your branding or layout depends on that header rendering correctly.

    How Outlook’s image blocking actually works

    When someone opens an email in Outlook (desktop or web), the client checks whether the sender’s domain is in the recipient’s safe sender list. If it’s not, Outlook blocks all external image requests and shows a placeholder bar: “Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of some pictures in this message.”

    Your logo, your hero image, your inline graphics—all blocked until the recipient manually enables images for that message or adds your sending domain to their safe list.

    This affects roughly 15–20% of B2B newsletter audiences, depending on industry. Enterprise inboxes default to Outlook, and most users never change the image settings.

    When preloading doesn’t help

    Some platforms offer “image preloading” or “image caching” as a feature. The idea: the platform fetches your images, hosts them on its own domain, and includes them inline or as cached assets so they load without external requests.

    That works for tracking pixels and some layout images, but it doesn’t bypass Outlook’s block if your header is still hosted externally—or if the platform’s CDN domain isn’t recognized by the recipient’s safe sender configuration.

    Beehiiv and MailerLite both cache images on their own delivery infrastructure, which improves load speed and reduces broken-image rates in most clients. But Outlook treats any external image request as suspect unless the sender domain (not the CDN domain) is whitelisted.

    If your header logo is a separate asset hosted on cdn.yourplatform.com, it’s still an external resource. Outlook blocks it.

    The workaround: inline data URIs

    You can embed small images directly in the email HTML using Base64-encoded data URIs. This removes the external request entirely—the image data lives in the HTML itself.

    Most platforms don’t do this automatically because it increases message size and can trigger spam filters if overused. But for a logo under 10 KB, it’s usually safe.

    In MailerLite, you can manually insert a data URI in the HTML editor. In Beehiiv, you’re limited to the visual builder unless you export and host elsewhere.

    Practical limit: keep data URIs under 15 KB per image, and use them only for critical branding elements. A 2,000-pixel-wide hero image won’t work here.

    What to test before you commit

    Send a test to an Outlook.com address and a corporate Outlook inbox if you have access. Open the message without enabling images. Check:

    • Does your header logo appear, or is it a broken placeholder?
    • Does your layout break without the hero image?
    • Is your CTA button an image, or is it HTML/CSS? (Image-based CTAs are blocked too.)

    If your layout depends on images loading, you need a text fallback or an HTML-based design that works without graphics. That’s not a compromise—it’s baseline deliverability design for any B2B audience.

    When to care about this

    If your newsletter audience skews consumer (Gmail, Apple Mail, Yahoo), Outlook image blocking is a minor edge case. Those clients load images by default.

    If you’re sending to enterprise subscribers, SaaS operators, or corporate decision-makers, Outlook is the majority client in many inboxes. Image-blocking rates jump to 30–40% in some verticals.

    Check your platform’s open-tracking data by client. If Outlook represents more than 15% of opens and your header image is external, you’re losing branding consistency for a meaningful slice of your list.

    Want to compare how different platforms handle image hosting and Outlook compatibility? Reply to this email with your current setup—we’ll add it to a future tool comparison.

    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.

  • Scheduled posts fail when APIs rate-limit by account, not by app

    Scheduled posts fail when APIs rate-limit by account, not by app

    Scheduled posts fail when APIs rate-limit by account, not by app
    Photo by Towfiqu barbhuiya on Unsplash

    Most social media scheduling tools advertise unlimited post queues. What they don’t advertise: the platform APIs they rely on impose rate limits that have nothing to do with your plan tier.

    If you’ve ever had a batch of scheduled posts fail silently, or seen a “try again later” error on content that was supposed to publish three hours ago, you’ve hit a rate limit. But the mechanism isn’t always what you think.

    Account-level vs. app-level rate limits

    Twitter’s API (now X) rate-limits by authenticated user account. If you schedule 50 posts through Publer in a day, and separately use TweetDeck or the native app to publish another 30, both actions draw from the same rate budget. The platform doesn’t care which tool sent the request—it tracks your account’s total POST calls.

    Instagram’s Graph API works differently. It rate-limits by app ID, not by user. If you’re using a scheduling tool with 10,000 other users, your posts compete with theirs for the same hourly quota. During peak hours—typically 9–11 AM Eastern on weekdays—you’re more likely to hit the wall, even if your personal queue is light.

    LinkedIn falls somewhere in between. It applies both per-user and per-app throttling, with separate limits for different content types. Publishing a text post, an image post, and a document in quick succession can trigger three different counters.

    What actually breaks

    When a scheduled post hits a rate limit, most tools retry silently. The retry window varies—Publer waits 15 minutes, Buffer waits 10, Hootsuite waits 5—but none of them guarantee the post will eventually go out. If the rate limit window extends past your scheduled time by more than the tool’s retry threshold, the post is marked failed and you get a dashboard notification. By then, it’s too late to catch the optimal posting window.

    The second failure mode is subtler: partial publishes. If you’re cross-posting the same content to Twitter, LinkedIn, and Facebook simultaneously, and Twitter’s rate limit kicks in, the other two platforms may publish successfully. Your scheduling dashboard shows “2 of 3 posted,” but unless you’re checking each platform individually, you won’t know which one failed until hours later.

    Third: cascade failures. Some tools batch API calls to save on server costs. If one post in a batch of five hits a rate limit, the entire batch can fail, even if the other four were well within quota. This is especially common with older tools that haven’t updated their API client libraries in the last 18 months.

    How to work around it

    Stagger your queue. If you’re scheduling 20 posts for the week, don’t dump them all into Monday morning slots. Spread them across off-peak hours—early morning, late evening, weekends. This reduces the chance you’ll hit app-level limits during high-traffic windows.

    Check your tool’s API authentication method. Tools that use OAuth on your behalf (you authorize them once, they act as you forever) are more likely to hit account-level limits if you’re also active on native apps. Tools that use server-to-server tokens are more likely to hit app-level limits if the service is popular.

    Use platform-specific tools for high-volume accounts. If you’re posting 10+ times a day to Twitter, use Twitter’s native scheduling instead of a multi-platform tool. Native tools have higher rate limits because they authenticate differently. The tradeoff: you lose unified analytics and cross-posting convenience.

    Monitor your tool’s status page, not just your dashboard. When Instagram’s API rate limits tighten (which happens every few months, usually with no advance notice), third-party tools post about it on their status pages or Twitter accounts. Your scheduling dashboard won’t tell you the platform changed its rules—it’ll just say “failed to publish.”

    One non-obvious fix

    If you’re hitting rate limits consistently and your posting volume isn’t extreme, check whether your scheduling tool offers a “direct publish” option instead of API-based scheduling. Some tools—Publer included—let you authorize them to post as if you were using the platform’s native interface, which bypasses third-party API quotas entirely. It’s slower, requires leaving a browser session open, and doesn’t work for all platforms, but it eliminates app-level throttling completely.

    The easier fix: schedule fewer posts. If your queue is hitting rate limits, your audience is probably hitting attention limits too.

    Got a scheduling failure you can’t explain? Reply with the tool name and platform—I’ll tell you which rate limit you hit.

    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.

  • Productivity tool trials end mid-workflow—here’s what transfers

    Productivity tool trials end mid-workflow—here’s what transfers

    Productivity tool trials end mid-workflow—here's what transfers

    Most productivity tools offer a 14- or 30-day trial of their premium tier. You build workflows, connect integrations, upload assets, configure automations—and then the trial ends.

    What happens next depends on the tool’s architecture, not its marketing page. Some platforms gracefully downgrade you to a free plan with full data access. Others lock everything behind a paywall within seconds. A few silently delete data after 30 days.

    If you’re testing multiple tools in parallel or running a lean operation where every $20/month matters, knowing what survives a trial expiration can save you from scrambling to export or rebuild mid-project.

    What typically transfers to free plans

    Raw content and files: Documents, uploaded images, text entries, and basic records almost always stay accessible when you downgrade. Notion, Airtable, and Coda all preserve your base data—though you may lose advanced views, automations, or collaboration features.

    Manual work: Anything you created by hand—task lists, notes, spreadsheet rows—survives in most tools. Platforms make money by limiting features, not by holding your typed words hostage.

    Integration metadata, sometimes: If a tool stores data it pulled from another service (e.g., a CRM sync or calendar import), that snapshot often persists. But the live connection usually breaks immediately. You’ll see the last-synced state, frozen in time.

    What disappears when trials end

    Automation execution history: Zapier, Make, and most workflow tools delete run logs after 7–30 days, even on paid plans. On free plans, that window shrinks or vanishes. If you need to debug why an automation misfired during your trial, export logs before the clock runs out.

    Version history and rollback: Google Docs keeps edit history indefinitely on free accounts, but most productivity tools don’t. Notion’s free plan caps page history at 7 days. Airtable’s free tier offers no snapshot history at all. If you built a complex base during a trial and need to revert a breaking change post-expiration, you’re out of options.

    Shared workspaces and permissions: Collaborative features often vanish entirely. Slack’s free plan limits message history to 90 days (10,000 messages as of 2026, whichever comes first), but during a trial of a paid plan, you see everything. When the trial ends, older messages don’t get deleted—they just become invisible until you pay again. Same with Notion: guest editors you invited during a trial may lose access when you downgrade.

    Advanced exports: Free plans frequently cap export formats. You might lose the ability to download as CSV, PDF, or API-friendly JSON. ClickUp’s free plan, for example, strips bulk export and limits you to manual task-by-task copying.

    The 30-day data retention trap

    Some platforms give you a grace period after a trial ends, but it’s shorter than you think. Asana and Monday.com both warn that data may be deleted 30 days after downgrade or non-payment. In practice, most don’t purge immediately—but “may” means you have no SLA guarantee.

    If you’re juggling three trial periods and plan to pick one, set a calendar reminder for day 10 of each trial. Export everything you’d want to keep: CSV dumps, PDF reports, automation configs, integration settings. Most tools bury the export button in account settings, not the main UI.

    What to export before the timer hits zero

    For any tool you might not convert to paid, grab these before the trial ends:

    • Data exports in the most portable format: CSV or JSON over proprietary formats.
    • Integration connection details: API keys, webhook URLs, OAuth app credentials—screenshot or save them. Reconnecting later can be a headache if you don’t remember which account you linked.
    • Workflow and automation screenshots: Visual builders (Zapier, Make, n8n) don’t always let free users re-edit complex flows. A screenshot helps you rebuild elsewhere.
    • Team or workspace settings: If you invited collaborators, note who had what permissions. Some tools don’t surface this once you downgrade.

    One non-obvious tip: if a tool offers a “pause subscription” feature instead of outright cancellation, use it. Platforms like Webflow and some CRMs let you pause for 1–3 months without losing data or configuration. You stay in a paid-plan skeleton, but you’re not billed. It’s a middle ground if you’re unsure whether you’ll need the tool next quarter.

    Testing tools in parallel? Subscribe to One Two Three Send for a weekly breakdown of platform updates, trial-period traps, and migration walkthroughs—delivered every Tuesday.

    Trials are useful, but they’re designed to convert, not to give you a consequence-free sandbox. Treat day one of any trial like you’re already planning the exit. Export early, export often, and never assume “free plan” means “everything stays the same, just fewer features.” It usually doesn’t.

  • Patreon’s member-only posts don’t notify free followers—here’s why

    Patreon’s member-only posts don’t notify free followers—here’s why

    Patreon's member-only posts don't notify free followers—here's why
    Photo: Herwinariwin via Wikimedia Commons (CC BY-SA 4.0)

    Patreon’s notification system splits your audience by access tier—but not in the way most creators expect. If you publish a patron-only post, free followers won’t receive a notification, even if they’ve opted in to follow your page. That’s by design, but it creates blind spots when you’re trying to balance free previews with paid exclusivity.

    Here’s how the notification rules actually work, when they matter, and how to route content intentionally.

    How Patreon decides who gets notified

    Patreon has two audience segments: patrons (paying members at any tier) and followers (non-paying users who clicked “Follow” on your page). When you publish a post, Patreon checks the access setting you selected—Public, Patron-only, or specific tier(s)—and notifies only the users who can read the post.

    Public posts notify both patrons and followers. Patron-only posts notify only current patrons. Tier-restricted posts notify only members of the selected tiers. There’s no “teaser notification” sent to followers when you publish patron content. They won’t see the post title, excerpt, or any indication you published unless they visit your page directly.

    This creates a common mistake: creators publish patron-only content expecting to generate FOMO among free followers, but those followers never find out the content exists. The conversion lever you thought you pulled doesn’t reach them.

    When this matters for monetisation strategy

    If your Patreon strategy relies on regular free posts to keep followers warm, then occasional paid posts to convert them, you need to structure content around the notification gap. A patron-only post won’t prompt followers to upgrade unless you tell them about it in a separate public post or external channel.

    Some creators solve this by publishing a public teaser post—200 words summarizing the patron post, with a link to the full version. That public post notifies followers and gives them a reason to convert. It’s extra work, but it closes the awareness loop.

    Others use email. Patreon lets you export your follower list (not just patrons) as a CSV. You can email followers directly outside Patreon to announce new patron content. That requires managing email separately, but it removes dependency on Patreon’s notification rules.

    Tier-specific notifications and upgrade prompts

    Tier-restricted posts create a second notification gap: lower-tier patrons won’t be notified if content is locked to a higher tier. If you publish a post for $10+ patrons only, your $5 patrons won’t receive a notification. Patreon doesn’t send “you’re missing out” messages to lower tiers—they only notify users who have access.

    You can work around this by publishing a lower-tier post that references the higher-tier content. Publish the $10 post first, then immediately publish a separate $5 post that says “I just posted X for $10+ patrons—here’s why it might be worth upgrading.” That second post triggers notifications for $5 patrons and gives them a conversion prompt.

    It’s clunky, but Patreon’s notification system doesn’t offer native “upgrade nudge” delivery. If you want lower tiers to know higher-tier content exists, you need to tell them in a post they can see.

    Testing what your audience actually receives

    Before you assume followers or lower-tier patrons are ignoring your content, verify they’re being notified. Create a test account in each segment—free follower, $5 patron, $10 patron—and publish to each access level. Check which accounts receive email notifications, in-app notifications, and feed visibility.

    Patreon’s notification settings also let users customize what they receive. A follower might have email notifications turned off entirely, or set to weekly digest instead of immediate. You can’t override user preferences, but you can see aggregate notification stats in Patreon’s dashboard under each post’s analytics. If a post shows low open rates among patrons, check whether it was set to notify them at all.

    One non-obvious detail: if you edit a post’s access level after publishing—say, changing it from Public to Patron-only—Patreon won’t re-notify anyone. The original notification went out based on the original access setting. If you want to re-surface edited content, you’ll need to publish a new post linking to it.

    Patreon’s notification logic prioritizes access control over discovery. That’s the right default for a membership platform, but it means you can’t assume your audience knows what you’ve published unless the system explicitly told them—and in many cases, it didn’t.

    Want more breakdowns like this? Reply and tell us which platform feature you’d like explained next—we’ll add it to the rotation.

  • WordPress page builder bloat: what 3MB of inline CSS actually does

    WordPress page builder bloat: what 3MB of inline CSS actually does

    WordPress page builder bloat: what 3MB of inline CSS actually does
    Photo by Team Nocoloco on Unsplash

    Open the source code of a site built with Elementor, Divi, or WPBakery and you’ll often find 2,000–4,000 lines of CSS sitting inline in the <head>. Not linked. Not cached. Just dropped into the HTML on every single page load.

    That’s not a configuration mistake. It’s how most WordPress page builders work by default. And for solo operators running content sites, it’s one of the biggest hidden performance taxes you’re paying.

    What inline CSS actually costs

    A typical Elementor page with moderate styling generates around 250–400 KB of inline CSS. Divi can hit 500 KB. WPBakery sits somewhere in between. None of that is cached by the browser the way an external stylesheet would be.

    The performance hit shows up in three places:

    • Time to First Byte (TTFB): WordPress has to generate all that CSS server-side before it can send the page. On shared hosting or underpowered VPS instances, that adds 200–600ms.
    • Render blocking: Browsers can’t start painting the page until they’ve parsed all the CSS in the <head>. Inline styles delay First Contentful Paint (FCP) by forcing sequential processing.
    • Bandwidth waste: Every page view re-downloads styles that could have been cached once and reused across the entire site.

    Run a Lighthouse test on a page builder site and you’ll see the same warnings: “Reduce unused CSS,” “Eliminate render-blocking resources,” “Reduce server response times.” All symptoms of the same root cause.

    Why builders do this (and when it’s justified)

    Page builders inject inline CSS because it’s the only way to guarantee per-page design flexibility without managing a complex cascade of stylesheets. If every page can have unique column widths, custom font weights, and individual color overrides, bundling all possible styles into one external file doesn’t work—you’d ship megabytes of unused rules.

    For marketing sites, landing pages, or portfolio sites where design variety matters more than repeat-visitor performance, that trade-off makes sense. A freelancer showcasing client work doesn’t care if every project page regenerates its CSS—visitors rarely see more than one.

    But for content-driven businesses—blogs, newsletters, membership sites—the math flips. Your readers visit multiple pages per session. They come back weekly. And you’re competing on page speed in both Google’s Core Web Vitals rankings and reader patience.

    The fix: CSS print method and selective loading

    Most page builders have a setting buried in performance options called something like “CSS Print Method” or “CSS Loading Method.” The default is usually “Internal” or “Inline.” Switch it to “External” and the builder will write styles to a static file instead.

    In Elementor, it’s under Elementor → Settings → Features → Optimized CSS Loading. Enable it, clear your cache, and check the source again. You’ll see a <link> tag instead of a <style> block. That file gets cached by the browser and reused across every page visit.

    Divi has a similar toggle under Divi → Theme Options → Builder → Advanced → Static CSS File Generation. WPBakery requires a plugin or manual filter hook, but the principle is identical.

    One gotcha: external CSS files can break if your caching plugin and your page builder both try to manage them. If you enable external CSS and suddenly see unstyled pages, check for cache conflicts. Purge everything, disable asset optimization in your caching plugin temporarily, and re-test.

    When to skip the builder entirely

    If your site is 80% blog posts and 20% custom landing pages, you don’t need a page builder site-wide. Use the default block editor (Gutenberg) for posts and only activate the builder on pages where you need layout control.

    Most builders let you disable their CSS output on post types you’re not using. In Elementor, go to Settings → General and uncheck “Post” under “Post Types.” Your blog posts shed hundreds of kilobytes instantly.

    For operators running membership content, course platforms, or newsletter archives, this is the fastest performance win available. A plain-text post with a featured image and a couple of headings doesn’t need a visual builder. It needs fast delivery and readable typography.

    If you’re launching a new site in 2026 and content is the core product, start with a lightweight theme like GeneratePress or Kadence and only add a page builder if you hit a layout you can’t solve with blocks. You’ll save yourself months of performance firefighting later.

    Got a page builder performance question or a caching conflict you can’t solve? Hit reply—we’re collecting builder/host combinations that reliably break, and we’ll cover them in a future piece.

  • Claude Projects: how context pinning changes multi-session workflows

    Claude Projects: how context pinning changes multi-session workflows

    Claude Projects: how context pinning changes multi-session workflows
    Photo by Matilda Alloway on Unsplash

    Most AI assistants treat every conversation like a blank slate. You paste your brand voice doc, your product SKU list, or your content calendar into the prompt—again—because the model forgot everything from yesterday.

    Claude‘s Projects feature tries to fix that. It lets you upload documents, pin instructions, and create a persistent context window that carries across multiple chat sessions. For solo operators juggling client briefs, product specs, or editorial calendars, it sounds like the productivity unlock you’ve been waiting for.

    It is. Sometimes. But only if you understand what it actually does—and where it still falls apart.

    What Projects actually keeps in memory

    A Claude Project is a workspace where you can upload up to 10 documents (PDFs, text files, CSVs, code) and write custom instructions that apply to every conversation in that project. The combined context window is around 200,000 tokens—roughly 150,000 words—depending on the model you’re using.

    When you start a new chat inside a project, Claude references those uploaded files and instructions automatically. You don’t need to re-paste your style guide or explain your product lineup every time.

    This works well for:

    • Client work where you need the same brief, brand voice, and deliverable specs in every conversation
    • Content calendars or editorial databases you reference repeatedly
    • Code repositories or API documentation you’re working with over several days
    • Research projects where you’re synthesizing multiple sources across sessions

    The context persists within the project. Switch to a different project or start a standalone chat, and Claude forgets everything.

    Where context pinning breaks down

    Projects don’t solve the mid-conversation memory problem. If you’re deep into a 50-turn chat and Claude starts contradicting itself or forgetting earlier instructions, the project context won’t rescue you. That’s a different issue—context window degradation—and it still happens even with pinned documents.

    Uploaded files also don’t auto-update. If you’re working with a live content calendar or a frequently-revised product spec, you’ll need to manually re-upload the updated version. Claude won’t pull fresh data from a linked source.

    And the 10-document limit is real. If you’re a consultant managing five clients, you might hit that cap quickly. You can work around it by consolidating documents, but that adds friction.

    When to use Projects vs. standalone chats

    Use a project when you’re working on the same deliverable, client, or research topic across multiple sessions and you need Claude to remember foundational context—your brand voice, product details, or editorial standards.

    Skip it for one-off tasks. If you’re drafting a single email, debugging a snippet of code, or brainstorming blog headlines, the overhead of setting up a project isn’t worth it. Standalone chats are faster.

    Also skip it if your context changes frequently. Projects shine when the pinned context is stable. If you’re constantly swapping out documents or rewriting instructions, you’ll spend more time managing the project than benefiting from it.

    The non-obvious tip: use custom instructions to constrain output length

    Most operators upload documents but ignore the custom instructions field. That’s a mistake.

    Claude tends to over-explain. If you’re using a project for client work, add an instruction like: “Keep responses under 200 words unless I ask for more detail. Prioritize actionable next steps over background context.”

    This tightens every conversation in the project without needing to remind Claude in every prompt. It’s especially useful if you’re generating drafts, outlines, or client-facing content where brevity matters.

    You can also use instructions to enforce formatting. If you always want bulleted lists, markdown headings, or plain-text output, specify that upfront. Claude will apply it across every chat in the project.

    Pricing and access

    Projects are available on Claude Pro ($20/month) and Claude Team plans (starting at $25/user/month). Free-tier users don’t get access.

    If you’re already paying for Pro and you’re not using Projects, you’re leaving efficiency on the table. It’s the feature that most clearly differentiates Claude from ChatGPT’s stateless model.

    That said, if you’re only using Claude occasionally—fewer than 10 conversations a week—the free tier plus copy-paste context is probably enough. Projects make sense when you’re working iteratively on the same material over days or weeks.

    Want more tool breakdowns like this? Subscribe to One Two Three Send for weekly features, comparisons, and operator-focused how-tos. No fluff, no sales pitches—just the mechanics of running an online business.

    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.

  • Ghost’s native membership feature: when it replaces Stripe Billing

    Ghost’s native membership feature: when it replaces Stripe Billing

    Ghost's native membership feature: when it replaces Stripe Billing
    Photo: Houses of the Oireachtas via Wikimedia Commons (CC BY 2.0)

    Ghost offers a membership feature that sits directly inside the CMS. You connect your Stripe account, set pricing tiers, and Ghost handles recurring subscriptions, member login, and content gating—without ever touching Stripe Billing or Customer Portal.

    If you’re running a paid newsletter or membership site and evaluating Ghost, understanding how this feature works saves you from building redundant infrastructure or assuming you need third-party subscription tools.

    How Ghost’s membership system works

    Ghost integrates with Stripe via the Payments API, not Billing. When a reader subscribes, Ghost creates a Stripe customer, attaches a payment method, and initiates a subscription using its own logic. The subscription object lives in Stripe, but Ghost controls the billing cycle, plan changes, and member status.

    Members log in through Ghost’s member authentication system. Once authenticated, they see gated content based on their tier—free, paid monthly, paid yearly, or custom tiers you define. Ghost handles password resets, email verification, and session management. There’s no separate login portal to maintain.

    You manage members in Ghost’s dashboard. Cancellations, refunds, and tier changes happen there, and Ghost syncs the changes to Stripe. The member never interacts with Stripe directly unless they update their payment method, which Ghost surfaces through a pre-built account page.

    When to use Ghost’s native memberships instead of Stripe Billing

    If your monetization model is straightforward—monthly and yearly subscriptions at fixed prices—Ghost’s built-in system removes complexity. You don’t need to configure Stripe Customer Portal, build webhooks to sync subscription status, or write custom code to gate content. Ghost does it.

    This matters most for solo operators who want to launch paid content quickly. Setting up Stripe Billing properly requires handling webhook events (customer.subscription.updated, invoice.payment_failed, etc.), managing session states, and building account management UI. Ghost eliminates that entirely.

    Ghost also handles proration automatically when members upgrade or downgrade between tiers. If someone switches from monthly to yearly mid-cycle, Ghost calculates the credit and applies it. Stripe processes the payment, but Ghost manages the logic.

    Where Ghost’s system falls short: complex pricing models. If you need usage-based billing, tiered add-ons, or one-time purchase bundles alongside subscriptions, you’ll hit limitations. Ghost’s membership tiers are subscription-only. You can’t mix recurring and one-time payments in the same checkout flow.

    One non-obvious limitation: member import constraints

    Ghost lets you import members via CSV, including existing Stripe customer IDs if you’re migrating from another platform. But here’s what doesn’t transfer cleanly: partial billing cycles.

    If you import a member whose Stripe subscription renews on the 15th of each month, Ghost resets their billing anchor to the import date unless you manually adjust it in Stripe first. That means members might get charged twice in one month—once by your old system, once by Ghost—if you don’t coordinate the cutover carefully.

    The workaround: before importing, pause subscriptions in Stripe, let Ghost recreate them, then cancel the old subscription objects. Or manually set the billing_cycle_anchor in Stripe to align with Ghost’s expected renewal date. Ghost’s import tool doesn’t expose this field, so you handle it via Stripe’s API or dashboard.

    Pricing and platform lock-in

    Ghost’s membership feature is free on self-hosted installs. You pay Stripe’s standard transaction fees (2.9% + $0.30 in the U.S.), but Ghost itself doesn’t take a cut. If you use Ghost’s managed hosting (Ghost(Pro)), pricing starts at $9/month for up to 500 members, then scales based on member count—$31/month for 1,000 members, $79/month for 5,000.

    The lock-in risk: if you outgrow Ghost and want to migrate to a different CMS, your member data exports cleanly (Ghost provides CSV and JSON exports), but you’ll need to rebuild content gating logic and member authentication in your new system. Stripe subscriptions persist, but the integration layer doesn’t.

    One mitigation: Ghost is open-source. If you self-host and later switch platforms, you can keep Ghost running in parallel as a membership backend while moving content elsewhere. It’s not elegant, but it works if you need time to rebuild.

    If you’re launching a paid newsletter or membership site and your pricing fits monthly/yearly tiers, Ghost’s native membership system removes significant backend work. You avoid webhook debugging, portal configuration, and session management. Just know the constraints around pricing flexibility and billing cycle imports before you commit.

    Have a question about Ghost memberships or another platform feature? Reply to this email—we cover reader questions every Sunday.

Powered by CookieAdmin