One Two Three Send

Author: onetwothreeadmin

  • ConvertKit creator profiles: when public URLs help and when to hide them

    ConvertKit creator profiles: when public URLs help and when to hide them

    ConvertKit creator profiles: when public URLs help and when to hide them
    Photo by Kit (formerly ConvertKit) on Unsplash

    ConvertKit assigns every account a public creator profile by default. It lives at convertkit.com/creators/your-username, displays your name, bio, subscriber count (if you allow it), and links to your newsletter and products.

    Most operators don’t know it exists until someone finds it through search or the ConvertKit creator directory. Whether that’s helpful or harmful depends on what you’re building and how you talk about your list size.

    What the profile shows and where it appears

    The profile page includes your account display name, a short bio (pulled from your account settings), your subscriber count (optional), and any public forms or products you’ve published. ConvertKit indexes these pages in its own creator directory, and Google indexes them too.

    If you’ve enabled the subscriber count display, the number updates in near-real-time. That’s useful if you want social proof — “Join 12,483 readers” — but problematic if you’re pitching sponsors with inflated figures or prefer to keep growth private.

    The profile also surfaces every public landing page and form you’ve created. If you’ve launched a lead magnet, a product page, or a public archive, those URLs appear here. Retired campaigns stay visible unless you archive or delete the form.

    When public profiles help

    If you’re building in public or want organic discovery, the profile acts as a lightweight portfolio. Other ConvertKit users browsing the directory can find you by topic, and the page ranks for branded searches (your name plus “newsletter” or “ConvertKit”).

    It’s also a clean fallback link for podcast bios, Twitter profiles, or guest-post bylines when you don’t want to send people directly to a landing page. The profile gives context without forcing a signup decision immediately.

    Some operators use the subscriber count as a trust signal. If you’re at 5,000+ subscribers and competing for attention in a crowded niche, showing the number can differentiate you from newcomers. Just be prepared for that number to become your public baseline — it’s harder to hide later if growth stalls.

    When to turn it off

    Go to Settings → Public profile in your ConvertKit dashboard (checked November 2026). You can disable the entire profile or just hide the subscriber count.

    Turn it off if:

    • You’re pitching sponsors and don’t want them cross-checking your claimed list size against a public number.
    • You run multiple projects under one ConvertKit account and don’t want them visibly linked.
    • You’ve archived old landing pages or lead magnets and don’t want them resurfacing in search results.
    • You’re in a competitive niche and prefer not to telegraph your audience size to competitors.

    Disabling the profile removes it from the ConvertKit directory and blocks the public URL. Google may take a few weeks to drop the cached page, but it won’t re-index once the profile is private.

    The non-obvious detail: landing page visibility

    Even if you disable your creator profile, individual ConvertKit landing pages remain public and indexed unless you manually set them to private or delete them. The profile just aggregates them in one place.

    If you’ve launched a one-time lead magnet, promoted it, then moved on, that page is still live and findable. Check your Forms & Landing Pages list in ConvertKit and archive anything you’re no longer promoting. Archived forms stop accepting signups but don’t disappear from search immediately — you’ll need to wait for Google to drop them, or redirect the URL if you control a custom domain.

    This matters most if you’ve tested multiple hooks, offers, or positioning statements. A public profile or indexed landing page can contradict your current messaging, especially if you’ve pivoted topics or renamed your newsletter.

    If you want one central place for people to find you — and you’re comfortable with transparency around list size and past campaigns — leave the profile on. If you prefer control over what’s public and when, disable it and manage landing-page visibility manually.

    Got a ConvertKit setup question or a feature you’d like explained? Reply to this email — we’ll cover it in a future issue.

  • Productivity tool trial periods: what resets when you re-signup

    Productivity tool trial periods: what resets when you re-signup

    Productivity tool trial periods: what resets when you re-signup
    Photo: Matheus Ujacov via Wikimedia Commons (CC BY-SA 4.0)

    You burned through a seven-day trial, didn’t convert, and now—three months later—you want another look. Maybe the tool added a feature you need, or your workflow changed. The question: does a new email address get you a fresh trial, or will the platform recognise you and block it?

    The answer depends on how the vendor tracks identity, what data survives account deletion, and whether their trial logic keys off email, payment method, browser fingerprint, or IP address.

    What most platforms use to detect repeat trials

    Email address is the first line of defence. If you sign up again with the same address, most tools either block the trial outright or auto-convert you to a paid account at checkout. A few—like Notion and Airtable—let you start a new workspace under the same email, but trial eligibility still ties to the account, not the workspace.

    Payment method comes next. Stripe and PayPal pass a fingerprint to the vendor when you add a card, even during a trial. If you delete your account, sign up with a new email, but attach the same card, platforms like Canva and later-stage SaaS tools often flag it. According to Stripe’s card-testing prevention docs (checked November 2026), fingerprinting is standard for fraud prevention, and vendors can query it during signup flows.

    Browser fingerprint and IP address matter less than they used to. Privacy features in Safari and Firefox degrade fingerprinting accuracy, and dynamic IPs mean casual users rotate addresses weekly. A few high-ticket B2B platforms still log IP ranges during trial signup, but it’s rare among prosumer tools.

    What resets when you delete an account

    Content and configuration always go. Workflows, templates, uploaded files, and integrations disappear when you delete an account. GDPR and CCPA require vendors to purge personal data within 30–90 days of a deletion request, and most platforms process it faster to avoid liability.

    Trial eligibility usually does not reset. Even after deletion, your email and payment fingerprint remain in a tombstone record—enough metadata to prevent a second trial, but not enough to reconstruct your account. This is explicit in Airtable’s account-deletion policy (checked November 2026): “deleting your account does not make you eligible for another free trial.”

    Usage logs and billing history stick around longer. Even if your account is gone, the vendor keeps transaction records for tax and compliance. Stripe retains dispute-related data for up to ten years, and that includes trial-start timestamps tied to your card fingerprint.

    When a new email actually works

    If you use a different email and a different payment method (or skip adding a card until after the trial), most tools treat you as a new user. Disposable email services and plus-addressing ([email protected]) rarely fool the platform—most vendors normalise addresses and strip plus-suffixes before checking eligibility.

    A few platforms—particularly open-source-adjacent SaaS like Plausible Analytics and Fathom—don’t enforce trial limits at all. They rely on honour-system conversions and let you spin up multiple trials across different emails without friction. This is less common in 2026 than it was two years ago, as more bootstrapped tools tighten signup flows to improve conversion.

    What to do instead of chasing a second trial

    Ask for an extension. If you hit the trial wall mid-project, most support teams will add three to seven days if you reply to their onboarding emails and explain what you’re testing. This works better with smaller vendors than with public companies, but it’s worth one email.

    Check for seasonal promotions. Tools often reopen trial eligibility or offer discounted first months during Black Friday, year-end, or product launches. If you’re on their mailing list post-trial, you’ll hear about it.

    Use the free tier if one exists. Notion, MailerLite, and Airtable all offer permanent free plans that let you evaluate core features without a countdown. You lose advanced functionality, but you can test workflows and decide whether to pay before the clock starts.

    One non-obvious tip: if you’re comparing tools and know you’ll need multiple trials, use a password manager to generate a fresh identity (email, card, address) for each vendor. This isn’t about gaming the system—it’s about isolating each trial so you can evaluate honestly without cross-contamination from previous signups or cached payment methods.

    If you’ve hit a trial wall on a tool you actually need, reply and tell us which one. We’ll tell you whether an extension is likely or whether the free tier covers your use case.

  • Stop building traffic when you should be building attention

    Stop building traffic when you should be building attention

    Stop building traffic when you should be building attention
    Photo: U.S. Army Corps of Engineers Savannah District via Wikimedia Commons (Public domain)

    Most solo operators treat traffic as the win. You hit 10,000 monthly visitors, you celebrate. You double sessions, you tweet the screenshot. But traffic without attention is noise—and noise doesn’t convert, compound, or build businesses.

    The operators who grow sustainable online businesses optimise for a different metric: how long people stay, and whether they come back. That’s attention. And attention, not traffic, is what turns readers into subscribers, customers, and word-of-mouth.

    Traffic measures exposure; attention measures engagement

    A pageview tells you someone landed. It doesn’t tell you they read, clicked, scrolled, or remembered. You can drive 50,000 visitors from a viral Reddit thread and convert zero—because those visitors spent eight seconds skimming before bouncing.

    Attention is the sum of time on page, scroll depth, return visits, and actions taken. It’s harder to juice with tricks, and that’s exactly why it matters. If your average session duration is under 30 seconds and your return-visitor rate is below 10%, you don’t have an audience—you have a revolving door.

    Operators who chase traffic tend to optimise for headlines that bait clicks, topics that trend for a week, and distribution channels that send drive-by traffic. Operators who chase attention write fewer posts, go deeper, and focus on channels—email, RSS, bookmarks—that select for people who actually want to hear from them again.

    Compounding works on attention, not visits

    Traffic is linear. If you stop publishing or promoting, it falls. Attention compounds. A reader who spends 12 minutes on your site today is more likely to subscribe, more likely to return unprompted, and more likely to share your work with someone who’ll do the same.

    That compounding shows up in metrics most operators ignore: direct traffic as a percentage of total visits, subscribers per post, and repeat purchase rate. These numbers grow slowly, but they grow even when you take a week off—because they’re driven by memory and habit, not algorithmic distribution.

    If you’re running a content business, your goal isn’t to rank for every keyword or go viral every month. It’s to build a group of people who check in without being reminded. That only happens if the experience of reading you is worth repeating.

    What optimising for attention looks like in practice

    It means saying no to most traffic opportunities. You skip the listicle that’ll rank well but that nobody will finish. You turn down the guest-post swap that’ll send 500 visitors who leave in six seconds. You stop splitting one good idea into five thin posts just to hit a publishing cadence.

    Instead, you publish when you have something worth someone’s 10 minutes. You use subheadings, examples, and specifics—because readers skim first, and attention is earned in the first three paragraphs. You link to your own archive when it’s relevant, training people to treat your site as a library, not a feed.

    You also choose distribution channels differently. A Facebook link post might send 2,000 visits with a 12-second average session. An email to 400 subscribers might send 120 visits with a four-minute average. The second group is worth more—because they’re paying attention, and that attention transfers to the next thing you make.

    This doesn’t mean traffic is irrelevant. It means traffic is the input, and attention is the filter. If 100 people visit and 80 read to the end, you learn what’s working. If 10,000 visit and eight read to the end, you learn you’re optimising the wrong thing.

    Measure what actually predicts revenue

    Look at your analytics. Sort posts by pageviews, then sort them by average time on page. The gap between those two lists is the gap between what you’re chasing and what’s working.

    For most online businesses, the posts with the longest session durations are the ones that drive email signups, product sales, and inbound opportunities—even if their traffic numbers are modest. That’s because the people who finish those posts are the ones who trust you enough to take the next step.

    If you want to grow a business that doesn’t depend on the algorithm’s mood or the next platform shift, stop celebrating traffic spikes and start tracking how many people come back. Build less for the crowd and more for the people who’ll remember you tomorrow.

    One Two Three Send is written for operators building content businesses that compound. Subscribe to get one focused article every day—no fluff, no filler, just the tools and tactics that matter.

  • Google Business Profile scheduling: when posts disappear early

    Google Business Profile scheduling: when posts disappear early

    Google Business Profile scheduling: when posts disappear early
    Photo by Firmbee.com on Unsplash

    Google Business Profile lets you schedule posts up to a year in advance. What it doesn’t tell you: most post types expire automatically after seven days, whether you scheduled them for longer or not.

    If you’re using Business Profile posts to drive traffic to your newsletter landing page, product launch, or time-sensitive content, you need to know when Google pulls the rug out.

    The seven-day expiration wall

    Standard posts—updates, news, anything that isn’t an Offer or Event—live for exactly seven days from publication. Google counts from the moment the post goes live, not from when you hit schedule.

    Schedule a post on Monday for Thursday publication? It dies the following Thursday. You don’t get a warning. It just drops off your profile.

    Google documents this in the Business Profile Help pages (checked November 2026), buried three paragraphs into the post-type definitions. Most scheduling interfaces don’t surface the expiration date at all—you see “Scheduled for Nov 14” but no “Expires Nov 21.”

    Event and Offer posts follow their own clocks

    Event posts expire when the event end date passes. Set an event for November 15–17, and the post vanishes at midnight on the 18th, regardless of when you published it.

    Offer posts expire on the date you specify in the offer-end field. Google requires an end date; you can’t leave it open. Maximum duration is one year from creation.

    Both post types let you control longevity, but only if you structure your content as an event or offer. A standard “We published a new guide” post gets seven days no matter what.

    What this means for content campaigns

    If you’re running a two-week launch, don’t schedule one Business Profile post on day one and expect it to carry you through. You’ll go dark after seven days.

    Instead, schedule a sequence: one post on launch day, another on day six, a third on day twelve. Treat Business Profile like a feed that needs regular refresh, not a billboard you set once.

    For evergreen content—newsletter signup pages, course landing pages, resource hubs—Business Profile posts are the wrong tool. They’ll expire while the page is still live, and you’ll either manually re-post every week or let the profile go stale.

    Better evergreen options: the website link in your profile header (permanent), the Services section (persistent until you remove it), or a pinned post on your linked social accounts.

    How to check what’s live and what’s expired

    The Business Profile dashboard shows scheduled posts under the Posts tab, but expired posts disappear from the public view without moving to a visible archive. You won’t see “Expired – Nov 3” in your list; you’ll just see fewer posts than you remember scheduling.

    To audit what’s actually visible to searchers, open an incognito window, search your business name, and scroll through the posts carousel in the Knowledge Panel. Compare that to your scheduled list in the dashboard. Anything missing has already expired.

    If you manage multiple profiles or schedule in batches, set a calendar reminder for six days after each post goes live. Check whether it’s still pulling traffic in Google Search Console (filter by landing page URL if you’re linking to a specific page). If it is, queue the next post. If it’s not, stop wasting the effort.

    Scheduling tools don’t fix the expiration

    Third-party tools like Publer and Buffer let you schedule Business Profile posts alongside your other social content. They push the post to Google on the date you choose, but they don’t extend the seven-day lifespan.

    Some tools let you set up recurring posts—publish the same update every Monday, for instance. That works around the expiration by treating each week as a new post, but you’re still refreshing manually (or paying the tool to refresh for you).

    No tool can override Google’s post-type rules. If you schedule a standard post, it dies in seven days whether you used the native interface or a third-party dashboard.

    Want to see which of your traffic sources actually convert? Subscribe to One Two Three Send for breakdowns of the tools and tactics that move the needle for solo operators and small teams.

    The seven-day window isn’t a bug. It’s Google pushing you to keep the profile active. If you can’t commit to weekly posts, use the permanent sections—Services, Products, website link—and skip the feed entirely. A stale post history signals neglect just as much as no posts at all.

    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 plugin auto-updates: when to enable and when to pause

    WordPress plugin auto-updates: when to enable and when to pause

    WordPress plugin auto-updates: when to enable and when to pause
    Photo by Souvik Banerjee on Unsplash

    WordPress added per-plugin auto-update toggles in version 5.5, giving operators granular control over what updates while they sleep and what waits for manual approval. The feature sits quietly in the plugin list, easy to miss—but using it correctly can prevent broken checkout pages, missing forms, and late-night rollback sessions.

    Most solo operators treat auto-updates as binary: all on or all off. That leaves money on the table. The right approach is selective, based on each plugin’s role and the vendor’s track record.

    How the feature works

    Each plugin row in your WordPress dashboard includes an “Enable auto-updates” link. Toggle it on, and WordPress checks twice daily for new versions and installs them without intervention. The core system sends an email notification after each auto-update completes, listing what changed and linking to the changelog (checked November 2026, WordPress.org plugin documentation).

    Auto-updates run during the standard WordPress cron cycle, typically in low-traffic hours if your server respects the schedule. If an update fails mid-install, WordPress attempts to roll back to the previous version and logs the error. It doesn’t always succeed—especially if the failure involves database schema changes.

    The feature works independently of theme auto-updates and core auto-updates. You can run all three, none, or any combination.

    Which plugins to auto-update

    Enable auto-updates for plugins that meet all three criteria: low site-integration complexity, frequent security patches, and a vendor with a clean deployment history.

    Security and anti-spam plugins top the list. Akismet, Wordfence, and similar tools release patches within hours of discovering new attack vectors. Waiting even a day to manually update exposes your comment forms and login pages. These plugins rarely touch your theme or content rendering, so breakage risk stays low.

    Performance and caching plugins are the opposite. A caching plugin update can silently break CSS delivery, JavaScript execution, or CDN purging. If you run WP Rocket, W3 Total Cache, or similar, keep auto-updates off and test each release on a staging site first. The performance gain from a new version rarely justifies the risk of a broken front-end during a product launch.

    Page builders and form plugins sit in the middle. Elementor, WPForms, and Gravity Forms push updates often, and most are stable—but a bad release can take your lead-capture forms offline or scramble post layouts. If your business depends on a single landing page or checkout flow, disable auto-updates and schedule manual testing weekly. If you run dozens of pages and can tolerate occasional layout shifts, auto-updates save time.

    SEO and analytics plugins—Yoast, Rank Math, MonsterInsights—are safe to auto-update unless you’ve customised their output with filters or hooks. They touch metadata and tracking scripts, not front-end rendering, so breakage is rare. The exception: if you’ve hard-coded schema markup or custom Open Graph tags that conflict with plugin defaults, test updates manually.

    One non-obvious trick: auto-update only after vendor testing

    Many plugin vendors release updates in waves. They push to a small percentage of installs first, monitor error reports for 24–48 hours, then roll out globally. If you enable auto-updates, you’re in the first wave by default.

    To stay in the second wave—where critical bugs have already been patched—leave auto-updates off and manually update three days after a release appears in your dashboard. Check the plugin’s WordPress.org support forum or changelog for version increments like 3.2.1 following 3.2.0. If you see a point-release within 72 hours, the initial version had issues.

    For mission-critical plugins, subscribe to the vendor’s release notes via RSS or email. Most publish a changelog feed at pluginname.com/changelog or link it from their WordPress.org page. Skim each update summary before toggling auto-updates back on.

    When auto-updates cause problems

    Two failure modes happen often enough to plan for: email notification fatigue and silent cron failures.

    If you run fifteen plugins with auto-updates enabled, you’ll receive fifteen separate emails each time WordPress checks for updates—sometimes multiple per day if vendors release patches quickly. The volume trains you to ignore the messages, so you miss the one notification warning that a payment plugin failed to update and left your checkout broken. Consolidate auto-update notifications by filtering them into a dedicated email folder and reviewing it once weekly, or disable the emails entirely and check the plugin list manually.

    Silent cron failures happen when your hosting provider disables WordPress’s built-in cron and replaces it with a server-level cron job that doesn’t fire reliably. Auto-updates queue but never execute. Check your wp-config.php file for the line define('DISABLE_WP_CRON', true);—if present, confirm your host has configured a replacement cron job at wp-cron.php and that it runs at least twice daily (checked November 2026, WordPress developer cron documentation).

    If you’re running WordPress on BigScoots or a similar managed host, ask support to confirm cron job frequency before relying on auto-updates for time-sensitive security patches.

    One last thing: We publish a new operator-focused guide like this one every day. Subscribe to One Two Three Send to get tomorrow’s in your inbox.

  • Beehiiv Ad Network revenue share: what you keep and when you qualify

    Beehiiv‘s Ad Network promises hands-off sponsorship revenue: they sell the ads, you run them in your newsletter, and you both split the money. For operators who don’t want to cold-pitch sponsors or negotiate rates, it’s a clean trade. But the economics only make sense if you understand the split, the qualification bar, and the payout timing.

    The revenue split and what Beehiiv keeps

    Beehiiv keeps 25% of gross ad revenue; you receive 75%. That split applies to all ad placements served through the network, whether display ads in the body or sponsored content blocks. The figure is published on Beehiiv’s Ad Network page (checked November 2026).

    If an advertiser pays Beehiiv $1,000 for a campaign that runs in your newsletter, you receive $750. Beehiiv handles sales, creative approval, and insertion—your share arrives net of their commission.

    That 25% covers more than platform overhead. Beehiiv’s ad-sales team pitches brands, negotiates CPMs, and manages campaign delivery. For operators who lack a media kit or sponsor pipeline, the commission buys distribution you wouldn’t otherwise capture. For operators who already sell sponsorships direct, the trade-off is less attractive: you’re paying for sales work you can do yourself.

    Eligibility threshold and approval process

    You need at least 1,000 subscribers to apply for the Ad Network. Beehiiv reviews your content, audience, and engagement before approval; meeting the subscriber minimum doesn’t guarantee entry. The threshold is documented in Beehiiv’s support article on Ad Network eligibility (checked November 2026).

    Once approved, ad inventory depends on demand. Beehiiv doesn’t guarantee fill rate—some newsletters see ads every issue, others see sporadic placements. Ad type, vertical, and audience geography all influence match rate. A B2B SaaS newsletter with U.S. readers will see more inventory than a hobbyist cooking list with global traffic.

    If your newsletter qualifies but ad demand is low, revenue can be negligible for months. The network works best for operators who treat it as incremental income, not primary monetisation.

    Payout timing and minimum balance

    Beehiiv pays Ad Network earnings monthly, 30 days after the end of the month in which ads ran. Ads served in November are paid in late December. There’s a $10 minimum payout threshold; balances below that roll forward to the next month. Payment details are outlined in Beehiiv’s Ad Network payment support page (checked November 2026).

    That delay matters if you’re relying on ad revenue to cover operating costs. A campaign that runs in your newsletter today won’t deposit for six to eight weeks. For operators used to Stripe payouts or direct sponsor invoices that clear in days, the lag is a cash-flow adjustment.

    Payments arrive via the method you set in your Beehiiv account settings—typically bank transfer or PayPal. International operators may face currency-conversion fees depending on the payout method and receiving bank.

    When the Ad Network makes sense

    The network works when your time is worth more than the 25% commission. If you’re a solo operator publishing three newsletters a week and don’t want to spend hours pitching sponsors, the trade is efficient. You forfeit a quarter of gross revenue but reclaim the hours you’d spend on sales calls, rate negotiation, and creative back-and-forth.

    It works less well when you already have sponsor relationships or a predictable pipeline. Direct deals let you keep 100% of revenue and negotiate terms—ad placement, creative format, exclusivity—that networks can’t offer. Once your list crosses 5,000 subscribers and you’re fielding inbound sponsor interest, the economics tilt toward direct sales.

    The network also struggles in niches with thin advertiser demand. If your audience is narrow or non-commercial—say, literary fiction or municipal policy—fill rates will be low. Beehiiv’s ad marketplace skews toward categories with established ad spend: tech, finance, e-commerce, productivity.

    Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and tactics that power online businesses.

    One non-obvious detail: ad creative approval

    Beehiiv reviews advertiser creative before it runs in your newsletter, but you retain veto rights. If an ad doesn’t align with your editorial standards or audience expectations, you can reject it. That approval step is buried in the onboarding flow; many operators assume ads run automatically once they join the network.

    Use the veto. A mismatched ad—crypto pitches in a parenting newsletter, or aggressive upsells in a calm, minimalist publication—damages reader trust faster than the revenue compensates. The 75% you keep only compounds if your list stays engaged.

    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 assistant system prompts: where to store them and when to version

    AI assistant system prompts: where to store them and when to version

    AI assistant system prompts: where to store them and when to version
    Photo by Zulfugar Karimov on Unsplash

    Most solo operators write a good system prompt once, paste it into an AI chat window, get decent output for a week, then watch quality slide. The prompt drifts—small edits pile up, context bloats, and nobody remembers what the original instruction said. Six months later, you’re debugging output without knowing which version of the prompt produced it.

    System prompts deserve the same version control and storage discipline you give code or design assets. Here’s how to store them, when to version, and what breaks when you don’t.

    Store prompts as plain text files, not chat history

    Chat interfaces are ephemeral. Claude, ChatGPT, and other web UIs don’t guarantee indefinite history retention, and searching old threads for “that prompt that worked in July” wastes time. Worse, you can’t diff two versions of a prompt buried in separate chat sessions.

    Store system prompts as .txt or .md files in a dedicated folder. Name them by function: newsletter-intro-rewriter.txt, seo-meta-description.txt, customer-support-tone.txt. Keep them in Dropbox, Google Drive, or—better—a Git repository if you’re comfortable with version control.

    Plain text beats proprietary formats. You can grep, diff, and copy-paste without fighting file locks or platform-specific editors.

    Version prompts when output quality shifts

    Not every tweak needs a new version. If you fix a typo or tighten wording without changing intent, overwrite the file. But version the prompt when:

    • You change the task scope (e.g., adding competitor analysis to a product-description prompt)
    • You adjust tone or output length significantly
    • You switch models or providers (a prompt tuned for GPT-4 may underperform on Claude, and vice versa)
    • You notice output quality degrade and need to roll back

    If you’re using Git, commit with a meaningful message: git commit -m "Tightened newsletter-intro prompt: removed redundant context about audience size". If you’re not using Git, append a date or version number to the filename: newsletter-intro-v2-2026-11.txt.

    Versioning lets you A/B test. Run the same input through two prompt versions, compare output, and keep the winner. Without versions, you’re guessing which change caused the improvement—or the regression.

    Tag prompts with model and temperature settings

    A prompt is only half the recipe. The model, temperature, max tokens, and other parameters matter just as much. Store those settings alongside the prompt text, either in a header comment or a separate metadata file.

    Example header inside newsletter-intro-rewriter.txt:

    # Model: Claude 3.5 Sonnet (checked November 2026)
# Temperature: 0.7
# Max tokens: 500
# Last updated: 2026-11-09

You are an editor for a newsletter about online business tools...

    When output changes unexpectedly, check whether the provider updated the model or shifted default parameters. Claude and OpenAI both version their models; a prompt that worked on gpt-4-0613 may behave differently on a newer snapshot. Tag your prompt with the model identifier, and you’ll know when to retest.

    What breaks when you don’t version

    Three failure modes show up fast:

    Prompt drift. You edit a prompt in-place, forget what you changed, and output quality tanks. Without a prior version, you can’t roll back. You rewrite from scratch, wasting the tuning work you did months ago.

    Inconsistent output across team members. If two people use slightly different versions of the same prompt—one copied from Slack, one from an old email—you get inconsistent tone, structure, or accuracy. Customers notice. A single source of truth fixes this.

    Lost optimisation work. You spend an hour refining a prompt, then close the browser tab. Next week, you start over. Versioned prompts are an asset; unversioned ones are disposable scratch work.

    Tools that help (and their limits)

    Dedicated prompt-management tools exist—PromptLayer, Humanloop, and LangSmith all offer versioning, logging, and comparison features. They’re useful if you’re running prompts at scale via API and need analytics. But most solo operators don’t need the overhead. A folder of text files and basic Git hygiene solves 90% of the problem for free.

    If you’re already using Claude or ChatGPT via API in a script or automation, store prompts as variables in your codebase. That way, version control is automatic—every commit captures prompt and code together. Just avoid hardcoding prompts as long strings; pull them from external files so non-coders can edit without touching code.

    Start simple: one folder, one naming convention

    You don’t need a complex system on day one. Create a folder called prompts, drop in one .txt file per task, and commit to updating the file instead of rewriting in a chat window every time. That alone puts you ahead of most operators.

    When a prompt stops working, duplicate the file, rename it with a version suffix, and edit the new copy. Compare output. Keep the better version. Delete the worse one, or archive it in a prompts/archive subfolder if you think you’ll need it later.

    Versioning matters most for prompts you use weekly. One-off requests don’t need the ceremony. But if you’re generating newsletter intros, product descriptions, or support replies on a regular cadence, treat the prompt like infrastructure. Store it, version it, and document the settings that make it work.

    Got a prompt-management system that works for you? Hit reply and share your setup—we’ll feature the best approaches in a future piece.

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

  • Analytics dashboard date-range presets: which save time, which hide trends

    Analytics dashboard date-range presets: which save time, which hide trends

    Analytics dashboard date-range presets: which save time, which hide trends
    Photo: Saleemkce via Wikimedia Commons (CC BY-SA 4.0)

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

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

    Rolling windows vs. calendar blocks

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

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

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

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

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

    When Last 30 Days hides a two-week slump

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

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

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

    Quarter to Date and the mid-quarter blind spot

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

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

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

    When to build a custom range

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

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

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

    One rule: always compare to something

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

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

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

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

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

  • Stripe checkout session expiration: when links die and how to extend

    Stripe checkout session expiration: when links die and how to extend

    Stripe checkout session expiration: when links die and how to extend
    Photo: Politikaner via Wikimedia Commons (CC BY-SA 3.0)

    Stripe checkout sessions—the payment links you generate via the API or dashboard—expire. By default, a session lives for 24 hours. After that, the link returns an error, and your customer sees a blank page or an “expired” message depending on how you built the flow.

    If you’re selling one-time products, launching a course, or running a time-limited offer, session expiration matters. A customer who bookmarks your payment link on Monday may find it dead by Wednesday. Here’s how the mechanism works, how to control it, and when you should shorten or extend the window.

    How Stripe checkout session expiration works

    When you create a checkout session via the Stripe API, you can set an expires_at parameter. This is a Unix timestamp. If you don’t set it, Stripe defaults to 24 hours from session creation (Stripe API reference, checked November 2026).

    The maximum allowed expiration is 24 hours. You cannot extend a session beyond that window without creating a new session. The minimum is effectively immediate—you can set expiration as soon as the session is created, though there’s no practical reason to do so.

    Once a session expires, the URL still resolves, but Stripe shows an error. If you’ve built a custom success or cancel flow, the customer may land on a generic Stripe page instead of your site.

    When to shorten the expiration window

    Flash sales, early-bird pricing, and limited-inventory drops benefit from shorter session lifetimes. If your offer ends at midnight, set expires_at to match that deadline. This prevents customers from bookmarking a checkout link with old pricing and completing payment after the window closes.

    Example: you’re selling 50 seats to a workshop. You open registration at 9:00 AM and close at 5:00 PM the same day. Set session expiration to 5:00 PM. Any link generated during the day dies at the cutoff, and you avoid the edge case where someone checks out at 6:00 PM with a stale session.

    Shorter expiration also reduces the risk of price or inventory desync. If you update a product price or mark it out of stock, existing sessions may still reference the old state until they expire or you manually invalidate them.

    The trade-off: customer friction

    Short expiration windows introduce friction. A customer who adds your link to a tab and returns three hours later may find it dead. They’ll need to start over—navigate back to your site, click through to checkout again, and re-enter payment details if autofill doesn’t catch them.

    For evergreen products or recurring subscriptions, the default 24-hour window usually works. Customers rarely sit on a payment link for more than a few hours, and the risk of stale pricing is low if your product catalog is stable.

    If you’re running a high-touch sales process—say, sending a custom quote via email—consider the 24-hour limit carefully. A prospect who receives your link Monday afternoon may not review it until Tuesday evening. If the session expires, they’ll email you for a new link, and you’ve added a round-trip to the sales cycle.

    One non-obvious detail: session expiration and webhooks

    Stripe does not fire a checkout.session.expired event by default. If you’re tracking session state in your own database, you’ll need to poll or handle expiration client-side. Stripe’s dashboard shows session status, but you won’t get a webhook notification when a session times out unless you’ve built custom logic to listen for the absence of a checkout.session.completed event within your expected window.

    This matters if you’re pre-reserving inventory or seats. If you decrement stock when a session is created and rely on expiration to release it, you’ll need a background job that checks session age and restores inventory for sessions that expired without completion. Stripe won’t do that for you.

    If you’re using Stripe for one-time payments, course sales, or limited-run products, audit your session expiration settings. The default 24 hours is reasonable for most cases, but it’s not universal. Shortening expiration tightens control over pricing and inventory; extending it—within the 24-hour cap—reduces friction for slower-moving prospects.

    Set expiration deliberately. Don’t leave it to default and assume it matches your offer’s lifecycle.

    Have a question about payment flows or checkout quirks? Reply to this email—we read every one and fold operator questions into future issues.

  • Newsletter subscription forms: when multi-step beats single-page

    Newsletter subscription forms: when multi-step beats single-page

    Newsletter subscription forms: when multi-step beats single-page
    Photo by 2H Media on Unsplash

    Most solo operators install a newsletter form once and never revisit the structure. You embed a widget, ask for name and email, and call it done. But form layout—single-page versus multi-step—affects conversion, completion rate, and the quality of subscribers who land in your list.

    The choice isn’t about fashion. It’s about friction, perceived commitment, and where in your funnel the form appears. Pick wrong and you’ll either scare off casual readers or attract subscribers who never open.

    Single-page forms: when to use them

    A single-page form shows every field at once. Name, email, optional checkboxes for topics or frequency, and a submit button. No steps, no progress bar, no “Next.”

    This format works best when:

    • The visitor already trusts you. They’ve read three articles, listened to a podcast episode, or followed a recommendation. They know what they’re signing up for.
    • You ask for two fields or fewer. Email-only forms convert highest. Add name and you drop 10–15 percent. Add more and you lose another chunk with each field.
    • The form lives in high-intent locations. Bottom of a long-form post, dedicated landing page after a lead magnet, footer of a resource library. Anywhere the reader has already decided.

    Single-page forms lose when you try to collect preference data up front—content topics, send frequency, job title. Every visible field adds perceived effort before the visitor commits.

    Multi-step forms: the delayed-ask advantage

    A multi-step form splits the signup into two or more screens. Step one asks for email. Step two collects name, preferences, or segmentation tags. Some platforms let you add a third step for confirmation or a welcome offer.

    Multi-step forms convert better in two scenarios:

    • Cold traffic. A visitor lands on your site from search, a social post, or a backlink. They don’t know you yet. Asking only for email on step one lowers the perceived cost. Once they’ve typed their address and hit “Next,” completion bias pulls them through step two.
    • You need segmentation data but don’t want to sacrifice top-of-funnel conversions. Asking for industry, company size, or content preferences on step one scares people off. Asking on step two—after they’ve already given their email—gets you the data without the initial friction.

    Beehiiv, MailerLite, and ConvertKit all support multi-step forms natively. You define the fields for each step, set transitions, and embed the widget. The platform handles state between steps and writes all fields to the subscriber record once they complete.

    Where multi-step fails: anywhere the visitor has already decided. If someone clicks “Subscribe” on your About page or downloads a lead magnet, adding steps just annoys them. Single-page wins there.

    What breaks when you mix formats wrong

    Install a single-page form with five fields in your blog sidebar and watch your conversion rate drop to single digits. Visitors skim, see the wall of inputs, and bounce.

    Use a multi-step form at the end of a pillar post and you’ve added unnecessary clicks. The reader already spent ten minutes with your content—they’ve decided. Making them tap “Next” between email and name just costs completions.

    Another failure mode: platforms that don’t persist partial data between steps. If a visitor enters their email on step one, closes the tab, and returns later, some tools lose the session. They start over. That’s a lost subscriber. MailerLite and Beehiiv both handle session persistence well; older WordPress plugins sometimes don’t.

    One non-obvious tip: test button copy on step one

    Most multi-step forms use “Next” or “Continue” on the first screen. Try “Subscribe” or “Get access” instead. It sets expectations and reduces drop-off between steps. Visitors know they’re committing to a subscription, not just filling out a survey.

    The opposite works too: if your audience is skeptical or privacy-conscious, softer copy like “Continue” or “Almost there” performs better than “Subscribe now.” Test both against your baseline.

    Want more tactical breakdowns like this? Subscribe to One Two Three Send—we cover tools, workflows, and the mechanics that actually move your business 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.

Powered by CookieAdmin