- Grow 📧 Monetize
- Posts
- 📩 Build your BSS in one prompt
In partnership with
Your engaged segment is probably built on opens.
That means it is keeping subscribers no human has ever touched.
A Base Sending Segment fixes that. It decides who gets each send based on clicks, and it is built as a dial you tighten and loosen, not a filter you set once and forget.
This issue does two jobs. It walks you through the framework. And it hands your AI assistant the exact instructions to build one in beehiiv through the MCP, asking you the right questions as it goes.
Paste the link to this post into your AI with the prompt further down. It takes it from there.
Blu Dot surpasses 2,000% ROAS with self-serve CTV ads
Home furniture brand Blu Dot blew up on CTV with help from Roku Ads Manager. Here’s how:
After a test campaign reached 211,000 households and achieved 1,010% ROAS, the brand went all in to promote its annual sales event. It removed age and income constraints to expand reach and shifted budget to custom audiences and retargeting, where intent was strongest.
The results speak for themselves. As Blu Dot increased their investment by 10x, ROAS jumped to 2,308% and more page-view conversions surpassed 50,000.
“For CTV campaigns, Roku has been a top performer,” said Claire Folkestad, Paid Media Strategist, Blu Dot. “Comping to our other platforms, we have seen really strong ROAS… and highly efficient CPMs, lower than any other CTV partner we've worked with.”
Using Roku Ads Manager, the campaign moved from a pilot to a permanent performance engine for the brand.
*Ad
Why opens cannot tell you who is human
Apple Mail Privacy Protection fires your tracking pixel before your subscriber has even seen the subject line. Image prefetchers fire it. Corporate security scanners fire it.
That is opener bloat: subscribers your ESP reports as openers who have never clicked anything.
A ghost opens every send. It is the most reliable opener on your list. So it clears any open-based filter you set, no matter how tight you make it.
Clicks are the most reliable human signal you have. A Base Sending Segment is built around them. A subscriber gets your next send if they match any one of four branches:
Branch 1: Clicked in the last X days. This keeps your active readers.
Branch 2: Opened in the last X days AND clicked ever. This keeps readers who proved a human is behind the pixel.
Branch 3: Opened in the last X days AND subscribed within X days. This keeps new subscribers who are still settling in.
Branch 4: Subscribed in the last X days. This keeps brand-new subscribers, no activity required.
Branch 2 is the one that kills opener bloat. An open only counts if there is a click somewhere in that subscriber's history. One click, ever, and their opens mean something. Zero clicks and a long tenure, and they are gone.
Raw clicks are not verified clicks
Scanners do not just fire pixels. They follow links too.
On a list I run, raw clicks come in about 42% higher than verified clicks. That gap is machines.
beehiiv tracks both. Your BSS runs on verified clicks. Build it on raw clicks and you have let a chunk of the ghosts back in through a different door.
SOC 2 Ready in 14 days. Three sessions from you.
Enterprise buyers will not put your product near their customer data without a SOC 2 report. Sprinto gets you audit ready in 14 days, across three working sessions. AI agents do the collecting, you approve. Your auditor signs off.
*Ad
Your windows count sends, not days
Every X in those four branches is a window. There are four of them:
Click window (branch 1): how many sends can a past clicker go without clicking before they drop out?
Open window (branches 2 and 3): how recent does an open need to be to count?
Grace window (branch 3): how long do new subscribers get to prove themselves with opens alone?
New-subscriber window (branch 4): how long does a brand-new subscriber get sends with no activity at all?
Think about what a number in the settings actually means. A 30-day window at twice a day is 60 sends. At once a week, it is four or five. Same setting, completely different segment.
So you pick each window in sends first, then convert to days for beehiiv:
Window in days = sends in window ÷ sends per week × 7
A publisher who copies someone else's day values without matching their cadence ends up with a segment that is either far too loose or far too tight. That is why the AI asks for your cadence before anything else.
Where to start your windows
These are starting points, not finish lines. Run them, look at the results, then adjust.
Once a week: click window 120 days (about 17 sends), open window 120 days (about 17 sends), grace window 120 days (about 17 sends), new-subscriber window 90 days (about 13 sends).
Daily: click window 90 days (90 sends), open window 60 days (60 sends), grace window 120 days (120 sends), new-subscriber window 15 days (15 sends).
Written out as rules:
Once a week: clicked in the last 120 days, OR opened in the last 120 days and clicked ever, OR opened in the last 120 days and added in the last 120 days, OR added in the last 90 days.
Daily: clicked in the last 90 days, OR opened in the last 60 days and clicked ever, OR opened in the last 60 days and added in the last 120 days, OR added in the last 15 days.
Notice the daily windows are not the weekly ones scaled down. A daily sender's new subscribers get 15 sends with no activity required, and a weekly sender's get about 13. The send counts land close together even though the day values are far apart.
One rule holds at any cadence: the grace window has to be longer than the new-subscriber window. If it is not, branch 3 adds nobody that branch 4 did not already cover.
The prompt that does the building
You need an AI assistant with the beehiiv MCP connected. Then paste this:
Read this guide in full, then follow its "Instructions for the AI assistant" section step by step: [link to this post]
Using my beehiiv MCP connection, build a new Base Sending Segment for my publication. Ground rules:
- Ask me one question at a time and wait for my answer before moving on. Use tappable options whenever the answer is short.
- Every window value must come from my answers or from the defaults printed in the guide. Never invent or interpolate a number.
- Do not edit, delete, or replace any existing segment, and do not attach the new one to any post, template, or automation.
- Show me the full summary of settings and wait for me to choose "Build it" before you create anything.
Do not just type "create a Base Sending Segment" without the link. The BSS is a framework, not a beehiiv feature, and your AI does not know what it is. Without this post it will guess, and its most likely guess is an open-based engaged segment. That is the exact thing you are trying to replace.
Instructions for the AI assistant
If you are an AI assistant reading this post, follow these steps in order. Ask the user one question at a time. Never invent a window value. Every number in the segment comes from the user or from a default printed in this post.
How to ask questions
Use tappable options or buttons for every question with a short set of answers, if your interface offers them. Many readers are on their phones. If it does not, ask in plain text and number the options.
Ask one question per message. Wait for the answer before moving on.
Put the recommended option first and mark it "(Recommended)".
Always include a "Something else" option so the user can type their own value.
Use at most 4 options. If there are more choices than that (for example, more than 4 publications), list them in text instead.
Give open-ended number questions buttons too: offer the recommended value and "Something else."
Step 1: Find the publication. Call list_publications. Ask the user which publication the segment is for, even if there is only one. If the publication uses newsletter lists, ask whether the segment covers the whole publication or one list.
Step 2: Check what is already there. Call list_segments, and get_segment on anything that looks like a current sending or engaged segment. Show the user its conditions in plain language. If opens alone qualify someone in it, say so: that is opener bloat. If more than one segment looks like the current sending segment, ask which one to compare against in Step 8, with the candidates as options. Do not edit or delete any existing segment. The BSS is always created as a new segment.
Step 3: Get the sending cadence. Ask: "How many emails do you send per week to this audience?" Then check it. Pull the last 30 days of sent posts and compare. If the real cadence differs from the answer, show both numbers and ask which to use, with both numbers as options. Every window depends on this number.
Step 4: Ask for each window in sends. Ask these four questions, one at a time, in this order. After each answer, convert to days with days = sends ÷ sends per week × 7, rounded to the nearest whole day. Tell the user the day value before moving on.
1. Click window: "After how many sends in a row with no click should someone who used to click stop receiving your emails?"
2. Open window: "How many sends back should an open still count? Opens older than that are ignored."
3. Grace window: "For how many sends should a new subscriber stay on the list with opens alone, before they need a click?"
4. New-subscriber window: "For how many sends should a brand-new subscriber get your emails no matter what they do?"
With each window question, offer the starting value for the user's cadence from "Where to start your windows" as the recommended option, in sends and in days, plus "Something else." Include the one-sentence tradeoff: a longer window sends to more people and lowers density; a shorter one sends to fewer and raises it. If they send once a week or daily, use that set of defaults. If their cadence falls between the two, do not recommend a value. Show both sets, say neither was built for their cadence, and ask them to pick. Do not interpolate a number yourself.
Run these checks before moving on:
The grace window must be longer than the new-subscriber window. If it is not, branch 3 does nothing. Tell the user and ask them to change one.
If the open window is longer than the click window, point it out and ask whether that is intended.
Step 5: Confirm the click signal. Call get_segment_schema. If verified_unique_clicks is listed, use it for branches 1 and 2. Tell the user you are using verified (bot-filtered) clicks and why. If it is not available, stop. Tell the user raw clicks include scanner traffic, and ask before falling back to unique_clicks.
Step 6: Confirm before building. Show one summary: the publication, the cadence, each window in sends and in days, the click signal, and the segment name. Name it Base Sending Segment (BSS) - C/O/G/N using the day values. Ask for confirmation with the options "Build it" and "Change a setting." Build only after the user says yes.
Step 7: Build it. Call save_segment with segment_type set to dynamic. Use this where clause, replacing C, O, G and N with the day values for the click, open, grace and new-subscriber windows:
verified_unique_clicks(within: 'C days') > 0 AND status = 'active'
OR unique_opens(within: 'O days') > 0 AND verified_unique_clicks > 0 AND status = 'active'
OR unique_opens(within: 'O days') > 0 AND signup_date >= NOW() - INTERVAL 'G days' AND status = 'active'
OR signup_date >= NOW() - INTERVAL 'N days' AND status = 'active'
Send it as a single line. Three things to know about the beehiiv DSL:
It rejects nested groups. That is why status = 'active' repeats inside every branch instead of wrapping the whole clause in parentheses.
AND binds tighter than OR, so the clause reads as four branches with no parentheses needed.
beehiiv may rewrite day values as months (120 days becomes 4 months). Tell the user if it does. The drift is a day or two at the edges.
Step 8: Verify and report. Poll get_segment until its status is completed. Then:
Report the member count. If there was an existing engaged segment in Step 2, report its count too. The difference is the user's ghost count: subscribers the old segment kept that the BSS does not.
Tell the user to spot-check one long-tenured clicker in the beehiiv editor. verified_unique_clicks with no window should mean lifetime. Confirm it does not default to a shorter lookback.
Offer to calculate engaged audience density: 30-day verified clickers ÷ BSS size. That needs a temporary segment for the 30-day clickers, so ask before creating it, with the options "Create the density segment" and "Skip."
Do not attach the segment to any post, template or automation. The user decides when to start sending to it.
The AEO work, without the AEO hire.
Most AI visibility tools show you where you rank, then leave the work to you.
ChatFeatured is an AI search agent that does it: finds the questions competitors win, drafts the content in your voice, and tracks the lift.
Your team decides what ships. Month to month.
*Ad
Now start turning the dial
The segment will come out smaller than your old one. That is the point.
Density beats size. The subscribers you just stopped mailing were dragging down the numbers mailbox providers read before they ever read a word of your content.
Do not treat the member count as the result, though. Interrogate it.
If your BSS came out barely smaller than your old engaged segment, check whether it is really running on verified clicks. If it came out drastically smaller, check your windows against your cadence before you panic. The question is whether the number makes sense for how often you send.
Here is your Monday morning:
Write down your ghost count and your BSS size. That is your baseline.
Point your next send at the BSS instead of your old segment.
Watch placement and verified clicks for the next several sends.
Tighten the windows when Postmaster signals turn. Loosen them when they recover.
Setting the windows is the part most operators get wrong, because it depends on your cadence and your list. Build yours, then reply with your four window values and your ghost count. I will tell you whether they make sense for how often you send.
GM.