ConvertKit filters run backwards—and that breaks sequences
The café on Mercer Street smells like burnt espresso this morning, and every laptop screen shows the same thing: an automation dashboard where subscribers who should have entered a sequence two days ago are still sitting in limbo, untagged.
ConvertKit automation filters stack in reverse order—here’s how
ConvertKit applies automation rule filters bottom-to-top, not top-to-bottom like every other platform.
If you’ve built a ConvertKit automation with multiple filters—say, tag exists AND custom field equals a value AND subscriber joined after a date—and it’s not triggering the way you expected, the problem isn’t your logic. It’s the order ConvertKit reads your conditions. The platform evaluates filters from the bottom of the stack upward, which means the last filter you added is the first one it checks. Every other ESP and automation tool reads top-to-bottom. ConvertKit doesn’t, and the documentation buries this detail three layers deep.
This matters most when you’re using exclusion logic or time-based conditions. If you add “tag does not exist” at the top and “subscribed after 1 Jan 2026” at the bottom, ConvertKit checks the date first, then the tag. If your mental model assumes top-to-bottom evaluation, you’ll spend an hour staring at your sequence wondering why no one’s entering. The fix is simple—reverse your filter stack so the most restrictive condition sits at the bottom—but only if you know the platform reads backwards in the first place. Most operators don’t find out until a launch-day sequence sits silent.
The deeper issue is that ConvertKit’s visual builder implies top-to-bottom logic. The interface stacks filters vertically, you add them from top to bottom, and nothing in the UI signals that execution runs the other direction. If you’re migrating from MailerLite, Kit, or ActiveCampaign, you’ll rebuild your automations assuming the same logic applies. It doesn’t, and you won’t know until you test with real subscribers or check the activity log and notice the sequence never fired.
WORTH READING
Attribution windows shorter than your sales cycle break conversion tracking
Most analytics platforms default to a seven-day attribution window. If your funnel takes longer—if readers land on your site, subscribe to your newsletter, and convert to paid three weeks later—you’re crediting the wrong traffic source or losing the thread entirely. Google Analytics, Plausible, and Fathom all impose time limits on conversion tracking, and those limits don’t flex to match your actual customer journey. If you’re running paid acquisition or testing content funnels, a short attribution window makes every experiment unreadable. You need to know the window your tool uses, how to extend it, and when the data becomes meaningless.
TACTIC
Newsletter subscriber churn happens in silence—measure it weekly
Most operators check unsubscribe rates once a month, usually when a platform sends an automated summary email. By then, you’ve lost the thread. If churn spiked after a specific send, you won’t remember what you wrote or which segment you mailed. Weekly churn measurement—calculated as unsubscribes plus bounces divided by total active subscribers—gives you a tighter feedback loop. You’ll spot the send that triggered the spike, the subject line that misfired, or the automation sequence that’s haemorrhaging readers before it costs you a quarter’s worth of growth. ConvertKit, Beehiiv, and MailerLite all surface the raw numbers; you just need to pull them into a spreadsheet every Monday and track the trend.
FROM THE ARCHIVE
Workflow automation tools trigger twice when webhooks retry
Most automation platforms—Zapier, Make, Pabbly—retry failed webhooks automatically. That’s useful when a server times out, but it becomes a problem when the first attempt actually succeeded and your app just responded slowly. The retry fires, and now you’ve charged a customer twice, sent a duplicate welcome email, or created two identical rows in your CRM. Webhook retries don’t deduplicate by default, and most platforms don’t surface retry logic in the UI. If you’re connecting payment processors, email platforms, or membership tools via webhook, you need idempotency keys, timestamp checks, or external deduplication—otherwise every retry becomes a phantom event that costs you money or credibility.
Know someone who would like this? Forward today’s email—every operator we reach is one closer to running an online business with a little less friction.