PostHog / posthog

🦔 PostHog provides open-source product analytics, session recording, feature flagging and A/B testing that you can self-host.
https://posthog.com
Other
21.4k stars 1.28k forks source link

Paths Upcoming features #5665

Closed EDsCODE closed 3 years ago

EDsCODE commented 3 years ago

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

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

clarkus commented 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).

Funnel steps - Step Order-1 Funnel steps - Step Order

paolodamico commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

Screen Shot 2021-09-15 at 2 53 31 PM Screen Shot 2021-09-15 at 2 55 33 PM
neilkakkar commented 3 years ago

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 commented 3 years ago

That aligns with my latest understanding. Thanks, @neilkakkar

neilkakkar commented 3 years ago

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 commented 3 years ago

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

posthog-contributions-bot[bot] commented 3 years ago

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