Paths Upcoming features

[EDsCODE]

Here's a list of features to consider that will be implemented early next week:

• Paths based on user dropoff in funnel (Funnel persons path  #5699)
• Flexible # of steps view (be able to see more or less steps based on an integer param) (Path step limit param #5675)
• Conversion rates as percentages along with absolutes
• Time distribution of step conversions (Add Path timings #5693)
• Filter paths for cohorts (already works)
• Event exclusion (easily add events you don't want to see in paths) (Enable customising which events to consider on Paths #5741)
• mix and match different types of events (Enable customising which events to consider on Paths #5741)
• specify end point (Path end point target #5746) (Note: start point is already implemented. They don't work together simultaneously yet)
• search paths between two funnel steps

Will update this ticket with specific parameters used in api as we implement.

Tagging @clarkus for a head start on designs. @mariusandra @liyiy @alexkim205 @paolodamico so you have context

[EDsCODE]

@neilkakkar feel free to adjust based on what you think we should add/remove for near term deliverables

[paolodamico]

Thanks for putting this forward @EDsCODE! Some things that immediately come to mind,

• Are paths going to show any type of events or just pageviews? How do we remove noise from autocapture in a smart way? It could be helpful to have that information but quite noisy too.
• What are we trying to solve with the time distribution of step conversions?
• Are we filtering cohorts purely or having full breakdown capabilities?
• Are we allowing breakdowns on other attributes?
• Understanding positive conversions in a funnel could help too. Particularly around the conversation on optional steps (Can we set up branched funnels with optional steps? #5515)

[EDsCODE]

1. Good question I forgot to add that you'll see mix and matched events. We can keep the categories we have now and/or allow mixmatching. This is pretty much dependent on the user experience we want to offer especially in relation to our data. The $autocapture makes our events very noisy and sometiems the backend vs frontend events together get really confusing. We can filter this any which way but should decide together what's best for paths that will make it most clear

2. Just to show how long it took for users to move from one step to the next

3. Just filtering cohorts for now. I just realized the cohort filtering for paths is still included under the property filtering so this feature is unimportant here because it already exists. I had originally thought we removed it from paths

4. We should be able to do this but I didn't include it on the immediate list

5. Yup, we discussed this. Will need to figure out how to query it but will be next up after.

[paolodamico]

Thanks @EDsCODE,

1. Great! I think @clarkus could provide some input here. Based on mockups, we can put this in front of users too and get some input from them too.
2. So the problem I see with this (and please challenge) is that you'll have to see the entire distribution to get some useful information, not sure if even the median can ensure we don't get a skewed number, outliers will play a huge role here, and then viewing the entire distribution seems like such a deep dive that I wonder if users will actually use it.
   3 & 4. Not sure if we should keep filtering by cohorts for now, I think this will provide a ton of value when you can do full breakdowns and then compare performance.
3. 👍
4. In terms of UX I think it'd be quite helpful to surface particular relevant paths (e.g. on dropoffs show paths where most of the users went), CC @clarkus. One thing I'm not sure about is if we'll want to show the most relevant paths on a step level (e.g. biggest dropoffs on step 3) or overall in the entire graph. Thoughts?

[neilkakkar]

2. I think the worth here is to see the flow of users for all paths together: It's not about specific steps (use a funnel for that!), but an overview. Say, you have path time conversions as:

/ -> /signup : 20 seconds
/ -> /blog : 500 seconds

and the counts are, say, the reverse. The time to convert is like a proxy for how much effort it takes to go down this path, which can lead to insights like: All focused users quickly go from homepage to signup, while users coming from random sources, like HackerNews either just keep the tab open for a while, or go to places other than the CTA.

Even if there are outliers, the key is that they're removed from all path considerations, and what you're comparing is 2 averages, or 2 medians: from A->X, from A-Y, and from A-Z. It's the relative difference of the averages that is insightful.

A contrived example, and maybe something like this never happens in real life, but I think it's worth testing it out. Thoughts?

[paolodamico]

I think this was from before our chat today, but yeah might be worth trying, we could potentially see some valuable information as you suggested. If we pair this up with the median (or maybe even instead) we should get a pretty good understanding of what's going on and any potential impact around effort.

[clarkus]

This is mostly an update to show some progress on design. I only have a couple of hours into this so far, so it is extremely early. Any feedback you have is welcome with that context in mind 😅

This is mostly a process shot to show how I'm thinking we could visualize paths, fixed and variable path steps, value distribution, etc. In the example below I am working with redundant headers that I'm using to summarize the highlighted path, but also layer in affordance for excluding events, adding more steps, etc. I'm also thinking about how we might implement this in a way that is similar to funnels. This is generally the same layout, but with rectangles filling the available space in the column to represent the distribution of paths / events for that step.

Notably absent from this mockup is any concept of a sankey diagram. I'm not sure they're needed to be effective here.

[EDsCODE]

I like the direction!

+ I like the structure that this provides to path flows. Sankey diagrams get pretty chaotic
+ Not relying on a sankey diagram will allow us to add more functionality to the bars themselves such as clicking for more information
+ this seems a lot more space efficient to show information

- one point that's not clear with this visualization is how you would end up seeing the multitude of connections between events when you're not highlighting a specific flow. Multitude connections meaning that there could be several events in the first column and each of them could be connected to several in the second column.

[paolodamico]

Looking great! Love the lack of sankey. To add to @EDsCODE's feedback, it's also not clear how you would highlight complete drop-offs. Also worth adding absolute numbers and percentage numbers to each step.