Daily editorial newsletter · 512,400 subscribers · 25–31 Aug 2026
Last 7 days vs prior 7
Illustrative data
Delivered
3.34M −0.2%
Open rate
41.2% −0.4pt
CTOR
9.1% −2.8pt
Revenue
$34.1K −18%
Net list growth
+4,120 +6%
Sends in range
7 SENDS
Send
Delivered
Open rate
CTOR
Revenue
Daily Brief · Mon 31 Aug
06:00 ET
477,900
41.0%
8.8%
$4,610
Daily Brief · Fri 28 Aug
06:00 ET
478,400
40.8%
8.6%
$4,380
Daily Brief · Thu 27 Aug
06:00 ET
477,100
41.4%
9.0%
$4,720
Daily Brief · Wed 26 Aug
06:00 ET
476,800
41.6%
9.4%
$5,020
Daily Brief · Tue 25 Aug
06:00 ET
476,200
41.5%
9.7%
$5,190
Revenue is down 18% but delivery held flat. Answering why means opening Deliverability, Content Summary and Audience Builder, then reconciling them in a spreadsheet. Ask the assistant instead →
Campaigns › The Daily Brief › Template
The Daily Brief · Tue 1 Sep
Promotions · v1
Illustrative data
The whole v1 is one thing: a tracked promotion slot that lives in the template editor, next to the content blocks an editor already places. No separate ad system, no external demand, no HTML editing. Click the dashed Promotion block to place it.
Blocks
Masthead
The Daily Brief
Tue 1 Sep 2026
Lead story
The quiet repricing of long-dated debt
Markets · 640 words
Section
Politics: four things that moved
Politics · 4 items
Drop a block here
Section
What we are reading elsewhere
Links · 6 items
Footer
Preferences & unsubscribe
Promotion
NOT PLACED
Place the Promotion block to configure it.
Labelled as a promotion for every reader. Not configurable, by design.
The slot renders inside the editorial flow, in the publisher’s own voice and typography, always labelled. v1 is house, cross-promotion and partner content, which sits closer to editorial than a programmatic banner and is a gentler first ask of the reader.
The Daily Brief
Tuesday 1 September 2026
Markets
The quiet repricing of long-dated debt
Thirty-year yields have moved more in six weeks than in the previous eighteen months, and almost nobody outside the rates desks has noticed.
Politics
Four things that moved
The committee vote, the resignation nobody expected, and two quieter procedural changes that matter more than either.
From The Daily BriefPromotion
B
Brief Live: the year ahead in markets
An evening with our markets desk. 14 November, London. Subscribers get first access.
Labelled, always. The promotion label is enforced, not a setting the publisher can switch off.
Frequency capped. One per reader per week by default, so a heavy sender cannot fatigue a list.
Publisher-placed. The editor chooses where it sits in the flow. No auto-injection.
Why this first
No external demand, no ad serving, no payout rails. It works at any list size, and it serves the inventory the publisher owns, which the existing LiveIntent ad block does not.
The point of the whole thing is this screen. Promotion performance reports in the campaign report, next to opens and clicks, so the lifecycle manager never leaves Sailthru to find out whether it worked.
Delivered
477,900 −0.1%
Open rate
41.0% +0.2pt
CTOR
9.1% −0.1pt
Content revenue
$4,610 +1%
Promotions
$412 New
Send breakdown · Tue 1 Sep
1 SEND
Block
Impressions
Clicks
CTR
Conversions
Revenue
Lead story · Markets
195,900
8,240
4.2%
61
$2,180
Politics section
195,900
5,110
2.6%
38
$1,390
Promotion · Brief LiveHouse
195,900
1,470
0.75%
104
$412
What we are reading
195,900
3,020
1.5%
27
$1,040
Design-partner measurement. $412 on one send is not the claim. The claim is incremental revenue per send against a pre-launch baseline, measured across three design partners over 60 days.
Success threshold set before the pilot starts: incremental revenue per send clears a defined floor, and partners say they would pay to keep it. If it does not clear, the v1 thesis is wrong and we learn that in a quarter rather than after a roadmap.
Why the ad network option is greyed out. Third-party sources consistently report a ~3,000,000 monthly email impression minimum to apply. LiveIntent does not publish it, so treat the exact threshold as unconfirmed. The deeper reason sits in LiveIntent’s own documentation: “Because Apple MPP opens all emails, regardless if an actual person sees the content, impressions would inflate, and CTR and CPM would decrease”. So they divide by an “Apple Factor” to get Adjusted Impressions. Programmatic in-email is priced in a currency the vendor itself marks down. v1 is measured on conversions and verified subscribers instead.
Not built in this prototype
Area
What it does
Why it is not here
Case study · not part of the product
The reasoning behind the prototype
Illustrative data throughout
Senior PM decision brief · Part 2
Make the product say which of its own signals it cannot trust today.
Every analytics vendor has shipped a chat box on a governed layer. The part that only makes sense on Sailthru is different: it runs on two signals, one of which keeps getting less reliable. A reporting product that flags its own unreliable signal is a Sailthru feature. A chat box is a category feature.
Recommendation
Build
Signal integrity first. Chat second.
01
Problem · why
The join between these five reports is a person.
A lifecycle manager owns the daily newsletter. On Tuesday the editor asks why revenue per email fell 18 percent last week. The answer exists. Finding it looks like this.
1
Deliverability tab. Did bounce or complaint rate spike?
2
Google Postmaster. Did domain reputation drop a tier, quietly routing mail to spam while delivered still looks fine? Outside Sailthru.
3
List and segment health. Was this sent to a broader, more lapsed slice than usual?
4
Campaign content report. Did the offer or the targeting change?
5
Web and commerce analytics. Or did something break downstream of email entirely? Outside Sailthru.
Five surfaces, two of them not even Sailthru, none referencing the others. To know which one to open first, she has to already suspect the answer. That is the failure. Not that any single report is bad, but that the product quietly made the join between them a person, and never told her.
The job, in her words
“Tell me what changed, which of these numbers I am allowed to trust today, and what to check next.”
02
Outcomes
What the business gets, and what she gets. They are not the same sentence.
Business outcome
Reporting stops being the reason accounts add a second tool
Cut the share of routine diagnoses that need an analyst, and give Sailthru an answer in renewal conversations where today it has none. Baseline measured in discovery, not assumed.
Product outcome
I get a correct, explained answer without knowing the schema
Median time from question asked to answer accepted under 30 seconds, against a current baseline of tens of minutes and, for non-analysts, often never.
Who this is for
The lifecycle or CRM manager, and the editorial growth lead. They own the sends. They are not analysts, and today the product assumes they are. The shift is that diagnosis becomes as fast as description. Today those two are hours apart.
03
Solution · how
Start with the signal integrity layer, not the chat box.
V1 · the differentiated half
Which signals can I trust, on this segment?
MPP share surfaced, so open-based conclusions are flagged and clicks substituted automatically. Attribution window stated. Sample size checked.
V1 · the table-stakes half
Ask a question, get a traceable answer
A query plan over a governed metrics layer, executed deterministically, returned with a visible source trail.
The mechanism. The model interprets and explains. Governed services calculate.
01
Question
Plain business language
›
02
Query plan
Metrics, dimensions, filters, comparison
›
03
Semantic model
Definitions, grain, account overrides, caveats
›
04
Deterministic run
Authenticated services return the numbers
›
05
Explained answer
Evidence, confidence, next check
The four things that stop it inventing a number
1. The AI produces a query plan, never a value. Execution is deterministic. 2. Every answer shows its definitions, filters, time range and sample size. 3. Hazards fire on their own: MPP share, short attribution window, small sample. 4. Out-of-model questions are refused, not guessed at. A refusal is a feature.
Unlike
Amplitude, Mixpanel, ThoughtSpot, Snowflake and Tableau have all shipped conversational analytics on a governed layer. Proposing only that here is proposing that Sailthru catch up. Unlike a chat box over the same five reports, this one tells you which of the five is unreliable today, because it is the one platform where a known event broke one specific signal and left the rest intact.
04
Assumptions
Make the uncertainty visible before committing a roadmap.
Assumption
Confidence
How I would test it, cheaply
Diagnosis is a frequent, high-cost job, not an occasional one
Medium
Count analyst requests tagged as reporting questions over one quarter. Time ten real diagnoses end to end.
Metric definitions can be governed centrally across accounts
Low
Sample 20 accounts for custom variables that redefine core metrics. This is the one that changes the size of the work.
Visible evidence changes whether people accept the answer
Medium
Show the same answer with and without the provenance block to eight lifecycle managers. Measure stated trust and whether they act.
MPP share is computable per segment, not just per account
Medium
One query against existing open events and user-agent data. Answerable in a day by anyone inside.
Ranked drivers change what a marketer actually does next
Medium
Replay six historical incidents where the true cause is already known and check the ranking against them.
The one that would change the shape of the work
Sailthru is a seventeen-year-old multi-tenant platform where accounts carry custom variables and their own attribution configuration. If custom variables define core metrics for most accounts, this is not one semantic model. It is a shared core plus a per-account layer, and the effort changes enormously. That is why I am not giving you a timeline. In that case v1 covers platform-standard metrics only, and I would scope it that way rather than promise a date I cannot defend.
05
Scope
Three question types in. Seven tempting things out.
Ship
Lookup
What happened? Governed metric retrieval with definitions, filters and a comparison period.
Ship
Compare
Where did it change? Break down by campaign, audience, content, lifecycle stage or device.
Ship
Diagnose
Which supported factors explain the movement, ranked, with what was ruled out and what cannot be seen.
Cut first, if time runs short
Saved views · sharing · scheduled reports
Convenience. Real, but not the point, and each one is a week that does not buy trust.
Scope is how it stays trustworthy. Each of these is a way to be confidently wrong in front of a customer.
06
When
Ninety days buys evidence. It does not buy a launch.
Days 1 to 30
Model the truth
Inventory the top questions, metric owners, account overrides, data freshness, permissions and the reporting discrepancies people already know about.
Days 31 to 60
Prove one answer
A thin governed path for lookup, compare and one diagnosis. The eval set is built before the interface, not after it.
Days 61 to 90
Pilot the workflow
Run with selected lifecycle marketers against their current process. Measure correctness, time to insight, repeat use and material errors.
Sequencing, and why this order
The semantic model and the eval set come before any interface. A chat box on top of neither is a demo, not a product, and it is the version of this that gets built by accident when the deadline is the roadmap.
07
Is it working
Two eval layers, five numbers, and one that blocks the release.
Layer 1 · automated, every build
Did it plan correctly?
Right metrics, dimensions, filters and time range. Does the number match a deterministic query against the same data.
Layer 2 · human, sampled per release
Is the explanation actually right?
Are the ranked drivers the real cause, or a plausible correlation? Automated grading cannot judge this, and pretending otherwise is how these ship broken.
Five scores, graded per release. Plan accuracy, numeric correctness, driver correctness, refusal correctness, hazard recall. A regression on any one of them blocks the release.
Primary
Time to accepted answer
Median, question asked to answer accepted. The problem statement restated as a number. If this does not move, nothing else matters.
Supporting
Weekly active share
Do they reach for it, or quietly go back to the old reports?
Supporting
Answer acceptance rate
Usable, not merely fast.
Guardrail
Materially wrong answers
Near zero, hard ceiling, blocks release. One confidently wrong revenue number costs more trust than fifty good answers earn.
Scale when
Answers are materially faster, clear the eval bar, earn repeat use, and reduce manual reconciliation.
Stop or reshape when
Definitions cannot be governed, users do not trust the evidence, or the error risk outweighs the time saved.
08
Evidence boundary
What is sourced, what is my judgement, and what I invented for the demo.
Sourced
Checkable today
Sailthru has standard and custom reporting, filtering, a once-daily refresh on BI Hub, lifecycle metrics, real-activity engagement levels and role-based permissions. The MPP mechanism and its effect on open data.
Inferred
My product judgement
That a governed semantic layer plus deterministic execution is the right mechanism here, and that signal integrity is the differentiated half. This is my product proposal, not a documented Zeta plan.
Illustrative
Invented for the demo
Every number in the live prototype. The Daily Brief itself, the dollar values, the cohort shifts, the driver contributions and the 54 percent privacy-affected share are fabricated demo data.
Sailthru BI Hub FAQReports, filters, once-daily refresh, exports. The refresh cadence is a direct quote.
I had the Morning Brew story backwards and reversed it. I dropped a pricing comparison when the source would not hold. And I demoted a third-party impression threshold to “reported, not vendor-published”. Each is flagged on the slide where it appears. I would rather show you the corrections than a clean deck.
Senior PM decision brief · Part 3
Ship the outcome-priced monetisation before the impression-priced one.
The obvious move is to put a LiveIntent slot in the Sailthru template. Zeta owns both. I read LiveIntent’s own documentation before recommending it, and it changed my answer. Programmatic in-email is sold in a unit the vendor itself marks down.
Recommendation
Start
Tracked promotion slot. LiveIntent is v2.
01
Problem · why
Publishers monetise the newsletter everywhere except the tool that builds it.
A publisher assembles the send in Sailthru, then leaves it to sell, place, traffic and reconcile whatever pays for it. The house promotion is an image block with a tracked link. The revenue lands in a spreadsheet. Nobody can answer “what did this send earn?” without joining two systems by hand at month end.
The job, in their words
“Show me what this newsletter earned, next to what it did, without me exporting anything.”
02
The finding that decided it
In-email advertising is priced in a currency the vendor itself discounts.
The ad unit inside an email is an image, because mail clients will not run software. The client fetches it on open, and that fetch fires the auction. Apple opens every message before the reader does.
LiveIntent knowledge base, on their own platform
“Because Apple MPP opens all emails, regardless if an actual person sees the content, impressions would inflate, and CTR and CPM would decrease.”
So they divide by an “Apple Factor” and report Adjusted Impressions, which they note will always be lower than the raw number. The correction is honest and it works for billing. It does not work for a publisher deciding whether an advert is worth the cost to their reader relationship, and it does not work for me deciding in ninety days whether this was worth building.
And the eligibility bar is measured in the same inflated unit
Third-party sources consistently report a three million monthly impression minimum to join the network. LiveIntent does not publish it, so I would confirm it rather than assert it. If it holds, it also excludes most of the mid-market Sailthru serves.
03
The choice
Four ways to start. I would reject two, sequence one, and ship the fourth.
Starting option
What it needs that does not exist
Measured in
Decision
Build an advertiser marketplace
Demand, sales, billing, matching, trust
Impressions
Reject
Direct sponsorship operations
Inventory, booking, contracts, invoicing
Negotiated flat fees
Later
LiveIntent ad block
Nothing. It ships today in Visual Composer. Needs a linked account and inventory configured in LiveIntent, and will not render on triggered sends.
Adjusted impressions
Already there
Tracked promotion slot in the template
A slot primitive and a revenue row. That is all.
Signups and conversions
Start here
Why the fourth
House ads, cross-promotion and paid recommendations are measured on verified subscribers, signups and conversions. Things a human demonstrably did. There is no factor to divide by. It works at any list size, so it reaches the whole base rather than the top of the enterprise tier. And it serves the inventory the publisher owns, which the ad block does not.
04
Solution · how
Two kinds of inventory, and only one of them has a slot today.
01
Template editor
Already exists
›
02
Promotion slot
v1 builds this
›
03
Send and open
Already exists
›
04
Tracked event
v1 builds this
›
05
Campaign report
Plus a Promotions row
What already exists, and what does not
Sailthru already ships a LiveIntent ad block in Visual Composer. It serves bought demand, needs a linked account and inventory configured in LiveIntent, and does not render on triggered sends. What it does not serve is the inventory the publisher owns, and nothing shows what a send earned across both routes. Two commercial jobs, one send, and one report that does not exist yet.
05
The v1 user
The publisher. There is no advertiser in v1, and that is the point.
The publisher gets
Revenue from sends they already make
Placement and frequency they control, inside the editorial workflow they already use. One report instead of a monthly reconciliation.
Zeta gets
The answer to the riskiest question
Evidence on the thing that decides everything downstream: will a lifecycle marketer place a monetisation module in an editorial send and trust what it reports? Cheap to find out, and nothing else in this plan works without it.
The objection I would raise if I sat where you do
You already ship an ad block. The LiveIntent block is in Visual Composer today. But it serves bought demand. It does not serve the inventory the publisher owns, and nothing gives one view of what a send earned across both. That is a different commercial job, and it is the one I would start with.
06
Assumptions
The two that actually kill this are not technical.
Assumption
Confidence
How I would test it, cheaply
Publishers want to monetise the newsletter at all
High
Already evidenced by the market. This one is not the risk.
A slot primitive fits Zephyr and the drag-and-drop editor
Medium
Two-day technical spike with the platform team.
The campaign report can carry a new revenue row
Medium
Same spike. Read the reporting schema.
Two or three design partners will pilot it
Medium
Account overlap analysis, then four sales conversations.
LiveIntent sales agree this does not cannibalise them
Low
One conversation, held early. If it goes badly the plan changes shape.
Sailthru and LiveIntent teams can execute as one this soon after an acquisition
Low
Not testable from a document. Ask in week one.
Read the bottom two rows
Both low-confidence items are relationship risks, not engineering risks. Whether LiveIntent sales see this as cannibalisation, and whether two recently acquired organisations can ship one thing together. Those kill it. The slot primitive does not.
07
Where I would start
The first thing I would do is not build anything.
1
Pick two or three design partners who use both Sailthru and LiveIntent, deliberately spanning the eligibility line. At least one above the threshold and one below, because those two have different problems and I want to know whether one module serves both.
2
Map their current stack and revenue per send. What tools, what manual work, what it earns today. That is the baseline, and without it I cannot claim incrementality later.
3
Define one placement and one report that would let them retire a single piece of that stack. One, not a suite.
4
Ship it to those three. Measure incremental revenue per send and integration effort removed. Then generalise.
Success threshold, set before the pilot starts
Incremental revenue per send clears a defined floor, and partners say they would pay to keep it. If it does not clear, my v1 thesis is wrong, and I would rather learn that in one quarter with three publishers than after committing a roadmap.
08
Evidence boundary
What is sourced, what is my judgement, and what I invented for the demo.
Sourced
Checkable today
The MPP mechanism and LiveIntent’s Apple Factor, quoted from their own knowledge base. Zeta’s acquisition of LiveIntent in 2024 and of Marigold in 2025. beehiiv’s three monetisation mechanisms.
Inferred
My product judgement
That the publisher’s own inventory is the right place to start, given that bought demand is already served by the existing ad block. This is my recommendation, not Zeta’s roadmap.
Illustrative
Invented for the demo
The Daily Brief, the promotion, the $412, the send breakdown and every number in the Campaigns mockup. All fabricated. The $412 on one send is not the claim; incremental revenue per send against a pre-launch baseline is.