Open macobo opened 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.
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.
(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
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
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 :)
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.
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?
@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?
Is your feature request related to a problem?
We have quite a few features which directly relate to analytics
Quite a few of them are already directly interconnected:
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](https://user-images.githubusercontent.com/148820/112609724-8bc76700-8e24-11eb-8a82-d2b005cfbf25.png)
Thank you for your feature request – we love each and every one!