How I added group-property filtering to PostHog surveys
Small UI + logic changes that let teams segment survey responses by organization, industry, or other group attributes.
TL;DR
I contributed a feature to PostHog that allows survey responses to be filtered by group properties (e.g., company_name, industry). I updated the filter UI, wired filters into the survey query logic, added unit tests, and iterated with maintainers until the PR was merged making survey analytics more useful for teams that analyze data by organization.
Background
PostHog is an open-source product analytics platform used by thousands of engineering and product teams. Its survey tool helps teams collect user feedback, but before this change, survey filters were limited to user/event properties — you couldn’t slice results by organization or other group-level attributes.
The problem (what I found)
Product teams wanted to compare survey responses across organizations, teams, or industries. Without group-property filters, they had to build external workarounds or export data — a slow, error-prone process that broke the flow of insights inside PostHog.
My solution (what I did)
Frontend: Extended the existing property filter component to include group taxonomies (so group properties appear alongside person/event properties in the selector).
Query logic: Integrated those selected group filters into survey queries so the backend returns filtered survey responses correctly.
Testing: Added unit tests to cover single and combined group-filter scenarios, and validated behavior for edge cases (no group props, multiple group types).
Collaboration: Addressed maintainers’ feedback, refined the UI wording/positioning, and iterated until the feature matched PostHog’s UX and reliability standards.
Implementation notes (concise, for readers who want details)
Extended the
PropertyFiltersUI to recognize group taxonomies.Updated survey query generation to accept
groupfilters and include them in the server request payload.Added
surveyLogicunit tests to ensure filters worked individually and in combination.Kept the change backward-compatible: if no group filters are selected, the behavior is unchanged.
The review process & collaboration
I opened the PR, discussed the original feature request, and responded to review comments from maintainers. We iterated on naming, test coverage, and UI placement. Maintainers were supportive and gave helpful suggestions — after addressing those, the PR was approved and merged.
Result & impact
The PR was merged and shipped to PostHog users.
Product teams can now segment survey responses by organization, industry, and other group attributes directly in the UI.
This reduces friction for teams that need cross-organization analytics and aligns surveys with other segmentation tools in PostHog.
What I learned
Working in a large TypeScript + React codebase taught me how to introduce a small feature without breaking backward compatibility.
Collaboration matters: clear PR descriptions, tests, and quick responses to reviews accelerate acceptance.
Small UX improvements can unlock much richer product value for end users.
