The two paths, measured 12 min live
Split Mango Lane's 144,000 PDP sessions by one question: did the session use search before or at the PDP? Search path: 43,200 sessions (30%), converting at 12% - 5,184 orders. Browse path: 100,800 sessions (70%), converting at 4.5% - 4,536 orders. The two paths sum to 9,720 orders exactly, and the conversion ratio is 12 / 4.5 = 2.67x. A minority road carrying a majority-sized payload.
LiveIs 2.67x believable? The industry range5 min▶
Search-vs-browse conversion gaps are one of ecommerce's most repeated claims, and almost all the numbers are secondary - vendor and analyst studies, not your data. Teach them as a range, with flags on:
| Source (all secondary - treat as directional) | Claimed search-vs-browse ratio |
|---|---|
| Econsultancy | ~1.8x |
| Forrester | 2-3x |
| Algolia-relayed figures (Walmart 2.4x, Etsy 3x, Amazon 6x) | 2.4-6x |
The honest summary: vendor and analyst studies put search users at 1.8-6x browse conversion, and the often-quoted "15% of visitors, 45% of revenue" is commonly cited rather than independently verified. Mango Lane's 2.67x sits mid-range - plausible, not exceptional. If your own split lands outside 1.5-6x, suspect your path definition before you suspect your shoppers.
Path exploration without drowning 12 min live
GA4's path exploration draws a tree graph: the sequences of events or screens users actually walked, one branching step at a time. The tree is honest and overwhelming in equal measure - by step three you can be staring at hundreds of branches. Two settings decide whether you drown: the direction you path in, and what you use as nodes.
LiveForward, backward, and the five node types5 min▶
- Forward pathing: pick a starting point (say, Home) and ask "what did users do next?" Good for exploring how a screen is used.
- Backward pathing: pick an ENDING point (say, purchase) and ask "how did they get here?" This is the money question - it filters the tree to only the walks that ended where you care.
- Node types: each step can show Event name, Page title, Page path, Screen name, or Screen class. Screen name is the readable one - IF you did b1's homework and named your screens. Path a tree on Screen class and you get ProductViewController soup.
- Pruning: the tree shows the top 5 nodes per step by default, expandable to 20. Metrics per node: event count and total users.
LiveThe two recipes worth memorizing4 min▶
You will open path exploration a hundred times. These two setups do most of the work:
- Recipe 1 - backward from purchase. Ending point: the purchase event, nodes: screen name. The tree now shows which roads actually produce orders, weighted by reality. This is how you would DISCOVER the two-path split in Part 1 if nobody had handed it to you: search results keeps appearing one to two steps before the PDP in the converting walks.
- Recipe 2 - forward from search results. Starting point: view_search_results, nodes: screen name. Where do searchers go next? Mostly to a PDP = search relevance is working. Back to search results again and again = it is not - shoppers are re-querying because the first answer failed. That re-query loop is the cheapest search-quality signal you own.
Self-studyFunnel exploration - path's stricter sibling4 min read▶
Path exploration discovers roads; funnel exploration measures a road you already believe in. Worth knowing cold:
- Open vs closed: a closed funnel (the default) only counts users who enter at step 1; an open funnel lets users enter at any step. Mango Lane's PDP-direct entries are exactly why the distinction matters - a closed funnel starting at Home silently drops all 54,000 of them.
- Limits and toggles: up to 10 steps, up to 4 segments side by side, an elapsed-time toggle showing how long users take between steps, and a trended view of any step over time.
- The "next action" breakdown: for users who abandon at a step, the top 5 next actions they took instead. Abandoned checkout and went WHERE is the start of every leak diagnosis (b7 leans on this hard).
Rule of thumb: path exploration to find the story, funnel exploration to measure it monthly. b4's simulator is the third sibling: change the story's numbers and watch the orders move.
Path accounting drills ★ 15 min · everyone works
Three drills, full arithmetic, no calculator shame. Drill 1 proves the split is real accounting, not a slide decoration. Drills 2 and 3 turn it into money.
LiveCompute along: verify, shift, rescue13 min▶
Drill 1 - verify the split reproduces total orders. Search path: 43,200 x 0.12 = 5,184. Browse path: 100,800 x 0.045 = 4,536. Sum: 5,184 + 4,536 = 9,720 - the exact order total from the metrics course. A path split that does not cross-foot to the real total is a broken segment definition, and you check this BEFORE presenting, every time.
Drill 2 - the mix what-if. Suppose better in-app search prominence shifts 10,000 sessions from the browse path to the search path, and both path CRs hold. New orders: 53,200 x 0.12 = 6,384 and 90,800 x 0.045 = 4,086. Total: 6,384 + 4,086 = 10,470 - that is +750 orders, +7.7% on 9,720. Name it precisely: this is a MIX play. No gate improved, no CR moved - sessions migrated from the 4.5% road to the 12% road. Same decomposition discipline as b2's 44.4% scenario, now applied to paths. (And the same skepticism applies: the 10,000 movers must actually behave like searchers - intent-holding shoppers nudged to search will; browsers forced to search may not.)
Drill 3 - the zero-result rescue estimate. Suppose 8% of the 43,200 search-path sessions hit a zero-result page, and half of those are rescuable (synonym handling, typo tolerance, better suggestions) at the normal path CR. Extra orders: 43,200 x 0.08 = 3,456 zero-result sessions; x 0.5 = 1,728 rescuable; x 0.12 = 207 extra orders per month. Small next to Drill 2 - but zero-result fixes are close to free, and 207 orders x $68 AOV is about $14,000 a month for a synonyms file.
Path hygiene 4 min live
LiveThree rules before you diagnose on paths4 min▶
- Paths are session-scoped stories. The same shopper can walk the browse path Monday and the search path Friday. You are classifying sessions, not people - do not write "30% of our CUSTOMERS are searchers" on a slide that measured sessions.
- Do not diagnose on thin paths. A path slice with fewer than ~100 conversions swings wildly month to month - the metrics course's thin-slice rule, unchanged. Mango Lane's drills work because the slices carry thousands of orders; your "iPad users who searched twice in French" slice does not.
- Unnamed screens make path reports unreadable. b1's trap, compounding: one unnamed screen is one ugly row in a table, but in a tree it pollutes every branch it appears on. Fix screen names before your first path review, not after.
Try it yourself - this week ◐ 20-25 min total
- Run backward pathing from purchase in your tool (Recipe 1: ending point purchase, nodes = screen name). Write down the top 3 roads that actually produce your orders.
- Compute your own search-vs-browse split: sessions that fired view_search_results before converting vs those that did not, each path's CR, and the ratio. Check it cross-foots to your real order total.
- Place your ratio on the 1.8-6x industry range. Outside it? Audit your path definition (is search tracking firing at all? b1's URL-param trap) before concluding your shoppers are unusual.
- Bonus: run Recipe 2 (forward from search results) and estimate your re-query loop share - searchers whose next step is another search.
Sources this session draws on
Platform documentation for the tooling, canon numbers for the store, and one honestly-flagged industry range:
Three questions before you go 🎯 ◐ 90 seconds
1 · You want to know which roads actually produce orders. Which path-exploration setup answers it directly?
Backward pathing filters the tree to converting walks - the money question. Forward from Home shows how Home is used, converting or not; Screen class nodes give you class-name soup.
2 · Shift 10,000 sessions from browse path (4.5% CR) to search path (12% CR), both CRs holding. New order total?
Recompute both slices: 6,384 + 4,086 = 10,470, a +750 (+7.7%) gain from pure mix - the sessions moved to a road that converts 7.5 points higher. Option B forgets the 10,000 stop converting at 4.5%.
3 · Mango Lane's searchers convert at 2.67x its browsers. The right way to read that number?
1.8x (Econsultancy) to 6x (Algolia-relayed Amazon) is the flagged industry range; 2.67x sits comfortably inside it. The gap is mostly intent - searchers arrive knowing what they want - so it is expected, not a UX trophy.