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.

[clarkus]

Thanks for the feedback. I was thinking dropoffs could just look like dead ends in the path - no connection to the subsequent column and color changes to look less actionable. The step summary in the top the chart would have absolute and percentage numbers.

Event connections would be represented by starting at the same offset, or at an offset within the original bounds of the previous step. Hovering will highlight the exact path taken, but the relationship would still be communicated via the alignment mentioned previously. We would also see events repeated across multiple steps - For example in the previous comment, we might see "view product page" as the second largest event in step 2, but it also accounts for a large portion of step 3.

[clarkus]

I feel like I didn't do a great job explaining the event/path context in the previous examples. Here are a few illustrations that show how subsequent events are drawn in the context of the preceding event. Because we're representing total volume with height, we show subsets of that total potential volume in subsequent steps. This work just like funnels, except we have multiple paths in each step. Because of this, distinct paths tile under paths with a higher volume of sessions. In this way we always represent subsequent paths in the context of the previous path. Note that this is for path starting from a given point. the opposite would be tree of paths / events leading into a specific point.

Hopefully that's a clearer explanation of how I'm approaching this right now. I'm happy to talk through the ideas on a call if that helps answers everyone's questions. Thoughts @paolodamico @EDsCODE?

[neilkakkar]

This makes a lot of sense to me! I guess then: there wouldn't be any headers like in the previous diagram? And all of the information (like path name, average conversion, %, count) would be either on hover, or inside the box itself?

Or is the header like an extra bar that shows up on hover, showing the exact steps taken to get here?

[clarkus]

Oh sorry these are super bare bones wireframes. I should have said that. This is mostly me working out the visualization rules so I can be sure I communicate how we implement. I still need to layer in headers, menus, and other established things. I'm currently working through paths with starting and ending points specified. After that I should be ready to draw and share some higher fidelity work.

[neilkakkar]

Ah, when I said "header" I meant this:

I wasn't being 100% clear either.

But yeah, the basic concept makes sense to me. And it seems a lot more clearer than sankey diagrams.

One thing that remains unclear to me with such a representation is: how does merging back work? For example, if in the second bar you havs X, Y, Z events, all of which are followed by the A event, would we then have 3 different A events in the 3rd column? (one corresponding to the context of each of X, Y, Z) ?

I think where sankeys stand out is merging these back together well: makes it clear that this particular path item is popular, showing how N events lead to it. Thoughts on how best to represent this?

[clarkus]

I was seeing that header bar as a summary of the highlighted path. So if you're hovered over checkout in step 5, it summarizes the highlighted path to that point. If you moved your cursor down to a distinct event, you'd see the path change to reflect that route.

I think where sankeys stand out is merging these back together well: makes it clear that this particular path item is popular, showing how N events lead to it. Thoughts on how best to represent this?

There's no re-aggregation of common paths / events to show the consolidated counts. Instead the popular paths / events are repeated in the context of the preceding step. So if you had a popular step (view product page) you'd see that repeated in the step column.

[clarkus]

Here are more process shots for how we might expose inline actions for steps and events. In this example, there is a fixed starting page (landing page). All subsequent steps will be shown in the context of the previous step. In this example, you'll see landing > search > added to cart > delivery and landing > item detail page > view ratings > added to cart illustrated as the top paths. We are showing the top paths grouped by the events with the highest percentage of sessions in step 1. The opposite would be true if you were analyzing paths leading into a specific event or path item. If both a starting and ending point were specified, it would reduce the total number of paths represented. As more steps were added, you could expect to see more variety represented in each grouping.

Note that this is the key difference between this visualization and a sankey diagram and gets to the heart of @neilkakkar's statement above:

I think where sankeys stand out is merging these back together well: makes it clear that this particular path item is popular, showing how N events lead to it. Thoughts on how best to represent this?

This makes me wonder if we would benefit from distinct rendering modes - top paths OR top path items. Thoughts?

https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/PostHog-App?node-id=3260%3A37220

[marcushyett-ph]

Just thinking through Neil's point round other events leading to the same "primary end state"

This opens up questions about highlighting interstitial steps which are in different stages e.g. view item

[neilkakkar]

Trying to think through what users want out of Paths, and I guess I'm a bit unclear where most value lies.

1. If they want to find the most popular intermediate paths, then the sankey-like representation makes sense. (This one raises more questions for me: What do the conversion %s, timings mean after this path? Do you consider the base as the sum of all paths leading upto this event, or just the slice above)

2. If they want to "see what specific paths users take", a.k.a something that ties well with how they think about funnels.

(2) seems more often used to me, and the current designs solve for (2) well!

Just want to make this explicit, that we're changing semantics of paths (and what problems they solve) with this upgrade. Could use some product input with what problems (1) solves?

Side Note: Would be cool to have the option to create funnel out of a highlighted path. Allows me to then do more exploration along breakdowns, quant analysis, for the specific path.

[marcushyett-ph]

The core user need behind our focus on paths is:
Users need to understand why people are / are not successful with their product, so they can make it more successful

If I break this down into a couple of sub-problems - both of these align with your point 2:

• I need to understand the path of least resistance - so I can push more people through this path (e.g. the path most people took to be successful)?
• I need to understand the paths of most resistance - so I can help push people away from these paths and become successful (e.g. the paths which people are getting stuck on)?

There is another problem Paths (sankey) solves for today - which I'm not certain is an important one (and when I say important - does it contribute strongly to our mission of more successful products in the world?).

• I want to observe how users are flowing through my product

Personally I think this is quite un-actionable and likely time consuming, in the same way watching 100s of session recordings at random is, I very much feel that solving for this use case will get people spending time on PostHog but not get them to make their product more successful.

I'd be willing to take the controversial position of not supporting this use case and deprecating sanky diagrams - however on the condition that we validate this with 2 - 3 focus customers.

Side Note: Would be cool to have the option to create funnel out of a highlighted path. Allows me to then do more exploration along breakdowns, quant analysis, for the specific path.

Yeah this could be a killer way to create funnels - Select the event you want people to achieve.... now here's your funnel.

[neilkakkar]

I'd be willing to take the controversial position of not supporting this use case and deprecating sanky diagrams - however on the condition that we validate this with 2 - 3 focus customers.

Highly aligned! Less options, but options more geared towards what users want to do helps (1) reduce overwhelm. (2) differentiate us from existing established analytics solutions.

Like how getting to User Journeys in @mplitude was a pain (which is imo their best paths implementation), can appreciate how less is more.

... And then we'll grow big enough that users ask for more options, and then ....

[neilkakkar]

Yeah this could be a killer way to create funnels - Select the event you want people to achieve.... now here's your funnel.

Precisely! If you don't know where users come from, and you have this target conversion event, you could start with Paths with end point = target event . And then the UI should show something like:

(i.e. multiple paths ending at target event)

and then they could create funnels out of any of them, and just from paths, get a glance of which paths are most successful, i.e. ones with the highest conversion rate.

I like this a lot, and it's all enabled by this new visualisation.

At the same time, I imagine our visualisation gets a bit unwieldy when there's too many different paths all ending at target event (definitely possible when you filter by end point = target event ). Maybe we should reverse how the visualisation looks if end point is selected? (vs start point )

That is, you'd hover over the start event to highlight the full path, when target event is chosen. Not sure how confusing this gets. (A probably confusing suggestion: What if you discard dropoff counts? Everything ends at target event and target event is the biggest bar, kinda showing how users flow into this event. This aligns with user intention of choosing a target event, and seeing how/ from where users flow into it)

And when you choose start point it looks just like it does right now. When you choose both, we default to start point type of visualisation. And when you choose neither, you'd have multiple bars everywhere.

[neilkakkar]

The latest UI doesn't make it clear you can specify only a start or end point, and you don't need to set both.

Agree. Tech wise, we support both, neither, or either. (i.e. all combinations)

Genuine q, should we show some visual difference when viewing multiple types of events together?

Prelim thoughts suggest no to me? They're events happening in succession for a single user, so highlighting types (as we consider them types) doesn't make sense to me: For the people looking at paths, it may be natural to track from, say, URL to screen deep link, so no point in highlighting, and the actual type-highlighting they may be interested in are something like breakdowns.

it might just be easier to expand the graph as much as possible. Could we add a expand/collapse all?

What does all mean here? All session lengths? I'm not sure how useful all is, since it captures the long tail: say you have 1 user who did 100 events in a session, so you'd need 100 steps to expand all, while most users would be within K steps (yes, I'm assuming a power law distribution here).

[paolodamico]

Thanks @neilkakkar!

1. So to clarify, I was thinking more of having a different icon for each event time (like we're planning to do in the taxonomic event filter), still unsure if it's the right move but wanted to clarify.
2. Re expand all, sorry about the confusion. In the mockups we see one path per level and then the rest grouped in a "11 others" box. A expand box would vertically expand the 11 others. Though I may be misunderstanding what this other is for, not sure if it's a grouping for all long tail options (like we talked about for funnels) or if it's just a visual grouping so the graphic looks scaled.

[clarkus]

Feedback focused on the query builder panel first: Are we planning on shifting the headers/dividers to the new style proposed above or should we match the style that's been established with the funnel filters?

@EDsCODE I think either option can work, but I do think we need to make the query builder more consistent across insight types. That could happen as part of this issue, but really as long as the user can build the query, we'll be OK for now.

[clarkus]

So to clarify, I was thinking more of having a different icon for each event time (like we're planning to do in the taxonomic event filter), still unsure if it's the right move but wanted to clarify.

Yes I think this is important, but until we have those icons ready I'm not sure we can act on it here. Might be best to treat that separately as part of #4266

For "highlight path" view, are paths clickable? Using the primary colour suggests so, so if there's no primary action to take I'd consider highlighting them a different way.

Everything is actionable in the visualization, even drop-offs. I'll spend some time cleaning this up in the prototype and generally trying to align this to how we represent dropoff in funnels.

UX-wise, I think we could remove the "Autocapture" / "Page views" & "Screen views" conditionally if the project has none of these events (probably most teams won't have screen views).

💯

Genuine q, not sure if "highlight events" is clearer than "important events"?

This is a mistake on my part. I was going to change it all to "mark as important" to trigger the alternate styling.

I like the way we're visually showing filters, highlight & exclusion events but it's not aligned with the other insights. Thoughts on this? Perhaps having a two-col layout on the control box? Would also help ensure more of the main graph is above-the-fold. (@EDsCODE comment too)

See my response to @EDsCODE above. I think we need to tackle this work, but not necessarily as part of nailing paths. Generally a responsive layout that optimizes for larger screens and scales down to function for smaller screens would be ideal. It's just a matter of making that work across all insight types to give users a more consistent starting point.

The start/endpoint dropdowns don't seem like dropdowns, nor are they the same components as in the rest of the app.

These are intended to be overlays that expand to show the content of the shorter path items. When the value is sufficiently small, we lose the ability to display text inside the container. The idea here was to show that on hover, but give it a white background to mitigate any risk of contrast issues or readability. I think this will be more obvious after I get the prototype built.

It's not immediately clear what the purple colour represents. Two suggestions come to mind: a) add an icon that represents start/end to the event name; b) have a glyph (or plain circle) indicator in the event name dropdown with the colour.

I'll address this. Thanks.

Re expand all, sorry about the confusion. In the mockups we see one path per level and then the rest grouped in a "11 others" box. A expand box would vertically expand the 11 others. Though I may be misunderstanding what this other is for, not sure if it's a grouping for all long tail options (like we talked about for funnels) or if it's just a visual grouping so the graphic looks scaled.

@paolodamico I have an older example of what hovering over a collapsed group of path items looks like:
.
Does that address your feedback or is there more to it?

[neilkakkar]

(2) Select specific custom events to show on Paths (i.e. selecting specific events - of any type)

Not sure if we want this to be part of V1, but right now, the UI allows choosing specific types of events to show, but we can also choose specific events to show on Paths (so, something like, show all Pageviews, "insight loaded", and "insight analyzed" events. That's one way of mix and matching). This is different from "Important Events" in the sense that it removes all custom events apart from "insight loaded" and "insight analyzed" from the Paths data.

If we want to take this even further, we can also have filters on these custom events, like "insight loaded" with property_A = "blah". (Haven't implemented this on the backend yet, but fairly easy to do). This is similar to how we have funnel steps right now.

I'm not sure how to display this, but I do think atleast the basic level of customizability makes sense for Paths.

[clarkus]

Thanks, @neilkakkar I will work to incorporate that into the designs.

[paolodamico]

I think maybe we want to start enabling users to select specific events/actions but without filtering? My concern is that it'll add to much complexity to the interface right now and we're still unsure how this feature will actually be used, but @clarkus you may have better context on how it could fit the designs without being too intrusive?

Not sure if having it as filters will be discoverable enough for users, but it's a matter of visualizing and testing.

[clarkus]

I am working on the "specific events" portion of this now. I dropped the concept of "important events" because it felt like it conflicted a bit with selecting specific events. I should have something for that later today. The prototype for user testing is also up-to-date.

[clarkus]

Here's one rough concept idea for building event lists for each supported type. I don't think this should be the solution, but it does demonstrate the concept I have in mind for picking events. The goal here is to make the picker inclusive - we want to default to showing lots of events, but still make it easy to clear the selection and pick exactly what you want to see.

The key job here is browsing through event categories and selecting all, a subset, or none of those events to build a path visualization. Does something like this seem on target for how users might build more complex path visualizations?

[neilkakkar]

Oh, I like how this filters by type we care about.

Does something like this seem on target for how users might build more complex path visualizations?

For the basic event selecting (i.e. where we don't allow filters on selected events) 100% works.

---

Another slightly related point is that the start point and end point filter dropdowns need something similar for selecting: If it's a pageview event, you input the URL. If it's an autocapture event, you input the element you care about.

[paolodamico]

I think the way of selecting events here is pretty clear. It'll be really key how we implement this experience to make sure it can be used quickly and seamlessly so it doesn't create a pain for the user (e.g. expanding groups with results, search bar doesn't lose focus when you add/remove events, ...).

---

On a separate topic, based on the conversation yesterday and after some thought, I think we should not support paths with autocapture at all. The information from there will be pretty useless unparsed and full of noise. I think what we eventually want to support is paths with actions instead. Happy to dive more into this. Thoughts @neilkakkar ?

EDIT: Slack thread by @neilkakkar on the same topic.

[clarkus]

Another slightly related point is that the start point and end point filter dropdowns need something similar for selecting: If it's a pageview event, you input the URL. If it's an autocapture event, you input the element you care about.

How would this work with a mixed case of included events? If I am including page views, screen views, and custom events, my starting point would have to match the format of one of those categories. If I am only including a subset of page view events, my starting event would have to match the specific formatting of one of those events. Is that accurate? Is this still an issue given that we're considering dropping autocapture events?

[clarkus]

Here is an updated version of the query builder that breaks the event selector out into distinct groups. Being distinct would simplify implementation, but it would also make it easier to scale the interface across a variety of viewport sizes. This would also align better with the step layout we use for funnels, which allows for inline filtering and other actions.

[marcushyett-ph]

For @clarkus @EDsCODE and @neilkakkar context - one of the issues that came up at the offsite was sometimes GitHub issues get really long (like this one) and its really hard for someone to catch-up to get context and unclear what decisions have / haven't been made.

The proposed solution was to create a markdown file in posthog/meta or posthog/product-internal with the current state of any decision - so people can comment inline - and anyone new joining the conversation can catch up in a few seconds.

Since I'm just back and this issue feels quite overwhelming - I was wondering if we might be able to try? I'm not certain who would be best placed to do this - since the issue was started by @EDsCODE but the majority of content is from @clarkus

[clarkus]

I'll start an asset to track this and then I'll socialize it so others can update as they see fit. Will post here shortly.

[clarkus]

https://github.com/PostHog/product-internal/issues/161

[clarkus]

Here are updated concepts that show a layout similar to the one used for funnels. In this case the query builder is broken into an event selection component, excluded events, and filters. This update also allows for the reuse of the existing filter component from other insights. This should allow a user to define an event set along with filters for each category of events (web, mobile, custom).

[paolodamico]

Added feedback directly on Figma. Some meta-feedback: it's still hard to know where to give feedback on Figma because there are so many artboards. Maybe linking the specific artboard when asking for feedback or adding more organization comments on the file could work.

---

Another topic. Should we merge screen & page views together and simplify? Most of the time you have either a mobile app or a web app (and very few users use paths with screen views, 10X less than pageviews).

[clarkus]

Added feedback directly on Figma. Some meta-feedback: it's still hard to know where to give feedback on Figma because there are so many artboards. Maybe linking the specific artboard when asking for feedback or adding more organization comments on the file could work.

Thanks I am still thinking through how to facilitate these reviews in a structured way in figma. I started an internal discussion about this if you have any thoughts you want to share - https://github.com/PostHog/product-internal/issues/162

[clarkus]

While working on the workflow that connects funnels to paths, it's becoming really obvious that we need a better solution for representing filtered events. #5229 is one solution that's been identified, but I wonder if we might work the currently selected values into the labels somehow, too. I feel like there's going to be a disconnect between funnels and paths if we can't ensure that primary identifier is shown prominently in each case.

In this example case, the most meaningful representation of the query is the value for the property filter.

[neilkakkar]

I think - as we've decided elsewhere - it makes sense to not support properties in V1, as we're doing for filters.

Except: By default, we support the Current URL property for $pageview and $screen events.

So yeah, working these out for Pageviews and Screens make sense, but since we already know exactly how this looks vs a random property, should be easier to represent?

[clarkus]

That aligns with my latest understanding. Thanks, @neilkakkar

[neilkakkar]

Now that the Paths UI is coming together, one question about matching the API with the UI:

On the UI, there’s 3 possible event types: Pageview events, Screen events, and Custom events.

This misses a 4th category, which is implicitly included in the backend when no toggles are selected: PostHog internal events. (like, $autocapture, or $plugin_running_duration, or $identify, $pageleave, $Feature Flag Called).

So far, I don't see a good reason for including these on Paths. And based on the UI, users would always select atleast one of the 3 possible categories to display paths, right?

Just making the decision here explicit, checking if everyone's aligned.

[paolodamico]

I think we can close this now? @EDsCODE @neilkakkar

[posthog-contributions-bot]

This issue has 7350 words. Issues this long are hard to read or contribute to, and tend to take very long to reach a conclusion. Instead, why not:

1. Write some code and submit a pull request! Code wins arguments
2. Have a sync meeting to reach a conclusion
3. Create a Request for Comments and submit a PR with it to the meta repo or product internal repo