Analytics by group/teams

[timgl]

Is your feature request related to a problem?

I want to be able to do analytics based on a group or a team, rather than just

Describe the solution you'd like

Most analytics providers (including segment) allow users to be 'grouped', something along the lines of posthog.group('distinct_id', 'group_id', {property: 'value'}).

I then want to be able to do analytics based on those groups. Something like "Show me how many groups have done a pageview in the last 30 days" or "Show me retention for groups".

I also want a screen of all groups with the number of people in it, allowing me to click into those to see who's in it etc. It would be especially cool if I could see the growth of the group over time (would mean we need to store the $add_to_group event probably?)

Describe alternatives you've considered

Adding the group id as a property on the event. This isn't great as then each user can only be a part of one group

Additional context

Some questions:

• How do we store this data (new table?)

cc @macobo

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

[macobo]

Example internal usecase: track how many projects have session recording turned on.

[macobo]

So there are many ways to achieve this - each with its own downsides. The ultimate question is 'what do we want the semantics to be'?

Group (or company) of users by definition contains many users. But how about users can they only belong to one company? Multiple?

If they can only belong to one company everything is easy - all events of the user are also events of the group.

If they can belong to multiple companies, things become more tricky as some events from user can belong to one company, some to the other.

Array user prop

We could make it so that if you have an user prop that's an array, you can do dimensional analysis based on that. E.g. in the UI you say this array prop means list of 'companies' and add a dropdown to insights page to not analyze by users, but by 'companies'.

The advantage here is that this is (reasonably) easy to realize on our current solutions, but the downside of not being able to associate events to a single company - which might be a good enough solution here.

(Ab)using distinct_id's

If users belong to multiple companies, they won't be using them at the same time. As a user switches company, e.g. a posthog.identify('distinct_id', { $group: 'company_id' }) call could identify which company is currently active. We could make some distinct_ids of a user belong to one 'company', some to the other and make use of that in our analytics.

This is harder to realize, especially on clickhouse since we don't do joins against persons tables there. However, it also provides semantics which are closer to what I've needed in the past.

Cc @fuziontech - iirc you mentioned some ideas during the offsite?

[paolodamico]

Agree with @macobo, we could definitely make us of this right away. There are some key questions about our product usage that this is blocking us to answer (see #2857 for example). This will also help our customer success process (see Slack thread). Will make a case for getting it prioritized for next release.

[macobo]

How it works at mixp@nel:

• https://help.mixpanel.com/hc/en-us/articles/360025333632-Group-Analytics
• https://developer.mixpanel.com/docs/javascript#section-group-analytics

1. You can have multiple groups (which you define yourself) - e.g. company, channel, etc.
2. You can add a distinct_id to one or more groups. So one user can be in multiple companies.
3. Each group entity has a profile similar to our current "Persons" view
4. You can filter and group by companies as usual

5. To do analytics by company you switch the "group" at the top of the report and can then graph DAU:

Not quite sure what the semantics of that is though - if user is part of 2 companies, are both counted as active?

I think to associate every event with a single company you could:

1. Each time user logs in/switches company, do .reset() in the javascript library, resetting the distinct_id
2. Set the group for this distinct_id as the active company

I think these semantics would work well for what I've needed in the past and what we'd like to use for ourselves.

cc @paolodamico @jamesefhawkins

[timgl]

Based on discussion with Karl:

• It might make sense to be able to dynamically generate groups. Feels like having to write code to create/add users to groups creates a big barrier esp for non technical users
• This is an advanced enough feature we can just build it in Clickhouse. Should reduce complexity

[macobo]

Another (potential) usecase for this - for feature flags, making sure members of a team all see the same set of features.

[paolodamico]

Very, very rough draft just to give a sense on how group analytics can fit the new design on #4050 (even if it looks similar to Mixpanel). We still need to figure out functionality/UX here. Particularly one of the key questions is if we'll do dynamic grouping based on a property, or static groups based on config set with code, or both.

[samwinslow]

@paolodamico in terms of information architecture, how do we want to treat aggregations and distributions for groups? What if I want to query sum of groups?

[kpthatsme]

@paolodamico What do you think about moving 'Property aggregation' and 'Property distribution' to a filter on the property dropdown instead of combining it in the Users + group drop down?

Very, very rough draft just to give a sense on how group analytics can fit the new design on #4050 (even if it looks similar to Mixpanel). We still need to figure out functionality/UX here. Particularly one of the key questions is if we'll do dynamic grouping based on a property, or static groups based on config set with code, or both.

[buwilliams]

Silly questions: What is a group? How is it different than a cohort? From what I've read above is seems that a group is just a list of people. If so, isn't that what a cohort is? Cohorts can be "dynamically" create in the UI today. I may be way off but maybe there's overlap?

[EDsCODE]

There's some more related information here: #3963

If I understand correctly, you can think of groups almost like users but where users are defined by a collection of distinct_ids, groups would be defined by a different user property that is set. For example, if you're on posthog on the hypothetical groups page (grouped by organization_id), you would get a list of profiles similar to the persons tab on our app right now but now each "user" would be an organization_id that combines the activities and properties based on organization_id rather than distinct_id.

This is different from cohorts where you're defining a specific set of users that you can put in a filter. The analytics you get from a cohort isn't treating each cohort as singular entity as it would with groups.

Tagging this old PR that I worked on as a possible way to edit users and add properties to them so you can easily associate a large number of users to a group: #3494 . It also could be used to define a custom cohort, we just need to make this clear

[macobo]

To put this another way: Users are not the only way to think about analytics in.

For posthog, we currently analyze retention on a per-user-basis, but from a business standpoint we care about organizations. We want to be able to analyze organizations and see who are at risk of converting, how many paying organizations are active, how many are inactive. This is really common for any B2B company.

You can go further with the concept: What if some entities in your analytics are not users at all? For us, we report statistics for posthog instances, but we have no way to tie these back together with specific organizations/users.

These are not the same as a cohort since you can't really compare across LARGE_N of cohorts in a comfortable way.

[buwilliams]

For group, is the difference then that groups have fluid users? Seems like a data model might look something like having a root container called entity and each entity has a type such as group, service, or company

[EDsCODE]

They're both a collection of users in some way yes. However, a cohort is a specific collection of users whereas group analytics is answering the question "I want to know how many organizations performed a pageview on this day". This means that when you're looking at a trend graph and you see the number 150, it wouldn't be 150 specific users it would be 150 organizations.

You technically could achieve this if you created a cohort for every single new organization_id that was created on app but this would be unsustainable. Group analytics should allow you to define a "user" on a different dimension not just distinct_ids and the querying will account for this without needing N number of manually created cohorts

[paolodamico]

From another user today:

Well it's a big +1 from me to implement that!
For more context, we have a collaborative product and we will try to track team usage across the same workspace.

[romj]

I don't know if / how to upvote feature requests, but I would also like this very much

[paolodamico]

This is actually a great way @romj, thanks for showing interest in this feature!

[paolodamico]

@macobo closing this issue now as we know have Group Analytics, feel free to open if something is missing.