I added outcome events for Explorer query runs and successful manual
notebook saves. Existing page visits and preview toggles do not show
whether users complete queries or persist notebooks.
**Changed:**
- **Query usage:** Accepted runs from query tabs and notebook cells emit
submitted and terminal outcome events with a shared run ID. Canceled
confirmations emit no run events.
- **Notebook adoption:** Successful manual saves emit created or updated
events. Recreated notebooks count as creations. Unsaved drafts and
failed saves emit neither.
- **Event metadata:** Explorer action events use `Explorer` as their
page title.
**Note:** Assistant-generated saves are outside this PR. Custom
properties omit SQL and notebook content. Page visits still carry the
browser title, which can include a notebook name.
## To test
Tested on the staging preview:
- [x] Run valid and invalid SQL from an Explorer query tab. Each run
emits one submitted event and one matching completed or failed event
with the same run ID.
- [x] Run database and Logs notebook query cells, then add a markdown
cell. The query cells emit matching event pairs; the markdown cell emits
no query event.
- [x] Save a new notebook, then edit and save it again. The successful
saves emit created and updated events.
- [x] Cancel a guarded query. It emits no query run event.
- [ ] Recreate a notebook deleted on the server after local edits. A
successful save emits created, not updated.
- [x] Inspect an Explorer action event request. Its page title is
`Explorer`; page visits still use the browser title.
- [ ] Force a notebook save failure. It should emit no save event. This
case was not tested manually.
## Linear
- fixes GROWTH-1298
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Analytics**
* Explorer query runs are tracked for database and log queries,
including whether they complete or fail.
* Query activity is associated with its location in Explorer, such as a
query tab or notebook cell.
* Successful notebook saves are tracked as creations or updates.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## 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: ad attribution capture.
## What is the current behavior?
Freebuff ad clicks arrive on supabase.com with a signed click id in
`?bfcid=`. Nothing captures it, so those signups are unattributed.
## What is the new behavior?
This PR captures `bfcid` and writes it to a cookie that, in production,
is scoped so the management API receives it. The conversion is reported
server-side on profile creation, in a separate change tracked in
GROWTH-1217.
Start with `enforceConsentDecision` in
`packages/common/consented-url-cookie.ts`. It is the rule everything
else hangs off, and `consented-url-cookie.test.ts` covers the state
matrix.
Capture:
- `bfcid` is read on landing and held in `sessionStorage` until the
consent decision resolves. Memory alone loses it when someone navigates
before answering the banner.
- Once consent is granted it goes into a cookie. In production on
`*.supabase.com` that cookie is scoped to `domain=supabase.com`, and it
is host-only elsewhere. It is written only after consent, which is the
signal GROWTH-1217 relies on.
- Values are validated with `/^bfc_[A-Za-z0-9._-]{1,508}$/`, the
validator Freebuff publishes in their tag, so we never store a value
their tag would reject.
- `bfcid` is added to the first-touch attribution props, which feed
pageview telemetry and are already consent-gated.
Consent:
- `enforceConsentDecision` reduces the decision to two states. Undecided
and declined both clear the cookie, since neither has consent to point
at. They differ in the retained value: an undecided visitor may still
accept, so it waits for them.
- `clearConsentedUrlCookie` drops the cookie. `discardConsentedUrlValue`
also drops the retained value.
- A module-level valtio subscription registers on import, guarded on
`window` so it is inert during SSR.
`packages/common/consent-state.ts` gains a generic `isResolved` flag and
no vendor knowledge. A consumer acting on a decision needs to tell "not
decided yet" from "decided against", which `hasConsented` cannot express
alone. `applyPriorDecisionToSDK` now returns its promise chains, so its
signature becomes `void | Promise<void>` and initialization awaits
settlement before marking the decision resolved. Worth checking the call
sites.
## Additional context
160 tests pass in `packages/common`. Typecheck and Prettier are clean
locally on the changed files. CI is still running on the latest commit.
Unverified: the clearing paths are covered by unit tests only. The
consent SDK is short-circuited in local and preview builds, so they
cannot be exercised outside production. An end-to-end conversion
recorded by Freebuff is also unverified, since it needs the server-side
change deployed.
GROWTH-1216
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added consent-aware handling for Freebuff Ads click identifiers,
retaining valid URL values until consent is resolved and storing them in
a cookie after approval.
- Added automatic cleanup when consent is denied or withdrawn, while
preserving unrelated cookies.
- Added support for capturing the click identifier in first-touch
attribution data.
- **Bug Fixes**
- Improved consent initialization tracking so completion is reported
after successful or failed resolution.
- Added safeguards for restricted browser storage, cookies, and
server-rendered environments.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Sean Oliver <882952+seanoliver@users.noreply.github.com>
The /sign-in page emitted only a pageview on entry and the success-side
`sign_in` event on exit: failed or abandoned attempts were invisible, so
"never interacted" and "tried and failed silently" could not be told
apart in the sign-in funnel. I added an unsampled `sign_in_submitted`
event at every initiation point and classified failure capture via
`dashboard_error_created` with a new `signin` origin.
**Changed:**
- **Submit attempts observable**: `sign_in_submitted` (method: `email`,
provider id, `sso`, or partner) fires from the DOM submit handler on the
password and SSO forms (so submits that fail client-side validation
still count), and from the OAuth, custom-provider, and partner
initiation handlers.
- **Failures classified**: each sign-in error path feeds the existing
funnel-error pipe with origin `signin` and a controlled reason slug
(`invalid_credentials`, `email_not_confirmed`, `captcha_failed`,
`sso_provider_not_found`, ...). GoTrue auth errors now classify via
their numeric `status`, guarded so transport failures (`status: 0`) stay
`network_error`.
- **Attempt events survive the OAuth redirect**: the telemetry event
POST sends with `keepalive` (scoped to `sign_in_submitted`, since
keepalive requests share a per-page in-flight body quota), so a
dispatched request is no longer aborted by the provider navigation; send
rejections are caught centrally instead of surfacing as unhandled
rejections. The fetch still dispatches after an async token lookup, so
preview testing verifies the GitHub-path event actually lands on the
wire.
- **Captcha rejection is no longer silent**: a rejected hCaptcha
challenge resolves the stuck loading toast with an error message, emits
`captcha_challenge_failed` (distinct from `captcha_failed`, which stays
reserved for the auth server rejecting a submitted token), reports to
error monitoring, and resets the captcha widget (previously: unhandled
promise rejection and a spinner that never resolved).
- **Partner method validated**: the partner sign-in page resolves the
URL-hash value against the provider registry and forwards the canonical
provider id into `method` on both `sign_in_submitted` and `sign_in`;
anything unregistered records as `unregistered_partner`, so a crafted
link can't poison the breakdown on either event.
**Note:** failure events stay on the shared 10%
`dashboard_error_created` sampling rate (a per-origin carve-out would
break cross-source volume comparability); the unsampled attempt event
carries the tried-vs-never-interacted signal at full volume.
## To test
Tested on Vercel preview (studio-staging, wire-level network capture +
staging ingestion check):
- [x] On `/sign-in`, submit a bogus email + password: expect a `POST
*/platform/telemetry/event` request with `action: sign_in_submitted`,
`method: email` in the network tab, plus an error toast. Observed: 201,
auth returned 400 as expected.
- [x] Submit with an empty password: expect `sign_in_submitted` to still
fire (validation failures count as attempts). Observed: event fired with
201 and no auth call followed.
- [x] Click "Continue with GitHub": expect `sign_in_submitted` with
`method: github` on the wire before the provider redirect. Observed: the
POST completed (201) before the browser landed on github.com, so the
keepalive path holds.
- [x] Negative case: fresh page load with no interaction fires no
`sign_in_submitted`.
- [x] Ingestion: all fired events (methods `email`, `github`, plus
organic `sso` submits from a real login on the same preview) arrived in
the staging project with the expected properties.
- [x] Re-ran the email and GitHub paths on the scoped-keepalive build
(`129bf8d`): both `sign_in_submitted` POSTs returned 201 (the GitHub one
completed despite the provider redirect), and both events ingested into
the staging project with the expected `method`/`category` properties.
## Linear
- GROWTH-1165 (no `fixes` keyword on purpose: the evidence checks run on
prod data post-deploy, and the issue closes manually after they pass)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Improved sign-in protection with more reliable invisible CAPTCHA
handling.
* Added sign-in submission tracking across password, SSO, partner,
custom OAuth, and external-provider flows.
* Added detailed classification for authentication, validation, CAPTCHA,
provider, and network errors.
* **Bug Fixes**
* Sign-in now stops safely and resets CAPTCHA when verification fails.
* Improved error reporting for failed sign-in attempts, including
redirects and OAuth flows.
* Ensured sign-in telemetry is delivered reliably during OAuth
redirects.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
Telemetry feature.
## What is the current behavior?
- Session replay is off, and nothing in the code keeps it off.
- `packages/common/posthog-client.ts` sets no recording config at all.
- So PostHog's project setting alone decides, for every app sharing that
project.
- Studio, www and docs share one project.
- Studio shows customer data almost everywhere: SQL editor, table rows,
connection strings, API keys.
- posthog-js masks inputs by default. It does not mask rendered text.
- [GROWTH-1055](https://linear.app/supabase/issue/GROWTH-1055)
## What is the new behavior?
- `posthogClient.init()` takes a masking config, and disables recording
when it gets none.
- Studio passes one behind `NEXT_PUBLIC_POSTHOG_SESSION_REPLAY`.
- Every other app passes nothing, so it never loads the recorder.
- Studio masks all text and all inputs.
- `data-ph-capture="true"` opts one element's text back in. Unused so
far.
- Canvas is blocked, because it records as images that text masking
cannot reach.
- Query strings and fragments are stripped from recorded URLs, where
auth callbacks carry tokens.
- Request and response bodies are never recorded.
- Console logs are never recorded, since masking only reaches DOM text.
- Masking is set in code, so PostHog's settings cannot loosen it.
- Consent gating is unchanged. Nothing records before a user accepts.
## Additional context
- Recording needs three things: this env var, the PostHog project
toggle, and user consent.
- All three are off or unset, so merging this changes nothing at
runtime.
- `NEXT_PUBLIC_POSTHOG_SESSION_REPLAY` goes into Vercel on Preview scope
first, to test on a preview build.
- Production scope comes later, once we are ready to record there.
- `NEXT_PUBLIC_*` is inlined at build time, so each scope needs a
rebuild afterwards.
- Text inside HTML attributes (`title`, `alt`, `href`) is still recorded
as-is.
- posthog-js exposes no hook for masking attributes, so covering it
needs `ph-no-capture` per component.
- Staging has no server-side masking config, so that is where this gets
verified.
- Plan: enable recording on staging, verify masked text on a preview,
then decide on production.
- Network timing stays on for the dashboard performance work. Payloads
stay off.
- Tests cover both masking functions and the config values.
## Screenshots
https://github.com/user-attachments/assets/aa064a04-f977-4453-a3da-2fe0cdcead08
<img width="889" height="651" alt="CleanShot 2026-07-31 at 10 13 43"
src="https://github.com/user-attachments/assets/f1d07946-fd68-42b2-89f1-d201bc605638"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
* **New Features**
* Added privacy-focused session replay for Studio.
* Text and form inputs are masked by default, with explicit opt-in
capture.
* Network recordings remove query strings and fragments.
* Headers, request bodies, canvas data, and console logs are excluded.
* **Bug Fixes**
* Improved whitespace and capture-attribute handling during masking.
* Session replay remains disabled without a masking policy or explicit
enablement.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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 — tiny telemetry addition. +7/-1 in one file.
## What is the current behavior?
[PR #45946](https://github.com/supabase/supabase/pull/45946) added
`org_count` as a PostHog person property to unblock targeting on org
membership. But `org_count` is set on every authenticated session (the
`Telemetry` component fires identify whenever `user.id` +
`organizations` resolve), not just at signup completion.
That means flag filters like `person.org_count == 1` match two
populations:
- Brand-new dashboard signups currently in their first org (intended)
- Returning users who happen to have one org and just signed in (not
intended)
For the upcoming `dataApiRevokeOnCreateDefault` experiment, this
contaminates the activation comparison because the "returning
single-org" group can't activate (they already did, months ago),
diluting the measured effect.
## What is the new behavior?
Adds `signup_timestamp: user.created_at` to the existing
`posthogClient.identify` call in `useTelemetryIdentify`. Since gotrue's
`user.created_at` is immutable, the value stays constant across sign-ins
— no need for `$set_once` semantics, no race with anonymous activity, no
cohort refresh lag.
Flag targeting can now combine `person.org_count == 1 AND
person.signup_timestamp >= <experiment_start_date>` to cleanly scope to
brand-new signups.
## Testing
No new unit tests added — the existing `useTelemetryIdentify` function
has no test file, the change is one additional field on an existing
call, and the property's correctness is verifiable end-to-end (sign up →
check PostHog person record). Adding to the test ticket
[GROWTH-854](https://linear.app/supabase/issue/GROWTH-854) for coverage
along with the broader posthog-client wrapper tests.
## Additional context
Ref: [GROWTH-853](https://linear.app/supabase/issue/GROWTH-853)
This is the follow-up gate before the 5% rollout of
`dataApiRevokeOnCreateDefault` — without this, the experiment would mix
brand-new signups with legacy single-org users on sign-in.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Enhanced telemetry and analytics data collection for signed-in users
by improving user identification tracking and adding signup timestamp
information for better analytics insights.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45951)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
GitHub OAuth redirects and Google SSO set the browser's Referer header
to their domain when redirecting back to supabase.com. Our attribution
pipeline treats these as genuine referral traffic, inflating the
`github` channel by ~20K orgs/week. The internal referrer fix
(GROWTH-647) surfaced this by reducing `unknown-internal` — it didn't
cause the issue, it revealed OAuth noise that was previously hidden.
## What happened
When users sign in with GitHub, the browser sends `Referer:
https://github.com/`. GitHub's login pages use
`origin-when-cross-origin` Referrer-Policy, which strips the path. So
OAuth redirects arrive as bare `github.com/` — indistinguishable from a
direct visit to github.com. Meanwhile, genuine GitHub referrals from
repos/READMEs always include the full path because those pages use
`no-referrer-when-downgrade`.
We validated against `mart_marketing_organization_attribution`: 98.5% of
GitHub-attributed orgs have bare `github.com/` as the referrer. Only
~250/week have specific paths (genuine referrals).
## Changes
- Added `isOAuthRedirectReferrer()` to `first-referrer-cookie.ts` —
identifies auth provider redirects:
- `accounts.google.com` blocked entirely (dedicated SSO subdomain)
- Bare `github.com/` blocked (OAuth redirect signature)
- `github.com/<specific-path>` preserved (genuine repo/README referrals)
- Wired into `shouldRefreshCookie()` so OAuth referrers never get
stamped into cookies
- Wired into `handlePageTelemetry()` referrer overrides as
defense-in-depth
- 17 new tests covering all OAuth patterns and edge cases
## Testing
All 52 tests pass. New tests cover Google SSO (bare + with path), GitHub
bare domain (with/without trailing slash), genuine GitHub referrals
(repo, README, discussion, blob), explicit OAuth path, non-OAuth
domains, empty/malformed URLs. Verified TDD — tests failed red before
implementation, green after.
Companion dbt PR in data-engineering handles historical data.
GROWTH-732
## Changes
Introduces two new files in `packages/common`:
- **`telemetry-first-touch-store.ts`** — a module-scoped singleton that
holds first-touch attribution data (referrer, UTM params, page URL) in
memory. Writes once on first load, cleared after the initial pageview
event fires or on opt-out. No device storage involved.
- **`useFirstTouchStore.tsx`** — a React hook that captures attribution
data on initial page load and writes it into the store, gated on the
`enabled` flag so it only runs where consent has been handled.
Trade-off: data is lost on a hard reload before consent is granted —
accepted edge case per GROWTH-656.
Follows the same module-scope pattern already used by `posthogClient`
and `consentState`.
## Testing
- Verify first-touch data is captured on initial load and readable by
`PageTelemetry` after consent
- Verify no cookie is set before consent
- Verify data is cleared after initial pageview fires
GROWTH-656
## Summary
The `homeNew` PostHog experiment has concluded. This PR graduates it by
making the new homepage (`ProjectHome`, formerly `HomeV2`) the permanent
default for all users, and removes all dead code from the old
experiment.
## Changes
- Remove `homeNew` PostHog feature flag checks and `home_new` experiment
exposure tracking from 3 files
- Rename `HomeNew/` → `ProjectHome/` directory and `HomeV2` →
`ProjectHome` export
- Delete old `Home/Home.tsx` component (shared components like
`ProjectList/` are kept — still used by org pages)
- Delete `pages/project/[ref]/building.tsx` and add a server-side
redirect from `/project/:ref/building` → `/project/:ref` to prevent 404s
during rollout (old cached JS bundles may still route to `/building`)
- Simplify `ContentWrapper` building-state logic in `ProjectLayout` —
always redirect building projects to home, always suppress building
interstitial on home page
- Always route to `/project/{ref}` after project creation (remove
`/building` path)
- Update all Observability imports from `HomeNew` → `ProjectHome`
## Self-hosted behavior change
Self-hosted Studio previously showed the old `Home` component (client
libraries + example projects) since PostHog flags don't load. This PR
changes self-hosted to show `ProjectHome` (TopSection with service
status + instance diagram, advisor, custom reports). All sections query
backend APIs that exist on self-hosted. E2E tests pass against the
self-hosted build.
## Testing
- [x] `pnpm turbo run build --filter=studio` passes
- [x] No remaining references to `homeNew`, `home_new`, or `HomeNew` in
codebase
- [x] No broken imports to deleted files
- [x] Self-hosted E2E tests pass (145 passed, 1 flaky, 4 skipped)
- [x] `/building` redirect added to both platform and self-hosted config
blocks
**Quick test:**
1. Navigate to any project homepage — should render the ProjectHome
component
2. Create a new project — should redirect to `/project/{ref}` (not
`/building`)
3. Visit a project in `COMING_UP` state on a non-home route — should
redirect to home
4. Visit `/project/{ref}/building` directly — should 302 redirect to
`/project/{ref}`
## Linear
- fixes GROWTH-671
## Problem
The `_sb_first_referrer` cookie isn't working. The www middleware
matcher explicitly excludes `/dashboard` and `/docs`, so the cookie
never gets stamped for Studio or Docs traffic. PostHog confirmed: only 1
event with `first_referrer_cookie_present=true` out of ~46.5M Studio
pageviews in the last 7 days.
## Background: what the matcher does
In Next.js, the `matcher` config controls which incoming requests the
middleware function even runs on. If a path doesn't match, the
middleware is skipped entirely — the request passes through untouched.
If it matches, the middleware runs and can mutate the response (set
cookies, headers, etc.).
This matters because Studio's SPA navigation works via silent
`/_next/data/` JSON fetches. If middleware runs on those requests and
returns `NextResponse.next()` with any mutations, it breaks those
fetches and causes full page reloads instead of client-side transitions.
## What we tried before
| PR | www runs on `/dashboard`? | Studio `proxy.ts` runs on all routes?
| Result |
|---|---|---|---|
| **#42768** (Attempt 1) | ✅ Yes — and also intercepts `_next/data` | ✅
Yes — `matcher` config removed, stamps cookie everywhere | Full page
reloads in Studio |
| **#43129** (Full revert) | ❌ No — www middleware deleted entirely | ❌
No — restored to `matcher: '/api/*'` only | Back to baseline, no cookie
stamping anywhere |
| **#43153** (Attempt 2) | ❌ No — `/dashboard` explicitly excluded | ✅
Yes — `matcher` config removed again, stamps cookie everywhere | Full
page reloads in Studio again |
| **#43189** (Attempt 3) | ❌ No — same as #43153 | ✅ Yes — `matcher`
config still removed, cookie stamping made conditional | Still broken |
| **#43190** (Ivan's fix) | ❌ No — `/dashboard` still excluded | ❌ No —
restored to `matcher: '/api/*'` only | Works — but cookie never stamps
for `/dashboard` traffic |
| **#43413** (this PR) | ✅ Yes — sets diagnostic cookie only, no
attribution stamping yet | ❌ No — unchanged, still `matcher: '/api/*'`
only | ❓ Untested in prod |
The common factor in every failure: Studio's `proxy.ts` ran on all
routes (including `_next/data` requests), which broke SPA navigation.
This PR is the first one that runs www middleware on `/dashboard` while
Studio's `proxy.ts` stays in its original narrow `/api/*` scope.
## What changed
This is Phase 1 of a two-phase rollout. We remove `dashboard|docs` from
the matcher's negative lookahead so www middleware runs on those paths —
but instead of stamping cookies, we set a short-lived (60s) diagnostic
cookie `_sb_mw_diag` on `/dashboard` and `/docs` requests.
The diagnostic cookie encodes
`hit=1&would_stamp={0|1}&has_cookie={0|1}`, which Studio telemetry reads
on the initial pageview and reports to PostHog as `mw_diag_hit`,
`mw_diag_would_stamp`, and `mw_diag_has_existing_cookie` properties.
A cookie rather than a header because response headers aren't readable
by JS. It also tests the actual Set-Cookie mutation path that Phase 2
will use (which is what Next.js issue #41885 is specifically about).
Phase 1 answers two key questions before we commit to Phase 2:
1. Does expanding the matcher break Studio SPA navigation?
2. What % of /dashboard arrivals would get a first-referrer cookie
stamped in Phase 2?
## Phase 2 readiness criteria
**Important caveat**: `mw_diag_*` data reflects consented users only and
may under-represent first-visit anonymous traffic. The Phase 2 decision
should account for this — the actual middleware execution rate is likely
higher than what PostHog reports.
### PostHog query spec
**Middleware execution rate**: Of all Studio initial pageviews on
`/dashboard` or `/docs` paths, what percentage have `mw_diag_hit =
true`? Expected: >= 90%. Below 70% warrants investigation (could
indicate edge caching bypassing middleware, or a matcher configuration
issue).
```
Filter: event = "$pageview" AND (current_url contains "/dashboard" OR current_url contains "/docs")
Breakdown: mw_diag_hit (true vs null/missing)
Metric: count(mw_diag_hit = true) / count(all) * 100
```
**Would-stamp rate**: Of events with `mw_diag_hit = true`, what
percentage have `mw_diag_would_stamp = true`? This tells us what
percentage of Phase 2 traffic would actually get a cookie stamped. No
hard threshold — unexpected values (< 5% or > 95%) suggest a logic bug
worth investigating before Phase 2.
```
Filter: event = "$pageview" AND mw_diag_hit = true
Breakdown: mw_diag_would_stamp (true vs false)
Metric: count(mw_diag_would_stamp = true) / count(all) * 100
```
**Existing cookie rate**: Of events with `mw_diag_hit = true`, what
percentage have `mw_diag_has_existing_cookie = true`? This tells us how
many users already have the cookie from a prior www visit.
```
Filter: event = "$pageview" AND mw_diag_hit = true
Breakdown: mw_diag_has_existing_cookie (true vs false)
Metric: count(mw_diag_has_existing_cookie = true) / count(all) * 100
```
### Go / no-go threshold table
| Signal | Go | Investigate | No-Go |
|---|---|---|---|
| `mw_diag_hit` rate (% of /dashboard+/docs pageviews) | >= 90% | 70-90%
| < 70% |
| SPA navigation errors (Sentry / Vercel logs) | No increase | < 0.1%
increase | > 0.5% increase |
| Middleware p99 latency (Vercel function logs) | < 50ms added |
50-100ms | > 100ms |
| Sample volume in first 24h | > 1,000 events | 100-1,000 (extend
window) | < 100 (insufficient data) |
## Changes
- `apps/www/middleware.ts`: Removed `dashboard|docs` from matcher; added
`isDashboardOrDocs` guard that sets `_sb_mw_diag` diagnostic cookie
instead of stamping attribution
- `apps/www/middleware.test.ts`: 12 tests covering cookie stamping on
www paths, diagnostic cookie encoding for all scenarios (external
referrer, direct nav, internal referrer, existing cookie)
- `packages/common/first-referrer-cookie.ts`: Exported
`MW_DIAG_COOKIE_NAME`, `MwDiagData` type, and `parseMwDiagCookie()`
helper
- `packages/common/telemetry.tsx`: Reads `_sb_mw_diag` on initial Studio
pageview; reports `mw_diag_*` properties to PostHog
## Testing
Unit tests pass (13/13 www, 31/31 first-referrer-cookie). Production
validation needed:
- [ ] Studio SPA navigation works (tab changes, SQL editor, no full page
reloads)
- [ ] PostHog shows `mw_diag_hit = true` on Studio initial pageviews
- [ ] `mw_diag_would_stamp` distribution looks reasonable before
enabling Phase 2
- [ ] Monitor 24h before Phase 2
Ref: GROWTH-625 / GROWTH-668
This pull request improves how user consent is handled for telemetry and
tracking, ensuring that analytics scripts and cookies are only active
when the user has provided consent. The changes both enforce stricter
checks before enabling Google Tag Manager and ensure that tracking
cookies are cleared when consent is denied.
## Summary
Re-lands the first-referrer cookie feature from #42768 (reverted in
#43129) with middleware matcher fixes that prevent Studio traffic
interference.
**Tracks:** [GROWTH-651](https://linear.app/supabase/issue/GROWTH-651)
## What changed
New shared module in `packages/common/first-referrer-cookie.ts` that
handles stamping and parsing a first-referrer cookie (referrer, UTMs,
click IDs, landing URL). Each app's middleware calls
`stampFirstReferrerCookie` on the edge response — www and docs are the
primary entry points, Studio is a fallback for direct visits with UTMs.
On the telemetry side, `handlePageTelemetry` now takes an options object
instead of positional args, reads the cookie on initial pageview, and
overrides the referrer if the cookie captured an external source but the
current referrer is internal (i.e., the user navigated cross-app). Also
sends `first_referrer_cookie_present`/`consumed` properties so we can
observe the handoff in PostHog.
The docs middleware matcher was broadened from `/reference/:path*` to
all docs pages so we stamp cookies site-wide, not just on reference
paths.
## Root cause of original revert
Two layers:
1. **Matcher gap**: www middleware ran on `/dashboard/*` traffic in prod
due to Vercel Multi-Zone architecture (www is the gateway for
`supabase.com`, proxying `/dashboard` → Studio, `/docs` → Docs).
Middleware runs *before* rewrites, so www middleware executed on all
proxied traffic.
2. **`_next/data` interception**: The matcher didn't exclude
`_next/data` paths. Client-side navigation in Next.js fetches JSON via
`/_next/data/...` — middleware intercepted these, returned
`NextResponse.next()` with cookie mutations (which processes through the
middleware response pipeline), and this interfered with the JSON
responses, causing full page reloads in the SQL editor.
## How this PR fixes it
| Fix | Detail |
|---|---|
| Exclude `_next/data` | All three matchers (`www`, `docs`, `studio`)
exclude `_next/data` via negative lookahead |
| Exclude `dashboard` + `docs` from www | www middleware no longer runs
on proxied app traffic |
| `/api/` path guard in Studio | Broadened matcher requires explicit
path check for API route filtering |
| `NextResponse.next()` semantics | Cookie stamping only happens on
matched paths; unmatched paths never enter middleware |
### `NextResponse.next()` vs `undefined` nuance
Returning an explicit `NextResponse.next()` with cookie mutations
processes through Next.js's middleware response pipeline (headers are
merged, cookies are set). Returning `undefined` (i.e. the request never
matches the matcher) lets Next.js handle the request completely
untouched. The matcher exclusions ensure `_next/data` and proxied app
paths never enter middleware at all.
## Testing
- ✅ 22 unit tests for shared cookie utilities (all pass)
- ✅ Studio prod build succeeds, middleware recognized as `ƒ Proxy
(Middleware)`
- ✅ Playwright validation: client-side navigation works across 3 page
transitions, `_next/data` requests return 200 OK without middleware
interception, no full-page reloads
- ❌ www/docs SSG builds require platform backend services (expected —
same as master)
## Summary
Fixes GROWTH-625.
Preserves first-touch attribution across app boundaries by persisting
external referrer context at the edge and consuming it on Studio's
initial pageview.
When users come from an external source to www/docs and then navigate to
Studio, Studio often only sees the internal `supabase.com` hop. This
change preserves the original external context so first-touch
attribution is retained.
## What changed
- **Shared first-referrer cookie utilities**
(`packages/common/first-referrer-cookie.ts`):
- `isExternalReferrer`, `buildFirstReferrerData`,
`serializeFirstReferrerCookie`, `parseFirstReferrerCookie`
- `hasPaidSignals` — detects click IDs (gclid, fbclid, etc.) and paid
utm_medium values
- `shouldRefreshCookie` — centralizes stamp-or-skip decision for all
apps
- `stampFirstReferrerCookie` — shared middleware helper used by all apps
(extracted from duplicated inline logic)
- **Edge middleware on all apps** — stamps cookie for external visitors,
refreshes on paid signals:
- `apps/www/middleware.ts` (simplified to use shared helper)
- `apps/docs/middleware.ts` (simplified to use shared helper)
- `apps/studio/proxy.ts` (integrated into existing proxy file)
- **Docs middleware matcher** — broadened from `/reference/:path*` to
all non-static paths so the first-referrer cookie is stamped on all docs
pages, not just reference paths
- **Telemetry** — Studio consumes cookie on initial pageview
(`packages/common/telemetry.tsx`). `handlePageTelemetry` refactored from
7 positional params to an options object for readability.
- **Tests** — 22 unit tests covering all utilities and edge cases
(including direct-navigation scenario)
## Behavior
- Writes `_sb_first_referrer` cookie when:
- cookie is not already set and request has an external referrer, OR
- cookie exists but incoming URL has paid traffic signals (click IDs or
paid utm_medium)
- Cookie: 365-day TTL, `domain=supabase.com`, `sameSite=lax`,
`secure=true` in production
- On first Studio pageview, if current referrer is internal and cookie
has external context:
- use persisted external referrer
- apply persisted UTM/click-id/landing-url attribution props
- Measurement properties: `first_referrer_cookie_present`,
`first_referrer_cookie_consumed`
## Manual testing
1. Visit `supabase.com/pricing?utm_source=google&utm_medium=cpc` from an
external referrer (or use DevTools to set a `Referer` header)
2. Check `_sb_first_referrer` cookie is set in Application > Cookies
3. Navigate to Studio (`supabase.com/dashboard`)
4. In PostHog (or browser network tab), verify the first `$pageview`
event has:
- `first_referrer_cookie_present: true`
- `first_referrer_cookie_consumed: true`
- `$utm_source: "google"`, `$utm_medium: "cpc"`
- `$referrer` points to the external source, not `supabase.com`
5. Verify subsequent route changes do NOT include
`first_referrer_cookie_*` properties
## Review feedback addressed
- Added `secure: true` flag on production cookies (Pam's first comment)
- Fixed inaccurate JSDoc on `utms` field — keys retain `utm_` prefix
(Pam's fourth comment)
- Added test coverage for edge cases: malformed URLs, multi-cookie
headers, http:// referrers (Pam's sixth comment)
- Docs matcher broadening: fast-path exit on cookie-exists check keeps
overhead minimal, exclusion list is correct
- Extracted shared middleware helper to eliminate duplication across 3
apps
- Refactored `handlePageTelemetry` from positional params to options
object
- Removed redundant null check in `hasPaidSignals`
- Added direct-navigation test case
- Deleted dead `apps/learn/middleware.ts`
- Fixed studio build: integrated cookie stamping into existing
`proxy.ts` (Next.js 16 rejects both middleware.ts and proxy.ts)
---------
Co-authored-by: pamelachia <26612111+pamelachia@users.noreply.github.com>
Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com>
## Problem
We need a local-only UI to inspect client and server telemetry events
and override flags during development without touching non-local env
behavior. This work is intended to be shared across Studio, Docs, and
WWW.
## Changes
- Introduced a shared `dev-tools` package with the Dev Telemetry Toolbar
UI, trigger, and provider.
- Wired the toolbar into Studio, Docs, and WWW app shells (local-only
gating).
- Added a local-only `devTelemetry()` opt-in with storage gating and SSE
subscription.
- Wired client PostHog events into a local listener and re-exported
types.
- Added local flag override cookie support in the UI and CODEOWNERS for
the new package.
- Added unit tests covering local/non-local behavior and flag utilities.
## Testing
Manual (local only):
- Start each app locally: `pnpm dev:studio`, `pnpm dev:docs`, `pnpm
dev:www`
- Open the app, run `devTelemetry()` in the browser console
- Click around and confirm both client and server events appear (client
will be page views only)
- Verify feature flag overrides (PostHog + ConfigCat) persist and
restore correctly
- Confirm dismissing the toolbar clears local storage and hides the
trigger
Unblocked by https://github.com/supabase/platform/pull/29172
Resolves GROWTH-591
Demo:
[github.com/user-attachments/assets/60b376db-7440-4ada-82f5-d1bd4af4db3b](https://github.com/user-attachments/assets/60b376db-7440-4ada-82f5-d1bd4af4db3b)
Screenshots:
<img width="1368" height="972" alt="1"
src="https://github.com/user-attachments/assets/d2f20a0c-191f-4118-bb5e-15b25f5a54a9"
/>
<img width="1423" height="790" alt="2"
src="https://github.com/user-attachments/assets/115598e2-7287-49bf-9ed7-71ecc679dee3"
/>
<img width="1433" height="882" alt="3"
src="https://github.com/user-attachments/assets/51f666f2-9efc-410f-baec-378bdee9dbfe"
/>
<img width="608" height="483" alt="4"
src="https://github.com/user-attachments/assets/584d6cf5-1b2f-4cee-9e6a-d55ce2e3bae5"
/>
<img width="628" height="305" alt="5"
src="https://github.com/user-attachments/assets/991a9b39-578a-4565-b110-537a02040a53"
/>
<img width="659" height="447" alt="6"
src="https://github.com/user-attachments/assets/95ef405c-fffa-44af-bf6a-f974b780e3fc"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Developer Toolbar (local only): view client/server telemetry, inspect
events, and manage/override feature flags with persistent overrides,
filtering, and clear/reload.
* Client-side telemetry hooks: surface structured events to dev tooling
for realtime inspection.
* **Bug Fixes**
* Fixed end-of-file newline in shared code.
* **Chores**
* Added dev-tools package, integrated provider and trigger across
Studio, Docs, and marketing sites, and added CODEOWNERS entry.
* **Tests**
* Added comprehensive tests and test setup for the DevToolbar.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
Sorted all imports in all packages, `cms`, `design-system` and
`ui-library` apps by running `pnpm format` on them.
All changes in this PR are done by the script.
Fixes bug where App Router pages (docs, www/blog) only tracked the
initial page load but not subsequent navigations.
The issue was introduced in PR #35384 which inverted the logic for
App Router telemetry tracking. The condition used a boolean flag
that prevented tracking after the initial page view.
The root cause: useEffect with [appPathname] dependency fires both
on initial mount AND on pathname changes. The flag-based approach
couldn't differentiate between these two cases.
Solution: Track the previous pathname to detect actual changes.
- Initial mount: previousAppPathnameRef is null, skip (initial effect handles it)
- Navigation: previousAppPathnameRef !== appPathname, send telemetry
Before: Only first page view tracked
After: All page navigations tracked (like Pages Router)
Affects: docs app, www app (blog pages)
- Add reset() method to PostHogClient class to clear user identification
- Call posthogClient.reset() before clearLocalStorage() in signout flow
- Include proper error handling and memory leak prevention
- Clear all pending state (identification, groups, events)
Resolves GROWTH-535
Remove backend API calls for page view and page leave tracking,
keeping only client-side PostHog tracking. Generic events and
identify calls remain server-side for now.
- Remove /platform/telemetry/page API call from handlePageTelemetry
- Remove /platform/telemetry/page-leave API call from handlePageLeaveTelemetry
- Both functions now return Promise.resolve() for compatibility
- Client-side PostHog tracking remains fully functional
- Keep sendTelemetryEvent and sendTelemetryIdentify unchanged
* fix: resolve 50% session tracking discrepancy on root route
- Fixes race condition causing ~50% discrepancy in session tracking between client and server on root route
- Implements event queuing to capture telemetry events before PostHog initializes
- Adds session ID correlation to enable unified tracking analysis between client and server events
- Uses sendBeacon API for both pageview and pageleave events to ensure reliable capture even during navigation
- Adds production safeguards with try/catch blocks and memory caps to prevent API errors from breaking tracking
* refactor(posthog-client): reduce max pending events and improve event handling
- Decreased the maximum number of queued events from 200 to 20
- Added the use of the sendBeacon API for pending events to survive page unload
- Added comments to clarify the handling of pending properties and events during posthog initialization
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
* Add third-parties dependency for GTM. Reexport the GTM from the common package.
* Add the TelemetryTagManager to four of the production apps.
* Add the GOOGLE_TAG_MANAGER_ID env var as a turbo dependency to the 4 apps.
* Skip rendering the tag manager if the env var is not set or not running on the platform.
* Fix the prop type to be extracted from the component.
* Add default values for consent to GTM.
* Another try to mimic gtag function.
* Fix a link in www.
* Try another approach.
* try.
* Remove the data-redaction flag.
* Remove extra code.
* Send a sign-up event if GTM is enabled.
* Send only the email to GTM.
* Minor fixes.
* Remove third-parties from pnpm lockfile.
* Lets try to make studio work again.
* Add CSP rules for img loading for GTM.
* Add event for testing.
* Add www.googletagmanager.com to the CSP rules.
* Add Stape to CSP rules.
* Fix stape CSP.
* Clean up the code.
* Remove extra console.log.
* Fix the stape urls for CORS.
* Fix the wrong category for Stape URL.
* Add google ads urls.
* Bump the timeout.
* Add google.com to the img-src for google ads.
* update csp
* remove comment
* update to use google analytics without signals
* add stape to default-src in csp
* move csp to middleware
* add google ads support and fix middleware base path
* remove google tag manager / google ads references from csp. load via stape proxy instead
* add double click url to image src
* add Google Tag Manager URL to CSP configuration
* add ga4 urls to csp
* remove google urls from CSP
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
* 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>
There were two bugs when trying to run the integrations page locally
with NEXT_PUBLIC_IS_PLATFORM=false:
1. The IS_PLATFORM check imported from common was not evaluating
correctly to a boolean. This is because I slapped a 'use client' on the
entire common package last year -_-""" which caused all its imports to
be evaluated to functions when used in server components. I have now
moved the 'use client's down to the submodules that actually need it.
2. When the integrations submenu is empty, the navigation menu errors
out because it expects all navigation items to either have children or
have links. Have updated this to gracefully hide empty headers.
