Field notes · AI security
← WritingOur first month of leads was 100% test traffic — how to tell a probe from a prospect
Grey Ridge Signals Group · August 2026
Our first month of leads was 100% test traffic — how to tell a probe from a prospect
Grey Ridge Signals Group · August 2026
The August metrics line read: 27 leads, 13 qualified, 5 nurture emails sent, 0 booked calls. We published that line, and then we audited the funnel end to end. The audit found what the line did not show: every one of those 27 leads was a test address. So were the 5 nurture sends. So, for that matter, is every row in the leads table — 47 rows, zero real prospects. Zero booked calls is therefore not a funnel leak. It is the expected output of a pipeline that has never ingested a real human. This article is that audit, and what it taught us about measuring our own machine.
1. The drip was the first thing we checked — and it worked
The suspicion that started the audit was simple: we had 5 nurtured leads and 0 bookings, and we wanted to know whether the nurture drip had actually fired. It had. The nurture_actions table held 14 rows, and the execution log confirmed the full chain for every one that reached the wait node:
- 5 fired — n8n executions 66, 67, 72, 74, and 77 each ran the full 48-hour wait, resumed, and completed the Resend POST on schedule. Resend accepted them and returned message IDs; the decoded payload for the first send shows the probe's own tagline: "live booking-guard E2E verification probe — qualified lead, real-MX test address."
- 6 logged-but-never-fired — rows written with a
follow_up_atthat never sent. Their executions predate n8n's 08-17 retention window, so the cause is unverifiable from the log. Zero real impact: all six are test addresses. - 3 scheduled — pending fire at 08-31 01:53–01:55, all test addresses.
So the drip was live, on schedule, and provably working — and every address it touched was synthetic. That reframed the question. It was never "why didn't nurtured leads book?" It was "who are the leads?"
2. Then we fingerprinted the funnel
The metrics SQL that produces the published August numbers reproduces them exactly from the live database: 27 total, 13 qualified. Then we broke the 27 down by domain:
| domain | count in the 27-lead bucket |
|---|---|
| example.com (RFC-reserved test domain) | 17 |
| sigrunner.com (our own operator test domain) | 7 |
| greyridgesignals.ai (foreman heartbeat probe) | 1 |
| not-an-email / blank | 2 |
A stricter probe-exclusion query — anything @example.com or @sigrunner.com, or classified TEST — leaves 3 residual rows: one foreman heartbeat probe on our own domain and two not-an-email junk rows. No real prospect exists in the leads table. The "5 nurtured" metric was five drip emails sent to test addresses; "0 booked" follows trivially.
The uncomfortable part is that the funnel did not look broken before this pass. Our metrics harness already applies an explicit exclusion rule for test traffic — classification='TEST', email LIKE 'e2e-%', email LIKE '%test@example.com' — and that rule is real, and it did remove the obvious probe rows. The lesson is that a rule only catches what it names. The named patterns (e2e-*, test-*) were excluded; the domains the tests live on were not.
3. Why the funnel looked real: probe discipline is double-edged
None of this contamination was accidental, and that is the point. Our E2E discipline is thorough: probes are named with timestamps (E2E Form Probe 1787195878), fired through the same public webhook as real submissions, logged to the same tables, and — once we learned that Resend hard-rejects @example.com with a 422 — given real-MX test addresses on our operator domain so the full email path actually exercises. We even clean probe rows up after verification where we can.
That discipline is exactly what makes the test traffic indistinguishable from real traffic in the metrics — which is what a good E2E probe is supposed to do. The cost is that a pipeline which is good at testing itself will, left unmeasured, report its own testing as business activity. The fix is not to stop probing. It is to fingerprint: domain-level exclusions, so the monthly number is real prospects, not QA traffic. The audit's recommendation — add @sigrunner.com / @example.com exclusion to the metrics SQL — is now the standing hygiene rule.
4. What this means if you're buying security work
Every consultancy reports pipeline numbers; almost none show their work. This audit is the version of showing your work that is actually useful to a buyer, and it suggests the questions you should ask any vendor quoting lead counts or booked-call ratios:
- Ask for the raw count and the exclusion rule. "27 leads" means nothing without "27 after excluding X, Y, Z." A vendor who cannot state the rule is reporting a number they have not examined.
- Ask what happens to their own test traffic. Does their E2E testing flow through the same pipeline they report on? If yes, ask how they keep it out of the metrics — named-pattern rules, domain fingerprints, or neither.
- Ask for the residual. After every exclusion rule they can name, what is left? That residual is the actual pipeline. If it is three junk rows, the pipeline has not ingested a prospect — and that is important information about where their "0 bookings" comes from.
- Ask whether the number can be reproduced from the database. A number that survives a read-only query and a stricter filter is a measurement. A number that only exists in a dashboard is a story.
The vendors who will hate these questions are the ones whose pipeline metrics are doing marketing work. The vendors who answer them in writing — including when the answer is embarrassing — are the ones whose security claims are worth auditing too. The two behaviors tend to travel together.
5. The lever is the input, not the conversion
The practical conclusion of the audit is clean: the machine works, and it has nothing to work on. The drip fires, the triage scores, the exclusions are named — the funnel is real and the input is empty. Zero booked calls with zero real prospects is not a conversion problem; it is a traffic problem. The binding constraint on booked calls is the number of real people who find the site at all.
That is the only honest reading of this month's zero, and it is why the fix is content: publishing on a cadence, getting the site indexed, and converting readers into the first cohort of real leads — this article is part of that effort. When the first real prospect lands in the funnel, the machine is already proven to handle it: it will be scored, qualified or nurtured, and offered a call. The audit's job was to make sure that when a real human finally shows up, we can tell the difference. Book an intro call — and if you ask us about our pipeline numbers, we will show you the audit.