Session Replay

Scope

The PostHog browser SDK is used only for identity and Session Replay. Product events go through Zooly's first-party journey endpoint so they can be persisted, sanitized, attributed, and retried centrally.

The client disables:

• autocapture
• automatic page views and page leaves
• console-log recording
• network-body capture

After initialization, Zooly explicitly starts recording and sends one sanitized $pageview anchor. This anchor gives PostHog an event with the current $session_id, allowing a new recording to be indexed and listed in Replay while normal product events remain server-side.

Public site

A visit to zooly.ai is recorded too: the home page, the conference page, PhotoBomb, Personalized Merch, and the other public pages. The visitor does not see a consent banner. The recording uses the same project as the app, shows the page as they saw it, and drops sensitive values from the address bar before they are stored. In Replay, filter these visits with environment = production.

That visit also shows up in Sessions with the replay button an app session has, because the site's journey events carry the visit's recording id.

Recording lifecycle

1. App or Auth loads the recorder with project key, host, and environment. The public site does the same when its page opens.
2. PostHog creates or reuses cross-subdomain identity and session cookies.
3. Zooly registers the normalized environment property.
4. Recording is started explicitly.
5. A sanitized $pageview replay anchor is captured.
6. /api/me resolves the stable internal identity and calls identify.
7. Product events reference the same PostHog distinct ID and session ID.

posthog.reset() runs when the app resets analytics identity, preventing the next user on a shared browser from inheriting the previous identity.

Cross-origin Auth modal

The onboarding login/signup modal renders zooly-auth inside a cross-origin iframe. To make it visible in the parent recording:

• recordCrossOriginIframes: true must be active in the shared replay options.
• The PostHog SDK must initialize inside both the App document and the Auth iframe.
• Both documents must use the same PostHog project token and host.
• Both deployments must use compatible session/identity settings.
• Testing must start with a new recording after both deployments are live.

If the replay shows a dark overlay but no modal content, use the cross-origin checklist.

PostHog project settings

In PostHog:

1. Enable Session replay → Record user sessions.
2. Keep recording conditions open to the required traffic. With no trigger groups, the current legacy fallback records all eligible sessions.
3. Use 100% sampling during controlled validation.
4. Confirm there is no unexpected URL blocklist or minimum duration.
5. Restrict access to internal administrators.
6. Set the required retention period.

Project-side settings cannot repair a missing or wrong client token. Verify Vercel configuration and deploy first.

Existing recordings do not change

Masking, iframe, and SDK changes affect only data captured after the new deployment. Always open a fresh incognito window and create a new session when validating a recorder change.

Direct links

Stats uses the recording ID stored with the first-party journey and links directly to:

https://us.posthog.com/project/<project-id>/replay/<sessionRecordingId>

This is more reliable than opening Replay search with a query string.

See the PostHog Session Replay privacy controls for the provider's current SDK privacy model.