Skip to content
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

Group Analytics - first impressions and feedback #7073

Closed
clarkus opened this issue Nov 11, 2021 · 5 comments
Closed

Group Analytics - first impressions and feedback #7073

clarkus opened this issue Nov 11, 2021 · 5 comments
Labels
feature/group-analytics Feeature Tag: Group analytics stale

Comments

@clarkus
Copy link
Contributor

clarkus commented Nov 11, 2021

I gave our fledgling group analytics features a trial run a bit ago. This is a super exciting change to our product! I think it's looking great and I only found a few things I'd like to surface as questions / discussion topics. Most of these are existing issues that are just exacerbated by additional aggregation options.

  1. The aggregation methods available generally make sense, but the use of unique instances caused me to pause a bit. It wasn't immediately obvious to me what an instance was referring to in this context. We have some related work to do here to clarify aggregation methods, so this really isn't an issue specific to group analytics.
  2. Are y'all tracking improvements to person modals and other click-through actions that cross-link insights? For example, in trends I typically can click on a data point to see all persons in that data point. There are parallels for groups, but we might still be in a scenario where we need some interstitial step to describe a data point.
  3. Does aggregating by groups preclude us from using any other insight options long-term? For example, if I am aggregating by group, does that limit my ability to compare time ranges or any other adjacent functionality?
  4. I think there are ongoing PRs out there for this, but the metrics are tagging incorrectly in the chart tooltip. Both unique instances and unique groups are tagged as unique_group. Related to the aggregation methods I mentioned above, we should clean up our chart tooltips to scale a bit better with these new aggregation methods. There are some ideas in a related issue at Make compare previous great! #4705 (comment) that would improve our ability to describe these items in each context.

Screen Shot 2021-11-11 at 9 07 53 AM

cc @macobo @liyiy

@macobo
Copy link
Contributor

macobo commented Nov 12, 2021

  1. Sharing one extra piece of feedback from Michael:

For me this doesn't seem obvious if it just says "$GROUP_TYPE". How bout "$GROUP_TYPE properties" like other tabs?

image

@macobo
Copy link
Contributor

macobo commented Nov 12, 2021

Thanks for the feedback. I've numbered each one and responding.

  1. The aggregation methods available generally make sense, but the use of unique instances caused me to pause a bit. It wasn't immediately obvious to me what an instance was referring to in this context. We have some related work to do here to clarify aggregation methods, so this really isn't an issue specific to group analytics.

In our case instance is a group type we send from the backend representing a site or instance of posthog that's been set up. :)

Agreed regarding cleaning up aggregation methods. I'm not really happy how it's represented in funnels, I think this needs some design-level thinking:
image

  1. Are y'all tracking improvements to person modals and other click-through actions that cross-link insights? For example, in trends I typically can click on a data point to see all persons in that data point. There are parallels for groups, but we might still be in a scenario where we need some interstitial step to describe a data point.

Person modals indeed don't currently work and it's logged in the board.

However I don't think a "person" modal when aggregating by groups even makes sense - instead showing (and linking) groups would make more sense here. So there's both technical and design work here on how these should look!

  1. Does aggregating by groups preclude us from using any other insight options long-term? For example, if I am aggregating by group, does that limit my ability to compare time ranges or any other adjacent functionality?

I don't think so. The one exception being perhaps linking insights to paths (or other user-only based insights).

Paths are inherently user-based so linking from say a funnel to it doesn't really make sense.

  1. I think there are ongoing PRs out there for this, but the metrics are tagging incorrectly in the chart tooltip. Both unique instances and unique groups are tagged as unique_group. Related to the aggregation methods I mentioned above, we should clean up our chart tooltips to scale a bit better with these new aggregation methods. There are some ideas in a related issue at Compare previous functionality is confusing Make compare previous great! #4705 (comment) that would improve our ability to describe these items in each context.

The tooltips were in review when you wrote the feedback, but are now fixed at least wording-wise.

image

However the larger problem here is that not all UI handles different wordings gracefully. E.g. funnels:

image

We should figure out what these issues are and I think it's 👍 to systematically solve these under this project.

Related: Should we use custom icons for groups? If so, what mechanism should that live by?

  1. For me this doesn't seem obvious if it just says "$GROUP_TYPE". How bout "$GROUP_TYPE properties" like other tabs?

There's a problem here in that the dropdown for selecting properties is quite narrow and you need to scroll to see all tabs with groups. @clarkus penny for your thoughts.

Some options:

  1. Increase the width
  2. Remove "properties" from every tab name
    ... or something else here design-wise?

@clarkus
Copy link
Contributor Author

clarkus commented Nov 24, 2021

There's a problem here in that the dropdown for selecting properties is quite narrow and you need to scroll to see all tabs with groups. @clarkus penny for your thoughts.

I think we might consider a consolidated list of options grouped by their type. When we have a sufficiently high volume of sections, we'll be more reliant on search to find the target option. We can help focus attention to specific sections by making sections collapsible. This might be less optimal in projects where groups aren't instrumented or where there is a low volume of group entities. I need to put time into fixing these scale issues in a few other places, so I will put something together for this as well. Note that this feels very related to #6254.

@posthog-bot
Copy link
Contributor

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

@posthog-bot
Copy link
Contributor

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.

@posthog-bot posthog-bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/group-analytics Feeature Tag: Group analytics stale
Projects
None yet
Development

No branches or pull requests

4 participants