[object Object]

The Mistake That Sends Marketing to a Million People

The most expensive HubSpot mistake of 2026 — the one I’ve seen six teams make in the past quarter — is a list with mixed AND/OR criteria that the builder thought was constrained, and was not. Marketing previews it. The preview says “12,400 contacts.” They send. It actually went to 940,000 because of how the filter groups resolved at send time.

This is a Boolean misread, not a bug. HubSpot’s list builder is doing exactly what was configured. The configuration is just not what the marketer thought it was.

Where the Misread Happens

The list builder groups criteria visually. Inside a group, criteria default to AND. Between groups, criteria default to OR. That’s correct, well-documented, and immediately wrong in your head if you grew up writing SQL.

Concrete example. A marketer wants “contacts who are in the ‘Engaged’ lifecycle stage AND in the ‘EMEA’ region AND have opted into product updates.” They build three filter rows. They’re in three different groups by default in the UI. The list resolves to “Engaged” OR “EMEA” OR “opted in” — a union, not an intersection. Preview shows the size of the largest group. The send goes to all three combined.

The version where the marketer thought through it correctly looks like one filter group with three AND criteria. Same three statements, different containment, and the size drops from 940K to 12K.

How to Audit Before You Send

Run this four-step check on any list above 50K contacts before campaign attach.

  1. Read the group boundaries out loud. “Anyone who matches group 1 OR group 2 OR group 3.” If that’s not what you meant, regroup.
  2. Check the size at each filter level. Add criteria one at a time and watch the count. The count should drop with each AND; if it stays flat or grows, your filter went into a new group.
  3. Re-create the list with the inverse. Build “everyone except this list” and check that the size adds up to the contact total. Audit math should reconcile.
  4. Compare to the previous campaign’s list size. If you’re suddenly sending to 10× the usual audience, that’s the alarm.

The four steps add about 10 minutes to a campaign send. They have caught 100% of the false-positive segments I’ve audited in 2026.

The “Refine” Trap

The “Refine” button on a saved list applies new criteria to the existing list — and looks like it’s adding AND clauses. It’s actually creating a new filter group, so the new criteria are OR’d against the original. If you “refine” a list of 100K contacts by adding “country = Germany,” you may not have refined; you may have added every German contact to a list that already had everyone in EMEA.

I default to never using Refine for production sends. Open the list, edit the original filter, and read the groups before saving.

What to Do When You Already Sent

If a send went to a too-large audience, the playbook is the same:

  • Pause downstream automation immediately (workflow enrollment usually fires off the send).
  • Audit unsubscribes from the send — that’s the real cost. Recovering unsubscribed contacts is essentially impossible.
  • Re-segment for the next send with the audit above. Do not “re-send the right list.” Wait at least a week and treat it as a separate campaign.
  • File the issue with marketing ops with a screenshot of the original filter groups. Pattern recognition prevents the same misread next quarter.

What HubSpot Won’t Do for You

HubSpot will not tell you that your segment grew unexpectedly. There is no anomaly detection on list size pre-send. The preview count is accurate but offers no comparison to historical sends. The size limit error only fires above the marketing-contacts ceiling, not above your campaign norm.

That gap is what the audit closes. Make it a step in your campaign QA checklist; it’s the cheapest insurance the marketing org will ever buy.

What to Do This Week

Pick your three largest active segments and re-read the group boundaries out loud. If you find one that’s OR where you wanted AND, fix it and re-check the size. If the size moves by more than 20%, you just prevented a bad send.

[object Object]
Share