Inside DROP: is the funnel step broken, or is it the offer?

Short answer: a funnel report tells you where people leave. It doesn't tell you why. Before anyone argues about button colours, DROP checks the boring causes first: is the step reachable, does it redirect and split your tracking, is there a next action on the page at all? Only when a step is technically clean does DROP call a big fall a UX or expectation problem.

The usage guide is DROP: how it works. This is the triage order.

What you paste in

Up to 10 steps, as step | url | drop, as CSV or TSV with headers, or as bare URLs. Paths like /checkout work if you also give the site origin. The drop column is forgiving:

• 18% is read as 18%.
• 1200/180, 1200 -> 180 or 1200 to 180 is read as in-and-out counts, giving (1200 - 180) / 1200 = 85%.
• A bare number from 0 to 100 is taken as a percentage.

Anything else is kept as a label, but not used in the maths.

The triage order, under the hood

DROP fetches each step, follows redirects, and reads the title, H1 count, forms, buttons, CTA-classed links, submit inputs and noindex. The first match decides the lane:

1. Not a valid URL (P0, Tracking): fix the step definition.
2. Couldn't fetch, or a 5xx (P0, Eng): fix the origin before reading any funnel number.
3. 404 or 410 (P0, Eng): the step URL is gone. Fix the link or the tracked URL.
4. 403 (P0, Eng): people (and this check) can't reach the step as pasted.
5. Redirects (P1, Tracking): the funnel may be split across two URLs. Track the final one.
6. No visible next action (UX): P0 when the drop is 50% or more, P1 otherwise.
7. H1 count isn't one, or no title (P1, Content): tighten the page's promise before blaming the funnel.
8. Sound, but a drop of 50% or more (P0, UX): now it really is a UX or expectation problem. Check the step before it, and what this page asks for next.
9. Sound, under 50% (P2, Tracking): if the number still looks wrong, verify the event with VERA before changing the page.

The 50% line isn't a benchmark. It's the point where DROP stops treating a fall as noise worth a P1 and starts treating it as the main suspect.

Edge cases

• Trailing slashes count as redirects. DROP compares the URL you pasted with the URL that answered, exactly. Paste https://samplebrand.test when the site answers on https://samplebrand.test/ and you'll get a redirect ticket. Paste URLs as they resolve.
• Script-rendered checkouts. The checks read the server HTML. A checkout that draws its form with JavaScript can read as "no next action". Confirm in a browser, and if that's what happened, file it as a rendering note, not a UX fix.
• Login walls. A 403 or a redirect to login may be correct for a logged-in step. DROP flags it, and you decide whether it's expected.

Worked example

Product | https://samplebrand.test/kits/blue-kit | 3400/1200
Basket  | https://samplebrand.test/basket       | 1200/180
Payment | https://samplebrand.test/pay          | 12%

Live: /kits/blue-kit 200, form present, 1 x h1
Live: /basket 301 -> https://samplebrand.test/cart
Live: /pay 200, button present, 1 x h1

The 85% basket drop looks like a UX disaster. But the basket URL redirects to /cart, so the funnel step is probably counting the wrong page. Fix the tracked URL first, then re-read the drop. The product page's 64.7% fall is technically clean but over 50%, so it's a P0 UX question: price, delivery, or what the button promises.

Run it: open DROP

The money angle

Funnel steps sit closest to revenue, so mistakes there cost the most. Redesigning a step on the strength of a broken tracking setup burns design time and can make conversion worse. DROP's order means engineering and tracking faults are cleared first, so the fix you pay for targets the real leak.

Pair it with LAND for the entry pages, and value the fix in PAYBACK before it goes into a sprint.