-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite the Retention Insight in HogQL #19639
Labels
enhancement
New feature or request
Comments
Feature request: add filters to the start and target events (just requested again) |
New requests:
|
The HogQL retention insight has now been launched to everyone 🎉 New things out of the gate:
Going to keep this issue open until we can also add the new requested features. |
Closing this. New requests moved to PostHog/meta#200 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem?
This is part of the push to rewrite all insights in HogQL. I've created separate issues for each insight type, so that users can subscribe here and get notified when it's done.
This issue is about the Retention insight.
Describe the solution you'd like
I'd like to rewrite the Retention Insight in HogQL.
Most product analytics insights are built in a bespoke way in our "legacy" Python codebase. This code produces ClickHouse SQL as its output. It's hard to extend, as every new feature (e.g. group support, multiple breakdowns) needs to be manually added to each insight. It's hard to extend the current system, and there are many bugs and unimplemented edge case features.
We've built HogQL, which takes care of implementation details, and lets users focus on writing queries. Every platform feature added to HogQL (e.g. group support, new aggregations, etc) will automatically be available in every insight everywhere.
We're now rewriting our python codebase to output HogQL instead of ClickHouse SQL. This will fix whole classes of bugs, make the system more robust, and allow the end user to directly modify the generated HogQL SQL for further analysis.
This migration is also a blocker for the removal of a lot of legacy frontend code, which is often causing bugs.
Additional context
See the latest todo list in the megaissue: PostHog/meta#130
The text was updated successfully, but these errors were encountered: