Fallout Filter That Silently Deletes a Segment
An e-commerce team builds a Workspace project with a fallout visualization: Step 1 = Product View, Step 2 = Add to Cart, Step 3 = Checkout, Step 4 = Purchase. The funnel shows a 92% drop between Step 1 and Step 2, which contradicts the team's analytics tool of record (which shows ~35%). A developer recently added a segment 'Exclude internal traffic' to the panel and a calculated metric 'Revenue per Visitor' that divides revenue by visits. The panel also uses a date range of 'Last 30 days' while the data view's calendar is set to a non-standard fiscal calendar.
1. List the likely causes of the inflated Step 1→2 drop and how you would isolate each.
Read the worked answer
Work from most-likely to least, isolating one variable at a time:
- Fallout scope/container mismatch. Fallout steps are evaluated within a container (visit or person). If Step 1 (Product View) and Step 2 (Add to Cart) are checked within a visit but the user's product view and cart add happen in different visits, the drop is artificial. Test by switching the fallout container between Visit and Person and compare.
- Segment interaction. 'Exclude internal traffic' applied at the panel level removes rows from all steps. If internal traffic disproportionately hits Product View but not Add to Cart (or vice versa), the ratio distorts. Remove the segment and re-measure; then apply it only where intended.
- Step definition. 'Product View' may be firing on every page (including non-product pages) or on a different event than the tool of record. Verify the exact event/dimension used per step against the source definition.
- Date range vs. fiscal calendar. The data view uses a fiscal calendar; 'Last 30 days' in Workspace resolves against that calendar. If the fiscal month boundaries differ, the window may include/exclude days unevenly, changing step counts. Switch to a rolling 30-day range and compare.
- Calculated metric leakage. 'Revenue per Visitor' dividing by visits is a metric, not a filter - it shouldn't change fallout counts, but if it's used as a step criterion it would. Confirm it's display-only.
Isolate by toggling one factor at a time and recording the drop % after each change.
2. How would you prove whether the fiscal calendar or the segment is the dominant cause?
Read the worked answer
Run a controlled comparison, changing one variable at a time and holding the other constant:
- Baseline: current panel (segment on, fiscal 'Last 30 days'). Record the Step 1→2 drop.
- Toggle segment only: remove 'Exclude internal traffic', keep fiscal range. Record drop.
- Toggle calendar only: keep segment, switch to a rolling 30-day range (or explicit dates that align to the fiscal period). Record drop.
- Toggle both: remove segment and use rolling range. Record drop.
The variable whose removal moves the drop closest to the ~35% benchmark is dominant. If removing the segment alone brings it to ~35%, the segment is the cause. If only the calendar change does, the fiscal boundary is the cause. If neither alone suffices but both together do, they interact.
Also sanity-check by pulling raw counts (not %) for each step under each condition - percentages can hide compensating errors. Document the fiscal calendar definition so the team knows why 'Last 30 days' isn't 30 calendar days.