Rebuilt on the brief that this page is mostly external — NetRevenue looking at how their funnel is performing, not us deciding what to fix. That is not a coat of paint on the three options below; it changes what the page is made of. Same real numbers, Aug 14–24 against the prior 11 days.
Option B’s shape, rebuilt for an outside reader. Every stage carries its own movement against the prior period, and the number in each taper is the one that actually describes funnel health: the share that continued. Drop-off is drawn in neutral grey, not red — in a high-ticket application funnel most visitors are supposed to stop, and colouring that as failure is both alarming and wrong.
Band width is the true share of traffic — nothing is scaled up to look better. The one stage that softened is the first click into the application (15.0%, down 5.9pt), which is what usually happens when traffic grows this fast; it is stated plainly rather than buried, and it is the stage we are working on.
wf_gate, the operator master) than
for NetRevenue (wf_c_nr, their own link password), and
app/[client]/layout.tsx already reads both to authorise the page. So the audience
is known server-side today, with no new plumbing: render the performance funnel for
everyone, and append the leak ranking and the cost-per-step table only when the operator
cookie is present. One page, one URL, two readings — and no risk of a diagnostic panel
reaching a client because you sent the wrong link.booked is NULL on every NR row. Externally that is worse than internally
— the client counts calls, so a funnel that stops before the call is the step they most
want to see missing. Wire it from the call log, or retitle the page.
Diagnosis first. The funnel compresses to five thin rows on the left — enough to see the shape — and the right half ranks where you are losing people and money, worst first. You read the answer before you read the data. Best if this page's job is to tell you what to go fix on Monday.
Bars are share of landing page views, so every row is comparable to the top.
Ranked by rate, not headcount — otherwise every small step looks fine next to the top of the funnel. Spend is attributed pro-rata to the traffic lost, so treat it as an order of magnitude, not an invoice.
An actual funnel. Each band's width is its real share of traffic and the taper between two bands is the loss, so the cliff between view and application start is physically visible rather than stated. It is brutal on purpose: that is what an 85% first-step loss genuinely looks like. Best if this page is ever shown to NetRevenue.
Band width is the true share of traffic, which is why the qualified band is a sliver — 30 people out of 998. Nothing is scaled up to look better.
The same funnel priced. One dense table, one row per step, and the column that matters is the last one: what each step costs you. $10 a view becomes $336 a qualified application, and the jump from $10 to $67 is the whole story in a single number. Best if this page's job is to feed budget and CAC decisions.
| Step | Count | Of views | Of prior | Lost | Cost each |
|---|---|---|---|---|---|
Landing page views |
998 | 100% | — | — | $10 |
Application starts |
150 | 15.0% | 15.0% | −848 | $67 |
Contact step |
94 | 9.4% | 62.7% | −56 | $107 |
Applications |
82 | 8.2% | 87.2% | −12 | $123 |
Qualified applications |
30 | 3.0% | 36.6% | −52 | $336 |
| — | — | — | — | not wired |
“Of views” is the absolute survival rate; “of prior” is the step-to-step rate the current page shows. Both matter, and only showing the second is what makes 87.2% look like good news when it is 8% of the people who arrived.
booked is NULL on every NR row, so the funnel stops at qualified. Either wire it
from the call log or retitle the page — right now it promises a step it cannot show.