One Two Three Send

Author: onetwothreeadmin

  • Productized service waitlists: when limited spots sell better than open carts

    Productized service waitlists: when limited spots sell better than open carts

    Productized service waitlists: when limited spots sell better than open carts
    Photo by Edoardo Cuoghi on Unsplash

    Most solo operators running productized services—coaching packages, content audits, technical reviews—leave their cart open all year. The pitch is simple: anyone can buy anytime. But operators who close enrollment and run waitlists report higher conversion rates, better client fit, and fewer refund requests.

    The psychology isn’t complicated. Scarcity works. But the mechanics matter more than the marketing angle. A waitlist isn’t just a landing page with a countdown timer—it’s a commitment device that changes how you deliver and who you attract.

    Why waitlists work operationally, not just psychologically

    The obvious benefit is urgency. When spots are limited and the next cohort opens in six weeks, buyers make faster decisions. But the real advantage shows up in delivery.

    If you sell a service with any back-and-forth component—calls, feedback rounds, async review cycles—batching clients by cohort smooths your workload. Instead of onboarding one person Monday, two on Thursday, and three the following week, you onboard twelve people the same day. You record one welcome video. You send one kickoff email. You run one group orientation call if the format supports it.

    Even if your service is fully one-to-one, batching intake means you’re not context-switching between discovery calls, active client work, and offboarding every single day. You spend two weeks selling, four weeks delivering, then two weeks improving your materials before the next round.

    This isn’t theoretical. Operators running quarterly cohorts report 20–30% more throughput than those with rolling enrollment, even when total revenue stays flat, because less time goes to administrative overhead.

    When to use a waitlist vs. open cart

    Waitlists work best when your service has one or more of these traits:

    • High touch. If you’re on calls, reviewing work, or providing detailed feedback, batching clients prevents burnout.
    • Seasonal demand. Tax prep, course launch support, year-end strategy—services tied to calendar events naturally suit closed enrollment.
    • Capacity caps. If you can only serve eight clients per quarter without quality dropping, a waitlist enforces that limit before you overcommit.
    • Improving materials. Closing the cart gives you time to update templates, refine your process, or add new deliverables without live clients expecting the old version.

    Open carts work better for low-touch, async, or evergreen products. If someone buys a Notion template, a recorded workshop, or a one-time audit with a two-week turnaround, there’s no operational reason to make them wait.

    How to structure the waitlist without killing momentum

    The failure mode of waitlists is letting interest go cold. Someone signs up in July, you email them in October, and they’ve moved on or forgotten why they cared.

    Successful operators send at least one interim email between signup and cart open. Not a sales pitch—a case study, a free template, or a behind-the-scenes update on what’s changing in the next cohort. The goal is to remind them you exist and prove you’re still improving the offer.

    Pricing also shifts. Operators who run waitlists often raise prices 10–20% compared to what they’d charge with open enrollment, because the exclusivity justifies it and the operational efficiency supports higher per-client value. If you’re spending less time on admin, you can afford to spend more time per engagement.

    One more structural detail: most high-converting waitlists offer early access to the waitlist itself. If general cart-open is Monday at noon, waitlist subscribers get a link Sunday night. That 12-hour window captures the highest-intent buyers and creates a second layer of exclusivity.

    What to track when you switch

    If you’re moving from open cart to cohort-based waitlist, track these four metrics over two cycles:

    • Waitlist-to-purchase conversion rate. Industry average is 15–25% for productized services. If you’re below 10%, your messaging or offer needs work.
    • Time from signup to open. Longer than eight weeks and you’ll lose half your list to attention decay.
    • Client start-to-finish time. Batching should compress this. If it doesn’t, you’re not actually delivering cohort-style.
    • Refund and satisfaction rates. Waitlists attract higher-intent buyers. If refunds don’t drop, the scarcity is cosmetic, not operational.

    The operators who make this work treat the waitlist as a forcing function, not a marketing tactic. It’s not about pretending you’re sold out—it’s about actually limiting capacity so you can deliver better work, faster, without burning out by Thursday.

    If you’re running a productized service and your calendar feels chaotic, try closing enrollment for one quarter. You’ll know in 90 days whether batching improves delivery or just annoyed buyers who wanted instant access.

  • WordPress plugin auto-updates: what breaks when background jobs fail

    WordPress plugin auto-updates are supposed to be set-and-forget. You toggle the setting, and your site stays patched without you logging into the dashboard every Tuesday. Except when the update runs halfway, stalls, and leaves your site in a state that doesn’t throw an error but quietly breaks functionality you won’t notice until a reader emails you three days later.

    This isn’t a rare edge case. It happens because WordPress doesn’t use server cron—it uses WP-Cron, a pseudo-cron system that fires when someone visits your site. If your traffic is low, if your caching is aggressive, or if your hosting provider throttles background requests, WP-Cron jobs can skip, delay, or terminate mid-execution. Auto-updates are one of those jobs.

    How WordPress plugin auto-updates actually run

    When you enable auto-updates for a plugin, WordPress schedules a background task via WP-Cron. Twice daily, it checks for new versions. If an update is available, it triggers a multi-step process: download the new plugin zip, deactivate the old version, extract the new files, reactivate, and run any database migrations the plugin author included.

    Each step depends on the previous one completing. If your server times out, if PHP hits its memory limit, or if WP-Cron doesn’t fire because no one visited your site in the last twelve hours, the process halts. WordPress doesn’t retry. It doesn’t log the failure in your admin dashboard. The plugin shows as the new version number, but the files might be a mix of old and new, or the database schema might still be two versions behind.

    You’ll notice this when a form stops submitting, when an API integration returns a 500 error, or when your members area throws a white screen. The error logs—if your host surfaces them—will show a missing function or a table that doesn’t exist. The plugin version in your dashboard will say 2.8.4, but the actual code running will be 2.8.2 with one updated file.

    What causes background job failures

    Three common scenarios stall WP-Cron-based auto-updates. First: aggressive full-page caching. If every request is served from cache, WP-Cron never fires. Plugins like WP Rocket and hosts like BigScoots often bypass cache for logged-in users, but if you’re not logging in regularly and your traffic is mostly anonymous readers hitting cached pages, your cron jobs can go days without running.

    Second: low memory limits. Shared hosting accounts often cap PHP memory at 128MB or 256MB. Plugin updates—especially for page builders or membership plugins—can exceed that during extraction and activation. The process dies silently, and WordPress moves on.

    Third: server-level request timeouts. If your host enforces a 30-second execution limit and your plugin takes 35 seconds to update, the job terminates before completion. No retry, no notification.

    How to fix this before it breaks your site

    Disable WP-Cron and set up real server cron. Most hosts let you add a cron job in cPanel or via SSH. Add this to your wp-config.php file, above the “stop editing” line:

    define('DISABLE_WP_CRON', true);

    Then create a server cron job that runs every fifteen minutes:
    */15 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

    Replace wget with curl if your server doesn’t have wget installed. This forces WP-Cron to fire on schedule, regardless of traffic.

    Second: increase your PHP memory limit. Add this to wp-config.php:
    define('WP_MEMORY_LIMIT', '512M');

    If your host restricts this, ask support to raise it or switch to a host that gives you control. Most VPS and managed WordPress hosts let you set this yourself.

    Third: monitor plugin update logs. Install a plugin like WP Crontrol to see which cron jobs are scheduled, when they last ran, and whether they completed. If you see wp_update_plugins or wp_maybe_auto_update stuck in the queue for days, your auto-updates aren’t running.

    When to disable auto-updates entirely

    If your site is mission-critical—handling payments, managing memberships, running a course platform—auto-updates introduce risk you don’t need. A plugin author can push a breaking change, and you won’t know until your checkout stops working. Manual updates with a staging site catch this. Auto-updates don’t.

    For solo operators running content sites, auto-updates are convenient if your cron setup is solid. For teams running revenue-dependent infrastructure, the trade-off isn’t worth it. Test updates in staging, deploy during low-traffic hours, and keep auto-updates off for plugins that touch payments, user authentication, or data migrations.

    If you do keep auto-updates enabled, audit your WP-Cron health quarterly. Check that jobs are firing, that memory limits are adequate, and that no plugin updates are stuck half-installed. That ten-minute audit prevents the three-hour debugging session when something silently breaks.

    Want more infrastructure breakdowns? Reply with the hosting or plugin setup that’s giving you trouble—we’ll cover it in a future piece.

  • Stripe connect onboarding: when split-payment setup blocks sellers

    If you’re building a marketplace, course platform with affiliate payouts, or any business that splits revenue between multiple parties, you’ve probably implemented Stripe Connect. And if you’ve watched sellers or partners try to onboard, you’ve seen how often they get stuck.

    The problem isn’t Stripe’s reliability—it’s that Connect has two completely different onboarding paths, and choosing the wrong one for your use case creates friction you can’t fix from your dashboard.

    Custom vs. Express: the split that matters

    Stripe Connect offers two main account types: Custom and Express. Custom accounts let you control the entire onboarding UI and branding, but you inherit full responsibility for collecting tax forms, verifying identity documents, and handling compliance. Express accounts hand that work to Stripe—your sellers see Stripe-branded onboarding, and Stripe manages verification.

    Most solo operators and small teams pick Express because it’s faster to implement. You redirect the seller to a Stripe-hosted form, they fill it out, and Stripe emails them when something’s missing. That works—until it doesn’t.

    The bottleneck shows up when a seller enters information that triggers manual review. Stripe’s automated checks flag certain patterns: mismatched business addresses, high-risk industry codes, or account details that don’t align with public records. When that happens, the seller sees a vague “under review” message, and you see nothing in your Connect dashboard except a pending status.

    Express accounts route all communication through Stripe’s support system, not yours. The seller waits for an email. You wait for the seller to resolve it. If they don’t check spam or if Stripe requests a document they don’t have on hand, onboarding stalls indefinitely. You can’t intervene, because you don’t own the relationship during verification.

    When Custom accounts make sense

    Custom accounts flip the script. You collect every data point yourself—legal business name, tax ID, bank details, beneficial ownership—and send it to Stripe via API. Stripe still runs the same fraud and compliance checks, but all communication routes through your platform.

    That means when a seller’s information gets flagged, you receive the webhook. You decide how to surface the error, what language to use, and whether to let them retry or escalate to support. You control the timeline.

    The tradeoff: you’re building the entire onboarding form. That includes file upload flows for identity documents, logic to handle different entity types (sole proprietor vs. LLC vs. corporation), and state management for multi-step verification. Stripe provides client libraries and examples, but you’re writing and maintaining the UI.

    For a solo operator launching a small marketplace, that’s often overkill. But if your sellers are high-value—coaches charging $2,000 per course sale, affiliates earning four-figure monthly commissions—the ability to unblock them yourself justifies the build time.

    The fields that fail most often

    Three data points cause the majority of Connect onboarding blocks:

    Business address mismatch. If a seller registers as a business entity but enters a residential address that doesn’t match their state’s business registry, Stripe flags it. This happens constantly with sole proprietors using their home address. The fix: let sellers clarify “doing business as” vs. registered entity name before they hit submit, or prompt them to choose “individual” instead of “company” as their account type.

    Bank account ownership. Stripe verifies that the bank account name matches the Connect account’s legal name. If someone registers their business as “Jane Doe Consulting LLC” but links a personal checking account under “Jane Doe,” verification fails. You can’t override this. The seller has to update their bank account or re-register the Connect account with a matching name.

    Missing beneficial ownership data. For any business entity, Stripe requires details on anyone who owns 25% or more of the company. If your onboarding form doesn’t explicitly ask for this upfront, the seller submits, gets approved provisionally, then hits a block weeks later when Stripe’s compliance review catches up. Custom accounts let you enforce this field before submission; Express accounts surface it late.

    What you can do today

    If you’re already using Express accounts and onboarding is slow, audit your redirects. Stripe’s account_onboarding link expires after the seller completes it once. If they need to update information later, you have to generate a fresh link and send it manually. Automate that: listen for account.updated webhooks with requirements.currently_due populated, and email a new onboarding link immediately.

    If you’re starting fresh or rebuilding, evaluate whether your sellers justify Custom accounts. A course platform with 12 high-ticket instructors? Build Custom. A marketplace with 300 low-margin sellers? Stick with Express and accept that 10–15% will get stuck in verification.

    Either way, monitor your capabilities status in the Stripe API. Every Connect account has a transfers capability that can be active, pending, or inactive. If it’s pending for more than 48 hours, surface that in your seller dashboard with specific next steps, not just “contact support.”

    Running a paid newsletter, course, or membership with complex payouts? Reply with your current setup—I’ll cover payout scheduling and transfer timing in an upcoming piece.

  • Traffic attribution breaks when visitors block referrer headers

    Traffic attribution breaks when visitors block referrer headers

    Traffic attribution breaks when visitors block referrer headers
    Photo by Agence Olloweb on Unsplash

    You check your analytics dashboard and see a spike in direct traffic. No campaign, no social bump, no obvious source. Just a flood of visitors showing up as (direct) / (none).

    Except they’re not typing your URL from memory. They’re clicking links—links your analytics can’t see because the browser stripped the referrer header before the page loaded.

    Referrer blocking has gone mainstream. Safari’s Intelligent Tracking Prevention strips referrers by default for cross-site navigation after seven days of inactivity. Firefox Enhanced Tracking Protection does the same. Brave blocks referrers entirely in strict mode. Even Chrome users running privacy extensions like uBlock Origin or Privacy Badger lose referrer data on every click.

    Your traffic reports don’t account for this. They show the symptom—inflated direct traffic—but not the cause. And if you’re running paid campaigns, sponsorships, or guest post strategies, you’re attributing conversions to the wrong source.

    What referrer blocking actually removes

    The document.referrer property tells your analytics where a visitor came from. When it’s blocked or stripped, your tracking script sees an empty string. Google Analytics 4, Plausible, Fathom, and every other client-side analytics tool treats that as direct traffic.

    But referrer blocking doesn’t affect all sources equally. Here’s what still works:

    • UTM parameters: Query strings like ?utm_source=twitter survive referrer blocking because they’re part of the URL itself, not the HTTP header.
    • Internal navigation: Same-origin clicks (e.g., navigating between pages on your own site) usually preserve referrer data, even with strict privacy settings.
    • Paid ad platforms: Google Ads, Facebook Ads, and LinkedIn Campaign Manager append their own tracking parameters (gclid, fbclid, li_fat_id), which bypass referrer headers entirely.

    What breaks:

    • Organic social traffic from privacy-conscious users
    • Links in email clients with privacy proxies (Apple Mail Private Relay, Hey, Proton Mail)
    • Guest post traffic from sites with strict referrer policies
    • Aggregator traffic (Hacker News, Reddit, niche forums)

    If 40% of your audience uses Safari or Firefox—and mobile Safari alone accounts for 25–30% of U.S. web traffic in 2026—you’re underreporting referral traffic by double digits.

    How to measure what’s missing

    Start by isolating suspected misattribution. In Google Analytics 4, create a segment for Session source / medium = (direct) / (none) and filter for sessions longer than 30 seconds with at least one engagement event. Direct visitors who bounce in under 10 seconds might be legitimate (typed URL, bookmark). But direct visitors who spend three minutes reading and click two internal links? They came from somewhere.

    Next, compare your Referral traffic report month-over-month. If referral traffic is declining while direct traffic is rising—and your total traffic is flat or growing—you’re seeing referrer erosion, not a shift in visitor behavior.

    For paid campaigns, cross-reference platform click counts with GA4 session counts. If Facebook Ads Manager reports 1,000 link clicks but GA4 shows 850 sessions with utm_source=facebook, the gap is likely referrer blocking combined with users who bounced before the analytics script fired. A 10–15% gap is normal. Anything above 20% suggests tracking issues.

    Two fixes that actually work

    Force UTM parameters on every external link. If you’re running guest posts, sponsorships, or link exchanges, append UTM tags manually. Don’t rely on the referrer header. A link to yoursite.com becomes yoursite.com?utm_source=partnername&utm_medium=referral. Yes, it’s visible in the URL. No, most readers don’t care.

    For your own outbound links—social media posts, email signatures, bio links—build a URL template and reuse it. Tools like Google’s Campaign URL Builder make this a 30-second task. You can also use link shorteners (Bitly, Short.io, yourownwordpress.com/go links) that auto-append UTM parameters, but remember: every redirect adds latency and another point of failure.

    Switch to server-side tracking for high-value conversions. If you’re tracking newsletter signups, course purchases, or lead magnets, send conversion events from your server, not the browser. When a user submits a form, your backend posts the event directly to GA4’s Measurement Protocol API or your analytics provider’s server-side endpoint.

    This bypasses referrer headers, ad blockers, and privacy extensions entirely. The trade-off: you lose automatic session stitching, so you’ll need to pass a client ID or user ID to connect server-side events to client-side sessions. Most ESPs (Postmark, Brevo, MailerLite) support webhooks that can trigger server-side tracking on email open or click events.

    When to stop worrying about it

    If your business model doesn’t depend on attribution—if you’re running a content site with display ads, or a membership where traffic source doesn’t affect LTV—you can ignore referrer blocking. Your ad network (Mediavine, Raptive, AdThrive) gets paid on impressions, not source accuracy.

    But if you’re buying sponsorships, testing new traffic channels, or splitting revenue with affiliates, referrer blocking costs you money. You’re either over-crediting direct traffic or under-crediting partners, and both skew your ROI calculations.

    Fix your tracking now, before your next campaign launches. Because the one thing worse than missing data is making decisions based on data you think is complete.

    Want more operator-focused breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools, tactics, and infrastructure that actually matter when you’re running a content business solo.

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

  • Google Analytics 4 event limits: when custom tracking stops recording

    Google Analytics 4 event limits: when custom tracking stops recording

    Google Analytics 4 event limits: when custom tracking stops recording
    Photo: Saleemkce via Wikimedia Commons (CC BY-SA 4.0)

    Google Analytics 4 enforces a hard limit of 500 distinct event names per property. Cross that threshold and GA4 stops recording new events entirely—no warning in the interface, no email alert, just silent data loss.

    Most solo operators discover this limit only after noticing gaps in their conversion funnels or realizing a new tracking event never logged a single hit. If you’ve layered on custom events for lead magnets, course enrollments, affiliate clicks, and content upgrades over months or years, you’re closer to the ceiling than you think.

    How the 500-event cap actually works

    GA4 counts every unique event name you send. That includes automatically collected events like page_view and session_start, recommended events like purchase and sign_up, and every custom event you’ve created.

    Once you hit 500, GA4 stops processing new event names. Existing events continue to log normally, but any event name it hasn’t seen before gets dropped. Parameters on existing events still work—so if you send button_click with a new button_id parameter, that logs fine. But a brand-new event called webinar_registration won’t appear anywhere.

    The limit applies at the property level, not per data stream. If you run multiple sites under one GA4 property, all domains share the same 500-event budget.

    Where event bloat comes from

    Three patterns push operators toward the limit faster than expected:

    Plugin-generated events. WordPress analytics plugins, form tools, and membership platforms often fire custom events for every interaction type. Install three plugins that each create 20 events, and you’ve burned through 60 slots without writing a single line of custom code.

    Developer handoffs. A contractor adds tracking for a product launch, then another developer implements event tracking for a new funnel six months later. No one audits what’s already there. Event names proliferate with slight variations—email_signup, email_sub, newsletter_subscribe—each consuming a separate slot.

    Abandoned experiments. You test a new lead magnet, set up tracking, then retire the offer. The event stays in your GA4 property forever, even if it hasn’t fired in a year. GA4 doesn’t archive or expire old event names automatically.

    How to audit your current event count

    GA4 doesn’t surface your total event count in the main interface. To see where you stand, open the Admin panel, navigate to Data display under the Property column, and click Events. Scroll through the list and count manually, or export the table to a spreadsheet.

    Pay attention to events with zero occurrences in the last 30 days—those are prime candidates for archiving. If an event hasn’t fired in three months and isn’t tied to a seasonal campaign, you probably don’t need it.

    Check your GTM container too. Tag Manager configurations often include events that were set up for A/B tests or one-off promotions and never removed. Each orphaned tag still counts against your limit if it ever fires, even once.

    What to do when you’re near the cap

    GA4 lets you mark events as archived, but archiving doesn’t free up slots. Archived events still count toward your 500-event limit—they just stop appearing in some reports. To actually reclaim space, you need to stop sending the event entirely and wait 24 hours for GA4’s backend to recognize it’s gone.

    The better fix: consolidate events using parameters. Instead of creating separate event names like download_ebook_seo, download_ebook_email, and download_ebook_productivity, send a single download_ebook event with a topic parameter. You’ll preserve granular reporting while using one event slot instead of dozens.

    For operators running multi-brand properties, consider splitting into separate GA4 properties. Each property gets its own 500-event limit, and you avoid cross-contamination between unrelated sites. The tradeoff: you lose consolidated reporting and need to manage multiple configurations.

    Before you hit the limit, document your event taxonomy. A simple spreadsheet listing every event name, what it tracks, and which tool or script sends it will save hours of forensic work later. Update it whenever you add new tracking, and review it quarterly to prune dead events.

    If you’re building a new analytics setup or migrating properties, start with a naming convention that uses parameters heavily. It’s easier to prevent event bloat than to clean it up after the fact.

    Spotted a gap in your GA4 setup or hit a tracking limit that cost you data? Reply and tell us—we cover the operational details other newsletters skip.

  • Why Instagram algorithm changes break your scheduling tool

    Why Instagram algorithm changes break your scheduling tool

    Why Instagram algorithm changes break your scheduling tool
    Photo by Solen Feyissa on Unsplash

    If you’ve ever scheduled a week’s worth of Instagram content only to find half of it never posted, you’re not alone. The problem isn’t usually your scheduling tool—it’s the gap between what Instagram rolls out in-app and what their API actually supports.

    Instagram’s public API, which scheduling tools like Publer, Buffer, and Later rely on, typically lags 3–8 weeks behind features released in the native app. When Instagram changes how Reels metadata is handled, how carousel aspect ratios work, or even how location tags are processed, your scheduling tool can’t adapt until the API documentation catches up—and sometimes that documentation arrives with no warning.

    What breaks most often

    Three categories of failures dominate:

    Media format mismatches. Instagram quietly updates supported video codecs, aspect ratio tolerance, or file size caps. Your tool validates the upload based on last month’s spec, the file passes local checks, then fails silently on Instagram’s end. You see “posted” in your dashboard; Instagram returns a 400 error the tool doesn’t surface.

    Feature deprecation. Instagram removes support for a tagging method, a carousel behavior, or a post type. If your tool cached the old API schema, it keeps trying to use the deprecated endpoint. Posts queue, then vanish. No error, no retry.

    Permission scope changes. Instagram periodically tightens what apps can do on your behalf. A scheduling tool that worked yesterday suddenly can’t post Stories or tag products because Instagram revoked a permission tier. You won’t know until you manually check the app.

    How tools handle the lag differently

    Not all scheduling platforms respond the same way when Instagram’s API shifts under them.

    Some tools, like Publer, poll Instagram’s API status endpoints every few hours and disable features preemptively if they detect instability. You’ll see a banner: “Instagram Reels scheduling temporarily unavailable.” It’s annoying, but you know.

    Others keep trying to post using the old method until enough users report failures. By then, you’ve lost days of content. Buffer and Hootsuite both had multi-day outages in March 2026 when Instagram changed how alt text was submitted—neither tool warned users in advance.

    A third group—mostly smaller tools—simply retry failed posts every hour for 24 hours, then give up. If you’re not checking your dashboard daily, you won’t realize anything went wrong until your engagement drops.

    What you can do about it

    First, enable all notifications in your scheduling tool. Most platforms offer email or Slack alerts for failed posts, but they’re off by default. Turn them on.

    Second, cross-reference your scheduled content with Instagram’s actual posting history once a week. Open Instagram, check your grid and Stories archive, compare it to your scheduling dashboard. If something’s missing, investigate immediately—don’t wait for metrics to tell you.

    Third, build a one-day buffer into your publishing calendar. If you’re scheduling content to go live Monday at 9 a.m., finalize it by Friday. That gives you the weekend to catch API issues before they cost you reach.

    Fourth, avoid brand-new Instagram features for at least two weeks after launch. If Instagram releases a new Reel template or sticker type, don’t try scheduling it through a third-party tool yet. The API probably doesn’t support it, and your post will either strip the feature or fail outright.

    When to post manually instead

    Some content types are too fragile to trust to automation right now. If your post includes:

    • Product tags (Instagram’s Shopping API breaks every 6–8 weeks)
    • Multi-image carousels with mixed aspect ratios (API validation is stricter than in-app)
    • Reels with trending audio (third-party tools can’t access Instagram’s licensed music library)

    …schedule a reminder to post manually instead. Yes, it’s slower. But a manual post that works beats a scheduled post that vanishes.

    Instagram’s API will never be as current as the app itself. That’s by design—Meta prioritizes native app features because they drive more ad revenue. Scheduling tools are playing catch-up in a game where the rules change weekly.

    The better you understand that gap, the fewer posts you’ll lose to it.

    Have a question about social scheduling, platform APIs, or workflow tools? Reply to this email—I cover one reader question every Sunday.

    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 model context windows: why 200k tokens doesn’t mean 200k words

    AI model context windows: why 200k tokens doesn’t mean 200k words

    AI model context windows: why 200k tokens doesn't mean 200k words
    Photo: DancingPhilosopher via Wikimedia Commons (CC BY-SA 4.0)

    If you’ve compared AI assistants lately, you’ve seen the context window numbers: 128k tokens, 200k tokens, even a million. The assumption is simple: bigger number means more text. But tokens aren’t words, and the difference costs you planning time, wasted prompts, and truncated outputs when you hit limits mid-task.

    Here’s the operator math you actually need, and when context size stops mattering.

    What a token actually represents

    A token is the smallest unit an AI model processes. In English, one token averages about 0.75 words—or four characters including spaces. That’s a rough average; actual token counts vary by language, punctuation density, and formatting.

    A 200,000-token context window holds approximately 150,000 words of plain English prose. If you’re pasting code, JSON, or heavily formatted text, that number drops. A 10,000-word article with embedded HTML might consume 15,000 tokens.

    Most AI platforms show token counts in their UI. Claude displays input and output token usage in the bottom-right of each conversation. ChatGPT Enterprise and API users see similar breakdowns. If you’re on a free or standard plan without token visibility, assume 1.3–1.5 tokens per word for mixed-format content.

    When context size actually matters

    You’ll hit context limits in three scenarios: long-document analysis, multi-file projects, and iterative editing.

    Long-document analysis is straightforward. If you’re summarising a 40,000-word research report, you need at least 53,000 tokens just for input—plus headroom for your prompt and the model’s response. A 128k-token window gives you margin; a 32k window forces you to split the document and lose cross-section coherence.

    Multi-file projects stack quickly. Pasting three blog drafts (3,000 words each), a style guide (2,000 words), and a content brief (1,500 words) consumes roughly 13,000 tokens before you’ve written a single instruction. If you’re working in Claude Projects or OpenAI’s persistent threads, every message you add stays in context until you hit the ceiling.

    Iterative editing is the silent token drain. Each reply—yours and the model’s—adds to the running total. A 10-turn conversation about rewriting a landing page can burn 30,000 tokens even if the page itself is only 800 words. When you hit the limit, the model drops the earliest messages to make room. If those early messages contained key instructions or reference material, the model’s output quality degrades without warning.

    The non-obvious cost of going wide

    Larger context windows let you load more material, but they don’t guarantee better output. Models perform best when the input is relevant and structured. Dumping six unrelated PDFs into a 200k-token window often produces worse results than curating two directly applicable documents in a 32k window.

    Context size also correlates with cost. Claude’s API charges $3 per million input tokens for Sonnet 3.5 and $15 per million for Opus. A single 150,000-token conversation costs $0.45 in input alone on Sonnet—or $2.25 on Opus. If you’re running dozens of long-context sessions per week, the bill adds up faster than most solo operators expect.

    There’s a practical ceiling, too. Reading and synthesising 150,000 words takes a human hours. If you can’t review the source material yourself, you’re trusting the model’s interpretation without verification. That’s fine for low-stakes summaries; it’s risky for client work, legal documents, or anything you’re publishing under your name.

    How to manage context in real projects

    Start with the smallest viable input. If you’re editing a blog post, paste the post and your edit brief—not your entire content archive. If the model needs more context, you can add it in follow-up messages.

    Use reference documents strategically. Instead of pasting a 50-page brand guide, extract the three sections relevant to your current task: voice, formatting, and example snippets. Reattach the full guide only if the model’s output misses the mark.

    For multi-document work, create a structured index. If you’re analysing five competitor landing pages, paste each page with a clear heading: “Competitor A – Landing Page.” Then ask the model to compare specific elements—headlines, CTAs, pricing tables—rather than requesting a general summary. Narrow questions produce tighter answers and burn fewer tokens per insight.

    In long conversations, periodically summarise and restart. After 15–20 turns, ask the model to summarise decisions and next steps, copy that summary into a new conversation, and continue from there. You’ll lose some nuance, but you’ll avoid the drift that happens when early context gets pushed out of the window.

    When to ignore context size entirely

    If your typical AI tasks are under 5,000 words of input—drafting emails, rewriting headlines, generating social captions—context window size is irrelevant. A 32k-token window gives you 24,000 words of headroom. You’ll never hit it.

    Same goes for structured workflows. If you’re using AI to generate product descriptions from a CSV template, each task is isolated. A 4k-token window is plenty.

    Context windows matter most for operators doing research synthesis, long-form editing, or multi-session projects. If that’s not your work, optimize for model quality and cost instead.

    Want breakdowns like this in your inbox? Subscribe to One Two Three Send for weekly deep-dives on the tools and workflows that actually move online businesses forward.

    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.

  • ConvertKit visual automations trigger twice when tags overlap

    ConvertKit visual automations trigger twice when tags overlap

    ConvertKit visual automations trigger twice when tags overlap
    Photo: Rlistmedia via Wikimedia Commons (CC BY 4.0)

    ConvertKit’s visual automation builder lets you create subscriber journeys triggered by tags, form submissions, product purchases, and other events. It’s more flexible than the older rule-based sequences—but that flexibility introduces a subtle bug that can send duplicate emails to the same subscriber.

    If a subscriber meets more than one entry condition at the same time, they can enter the same automation twice. The platform doesn’t deduplicate entries by default, so a single action can spawn two parallel runs of the same workflow.

    How the overlap happens

    Visual automations accept multiple triggers. You might configure an automation to start when a subscriber gets tagged “Lead Magnet A” or when they submit a specific form. If someone submits that form and your form settings apply the tag automatically, both triggers fire.

    ConvertKit processes each trigger independently. The subscriber enters once via the form trigger, and again via the tag trigger. If your automation sends a welcome email as step one, they receive two copies within seconds of each other.

    This also happens when you use Zapier or API calls to apply tags. If your Zap adds a tag and triggers a webhook that also starts the automation, you’ve created two entry points for the same event.

    Where it breaks workflows

    Duplicate entries don’t just mean duplicate emails. If your automation includes conditional splits, each instance of the subscriber moves through independently. A subscriber in two parallel runs can trigger different paths based on timing—one instance might hit a delay while the other checks a condition immediately.

    This gets worse in automations with wait steps. A subscriber paused for three days in one run might complete a purchase during that window, which your second parallel run detects immediately. Now they’re receiving emails from two conflicting sequences: one treating them as a lead, the other as a customer.

    ConvertKit’s reporting doesn’t surface this clearly. The automation analytics show total entries and completions, but don’t flag when the same email address enters multiple times. You’ll see inflated entry counts without realizing some subscribers are being double-processed.

    How to prevent it

    The safest fix is to use a single trigger per automation. If you need multiple entry points, create separate automations for each and funnel subscribers into a shared tag-based sequence after the initial step.

    Alternatively, add a filter at the start of your automation that checks for an exclusion tag. The first action in your workflow applies a tag like “Automation-Started-Welcome-Series,” and the entry conditions exclude anyone who already has that tag. This blocks the second parallel run before it sends anything.

    You can also audit your form settings and Zapier workflows. If a form already triggers an automation, don’t also apply a tag that serves as a separate trigger for the same workflow. Pick one mechanism and stick with it.

    For API users, check whether your webhook handler and tag application both fire automations. If you’re using ConvertKit’s subscriber tagging endpoint, make sure your webhook doesn’t also trigger on that tag event unless you’ve built in deduplication logic on your end.

    What ConvertKit could do

    Other platforms like ActiveCampaign and Drip deduplicate automation entries by default. If a contact is already active in an automation, a second trigger either gets ignored or restarts the sequence from the beginning—your choice via a setting.

    ConvertKit doesn’t offer this. The visual builder treats each trigger as independent, with no native deduplication toggle. You can request it via their feature feedback form, but as of September 2026, it’s not on the public roadmap.

    Until then, the workaround is manual: simplify your triggers, use exclusion tags, and test every automation with a real subscriber before turning it on for your full list.

    Have you hit this issue in ConvertKit or another platform? Reply and let me know how you solved it—I’ll share the best workarounds in a follow-up.

  • Newsletter double opt-in: when confirmation emails cost you 40% signup loss

    Newsletter double opt-in: when confirmation emails cost you 40% signup loss

    Newsletter double opt-in: when confirmation emails cost you 40% signup loss
    Photo by Stephen Phillips – Hostreviews.co.uk on Unsplash

    Every newsletter platform offers double opt-in as a setting. Most treat it as a deliverability best practice. Some operators swear by it. Others disable it immediately and never look back.

    The truth is more nuanced: double opt-in trades signup volume for list quality, and the cost is steeper than most operators realize.

    What double opt-in actually does

    Single opt-in adds an email address to your list the moment someone submits the form. Double opt-in sends a confirmation email first, requiring the subscriber to click a verification link before they’re added.

    The intent is defensible: it blocks typos, spam traps, and fake signups. It proves the address is real and the owner consented. ISPs like Gmail and Outlook treat double opt-in lists more favorably because confirmed subscribers complain less and engage more.

    But here’s the friction cost: industry averages show 30–50% of people who submit a signup form never click the confirmation link. That’s not because they changed their mind—it’s because the email landed in spam, they closed the tab, or they got distracted. You lose nearly half your signups to inbox logistics.

    When double opt-in makes sense

    If you’re running paid traffic to a lead magnet, double opt-in is expensive. You’re paying per click, and half those clicks evaporate before they become subscribers. The math gets worse if your cost-per-lead is above $2.

    Double opt-in works better when:

    • You’re in a high-regulation jurisdiction (GDPR-heavy EU markets treat double opt-in as safer legal ground)
    • Your content attractsbot traffic or low-intent freebie hunters
    • You’re sending high-frequency emails and need engaged subscribers who won’t mark you as spam
    • Your list monetization depends on open rates or click-through performance, not raw size

    Platforms handle the setting differently. Beehiiv defaults to single opt-in but lets you toggle double opt-in per form. MailerLite offers both, with double opt-in recommended for EU-based audiences. Brevo enforces double opt-in for free-tier accounts but allows single opt-in on paid plans once your sender reputation is established.

    What the confirmation email reveals

    If you enable double opt-in, the confirmation email becomes your first deliverability test. If 60% of confirmation emails never get clicked, check your sending domain’s SPF and DKIM records—those subscribers might not be ignoring you; they might never have seen the message.

    Postmark, which handles transactional email and small-volume newsletters, publishes delivery stats by mailbox provider. Confirmation emails to Gmail addresses see 92–96% inbox placement when authentication is correct. Yahoo and Outlook sit closer to 85–88%. If your confirmation rate is below 50%, it’s not a subscriber problem—it’s a delivery problem.

    One fix: customize the confirmation email subject line. Default text like “Please confirm your subscription” gets filtered aggressively. Try something specific to your content: “Your [Topic] guide is one click away” performs better because it reminds the reader why they signed up.

    The hybrid approach

    Some operators split the difference: single opt-in for organic traffic, double opt-in for paid. Most platforms don’t support conditional opt-in logic natively, but you can approximate it by creating separate forms with different settings.

    Another tactic: enable single opt-in, but send a welcome email immediately with a soft call to action—”Reply and tell us what you want to read about.” Replies signal engagement to ISPs almost as effectively as a confirmation click, and you get qualitative feedback in the process.

    If you’re optimizing for subscriber count and you trust your traffic sources, single opt-in wins. If you’re optimizing for engagement metrics and long-term deliverability, double opt-in pays off over six months. There’s no universal answer, but the 40% conversion penalty is real, and it’s worth measuring in your own signup flow before you commit.

    Have a question about newsletter setup, deliverability, or platform quirks? Reply to this email—operator questions shape future articles.

    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 multisite network admin: when one dashboard controls fifty sites

    WordPress multisite network admin: when one dashboard controls fifty sites

    WordPress multisite network admin: when one dashboard controls fifty sites
    Photo by Team Nocoloco on Unsplash

    WordPress multisite lets you run dozens—or hundreds—of sites from a single installation. One database, one set of core files, one admin login that controls everything. It’s how WordPress.com hosts millions of blogs, and it’s available in every self-hosted WordPress install.

    But the network admin dashboard isn’t just a beefed-up version of the regular WordPress admin. It works differently, exposes different controls, and introduces failure modes you won’t encounter on a single site. If you’re running multiple content sites, client projects, or testing environments, understanding what network admin actually does will save you hours of troubleshooting.

    What network admin controls (and what it doesn’t)

    When you enable multisite, WordPress splits its admin interface into two layers. Each site still has its own dashboard where editors manage posts, pages, and basic settings. The network admin sits above that, accessible only to super admins, and controls infrastructure shared across all sites.

    From the network admin dashboard, you can:

    • Add, delete, archive, or mark sites as spam
    • Install plugins and themes once, then enable them selectively per site
    • Create new users with network-wide access or restrict them to specific sites
    • Configure domain mapping, so different sites answer to different domains
    • Set upload limits, storage quotas, and permitted file types globally

    You cannot directly edit another site’s content from network admin. To publish a post on Site B, you still need to switch to Site B’s dashboard. Network admin is about infrastructure and permissions, not day-to-day content operations.

    Plugin and theme activation works in two steps

    On a single WordPress site, you install a plugin and activate it. Done. On multisite, installation and activation are separate, and both require network admin access.

    First, you network-install the plugin—uploading it or pulling it from the repository. At this stage, it’s dormant. No site can use it yet. Then you either network-activate it (turning it on for every site instantly) or enable it per-site, letting individual site admins activate it themselves.

    This two-step design prevents rogue site admins from installing code network-wide. It also means you can test a plugin on one site before rolling it out. But it introduces a common mistake: activating a plugin on one site, seeing it work, then wondering why it’s missing on Site #7. You have to check both the network plugins page and each site’s plugins page to know what’s actually running.

    Themes work the same way. Network-enable a theme, and it appears in every site’s theme picker. If you don’t enable it, site admins won’t see it at all—even though the files are physically installed.

    When multisite makes sense (and when it’s overkill)

    Multisite shines when you’re running multiple sites that share the same plugin stack, user base, or design system. Examples:

    • A media company publishing five topical sites under different domains
    • An agency managing client sites from one hosting account
    • A solo operator running separate content brands that share backend infrastructure
    • A staging/production split where both environments live in one installation

    Multisite is not a good fit if your sites need fundamentally different plugins, have separate user bases with no shared logins, or require independent backups and update schedules. In those cases, separate WordPress installs—each with its own database and admin—are simpler to manage and easier to migrate or sell later.

    Multisite also complicates hosting. Not every managed WordPress host supports it. Those that do often charge more, because resource limits (disk, CPU, database queries) now apply to the entire network rather than one site. If Site #3 gets traffic-spiked and maxes out your database connection pool, every site in the network slows down.

    The non-obvious tip: use subdirectory mode unless you control DNS

    When you set up multisite, WordPress asks whether new sites should use subdomains (site2.example.com) or subdirectories (example.com/site2). Both work, but subdirectories are far easier to manage unless you already have wildcard DNS and SSL configured.

    Subdomain mode requires a wildcard DNS A record pointing *.example.com to your server, plus a wildcard SSL certificate (or a host that auto-provisions Let’s Encrypt certs per subdomain). If you don’t control DNS—say, you’re on a shared host or using a domain registrar with limited DNS editors—subdomain mode breaks. New sites won’t resolve, and you’ll chase certificate errors for hours.

    Subdirectory mode just works. No DNS changes, no SSL gymnastics. The tradeoff: URLs look less independent. But if you’re running a network for operational efficiency rather than separate brand identity, subdirectories save you a week of troubleshooting.

    WordPress multisite isn’t a feature most operators need. But if you’re managing more than three sites with overlapping workflows, it’s worth the learning curve—just expect to spend a day reading documentation before your first network goes live.

    Got a question about WordPress infrastructure or any other online-business tool? Reply to this email—I answer every one, and reader questions often become future articles.

Powered by CookieAdmin