0 of 62 agencies loaded the free AI-visibility report we ran on one of their own clients within 2 to 7 days. 4 of 43 opened the email where opens were measurable, and 0 replied

Method, stated before the numbers

The population is every address with a step-1 send in the campaign's own sent list on Instantly at the read (62 addresses; 98 sends in all, 62 first emails and 36 follow-ups; the campaign's bulk counter reports the same 98). Each first email names the agency, names one client the agency lists on its own site, states in one sentence what four AI answers said about that client, and links the report on our domain with a campaign tag in the URL. Addresses are bucketed by send day into the tracking state the message went out under, which is why the populations are compared and not pooled: P1 was sent 2026-09-02 with open and link tracking on and, through a sequence defect fixed the next day, got its follow-up nine minutes after the first email; P2 was sent 2026-09-03 and 2026-09-04 with tracking on and the five-day wait in place; P3+P4 was sent 2026-09-07 with both tracking flags off and the report link on the bare domain, after the tracked populations showed 0 of 21 Google-hosted openers (that read).

A bounce is a lead Instantly moved to its bounced status, live or preserved when the lead was deleted. Opens and replies are Instantly's per-lead counters; a population sent with tracking off cannot register an open and is marked not measurable. A report load is a PostHog pageview or report-viewed event whose path is one of the 62 report ids in the population, by any person, since 2026-09-02; 69 such rows exist on any report path in that window, 4 of them on the population's reports, and all 4 of those carry our own instrument's tag (a probe of one report on 2026-09-03) and are counted separately. The computation is the committed script `content/news/give_load_cut.mjs`; it writes `content/news/give-load-cut-2026-09-09.json` with counts only, no addresses and no report ids, and 12 of 12 self-checks pass, including that bounces, sends and replies equal the campaign's bulk counters.

By population

The one figure that moves between populations is the open count, and it moves the wrong way for a tracking explanation: 3 of 10 P1 addresses opened (8 opens between them, both touches inside nine minutes), 1 of 33 P2 addresses opened, and P3+P4 cannot be measured. The report load count does not move: 0, 0, 0. Every report link in the population was live and returned HTTP 200 on the day it was sent, and the same links are loaded by our own instrument on the day of the probe, so the 0 is the recipients, not the link.

What this rules out and what it does not

• It rules out the shared tracking host as the whole explanation. P3+P4 went out with no rewritten links and no pixel and reads 0 loads of 17 live at 2 days; the tracked populations read 0 of 40 live at 5 to 7 days.
• It does not rule out the inbox. 4 of 43 tracked addresses registered an open, and a Google-hosted recipient who opens in a client that blocks images registers nothing; the tracked read is a floor on opens, not a count.
• It does not yet rule out time. The newest 19 addresses are 2 days old at this read and the follow-up that names the report a second time has not gone to them; the oldest 10 are 7 days old with the follow-up delivered and read 0.
• It says nothing about the offer. Nobody has reached the page where the offer is made.

The pre-registered read, 2026-09-11

Set on 2026-09-06, before any P3+P4 row was sent: on 2026-09-11 every P3+P4 address is at least 45 hours past its first email. Counting real report loads plus replies across those 19 addresses, 17 live:

1. 12 or more rows with a load or a reply: the tracking host was plausibly the variable; the campaign's daily limit rises by 10 per inbox for each clean day after, to a ceiling of 50.
2. 2Exactly 1: the daily limit holds at 20 and the read repeats on 2026-09-14 on at least 30 such rows.
3. 30: the campaign pauses that day, both sending inboxes rest for 7 days, and the next change is to the offer object itself, not to the email.

On today's tape the read lands on the third branch. A second read is added here for the record: on 2026-09-16, when every P3+P4 address is at least 7 days old and has had its follow-up, real report loads on those 19 addresses are published with the same script and a dated artifact, whichever branch 2026-09-11 took.

Artifact

`content/news/give-load-cut-2026-09-09.json` holds the population count, the bulk counters, the per-population table (sent, bounced, live, follow-up sent, openers, opens, clickers, replies, real and probe report loads, age range), the PostHog row counts and 12 self-checks (0 failed). It is produced by `content/news/give_load_cut.mjs`, which reads Instantly's sent list, lead list and bulk analytics for the campaign and one HogQL query on PostHog; the address-to-report mapping stays in the repository's private prospects directory. The previous read on this campaign is the mailbox-verification cut. Written without em dashes.