Author: onetwothreeadmin

  • Traffic attribution breaks when you change page URLs mid-campaign

    Traffic attribution breaks when you change page URLs mid-campaign

    Traffic attribution breaks when you change page URLs mid-campaign
    Photo by Veit Hammer on Unsplash

    You launch a paid campaign, queue up social posts, send a newsletter blast—then realize the landing page slug is wrong. Or you decide to consolidate two pages. Or you migrate a high-traffic post to a new URL structure.

    The redirect goes live. Traffic keeps flowing. But your attribution data fractures.

    Campaign managers, Google Analytics, and email platforms all track the original URL. When visitors hit a 301 redirect, most analytics tools log the destination page as the conversion point, but the source parameters often stick to the original link. The result: your dashboard shows conversions on the new URL with no clear path back to the campaign that drove them.

    What breaks first: UTM parameters and referrer strings

    When a visitor follows a link with UTM parameters—?utm_source=twitter&utm_campaign=launch—and hits a redirect, the parameters usually survive the hop. Google Analytics 4 and most tag managers preserve them across 301s and 302s.

    But if you change the URL after the campaign link is already distributed—say, in a newsletter that’s already sent or a Facebook ad that’s been running for three days—those links now point to a page that redirects. The UTM params land on the new URL, but your campaign report in GA4 shows two separate page paths: the old slug and the new one. If you’re filtering by page path or using it as a secondary dimension, your conversion count splits across both.

    Referrer strings are worse. If someone clicks a link from an external site (a backlink, a forum post, a guest article), the referring domain is logged by your analytics tool when the page loads. A redirect in the middle often strips or rewrites the referrer header, especially if the redirect chain includes a tracking proxy or a CDN. You lose visibility into where the traffic actually originated.

    Email and ad platforms track the click, not the final destination

    Email platforms like Postmark, MailerLite, and Beehiiv log the link you included in the email. If that link is yoursite.com/old-page, the click report shows clicks to /old-page—even if the visitor ends up on yoursite.com/new-page after the redirect.

    The same applies to Facebook Ads, Google Ads, and LinkedIn Campaign Manager. The platform records the destination URL you entered when you created the ad. If you change the page slug after the ad goes live, the platform’s click and conversion data still references the original URL. Your GA4 data shows the new URL. Matching them up requires manual cross-referencing or custom reporting dimensions.

    If you’re running A/B tests or comparing campaign performance across channels, this split makes it nearly impossible to attribute conversions accurately without a spreadsheet mapping old URLs to new ones.

    How to handle URL changes mid-campaign

    The cleanest fix: don’t change URLs while campaigns are active. If you must rename a page, wait until the campaign ends, or build the new URL from the start and redirect the old one before you launch.

    If the change is unavoidable, update the link in every place you control. Edit the email draft if it hasn’t sent. Pause the ad, change the destination URL, and restart it. Update your social scheduler if posts are still queued. Most platforms let you edit scheduled posts in tools like Publer or Buffer without losing the post slot.

    For links you can’t change—like a newsletter that already went out or a backlink from a published article—set up a 301 redirect and add a note in your analytics tool. In GA4, create a custom event or annotation marking the date you changed the URL. In your campaign spreadsheet, log both the old and new URLs with a note that they’re the same destination. When you pull reports, filter by campaign parameter (utm_campaign) instead of page path.

    If you’re consolidating multiple pages into one, use a URL parameter to distinguish the source. Redirect /old-page-1 to /new-page?from=old1 and /old-page-2 to /new-page?from=old2. GA4 will log the parameter, and you can build a custom report that groups conversions by the from value.

    When attribution is already broken

    If you’ve already changed URLs and your data is split, you can retroactively fix some of it. Export raw event data from GA4 (Explore → Free-form → add Page Path and Campaign as dimensions). Use a spreadsheet to map old URLs to new ones, then build a calculated field or pivot table that consolidates them.

    For email platforms, export the click report and match it to GA4 data by timestamp and user ID. Most ESPs let you export click-level data with timestamps. If your GA4 property is logging User ID or Client ID, you can join the two datasets and attribute conversions back to the email campaign even if the page path doesn’t match.

    It’s manual work, but it’s faster than rebuilding your entire attribution model.

    One tip: if you’re running affiliate campaigns or tracking sponsor conversions, URL changes mid-campaign often void your conversion tracking. Most affiliate networks (ShareASale, Impact, CJ) require you to register the destination URL when you create the link. Changing it without updating the network’s records means conversions won’t be credited. Always check your affiliate dashboard and update the destination URL there too.

    Want more attribution and tracking breakdowns? Subscribe to One Two Three Send—we cover the operational details that break (and how to fix them) every week.

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

  • AI prompt versioning: why saving iterations matters more than the final draft

    AI prompt versioning: why saving iterations matters more than the final draft

    AI prompt versioning: why saving iterations matters more than the final draft
    Photo by Zulfugar Karimov on Unsplash

    You’ve spent twenty minutes refining a ChatGPT prompt that generates product descriptions. It works beautifully. Two weeks later, you tweak it for a new product line—and suddenly the old output style vanishes. You can’t remember what you changed. The prompt is gone.

    Most solo operators treat AI prompts like scratch paper: they edit in place, overwrite, and move on. That works until a prompt stops performing, a client asks for the “old version,” or you need to debug why Tuesday’s output doesn’t match Monday’s.

    Prompt versioning—saving each iteration instead of overwriting—solves this. It’s not about perfectionism. It’s about maintaining a working asset when context, models, and requirements shift constantly.

    Why prompts degrade over time

    AI models don’t change day-to-day, but three things do:

    • Your input context. You add a new product category, a different tone requirement, or an edge case. The prompt that worked for fifty items breaks at sixty.
    • Model updates. OpenAI, Anthropic, and others push model improvements without warning. A prompt optimized for GPT-4 in May might behave differently in August.
    • Your memory. You remember the prompt works. You don’t remember which phrasing made it work, or what you removed three edits ago.

    Without versions, you’re guessing. With them, you can diff two iterations, isolate what changed, and roll back when an edit breaks something subtle.

    How to version prompts without overhead

    You don’t need Git. You need a system light enough that you’ll actually use it.

    Option one: dated text files. Create a folder. Name each prompt file with a date and slug: 2026-08-11-product-description.txt. When you edit, save a new file. Costs zero dollars, works offline, and grep searches instantly.

    Option two: a dedicated tool. Tools like PromptLayer, LangSmith, or Humanloop log every prompt and response automatically. You get diffs, performance tracking, and rollback in a UI. Trade-off: another subscription (typically $20–50/month) and vendor lock-in.

    Option three: a Notion database. One table. Columns for version date, prompt text, model used, and sample output. Filter by project. Duplicate a row to create a new version. Free tier handles this fine for solo operators.

    Pick the one you’ll actually maintain. Versioning only works if it’s faster than not doing it.

    What to track in each version

    Don’t just save the prompt text. Capture:

    • Date and version number. Even a simple v1, v2, v3 helps.
    • What changed and why. One sentence: “Added tone constraint for technical audience” or “Removed example because it biased output.”
    • Model and settings. GPT-4, temperature 0.7, max tokens 500. When output shifts, you need to know if the prompt changed or the settings did.
    • Sample output. Paste one good result. Future-you will forget what “good” looked like.

    This takes sixty seconds per version. It saves hours when something breaks.

    When to create a new version vs. edit in place

    Not every typo fix needs a version. Use this rule:

    Create a new version when you change structure, logic, constraints, or examples. Edit in place when you fix typos, formatting, or obvious errors.

    If you’re not sure, version it. Disk space is cheap. Lost prompts aren’t.

    The rollback test

    Here’s how you know versioning is working: a client asks for last month’s email style. You open your prompt archive, copy v8, and regenerate. Done in two minutes.

    Without versions, you’re rewriting from memory, testing five variations, and hoping one feels right.

    Prompts are infrastructure now. Treat them like code: version, document, and never assume you’ll remember what worked.

    What’s one prompt you wish you’d saved three edits ago? Hit reply—I read every response, and reader examples shape future deep-dives here.

  • WordPress plugin auto-updates: when to enable and when to audit first

    WordPress plugin auto-updates: when to enable and when to audit first

    WordPress plugin auto-updates: when to enable and when to audit first
    Photo: Matinbeigi via Wikimedia Commons (CC BY-SA 4.0)

    WordPress added automatic plugin updates in 2020, but most solo operators still toggle them on or off by instinct. Some enable everything and hope for the best. Others disable all auto-updates and let security patches pile up for months.

    Both approaches fail eventually. A smarter strategy is to classify your plugins by risk, then set auto-update policies based on what breaks when something goes wrong.

    What auto-updates actually do

    When you enable auto-updates for a WordPress plugin, the core update routine checks twice daily for new versions. If a new release is available, WordPress downloads and activates it without asking. No email confirmation. No manual review.

    Minor updates—like going from version 3.4.1 to 3.4.2—usually contain security patches or bug fixes. Major updates—like 3.x to 4.0—often introduce new features, deprecate old functions, or rewrite significant chunks of code.

    WordPress doesn’t distinguish between the two when auto-updating. If the developer ships a major version, your site will install it overnight. That’s where problems start.

    The risk matrix: which plugins to auto-update

    Start by grouping your active plugins into three tiers based on what happens if they break.

    Tier 1: Critical path plugins. These handle forms, checkout flows, email capture, payment processing, or user authentication. If they fail, you lose subscribers or revenue. Examples: WooCommerce, Gravity Forms, MemberPress, any payment gateway integration.

    Never enable auto-updates for Tier 1 plugins. Test major updates in a staging environment first. Even minor updates can introduce conflicts with your theme or other plugins, and you won’t know until someone reports a broken checkout.

    Tier 2: Analytics and third-party integrations. These plugins connect WordPress to external services—Google Analytics, Facebook Pixel, ConvertKit, Zapier webhooks. They rarely touch core site functionality, but when they break, you lose tracking data or automation triggers.

    Enable auto-updates for security patches only if the plugin developer uses semantic versioning and maintains a public changelog. If the developer ships breaking changes without warning, disable auto-updates and check manually once a month.

    Tier 3: Cosmetic and convenience plugins. Syntax highlighters, table-of-contents generators, related-post widgets, social share buttons. These improve the reader experience but don’t affect conversions or data collection.

    Enable auto-updates. If something breaks, you’ll notice it during your next post preview. The risk is low, and staying current reduces the chance of a security exploit in an unmaintained codebase.

    The audit cadence nobody talks about

    Enabling auto-updates isn’t a one-time decision. Plugin developers change ownership, get acquired, or abandon projects. A plugin that was safe to auto-update in January might ship a disastrous update in August.

    Set a quarterly reminder to review your auto-update settings. Check each plugin’s changelog for the last three months. If you see phrases like “major refactor,” “breaking changes,” or “deprecated legacy support,” disable auto-updates and test manually before upgrading.

    Also watch for plugins that haven’t shipped an update in six months. That’s often a sign the developer has moved on. Disable auto-updates, find a replacement, and migrate before a WordPress core update introduces a fatal incompatibility.

    The staging environment exception

    If you run a staging site that mirrors production, you can auto-update aggressively there and manually promote updates only after confirming nothing broke. This works well for operators publishing daily or running membership sites where downtime is expensive.

    The catch: staging environments need to be true mirrors. Same theme, same plugins, same server PHP version, same database size. A lightweight staging site with dummy content won’t catch conflicts that only appear under load or with real user data.

    Most managed WordPress hosts—BigScoots, Kinsta, WP Engine—offer one-click staging environments that sync database and files from production. If your host doesn’t, the manual sync overhead usually outweighs the auto-update safety benefit.

    Want more infrastructure breakdowns like this? Subscribe to One Two Three Send for weekly operator-to-operator guides on the tools that actually run online businesses.

  • Social media scheduling tools charge per profile—here’s the math

    Social media scheduling tools charge per profile—here’s the math

    Social media scheduling tools charge per profile—here's the math
    Photo by Shutter Speed on Unsplash

    Social media scheduling tools advertise their pricing per user or per month, but the real cost driver is hidden one line down: connected social profiles. Connect three Twitter accounts, two Instagram profiles, and a LinkedIn page, and you’ve just burned through six profile slots—often before you’ve scheduled a single post.

    Most solo operators discover this the hard way when they hit a tier ceiling or get an upgrade prompt halfway through onboarding. Here’s how the billing actually works, what counts as a profile, and when it makes financial sense to consolidate or split your setup.

    How profile-based pricing works

    A “profile” is any individual social media account you authorize the scheduling tool to post to. That means:

    • Each Twitter/X account = 1 profile
    • Each Instagram account = 1 profile (even if it’s a business account linked to the same Facebook page)
    • Each Facebook page = 1 profile
    • Each LinkedIn personal profile = 1 profile
    • Each LinkedIn company page = 1 profile
    • Each Pinterest board set = 1 profile
    • Each TikTok account = 1 profile

    Most tools in the $15–$30/month tier cap you at 5–10 profiles. Publer‘s base plan allows 5 profiles for $12/month; Buffer’s Essentials tier gives you 3 channels for $6/month per channel; Hootsuite starts at 10 profiles for $99/month. If you run a personal brand, a side project, and a client account, you’re already at 9–12 profiles depending on how many networks each presence spans.

    The pricing jumps aren’t linear. Going from 10 to 15 profiles often doubles your monthly cost, and tools don’t prorate—if you need 11 profiles, you pay for the 15- or 20-profile tier.

    What actually counts as separate profiles

    Instagram business accounts linked to Facebook pages still count as two separate profiles in most tools, even though Meta treats them as a paired entity. If you manage both the Instagram account and its parent Facebook page, that’s two slots.

    LinkedIn personal profiles and company pages are always separate, even if you’re the sole admin of the company page. Scheduling to both burns two profiles.

    Twitter/X accounts are straightforward: one account = one profile. But if you run a brand account and a founder account, that’s two.

    Some tools treat Pinterest differently. A few count your entire Pinterest presence as one profile; others count each board you schedule to separately. Check the tool’s FAQ before connecting Pinterest—it’s the billing wild card.

    Threads accounts, as of mid-2026, are starting to appear as standalone profiles in newer tools. If your tool added Threads support recently, expect it to count separately from Instagram, even though they share a login.

    When to consolidate vs. pay for more profiles

    If you’re managing a personal brand and one side project across four networks (Twitter, LinkedIn, Instagram, Facebook), you’re at 8 profiles. Consolidating down to three networks drops you to 6 profiles, which might slide you into a cheaper tier and save $10–$20/month.

    The calculus changes if those extra profiles generate revenue. A client account that pays $500/month justifies the $15 tier bump. A side project Instagram with 800 followers and no monetisation path doesn’t.

    Splitting tools is sometimes cheaper than upgrading. If you need 12 profiles, paying for two separate tools at the 5-profile tier ($12/month each = $24 total) often beats a single tool’s 15-profile tier at $39/month. The tradeoff: you lose unified analytics and have to check two dashboards.

    One non-obvious trick: if you only post to certain profiles sporadically, disconnect them between campaign bursts. Most tools let you reconnect profiles without losing historical post data. A quarterly LinkedIn company page update doesn’t need to occupy a profile slot year-round.

    Profile limits and team growth

    Profile caps bite hardest when you add a team member who brings their own accounts. A VA with their own Instagram and Twitter presence can add 2–4 profiles to your tool overnight, pushing you into the next tier even if they’re only scheduling for you 10 hours a week.

    Some tools separate user seats from profile counts; others bundle them. Buffer charges per channel but allows unlimited users per account. Publer charges per profile and allows 1–10 users depending on tier. Hootsuite charges for both users and profiles, but scales the profile limit with user count.

    If you’re hiring contractors who manage their own social accounts, ask whether they can bring their own scheduling tool login instead of adding their profiles to yours. You lose some workflow visibility, but you avoid the tier jump.

    Profile-based pricing isn’t going away—it’s the revenue model that funds these tools’ API costs and storage. But understanding the math before you connect a seventh account saves you from surprise billing and forces a useful question: which profiles actually matter?

    What’s your profile count across tools right now? Hit reply and let me know if you’ve found a billing structure that actually works for multi-project operators.

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

  • Google Search Console filter logic: combining AND vs. OR operators

    Google Search Console filter logic: combining AND vs. OR operators

    Google Search Console filter logic: combining AND vs. OR operators
    Photo: John Poyser via Wikimedia Commons (CC BY-SA 2.0)

    Google Search Console lets you stack filters to narrow down query, page, country, and device data. But the way it combines multiple conditions isn’t intuitive—and if you’re used to spreadsheet filter logic or SQL, you’ll get surprising results the first time you try to isolate a segment.

    The interface offers two combination modes: “Filter by AND” and “Filter by OR.” The labels sound clear. In practice, they behave differently depending on whether you’re filtering within the same dimension or across different ones.

    Same dimension: OR is the only option that works

    If you want to see data for two specific queries—say, “WordPress caching” and “WordPress CDN”—you’d think you could add both as separate query filters and choose AND to show rows matching both. You can’t. When you add multiple filters to the same dimension (queries, pages, countries, devices), Search Console forces OR logic even if you select AND.

    Why? A single search impression can’t satisfy two different query strings simultaneously. A click either came from “WordPress caching” or “WordPress CDN,” never both. So AND would return zero rows. Google’s interface quietly overrides your selection and treats same-dimension filters as OR.

    This trips up operators who want to exclude certain queries while viewing others. You can’t add a “Query contains ‘caching’” filter and a “Query does not contain ‘plugin’” filter and expect AND logic to show caching queries that aren’t about plugins. Both filters apply to the query dimension, so Search Console ORs them—you’ll see every caching query plus every query that doesn’t contain “plugin,” which is almost your entire dataset.

    Different dimensions: AND and OR work as labeled

    When you filter across different dimensions—one filter on queries, another on pages, a third on country—the AND/OR toggle behaves as expected.

    Example: You want to see how the query “email deliverability” performs on your /guides/postmark-setup page in the United States. Add three filters: query exactly matches “email deliverability,” page exactly matches your URL, country exactly matches USA. Set the combination mode to AND. You’ll get rows that satisfy all three conditions.

    Switch to OR, and you’ll see every impression that matches any of the three: every “email deliverability” query across all pages and countries, every impression on that Postmark guide regardless of query, and every US impression regardless of query or page. The dataset explodes.

    For cross-dimension filtering, AND is almost always what you want. OR is useful when you’re trying to compare performance across segments—like traffic from the US or the UK combined, filtered to a specific landing page.

    The non-obvious workaround: use regular expressions for exclusions

    If you need to exclude certain query patterns while keeping others, don’t stack multiple query filters. Use a single filter with a regular expression that combines inclusion and exclusion logic in one pattern.

    Say you want queries containing “WordPress” but not “theme” or “plugin.” Instead of three separate filters, use one: set the filter type to “Custom (regex)” and enter wordpress(?!.*(theme|plugin)). The negative lookahead excludes rows matching your unwanted terms without triggering Search Console’s forced OR behavior.

    Regular expressions aren’t exposed prominently in the filter dropdown—select “Custom (regex)” under the query filter type menu. The interface doesn’t validate your regex in real time, so test patterns in a regex tester before applying them to avoid silent failures.

    When filter combinations cost you accurate attribution

    Stacking too many filters—especially across queries and pages—can shrink your sample size below Search Console’s anonymization threshold. Google suppresses rows when impression counts fall under ~10 to protect user privacy. If your AND filter combination is too narrow, you’ll see “(not set)” or missing rows, even though the traffic exists.

    This happens most often when you filter by long-tail queries (low volume) AND specific pages (also low volume) AND a narrow date range. Broaden one dimension—expand the date range to 28 days, or widen the query filter to “contains” instead of “exactly matches”—and the data reappears.

    If you’re debugging attribution or trying to confirm whether a specific query drives traffic to a specific page, export the full dataset as a CSV and filter locally in a spreadsheet. The export includes rows that fall below the UI threshold, though Google still suppresses some for privacy.

    Want to catch more tool-behavior nuances like this? Subscribe to One Two Three Send for weekly breakdowns of how online-business software actually works—no fluff, just the mechanics that matter.

  • Stop refreshing Stripe—affiliate networks delay payouts by design

    Stop refreshing Stripe—affiliate networks delay payouts by design

    Stop refreshing Stripe—affiliate networks delay payouts by design
    Photo by Fahim Junaid on Unsplash

    You check your affiliate dashboard. The clicks are there. The conversions are confirmed. The revenue number updates in real time. But the money doesn’t hit your account for another 60 days.

    This isn’t a bug. It’s how affiliate networks are built—and understanding the gap between “earned” and “paid” changes how you budget, forecast, and pick which programs to join.

    Why affiliate networks hold payments

    Most affiliate programs operate on net-30, net-60, or net-90 payment terms. That means if you generate a sale on August 1, the network pays you 30, 60, or 90 days after the end of the month in which the sale occurred—so September 30, October 30, or November 1 at the earliest.

    The delay isn’t arbitrary. Networks wait because:

    • Refund windows: Many products allow 14-, 30-, or 60-day returns. Networks withhold payment until the refund window closes to avoid clawing back commissions later.
    • Fraud detection: Payment processors and affiliate platforms use the delay to identify patterns—chargebacks, coupon abuse, cookie-stuffing—that invalidate commissions.
    • Cash flow smoothing: The merchant doesn’t pay the network immediately either. The delay synchronizes inbound and outbound cash.

    For SaaS affiliate programs, the lag can stretch even further. Annual subscriptions sometimes hold first-month commissions until the customer passes 60 or 90 days active, ensuring the sale wasn’t fraudulent or immediately refunded.

    How payment timing varies by program type

    Not all affiliate programs use the same clock. Here’s what to expect:

    Self-hosted platforms: Tools like Easy Affiliate (WordPress) and Rewardful (Stripe-native) let merchants set their own terms. Default is often net-30, but some operators push to net-60 to pad working capital.

    Marketplace networks: Amazon Associates pays roughly 60 days after month-end. Impact and ShareASale default to net-30 but vary by merchant. PartnerStack is often net-60 for SaaS.

    Direct partnerships: If you negotiate a private affiliate deal, payment terms are negotiable—but expect net-30 as the starting point unless you have leverage or volume.

    The fastest-paying programs are usually membership platforms or newsletters using Stripe-native tools like Rewardful, where the merchant can configure near-real-time payouts. But even then, most leave a 14-day buffer to catch refunds.

    How to forecast when you’ll actually get paid

    The mistake most operators make: treating dashboard revenue as cash in hand. It’s not. It’s a promise to pay, subject to refunds, fraud checks, and the network’s payment schedule.

    Here’s how to model it:

    Track three dates per sale: Conversion date, commission confirmation date, and scheduled payout date. Most dashboards show the first two; you have to calculate the third yourself.

    Build a rolling 90-day cash forecast: Use a spreadsheet with columns for each week. Drop expected payouts into the week they’ll actually arrive, not the week you earned them.

    Flag minimum payout thresholds: Many networks (Amazon, Impact, CJ) only pay when you hit $50–$100 in commissions. If you’re earning $40/month from a program, your first payment might take three months—even on a net-30 schedule.

    Watch for holds on new accounts: Some networks extend the payment window for your first 1–3 payouts. ShareASale, for example, holds first payments longer to establish trust.

    When to drop a program over payout terms

    A high commission rate matters less if cash flow timing breaks your budget. Here’s when to walk:

    Net-90 with a high refund rate: If the product has a 30-day trial and the network waits 90 days post-month-end, you’re looking at 120+ days to cash. That’s a loan you’re giving the merchant.

    Rolling holds without disclosure: Some programs add “additional review” holds without warning. If payouts are routinely late beyond stated terms, leave.

    Threshold + long terms: A $100 minimum payout on net-60 terms means slow earners might wait six months for their first check. That’s fine for side income, but not if affiliate revenue pays your hosting bill.

    Conversely, if you’re choosing between two similar programs, payout speed can be the tiebreaker. A 10% commission paid net-30 beats 12% paid net-90 if you need cash flow predictability.

    Want to compare payout structures across platforms before you commit? Subscribe to One Two Three Send—we track terms, thresholds, and timing for the tools online operators actually use.

    The affiliate dashboard is not your bank account. Treat it like accounts receivable: earned, but not yet liquid. Build your budget around payment dates, not conversion dates, and you’ll never be surprised when the money’s late.

  • ConvertKit vs. MailerLite vs. Beehiiv: landing page builders compared

    Most newsletter platforms now bundle landing page builders alongside their email tools. The pitch is compelling: skip the WordPress plugin maze or the monthly Carrd subscription and build your signup page where your subscribers live.

    But the feature sets vary wildly. Some platforms give you a drag-and-drop canvas with custom code access. Others lock you into three templates and call it a day. If you’re choosing a platform partly based on landing page capability—or wondering whether to migrate—here’s what ConvertKit, MailerLite, and Beehiiv actually offer in 2026.

    ConvertKit: functional but rigid

    ConvertKit’s landing page builder uses a template system with limited layout flexibility. You pick from roughly a dozen pre-built designs, swap the headline and image, adjust colors, and publish to a convertkit.com subdomain or your own custom domain.

    The editor is intentionally constrained. You can’t rearrange sections or add custom HTML blocks. Form fields are tied to your ConvertKit account, so multi-step opt-ins or conditional logic require workarounds using their visual automation tool.

    What it does well: Speed. You can ship a decent-looking page in under ten minutes. The templates are mobile-responsive by default, and the form-to-subscriber pipeline is instant—no webhook delays or API keys to configure.

    Where it falls short: Customization. If your brand requires a specific layout—hero image on the right, testimonial grid below the fold—you’re out of luck unless that exact template exists. There’s no CSS panel, no custom code injection, and no A/B testing at the page level (only at the form level).

    Pricing note: Landing pages are included on all ConvertKit plans, starting at $25/month for up to 1,000 subscribers.

    MailerLite: drag-and-drop with design latitude

    MailerLite offers a block-based builder that feels closer to a lightweight page builder than a form wrapper. You drag in text blocks, images, buttons, countdown timers, and embedded videos. Each block has spacing, alignment, and styling controls.

    You can add custom HTML and CSS if you need it, which makes MailerLite the most flexible option here for operators comfortable tweaking code. The platform also supports A/B testing at the page level—two headlines, two hero images, winner determined by conversion rate.

    What it does well: Design freedom without requiring a separate tool. If you want a two-column layout with a form on the left and social proof on the right, you can build it in fifteen minutes. The custom domain setup is straightforward: add a CNAME record, verify, done.

    Where it falls short: The template library is smaller than ConvertKit’s, and the drag interface can feel finicky when nesting blocks inside containers. If you’re not design-confident, you’ll spend more time fiddling with padding than writing copy.

    Pricing note: Free plan supports landing pages for up to 1,000 subscribers. Paid plans start at $10/month and add A/B testing, custom HTML, and removal of MailerLite branding.

    Beehiiv: built for growth operators, priced accordingly

    Beehiiv’s landing page builder sits somewhere between ConvertKit’s rigidity and MailerLite’s flexibility. You get templates, block-level editing, and the ability to embed custom code—but the real differentiator is integration with Beehiiv’s referral and monetization tools.

    Landing pages can display referral progress bars, show subscriber counts as social proof, and integrate with Beehiiv’s Boost network for cross-promotion. If you’re running a growth-focused newsletter and want the landing page to pull double duty as a referral hub, Beehiiv is the only platform here that supports it natively.

    What it does well: Growth mechanics. The referral milestone display, the subscriber count badge, and the optional “Powered by Beehiiv” removal all cater to operators treating their newsletter as a serious business. The analytics dashboard shows page views, conversion rate, and referral source attribution in one view.

    Where it falls short: Cost. Landing pages are included on all plans, but the free tier caps you at 2,500 subscribers and includes Beehiiv branding. The Scale plan ($42/month) is where you unlock custom domains, remove branding, and access A/B testing. If you’re just starting out, that’s steep compared to MailerLite’s free option.

    Who should use which

    Pick ConvertKit if you want to ship a signup page fast, don’t need layout control, and already use ConvertKit for email. The landing page builder won’t wow anyone, but it won’t slow you down either.

    Pick MailerLite if you’re design-comfortable, want A/B testing without paying ConvertKit prices, or need the flexibility to inject custom code for tracking pixels or embedded widgets. It’s the best value here for solo operators on a budget.

    Pick Beehiiv if your newsletter strategy includes referral programs, cross-promotion, or monetization features that require tight integration between the landing page and the platform. You’ll pay more, but the growth tools justify it if you’re past the hobbyist stage.

    One last note: none of these builders rival a dedicated tool like Carrd or Webflow for pure design capability. But if you’re optimizing for speed and operational simplicity—one login, one billing relationship, one support queue—the built-in option usually wins.

    Reply with the platform you’re using and whether the landing page builder actually ships for you. I’m curious how many operators still reach for WordPress or a standalone tool despite these built-in options improving every year.

    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 database backups: snapshot frequency vs. disk cost

    WordPress database backups: snapshot frequency vs. disk cost

    WordPress database backups: snapshot frequency vs. disk cost
    Photo by Woliul Hasan on Unsplash

    Most WordPress operators set a backup schedule once and forget it. Daily snapshots sound safe. Hourly feels safer. But backup frequency compounds fast—and if you’re running on managed WordPress hosting or a VPS, you’re paying for every copy stored.

    The question isn’t whether to back up. It’s how often you need to, what retention window actually protects you, and when snapshot frequency starts costing more than the risk it mitigates.

    Backup frequency changes your storage footprint

    A typical WordPress database for a content site with 500 posts, 2,000 comments, and standard plugin metadata runs between 15 MB and 50 MB. If you’re running WooCommerce, memberships, or forum software, double or triple that.

    Hourly backups with 30-day retention mean 720 snapshots per month. At 30 MB per snapshot, that’s 21 GB of backup storage. Most managed hosts allocate 10–20 GB of backup space before charging overage fees—usually $0.10 to $0.25 per GB per month.

    Switch to daily backups with the same retention, and you drop to 30 snapshots: 900 MB total. The difference is $2 to $5 per month for a small site, but $20+ if your database crosses 200 MB.

    Backup plugins like UpdraftPlus and BackWPup let you set different intervals for database vs. files. Your database changes every time someone comments, subscribes, or places an order. Your theme files don’t. Splitting the schedule—hourly database, weekly files—cuts storage costs without losing transaction-level recovery.

    Retention windows protect different failure modes

    Thirty-day retention is a convention, not a requirement. What you’re protecting against determines how far back you need to go.

    If you’re worried about a bad plugin update or a botched migration, you need snapshots from the last 48 hours. Anything older than a week is archaeological. A 7-day retention window with hourly backups gives you 168 recovery points and costs one-quarter the storage of a 30-day window.

    If you’re worried about silent data corruption—broken automation, spam injection, or a membership plugin quietly deleting records—you need longer retention, but you don’t need high frequency. Weekly backups kept for 90 days let you spot patterns and roll back months without paying for hundreds of hourly snapshots.

    The hybrid approach: hourly backups kept for 7 days, plus one weekly backup kept for 12 weeks. That’s roughly 180 snapshots instead of 720, and it covers both rapid rollback and long-term forensics.

    Incremental vs. full snapshots: what your plugin actually stores

    Not all backup plugins store full copies every time. Incremental backups save only the database rows that changed since the last snapshot. UpdraftPlus, BlogVault, and most enterprise WordPress backup tools support incremental mode.

    For a content site publishing twice a week, an incremental backup after the first full snapshot might be 500 KB instead of 30 MB. Over a month, that shrinks your storage footprint by 80% or more.

    The tradeoff: incremental backups depend on the chain. If snapshot #4 is corrupted, you can’t restore from snapshot #10 without it. Some plugins automatically store a weekly full backup alongside incrementals to break the dependency chain. Check your plugin’s settings—most don’t enable this by default.

    When to pay for more frequent backups

    If you’re processing transactions, taking payments, or running time-sensitive campaigns, hourly backups are worth the cost. Losing six hours of WooCommerce orders or sponsor sign-ups isn’t a storage-cost discussion—it’s a revenue-loss discussion.

    If you’re publishing a content site with no e-commerce and infrequent comments, daily backups are enough. Your exposure window is the time between backups, and for most solo operators, a day of republishing is tolerable compared to the compounding cost of storing 720 snapshots you’ll never use.

    One non-obvious tell: check your WordPress database activity log (if your host provides one, or install Query Monitor for a week). If 95% of your write queries happen during your publishing window—say, Tuesday and Thursday mornings—you don’t need constant snapshots. Schedule backups for right after you publish, and drop frequency the rest of the week.

    What breaks when you skimp

    The biggest failure mode isn’t missing a backup window. It’s discovering your backups don’t restore.

    Twice a year, test a restore to a staging environment. Download a snapshot, spin up a local WordPress instance or a staging server, and import it. If your backup plugin stores files and database separately, make sure both pieces actually reconnect. I’ve seen operators keep 90 days of database snapshots that restored to a blank site because the file backup was misconfigured.

    Second most common break: your backup plugin times out mid-snapshot because your host limits PHP execution to 60 seconds and your database takes 90 to export. This fails silently unless you check logs. Solution: switch to a plugin that chunks exports (UpdraftPlus and BackWPup both do this), or move to host-level backups if your provider offers them.

    Want more infrastructure breakdowns like this? Subscribe to One Two Three Send—we cover the WordPress tooling, hosting gotchas, and cost optimizations that solo operators actually run into.

  • Claude’s Projects feature: when to group chats vs. start fresh

    Claude’s Projects feature: when to group chats vs. start fresh

    Claude's Projects feature: when to group chats vs. start fresh
    Photo by Brecht Corbeel on Unsplash

    Claude‘s Projects feature lets you bundle related chats under a single workspace with shared context. Instead of re-pasting the same background information into every new conversation, you load it once at the project level and every chat inside inherits it.

    For solo operators juggling client briefs, editorial calendars, or product documentation, it’s a way to stop copy-pasting setup prompts. But the feature has edge cases that aren’t obvious until you hit them.

    How Projects actually work

    When you create a project in Claude, you get two things: a custom instruction field (up to 150,000 characters) and a collection of conversations that all reference that instruction set.

    The custom instruction field is where you load context that doesn’t change often—brand voice guidelines, product specs, audience definitions, style rules, or a content brief template. Every chat you start inside that project treats the custom instruction as invisible preamble. You don’t see it in the chat window, but Claude does.

    Each conversation still has its own thread history. Projects don’t merge chats—they just give them a shared foundation.

    Pricing-wise, Projects are available on Claude Pro ($20/month) and Team plans ($30/user/month). The feature isn’t on the free tier.

    When to group chats in one project

    Projects make sense when you’re working on a defined scope with consistent context. A few scenarios where grouping pays off:

    • Client work with recurring briefs. Load the client’s brand guide, target audience, and tone preferences once. Start a new chat each time you draft an email sequence, landing page, or blog post. You avoid re-explaining who the client is every time.
    • Newsletter editorial planning. Drop your content pillars, audience persona, and past performance notes into the project instruction. Use separate chats to brainstorm individual issues, outline series, or workshop subject lines.
    • Product documentation. If you’re writing help docs or onboarding flows for a SaaS tool, load the feature list and UI terminology as project context. Each chat becomes a different doc or tutorial, but Claude stays consistent on naming and structure.

    The common thread: stable context, variable tasks.

    When starting fresh beats grouping

    Projects aren’t always the right move. If context shifts between tasks, a shared instruction field creates drag instead of efficiency.

    Examples where separate projects—or no project at all—work better:

    • Multiple clients or brands. If you’re a freelancer managing three clients, don’t try to cram all three brand voices into one project. Create one project per client, or skip projects entirely and paste the relevant brief into each standalone chat.
    • Exploratory research vs. execution. If you’re using Claude to explore a topic before you commit to a direction, a project’s fixed context can anchor you too early. Start a regular chat, figure out your angle, then build a project once the scope is clear.
    • Short, one-off tasks. If you need a quick regex pattern, a subject line A/B test, or a single email rewrite, the overhead of setting up a project isn’t worth it. Just open a chat and go.

    Projects shine when repetition is expensive. If you’re not repeating context, don’t add structure.

    The non-obvious tip: token limits apply to the whole project

    Here’s the part that catches people: Claude’s context window includes everything—the custom instruction, the full chat history, and your new prompt. On Claude 3.5 Sonnet, that window is 200,000 tokens (roughly 150,000 words).

    If your project’s custom instruction is 50,000 tokens and you’ve been working in the same chat for a while, you can hit the ceiling faster than you expect. When that happens, Claude starts dropping early parts of the conversation to stay within limits.

    The fix: start a new chat inside the project when threads get long. The project context persists, but the individual chat history resets. You keep the shared foundation without dragging around a 30-message thread about last week’s draft.

    Most operators don’t monitor token counts until something breaks. If Claude starts “forgetting” details you mentioned earlier in a thread, that’s your signal to branch into a fresh chat.

    Who this feature is actually for

    Projects work best for operators with defined, recurring workflows—freelancers with repeat clients, solo founders managing a single product’s content ecosystem, or small teams collaborating on a shared editorial calendar.

    If your work is exploratory, ad hoc, or spans too many contexts to consolidate, the feature adds friction. It’s a tool for operators who’ve already standardized their process and want to stop re-typing the same setup every time they open Claude.

    Using Claude for content work? Reply and tell us what you’re loading into project instructions—we’re tracking what solo operators actually automate vs. what stays manual.

    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.

  • Medium’s paywall import tool: how it handles canonical URLs

    Medium’s paywall import tool: how it handles canonical URLs

    Medium's paywall import tool: how it handles canonical URLs
    Photo: Deanmarcco via Wikimedia Commons (CC BY-SA 4.0)

    If you’re running a content business and republishing on Medium for extra reach, you’ve probably used the import tool. It’s meant to pull in a story from your site, preserve the canonical tag pointing back to your original, and let you reach Medium’s audience without tanking your SEO.

    That’s the pitch. Reality is messier—especially when the Medium Partner Program paywall is involved.

    How the import tool is supposed to work

    Medium’s story importer lives at medium.com/p/import. Paste in your original URL, hit import, and Medium pulls in the HTML, strips most formatting, and adds a canonical link element in the story’s head pointing back to your domain.

    Google sees the canonical, treats your site as the source of truth, and Medium becomes a syndication channel. You get distribution without splitting ranking signals.

    That works fine when the imported story is published as a free, public post. The canonical tag stays intact. Google can crawl both. No problem.

    What changes when you add the paywall

    The moment you tick the box to make an imported story eligible for Medium’s Partner Program—putting it behind the metered paywall—Medium’s handling of the canonical tag shifts.

    For logged-out users and non-members, Medium still shows the story preview and preserves the canonical link in the HTML. But for Googlebot and other crawlers that can access paywalled content (Medium allows limited crawling for indexing), the canonical tag remains, but the story itself is now gated in a way that changes crawl priority and indexability signals.

    In practice, Google often still respects the canonical and doesn’t index the Medium version as the primary result. But operators have reported cases where a paywalled Medium import begins to rank separately—especially if the original post is on a lower-authority domain, or if the paywall causes Google to treat the Medium version as distinct content due to access restrictions.

    There’s no official documentation from Medium clarifying crawl behavior for paywalled imports. Their public support docs say the importer “preserves canonical tags,” but don’t address what happens when the Partner Program paywall is enabled.

    When canonical drift actually matters

    If you’re importing to Medium purely for the Partner Program revenue and your original post already ranks well, canonical drift is mostly a non-issue. Your site keeps its position, Medium earns you a few dollars in read time, and you move on.

    It becomes a problem in two scenarios:

    • Your site has low domain authority. If Medium’s domain strength outweighs yours, Google may start treating the paywalled import as the preferred result, especially if the canonical tag is present but the content diverges (Medium’s paywall preview vs. your full post).
    • You’re importing frequently and at scale. If you’re cross-posting dozens of articles, you risk creating a shadow content library on Medium that competes with your own site in long-tail search. Even if canonicals are set correctly, the sheer volume of Medium URLs in the index can dilute click-through to your domain.

    The workaround: delay the import

    The cleanest approach is to let your original post index and gain traction on your own site first. Wait 30 to 60 days, then import to Medium and enable the paywall.

    By that point, Google has already crawled, indexed, and likely ranked your original. The canonical tag on the Medium import reinforces the existing signal rather than creating ambiguity.

    If you’re importing immediately after publishing, consider leaving the Medium version outside the paywall for the first two weeks. Publish it as a free post with the canonical intact, let Google confirm the relationship, then add it to the Partner Program later. Medium lets you toggle paywall status post-publication without breaking the import.

    One more thing: Medium’s importer occasionally fails to pull in the canonical tag at all, especially if your site uses JavaScript rendering or non-standard HTML structures. Always check the imported story’s page source after publishing. If the <link rel="canonical"> is missing, you’ll need to contact Medium support or manually add a noindex tag to the Medium story via their settings (though that kills Partner Program eligibility).

    Want more technical breakdowns of online-business tools? Subscribe to One Two Three Send and get one in your inbox every week—no fluff, just the mechanics that matter.