## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Feature + two follow-on fixes — small, scoped to telemetry / experiment
plumbing.
## What is the current behavior?
PostHog feature flags evaluated in Studio only have access to the
`gotrue_id` person property (set in `useTelemetryIdentify`) and the
`organization`/`project` group associations from pageviews. Flags can't
target users by org membership without a behavioral cohort, which
refreshes on a ~hourly schedule and lags behind real-time signup state.
This is blocking the rollout of the `dataApiRevokeOnCreateDefault`
experiment ahead of the May 30 default-privileges breaking change — we
need to target brand-new dashboard signups with no prior org membership,
and there's no person property to filter on.
## What is the new behavior?
Three changes, scoped tightly to make experiment targeting reliable for
brand-new signups:
### 1. Mirror `org_count` to a PostHog person property
(`apps/studio/lib/telemetry.tsx`)
The Studio `Telemetry` component now mirrors the user's current org-list
length to a PostHog person property `org_count` via
`posthog.identify(user.id, { org_count })`. The effect:
- Subscribes to `useOrganizationsQuery` (shares the same React Query
cache as `useSelectedOrganizationQuery`, so no extra network requests).
- Dedupes via a ref keyed on `{ userId, orgCount }` so we only call
identify when the value actually changes — handles user-switch
(logout/login as different user with same count) correctly.
- Generic enough to be useful beyond this experiment — analytics
segmentation by org membership, future flags that depend on multi-org
behavior, etc.
### 2. Merge pre-init identify properties
(`packages/common/posthog-client.ts`)
The previous `pendingIdentification` slot was a single-write buffer —
calling `posthogClient.identify()` before the PostHog SDK initialized
would overwrite any prior queued identify. Latent until this PR added a
second identify caller (`org_count`), which exposed the last-write-wins
behavior on first-visitor-before-consent flows. Now merges properties
across pre-init calls for the same user so both `{ gotrue_id }` and `{
org_count }` land on the person record when the SDK flushes. Caught
during Codex review.
### 3. Gate the exposure event on `org_count` being present
(`apps/studio/hooks/misc/useDataApiRevokeOnCreateDefault.ts`)
`useTrackDefaultPrivilegesExposure` previously fired on the first
non-undefined value of the `dataApiRevokeOnCreateDefault` flag. For
brand-new signups, this races the `org_count` identify: the initial
`/flags/` response (before targeting can match) returns the untargeted
variant, the exposure locks it in via `hasTracked`, then our identify
fires and a subsequent `/flags/` refresh updates the flag — but the
exposure has already recorded the wrong variant.
Fix: gate the exposure on `org_count` being present on the SDK person,
subscribing via `onFeatureFlags` so we pick up the post-identify
`/flags/` response. Adds `posthogClient.getPersonProperty` as the
local-state reader. Without this, the experiment would have a ~5-15%
noise floor on cohort assignment for new signups.
## Verification
End-to-end verified locally against the staging PostHog project (34343):
- Local Studio's PostHog SDK has `$stored_person_properties: {
gotrue_id: <uuid>, org_count: 1 }` after sign-in.
- Both `$set` events landed server-side within ~300ms of each other, and
the staging person record now shows `org_count = 1.0` with `gotrue_id`
preserved.
- Targeting query `person.properties.org_count == 1` works end-to-end
against staging.
## Additional context
Ref: [GROWTH-853](https://linear.app/supabase/issue/GROWTH-853)
Targeting plan for the flag once shipped: `person.org_count == 1` plus a
behavioral filter on recent `sign_up` event, at 5% rollout.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Telemetry now records and syncs the user's organization count as an
analytics person property and avoids redundant identifications when
unchanged.
* Analytics client now merges queued identification properties made
before initialization and exposes a method to read stored person
properties.
* **Bug Fixes**
* Tracking now waits for organization-count readiness before firing
certain exposure events to prevent missing data.
* **Tests**
* Added/updated tests to cover person-property behavior and gating
logic.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45946)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Adds client-side PostHog tracking to run in parallel with server-side telemetry across studio, docs, and www. This enables session replays and resolves a race condition where page views arrive before group assignments resulting in attribution errors.
Changes:
- Created PostHog client wrapper with consent-aware initialization in common package
- Integrated PostHog client calls into existing telemetry functions to send events to both PostHog (client) and backend (server)
- Updated CSP to allow connections to PostHog endpoints
- Added environment variable support for all apps
- PostHog client accepts consent as a parameter and respects user preferences
- Events can be distinguished in PostHog by $lib property (posthog-js vs posthog-node)
- PostHog URL configured based on environment (staging/local uses ph.supabase.green)
- Maintains full backward compatibility with existing telemetry system
Resolves GROWTH-438
Resolves GROWTH-271
* chore: add usercentrics for consent management
* client component to make next.js happy
* address feedback
* move consent state to common
* fix import
* ensure page events are sent correctly
* add feature flag provider to ui library site
* fix ui lib 500 error
* skip in test env
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
Sean Oliver
