Closed EDsCODE closed 3 years ago
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).
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).
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
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. https://github.com/PostHog/posthog/issues/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.
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?
That aligns with my latest understanding. Thanks, @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.
I think we can close this now? @EDsCODE @neilkakkar
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:
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