EDsCODE
commented
3 years ago @neilkakkar feel free to adjust based on what you think we should add/remove for near term deliverables
Closed EDsCODE closed 3 years ago
EDsCODE
commented
3 years ago @neilkakkar feel free to adjust based on what you think we should add/remove for near term deliverables
paolodamico
commented
3 years ago Thanks for putting this forward @EDsCODE! Some things that immediately come to mind,
EDsCODE
commented
3 years ago 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
Just to show how long it took for users to move from one step to the next
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
We should be able to do this but I didn't include it on the immediate list
Yup, we discussed this. Will need to figure out how to query it but will be next up after.
paolodamico
commented
3 years ago Thanks @EDsCODE,
neilkakkar
commented
3 years ago / -> /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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago Trying to think through what users want out of Paths, and I guess I'm a bit unclear where most value lies.
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)
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
commented
3 years ago 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:
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?).
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 funnelout 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
commented
3 years ago 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
commented
3 years ago 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.
EDsCODE
commented
3 years ago 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.
Well stated. I was briefly discussing this with Chris too that the new paths visualization does conceptually change what information is being shown. Flows generally "feel" very powerful in giving an overview of how users are working through a product but the new visualization arguably provides more clarity in what to focus on.
I had some reservations about the conciseness of this visualization and repeated events in different flows without showing merging, but showing less and allowing for more discovery as users click through "5 others" toggles might be a more effective way to tackle the chaos of paths. Putting this visualization in front of users should be really productive in helping us decide how to move forward
clarkus
commented
3 years ago Here are some more updates for path analysis that show how we can layer in actions depending on the path itme being highlighted. Think of this layout almost like a calendar: There are N columns, each column has a maximum height, and a set width based on the container size and the number of steps. As each path item is placed in each column, its height is determined by the total count of events. This is based on a 1280px wide browser, but we could comfortably fit 6 steps in using this layout.
Smaller viewport sizes and / or a higher number of steps would require some pagination-like control that lets you page through the steps in the container. Unless we want to make the container really tall, we'll have to cap or overflow events with lower counts into aggregates (for example, 4 others 4%). When hovered, we can itemize the components of that aggregate group and provide actions to affect those path items.
In some cases, path items will not be sufficiently tall to contain their descriptive values. Much like the case with "others" we'll show the full detail on hover / focus / keyboard focus / etc.
There are some more idea in here for inline actions on path events. Some ideas:
https://www.figma.com/file/9yWtngNb1AIuf6KmXaEPJA/App-doodles?node-id=1165%3A138772
I am almost done working through paths that lead into a given event / path item. I should have that available tomorrow.
clarkus
commented
3 years ago This update should capture everything in the current scope for paths. The one thing that isn't really represented is:
mix and match different types of events
I see how this might modify the behavior of the first parameter in the paths query (allowing multiple selection) but I am not sure how this context change might impact other capabilities in this feature. For example, does showing both web and mobile events prevent us from filtering the set or change the way we exclude events? Said another way, what are the technical constraints with mixed events types?
This update also includes some ideas for updating query building across insight types. It's a variable-width container that could work at full screen or, in larger viewports, a multi-column layout. This update only demonstrates the full screen version (which is what we have now).
https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/?node-id=3266%3A25549
neilkakkar
commented
3 years ago Ending at X is just how I imagined, love this! I'd expect highlighting to work in reverse as well? i.e. if I hover over "01 View Product Page", then it highlights the path "View Product Page -> Search -> View Product Page -> Added to Basket" ?
If I had "01 View Product Page -> 02 X -> 03 View Product Page -> Added to Basket" as a valid path, would X show up between "02 Session start" and "02 Search"? It's a thin slice, let's say, (i.e. only 500 of View Product Page do X, rest do search) so would it bork existing semantics of greater step is a superset of previous step?
Is Session Start like the reverse of dropoffs? A reverse padding of sorts so that the final count makes sense?
neilkakkar
commented
3 years ago what are the technical constraints with mixed events types?
There are a few constraints when it comes to exclusions, like: Don't make it possible to exclude and Include the same events.
Mixing and matching is poorly named (our bad), since by default, we allow mixing and matching everything now. What these filters would do, is allow you to select (1) One or more specific types of event to search on (autocapture, web, pageview, custom). (i.e. selecting event types) (2) Select specific ~custom~ events to show on Paths (i.e. selecting specific events - of any type) (3) Exclude specific events (type exclusion not allowed, since that basically means not choosing the type in inclusion types)
(1) and (2) and (3) can be mixed and matched together, barring few constraints like the above. These are all logical constraints though, and not technical.
So you could, for example, choose "pageview" type, and then exclude "pageview" events with URL = "blah".
This wasn't clear before, apologies!
neilkakkar
commented
3 years ago re: Starting at, Ending at dropdown selector: We can have both, start point and end point, so it's more like an AND selector?
clarkus
commented
3 years ago Ending at X is just how I imagined, love this! I'd expect highlighting to work in reverse as well? i.e. if I hover over "01 View Product Page", then it highlights the path "View Product Page -> Search -> View Product Page -> Added to Basket" ?
I was thinking "highlight event" is the same as saying "make this event exceptional - give it a different color coding, give it priority sorting, etc. One shortcoming of this interface is that path items with smaller distributions of events will be less immediately obvious. Highlighting is a way to overcome that. One issue might be when a highlighted event is a member of an "other grouping". Breaking that out of the "other" grouping would break the display a bit... I mean it could work, but it'd be harder to lines things up :)
If I had "01 View Product Page -> 02 X -> 03 View Product Page -> Added to Basket" as a valid path, would X show up between "02 Session start" and "02 Search"? It's a thin slice, let's say, (i.e. only 500 of View Product Page do X, rest do search) so would it bork existing semantics of greater step is a superset of previous step?
You would see that path item displayed in step two sorted by value - so if the other options were larger than X, X would show under neath those. If X was sufficiently small, it would be aggregated into an "other" grouping at the appropriate sort order. Clicking on that item would expand the group to see an itemized sorting of all sub-path items. I'm not showing subsequent paths from "other" groupings right now. I was thinking that if a user really wanted to explore a path item that was smaller, they could set it as a starting or ending point to see everything in the context of that path item.
Is Session Start like the reverse of dropoffs? A reverse padding of sorts so that the final count makes sense?
Yup it's a way to represent events that start mid-path. It is exactly the opposite of dropoff.
clarkus
commented
3 years ago This wasn't clear before, apologies!
@neilkakkar no worries. That's how I was picturing it, but wanted to ask so I could be certain. Thanks for elaborating!
re: Starting at, Ending at dropdown selector: We can have both, start point and end point, so it's more like an AND selector?
I was going to ask about this. I have an example I'm working on with both fixed and end points. This would be a lot like the other examples, except we'd be able to exclude a lot of events given that we know the target. Is there any scenario where we could allow other fixed points in a path? For example, Start at "view homepage", any 2 path items, "added to basket", any 2 path items, "check out".
neilkakkar
commented
3 years ago Nope, no fixed points in the middle. We only want to allow one start and one end (technical constraint). If someone wants to do something like this, it's either a funnel of the pinned items (effectively that's what we're doing with pinning in the middle), or two different path views.
clarkus
commented
3 years ago Thanks for clarifying. I am going to put together examples of highlighting across various scenarios, as well as a fixed start and end funnel. Thanks for the support, @neilkakkar!
clarkus
commented
3 years ago This update extends the previous one in a few areas:
I also put together a simple case to demonstrate how rules in the query builder would adapt to narrower viewports
https://www.figma.com/file/gQBj9YnNgD8YW4nBwCVLZf/?node-id=3266%3A25549
EDsCODE
commented
3 years ago 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?
paolodamico
commented
3 years ago So first thing, I'd love if we can convert this into an operational prototype to run some usability tests (@clarkus) and get some early feedback. Any thoughts too @EDsCODE @neilkakkar ?
Based on the problems we're trying to solve with Paths, the latest design is great at understanding the path of least resistance. I'm not sure if we could have a better representation to help you understand the negative case to better help you improve. For instance, highlighting relevant paths with large drop-offs. Drop-off boxes in this context are quite unactionable by themselves.
On the latest Figma (@clarkus):
neilkakkar
commented
3 years ago 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
commented
3 years ago Thanks @neilkakkar!
clarkus
commented
3 years ago 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
commented
3 years ago 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 https://github.com/PostHog/posthog/issues/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
commented
3 years ago (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
commented
3 years ago Thanks, @neilkakkar I will work to incorporate that into the designs.
paolodamico
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago 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
commented
3 years ago
Here's a list of features to consider that will be implemented early next week:
Filter paths for cohorts(already works)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