Reading FlowTrace Results

FlowTrace results are most useful when you read them in structural order instead of as isolated test runs.

Start with the map

The map tells you whether FlowTrace understands the funnel correctly. If the map is wrong, every downstream trace interpretation is weaker.

Focus on:

• missing pages
• duplicate pages
• CTAs that route to the wrong destination
• dead ends where you expected a continuation

Then review pathways

Pathways are the concrete routes a user can take through the funnel. A single node can belong to multiple pathways, so issues often need to be interpreted in pathway context instead of page context alone.

Then inspect traces

Each trace is the browser-verified record of what happened when Funnel Pulse walked a pathway. Look for:

• where the trace degraded or failed
• whether the failure is structural, functional, or environment-specific
• whether the problem blocks conversion or only weakens the experience

Evidence versus verdicts

The platform direction is explicit: keep structured verdicts in SQL for dashboards, and keep screenshots or other heavier evidence in blob or lake storage. If you ever see image payloads or other bulky evidence being stuffed into relational text fields, that is waste and should be removed.

Where this connects to traffic

Traffic data is now entering the platform, but it is still mostly funnel-level rather than node-level. The long-term fit is straightforward: traffic should resolve to the same map so that page views, leads, purchases, and issues can all be interpreted against the same nodes and pathways.