Group analytics mega-issue

Problem

We keep hearing the same problems with group analytics:

• Difficult to understand — We get frequent churn-survey responses from customers who don't know what they turned on or how to use it. 20% of organizations paying for group analytics aren't collecting any group events.

• Restricted to paid users — Group analytics is only available on paid plans, so customers can't instrument it early. Because there's no historical tagging, adopting it late permanently loses data. Only 6% of new customers adopt a paid plan at sign-up.

• Mental model doesn't fit our customers — An estimated 80%+ of customers use groups for accounts, organizations, teams, or businesses. They expect users to belong to groups, but we instrument groups at the event level. That's fine, and it's better for query performance, but we have to translate it to customers far better to match their mental model.

• Doesn't play well with cohorts — A known issue: groups can't be used as filters or as properties to build cohorts. Customers expect this, because in their mental model users belong to groups, so cohorting users by group properties is a natural expectation.

• Pricing doesn't align with value — We currently charge based on identified events, not group-tagged events. This confuses customers and discourages adoption when only a small share of their events are group-tagged.

• Low awareness and adoption — Group analytics isn't in onboarding or the setup wizard, and it's hidden in billing behind a toggle. Only 8.5% of users are tagging events with groups. We think this is well below the percentage of customers who would find value in it. Driving this up is the main business objective of this mega-issue.

• Can be worked around with event properties - "None of our saved insights, cohorts or flags use group analytics - we now attach org context as a plain event property instead, so the add-on is unused." (Churn survey, 8/30/2026)

Goals

Our primary objective is to increase the share of customers who instrument group analytics and get value from it. Today only 8.5% of users tag events with groups — well below the share we believe would benefit. Everything below ladders up to moving that number.

• Make it clear. Customers should understand what group analytics does, how it works, and how to use it — so they stop enabling it without knowing what they turned on. Success: fewer confused churn-survey responses; the 20% of paying orgs collecting zero group events trends toward zero.
• Make it easy to adopt early. Get groups instrumented from day one — in the free tier and during onboarding — instead of after an upgrade, since there's no historical tagging. Success: groups instrumented at sign-up, not just post-upgrade.
• Match the customer mental model. Let customers instrument groups the way they think about them (users belong to organizations) without changing our event-level model.
• Make groups work everywhere. Groups should be usable across cohorts, surveys, and experiments — not just insights.
• Align pricing with value. Charge for the group events customers actually use, removing a barrier to adoption rather than creating one.

Sub-issues

Each of these will have an associated issue, and potentially an RFC for more impactful changes (like pricing).

1. Include group analytics in the free tier — Group analytics is most impactful when it's instrumented from day one, since there's no historical tagging. Today, only 6% of new customers are on a paid plan with access, so most never get the chance to start early.

2. Group analytics as a UI toggle, not a billing toggle — Customers only need to start ingesting group tagged events to start using group analytics. The group analytics toggle is just a UI toggle (starts showing the groups in analytics / experiments / etc.), and it turns on automatically for any organization that ingests a group event. This should drive up adoption of group analytics, since only 1 step is required to start using it.

3. Pricing metric change — Base group pricing on group events, not identified events. [RFC](https://github.com/PostHog/requests-for-comments-internal/issues/1042). We may need to adjust pricing of group events as a result of the revenue-loss associated with this switch.

4. Allow for person-less events — Once we've changed pricing and start charging for group events, we can start allowing for person-less events. Currently group properties can only be included on identified events. #49905

5. Person-level group tagging — Add group tagging inside identify events, so every event from a person tagged with a group ID is associated with that group. This matches how most customers think about groups (users belonging to organizations). This is one of the bigger changes in this proposal #65190

6. Seamless group usage in cohorts, surveys, and experiments — Groups are hard to use across cohorts, surveys, and experiments today, because cohorts are based on people and people have no associated groups. Person-level group tagging (sub-issue 4) makes this possible. (Issue [#62986](https://github.com/PostHog/posthog/issues/62986))

7. Revamped group and person tagging documentation — Updated docs and create a short visual/video explainer of how event enrichment works, covering both person-based group tagging and direct event tagging.

8. Include group tagging in the Wizard — Ensure the wizard checks for applicability of using group events during initial instrumentation. Create a separate wizard tool for group analytics instrumentation as well for existing projects.

9. Visual groups and persons properties manager — A view showing which properties are available on groups and persons, with visual connectors to other tables to encourage Data Warehouse adoption.

Person-tagged groups: detail (sub-issue 4)

Moved detail on this to a separate issue: #65190