🦔 PostHog is developer-friendly, open-source product analytics.

Is your feature request related to a problem?

Better Visualisation of Funnels

Describe the solution you'd like

• Show relative percentage at each stage
• Show gradual decrease in numbers focusing highest attrition

Thanks, @rajatkb for the suggestion!

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

Opening this issue to start the discussion around quantitative analysis (Step 2) for the conversion optimization process (more context on https://github.com/PostHog/product-internal/issues/127#issuecomment-896231144).

@macobo I think you'd be interested in being actively involved in working out the solution for this? Would be great to also have an engineer from Core Experience Team actively involved too (@liyiy @alexkim205). @clarkus too.

How do you want to start work on this? I'm thinking we could start a discussion from first principles and some research/benchmarking. Probably easier to start this in a Google doc instead to have more fluidity?

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

• Paths based on user dropoff in funnel (https://github.com/PostHog/posthog/pull/5699)
• Flexible # of steps view (be able to see more or less steps based on an integer param) (https://github.com/PostHog/posthog/pull/5675)
• Conversion rates as percentages along with absolutes
• Time distribution of step conversions (https://github.com/PostHog/posthog/pull/5693)
• ~~Filter paths for cohorts~~ (already works)
• Event exclusion (easily add events you don't want to see in paths) (https://github.com/PostHog/posthog/pull/5741)
• mix and match different types of events (https://github.com/PostHog/posthog/pull/5741)
• specify end point (https://github.com/PostHog/posthog/pull/5746) (Note: start point is already implemented. They don't work together simultaneously yet)
• search paths between two funnel steps

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

Is your feature request related to a problem?

Reports are useful for saving ad-hoc analysis. I want to:

• Save/share reports which are individually useful
• Add same report to multiple dashboards

We have a concept of saved reports already. You can access them by:

1. Going to insights
2. Clicking history
3. (Optional) Giving a unnamed insight a name
4. Clicking on "saved" tab

Describe the solution you'd like

Make reports a more top-level thing with:

1. Default tab to "saved" insights, history being a different tab
2. Provide tooling to manage reports - e.g. filtering by name, creator, when created, starring, etc.
3. Allow adding reports directly from dashboards - e.g. by having a (+) button which when opened allows to filter saved reports.
4. Add a way to open recent reports of same type to insights. Move all "saved funnels" to reports.

How filtering is handled by Heap

Describe alternatives you've considered

Only using dashboards - makes it harder to reuse reports in dashboards, bad for discovery.

How mixp@nel does it:

At top of insights there are New, Save, Save as new buttons.

Clicking open opens a modal for filtering these reports:

Additional context

There's a downside to this: we'd be cluttering our side nav even more with "related" functionality.

cc @paolodamico @EDsCODE

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

Following up from https://github.com/PostHog/posthog/issues/7418 , here's what we need to do to get the MVP out in these 2 weeks:

Main Tasks:

1. [x] Figure out & build the UI Creation Flow - @liyiy
   • @clarkus & @paolodamico : we could use some input here about the basic flow. (specifically on how we should structure this, disregard full fledged wireframes for now) There's 2.5 steps to creating an experiment: (1) Create an insight & (2) Choose a FF. (2.5): Name and description of experiment.
   • As you can tell, there's lots of ambiguity above^ that we need to clean up.
   • (We considered a flow where funnels have a "create experiment from insight" button, but @macobo mentioned how this increases complexity on the standard funnels view, and reduces discoverability quite a bit in simple mode)
   • (future context): There's a back & forth when choosing an insight & FF: They choose an insight, we tell them how long the experiment will run for. They tweak FF rollout % / definition, we tweak how long we expect experiment to run for. They tweak insight definition, we tweak how long to run the experiment for. What's a good way of doing this?
2. [x] Build Experiment Page with the Insight and experiment results (also see here)
3. [x] Create Plugin to add $active_feature_flags & $feature/{key} to every event (we only do it for web captures today) - @neilkakkar - deferred. Just focusing on posthog-js for now.
   • This implicitly allows breakdowns by Feature Flags on Funnels
4. [x] Given a funnel with FF breakdown, calculate experiment results
5. [ ] Given a funnel and FF, calculate how long an experiment should run

New constraints:

1. To give accurate results on expected running time, we need to answer the question: Given a FF, how many people in the past X days on this insight would've belonged to this FF? And use this to estimate. For now, restricting scope to basic FFs only (i.e. flag with the only property being the rollout % to all users).

When working on the designs for #1659, @lottiecoxon helped us create different color scheme proposals for the main dashboards 🙌 (full design here). Opening this issue to discuss the different proposals.

Current color scheme

Proposal 1

Proposal 2

Proposal 3

Proposal 4

Expanding on this sprint planning comment

Nail Seamless Analytics Experience (Working title)

Owner: @Twixes

Why?

Why? Insights and dashboards are very sluggish and inconsistent to use. The app doesn't spark joy.

Goals

Goal 1: "It should be possible to go from a dashboard to an insight and back in 0.1 seconds" Goal 2: TBD, working draft: "80% decrease in WTF/minute during usability surveys."

Steps

• P1, fix before other stuff. Persons modal loads forever on trends @mariusandra

• Finally release saved insights @mariusandra

• Implement the Information Architecture flow and refresh the look @Twixes

• Combine the UX of insights, saved insights and dashboards into a coherent whole @Twixes and @mariusandra

• Chart UX improvements:

  • Add all chart types with various states into storybook @mariusandra
  • Unify "not loaded" states amongst all charts
  • Don't show "No matching events" when never loaded anything yet
  • Add "area chart" and "percentage mode"

Is your feature request related to a problem?

Through numerous customer interviews we now know there seems to be a bit of an issue with our current navigation, in which a) users find it a bit hard to reach the features they need or b) users are unaware of other features/capabilities of PostHog. This design proposal attempts to tackle that. Also attempting to balance the need to make all features easily discoverable to the problem of having so much stuff that it's overwhelming for new users.

Aside from the above, this design also introduces full support for multiple projects and multiple organizations.

Release plan. As this is a particularly intensive change (from a UX perspective), I'm thinking that we can release in the following manner:

1. Multiple feedback rounds (this thread).
2. Initial implementation (very intense UX change, but fortunately it will likely not require a huge code change).
3. Beta testing with select power users (do usability tests and get qualitative feedback from them).
4. Phased release with feature flags (quantitative impact).
5. Full release.

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

This will average over the preceding smoothing_intervals intervals. The driver for this is to remove either weekly or monthly trends.

Limitations at the moment are that it only works for total volume queries, as it relies on the results from clickhouse being from a single timeline series.

Video example here

Tasks

• [x] https://github.com/PostHog/posthog/pull/4783
• [x] https://github.com/PostHog/plugin-server/pull/480
• [x] https://github.com/PostHog/posthog/pull/4871

Requested by a potential user on a call.

If I'm exporting events somewhere else, I'd like some metrics as to what percentage of my events actually get delivered.

Segment provides this:

They infer success from the lack of an error being thrown.

One step towards "UI plugins" that could help here is allow plugin devs to set metrics that would appear on a dashboard. A native API like this, for example:

const eventsDelivered = await storage.get('eventsDelivered')
const eventsProcessed = await storage.get('eventsProcessed')
updateMetric('percentageDelivered', (eventsDelivered/eventsProcessed)*100)

This way we don't have to deal with the problem of rendering arbitrary code yet, but give plugin devs the option to show some more stuff on the UI. Just a quick idea though.

This issue is to discuss the frontend implementation of the time conversion analysis view. Full product specs can be found here.

Initial wireframe draft below (from @corywatilo's new UI on #4535). Looking for feedback @corywatilo @marcushyett-ph @mariusandra @kpthatsme. The histogram is quite simple that's why it's mocked. On the y-axis we have a regular number scale as we have today. On the x-axis we have each bucket range.

Problem

closes #12617

When listing recordings a separate query is made for the PersonDistinctId of each person in the results

Changes

prefetches the distinct ids

How did you test this code?

Added a developer test

Bug description

From a Customer signing up to EU Cloud (names redacted):

Hello Simon! Just tried to login with an invite an admin sent me. They invited me on [email protected], and I tried to login using my Google Workspace-account which is: [email protected]. This gave me a Server Error (500) on my way back to PostHog, from Google's Oauth. I suspected this could be due to case-sensitivity, so an admin changed the invitation to [email protected] , and then it worked, so just letting you know.

How to reproduce

1. See above

Environment

• [x] PostHog Cloud
• [ ] self-hosted PostHog, version/commit: please provide

Additional context

Thank you for your bug report – we love squashing them!

Problem

We want to avoid unnecessary postgresql queries

Changes

Cache view.team/view.organization for the duration of a request.

Leads to a bigger refactoring around permissioning.

How did you test this code?

Tests.

Verified each request creates a new view object so caching does not persist beyond a request.

Problem

Changes

1. Fix bug where admin+ was unable to add a custom edit role.
2. Add basic usage tracking

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

How did you test this code?

Problem

• Loading a dashboard with 10 insights was doing upwards of 90 queries total for calculating insight permissions
• Moving business logic out of models has both performance and maintainability benefits
• view.team/view.organization did a query each time they were accessed.

Changes

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

How did you test this code?