Add PostHog to a Next.js app with client and server event capture, user identification, feature flags, session replay privacy controls, reverse-proxy planning, and production analytics validation.
Open the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
86
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (5/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
5/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
7 prerequisites to line up before setup. Have accounts and credentials ready first. Includes a review or approval gate.
Safety & privacy surface
8 safety and 7 privacy notes across 7 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
| Platform | Support | Install path |
|---|---|---|
| claude-code | Native | .claude/skills/<skill-name>/SKILL.md |
| codex | Native | .agents/skills/<skill-name>/SKILL.md |
| windsurf | Native | .windsurf/skills/<skill-name>/SKILL.md |
| gemini | Native | .gemini/skills/<skill-name>/SKILL.md or .agents/skills/<skill-name>/SKILL.md |
| cursor | Adapter | .cursor/rules/<skill-name>.mdc |
| cli | Manual | AGENTS.md or tool-specific context file |
# Trigger
"Apply the PostHog Next.js product analytics skill to this app."
# Required output
1) Current analytics, routing, auth, consent, and data-classification inventory
2) PostHog client, server, feature flag, replay, proxy, and environment plan
3) Event taxonomy, identify/group, privacy masking, and validation checklist
4) Safety, privacy, retention, access-control, and rollback notesThis skill is based on PostHog's official Next.js guide, JavaScript SDK docs,
session replay docs, session replay privacy controls, feature flag docs,
feature flag bootstrapping guide, and PostHog/posthog-js repository reviewed
on 2026-06-04. The current Next.js guide covers posthog-js,
posthog-node, client initialization through instrumentation-client.js or
instrumentation-client.ts, NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN,
NEXT_PUBLIC_POSTHOG_HOST, user identification, server-side analytics,
feature flag access, and reverse-proxy options.
Prefer the live PostHog docs and official repository over model memory for package names, initialization files, SDK options, feature-flag APIs, replay masking behavior, reverse-proxy guidance, and privacy-control defaults.
Use this skill for PostHog-backed product analytics in a Next.js application. It is not a generic analytics comparison, not a legal compliance checklist, and not permission to record real user sessions without consent, retention, access, and masking review.
/src layout, server/client component boundaries,
middleware, rewrites, analytics code, auth provider, and deployment platform.posthog-js for browser capture and posthog-node for server-side
capture only where both are needed. Add @posthog/react only when React
feature flag hooks are part of the implementation.NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN and
NEXT_PUBLIC_POSTHOG_HOST environment-specific.identify, how to handle
anonymous users, how to reset on logout, how to represent organizations or
workspaces, and how backend events use the same stable IDs.ph-no-capture, sensitive third-party widgets, and recording controls
before enabling production recordings.instrumentation-client.SKILL.md-style instructions when editing
Next.js projects that add PostHog SDKs, feature flags, replay, or analytics
validation.Issue: Events appear locally but not in the intended PostHog project
Fix: Check NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN, NEXT_PUBLIC_POSTHOG_HOST,
environment-specific build variables, ad blockers, reverse-proxy rewrites, and
whether preview deployments are intentionally disabled.
Issue: Feature flags flicker between server and client
Fix: Review server-side evaluation, bootstrapping, distinct ID consistency, client hydration order, cache settings, and fallback behavior. Avoid rendering user-visible decisions before the intended flag value is available.
Issue: Recordings show sensitive text, URLs, or account details
Fix: Disable recording for the affected route until masking is fixed. Add
input masking, text masking, URL redaction, ph-no-capture, and explicit
recording controls, then validate with synthetic data.
Issue: Server-side events are missing from route handlers or server actions
Fix: Confirm the server client is initialized with server-only values, the runtime can reach the PostHog host, event capture is awaited where needed, and short-lived contexts flush or shut down the client before returning.
Issue: Logout or account switching links events to the wrong user
Fix: Review identify, anonymous ID handling, reset behavior, cookies,
local storage, organization IDs, and backend distinct IDs. Test switching
between two synthetic accounts in the same browser.
Current HeyClaude content has incidental PostHog mentions in Mintlify
documentation automation and telemetry notes, plus generic product-management
analytics content. There is no dedicated PostHog, posthog-js, posthog-node,
PostHog Next.js, session replay privacy, or PostHog feature flag skill entry.
This entry is specifically scoped to official PostHog integration work for
Next.js apps and is source-backed by PostHog docs and the PostHog/posthog-js
repository.
This is a source-backed community content entry submitted by oktofeesh1.
There is no paid placement, affiliate link, sponsorship, or maintainer-verified
package artifact attached to this listing.
Show that PostHog Next.js Product Analytics Skill is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/skills/posthog-nextjs-product-analytics)PostHog Next.js Product Analytics Skill side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Add PostHog to a Next.js app with client and server event capture, user identification, feature flags, session replay privacy controls, reverse-proxy planning, and production analytics validation. Open dossier | Add or maintain Auth.js authentication in a Next.js app with next-auth, auth.ts, route handlers, providers, sessions, adapters, protected resources, proxy or middleware behavior, deployment configuration, and migration review. Open dossier | Add Better Auth to a Next.js App Router project with API route handlers, database-backed sessions, client helpers, protected route checks, and production auth safety review. Open dossier | Add Clerk authentication to a Next.js App Router project with middleware, route protection, session-aware UI, environment hygiene, and production auth safety checks. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | — | — | — | |
| Category | skills | skills | skills | skills |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Added | 2026-06-04 | 2026-06-04 | 2026-06-04 | 2026-06-04 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓The download URL is PostHog's external source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. Do not commit PostHog personal API keys, project API keys, write keys for other services, session cookies, OAuth credentials, data warehouse credentials, or copied dashboard values. A PostHog project token is normally exposed to client-side code, but it still must be scoped to the intended project and environment; do not confuse it with private API credentials. Analytics code can change route behavior, client bundle size, network requests, cookies, local storage, feature-flag rollout behavior, and server-side request timing. Feature flags and experiments can alter production behavior for real users. Add owner, rollout, fallback, kill-switch, and cache/bootstrapping review before shipping. Session replay, autocapture, heatmaps, and network capture can record sensitive product screens if masking and exclusion rules are incomplete. Do not enable replay or autocapture on auth, payment, healthcare, education, finance, admin, internal tooling, or support-data screens without explicit privacy review. If using a reverse proxy to improve event delivery, review CDN, middleware, rewrite, cache, rate-limit, WAF, and data-routing implications before deploying. | ✓The download URL is the external `nextauthjs/next-auth` source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. Auth.js is now part of Better Auth, and the official README recommends Better Auth for many new projects. Confirm why Auth.js remains the intended choice before adding it to a greenfield app. Do not commit `AUTH_SECRET`, OAuth client secrets, adapter connection strings, email SMTP credentials, WebAuthn secrets, session tokens, cookies, or copied dashboard values. Authentication changes can alter sign-in, sign-out, callback URLs, cookie names, session lifetime, authorization behavior, provider access, and account-linking semantics. Proxy or middleware protection is not a substitute for checking authorization close to data access. Server actions, route handlers, loaders, and database queries still need session and permission checks. Provider callbacks, JWT/session callbacks, adapter customizations, and account-linking rules can create authorization bypasses or identity confusion if reviewed only through the UI happy path. Edge runtime, proxy, middleware, database adapters, and provider SDKs have compatibility constraints. Verify runtime support before moving auth code into edge-executed paths. Test OAuth in non-production first. Callback URL mismatches, domain changes, preview deployments, and secret rotation can lock users out or route tokens to the wrong environment. | ✓The download URL is Better Auth's external source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. Do not commit Better Auth secrets, OAuth provider secrets, database URLs, email-provider credentials, API-key plugin secrets, or copied dashboard values. Run schema generation or migrations only against the intended database environment; auth tables, sessions, accounts, and verification records are production-critical. Treat route protection as server-side authorization work. UI hiding, optimistic middleware redirects, or cookie existence checks are not full access control. Review `proxy.ts` or `middleware.ts` behavior by Next.js version before relying on database-backed session checks inside request middleware. Keep OAuth callback URLs, base URLs, trusted origins, and cookie settings environment-specific to avoid broken login loops or cross-environment session confusion. Track Better Auth release notes and security advisories before introducing auth flows or enabling advanced plugins in production. Add rollback steps before replacing an existing auth provider because user, account, session, and verification tables can affect active logins. | ✓The download URL is Clerk's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows. Clerk middleware does not protect routes by default; require an explicit protected-route matcher before assuming a page, API route, or tRPC endpoint is private. Do not commit `CLERK_SECRET_KEY`, webhook signing secrets, OAuth provider secrets, or copied dashboard values to source control, issue comments, screenshots, or chat transcripts. Review middleware matchers carefully. A broad matcher can affect static assets and public routes, while a narrow matcher can leave sensitive routes unauthenticated. Treat organization roles, custom permissions, and metadata checks as authorization logic that needs tests, not just UI hiding. Webhook handlers can mutate user, membership, subscription, and organization state. Make handlers idempotent and verify signatures before processing events. Confirm production domains and redirect URLs before deploy; wrong origins can break sign-in, leak users into the wrong environment, or create confusing callback loops. |
| Privacy notes | ✓PostHog can process user identifiers, account or organization IDs, event names, event properties, page URLs, referrers, device data, IP-derived context, cookies, local storage values, feature-flag evaluations, experiment assignments, and session recordings. Session replay can capture rendered text, URLs, form states, clicks, scrolls, console context, and optional network metadata depending on configuration. Mask inputs, sensitive text, query strings, authentication tokens, email addresses, IDs, payment fields, admin data, and support/customer content before enabling replay in production. Use `ph-no-capture`, `maskTextSelector`, input masking, URL redaction, and recording start/stop controls for sensitive views instead of assuming defaults cover every custom component. Use synthetic users and non-production PostHog projects for examples, screenshots, demos, issue reports, and AI-assisted debugging. Avoid pasting raw recordings, person profiles, event exports, feature-flag targeting lists, customer identifiers, or dashboard screenshots into prompts or public issues. Review PostHog Cloud/self-hosted retention, regional hosting, data-processing, team access, export, and deletion behavior before sending real customer data. | ✓Auth.js can process user profile data, email addresses, OAuth account IDs, provider tokens, refresh tokens, session tokens, cookies, adapter records, verification tokens, WebAuthn data, and callback payloads. Auth callbacks, debug logs, server logs, failed sign-in logs, screenshots, issue reports, and AI prompts can expose provider IDs, token claims, user metadata, cookies, callback URLs, or database identifiers. Use synthetic accounts and non-production providers for demos, public examples, screenshots, and AI-assisted troubleshooting. Avoid pasting raw OAuth payloads, cookies, JWTs, session objects, adapter rows, production user records, or provider dashboard screenshots into prompts or public issues. Review Auth.js, provider, database, deployment-platform, email-provider, analytics, and AI-assistant retention behavior before using real customer identity data in troubleshooting. | ✓Better Auth handles user identity, email addresses, password-auth state, OAuth profile data, sessions, cookies, accounts, verification tokens, and plugin-specific user data. Application logs, error trackers, request traces, AI prompts, and screenshots can retain user IDs, emails, callback URLs, cookies, session state, or OAuth provider details. Use synthetic users and test OAuth applications for examples, demos, issue reports, screenshots, and AI-assisted troubleshooting. If organization, API key, two-factor, passkey, or SSO plugins are enabled, treat membership, roles, credentials, and device metadata as sensitive authorization data. Review Better Auth, database, deployment-provider, analytics, email-provider, and AI-assistant retention policies before using real customer identity data. | ✓Clerk processes user identity, email addresses, sessions, cookies, authentication factors, OAuth profile data, organization membership, and optional user metadata. Application logs, error reports, webhook payloads, request traces, and AI chat transcripts can retain user IDs, email addresses, session state, redirect URLs, or organization names. Keep public examples synthetic. Do not paste real Clerk keys, dashboard screenshots, webhook payloads, user records, or organization metadata into prompts or PRs. Review Clerk, deployment-provider, analytics, and AI-assistant retention policies before using real customer identity data in troubleshooting sessions. If custom metadata stores roles, billing flags, internal account IDs, or entitlement data, treat it as sensitive authorization data and avoid exposing it client-side unless intended. |
| Prerequisites |
|
|
|
|
| Install | | | | |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Add or maintain Auth.js in Next.js with providers, sessions, adapters, protected routes, deployment settings, and migration checks.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.