search

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
20.3k stars 1.21k forks source link

Interconnect more analytics features #3765

Open macobo opened 3 years ago

macobo commented 3 years ago

Is your feature request related to a problem?

We have quite a few features which directly relate to analytics

  1. Insights a. Trends b. Funnels c. ...
  2. Sessions
  3. Cohorts
  4. People
  5. Events
  6. Actions
  7. Feature flags

Quite a few of them are already directly interconnected:

  1. You can jump from most trend graphs to sessions
  2. We list events, sessions and now cohorts in persons pages
  3. Can jump to person page from insights, cohorts, sessions and events
  4. Can jump from events table to insights for that event

However a lot of interconnections are missing, for example:

Each of these interconnections make going from "hmm that's weird" to insights much easier, currently it's too much work to jump between all these different things.

Describe the solution you'd like

Universal way to represent "view/analyze in X" in different views.

Ideally one that's mostly consistent throughout different parts of the app - we currently have a mixture of tabs, popups when you click on things and tables underneath things.

Additional context

Not sure what the way is (cc @corywatilo, @lottiecoxon) - this is an interesting design challenge.

cc @paolodamico and @EDsCODE - we've discussed this in the past cc @kpthatsme - you're working a lot with data, do you think this would make sense/improve both your usage and no of learnings?

Screenshots

Some ideas from other products: image

image

image

image

image

image

Thank you for your feature request – we love each and every one!

kpthatsme commented 3 years ago

Yes, agreed with basically the entire list – If I had to pick a couple as a start- cohorts from funnel trends + the ability to go between trends --> funnel seamlessly would be massive value adds.

kpthatsme commented 3 years ago

Want to add one more thing to your list- the ability to add filters to events on retention would be really powerful.

This would definitely save tons of time as its one of those things where you need historical data – right now there is a workaround possible by creating an action but if it's easy to do for the chart it would be good.

EDsCODE commented 3 years ago

(1) partially is behind the save-cohort-on-modal this flag just needs some analysis and can be rolled out. It only works for trends/stickiness so still does need to be expanded

buwilliams commented 3 years ago

Looks like we need an overall approach plus specific implementations on each related feature of the app. I don't feel I know enough about the overall mental model of PostHog to suggest an overall approach yet. You guys have any suggestions for how we could organize this work? @macobo @kpthatsme

macobo commented 3 years ago

I think it's best to approach this case-by-case for now and unify as we have more context on the how.

I suggest picking 1-2 to start and going from there, feel free to take full reign, I just dumped all the context I had into the issue post for the larger idea/feature. @paolodamico and @EDsCODE are probably able to help design- and implementationwise :)

EDsCODE commented 3 years ago

I would suggest tackling (2) to start. You can take a look at how we've implemented the logic for clicking on a datapoint for guidance and apply that to the necessary charts. Specifically in posthog/api/person.py you'll find several endpoints such as stickiness retention lifecycle that contain the logic for returning people when you click into a datapoint on the respective graphs.

Note: Trend is tucked in a different place under posthog/api/action.py in the people function. Moving this endpoint to the person.py file is also a point of refactoring that could be done.

2nd Note: This task is fairly in the weeds but it should help you get a good grasp on the format of the codebase. For example, when you go ahead and implement it, you'll have to take note that the ee deployment should also be handled. You can see in ee/clickhouse/views/person.py we inherit the class mentioned above (from posthog/api/person.py) but change the query classes so that the clickhouse implementation is reached when we're using a clickhouse deployment.

buwilliams commented 3 years ago

I took a first pass at cohorts for the Trends Bar Chart #3825. I'm hoping this is headed in the right direction but I'm sure it needs work. Thoughts?

buwilliams commented 3 years ago

@EDsCODE I'm looking at the first item, "Being able to define a cohort from a trends graph" but it's already implemented behind a feature flag. Any reason to keep it behind a feature flag?