Generated banner for Integration Nextjs Pages Router
Generated logo for Integration Nextjs Pages Router

Integration Nextjs Pages Router

PostHogOfficialCreated by PostHog

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found

From the author

PostHog integration for Next.js Pages Router applications
— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a systematic approach to integrating PostHog into Next.js projects that utilize the Pages Router architecture. It covers client-side initialization, server-side tracking, user identification, and error tracking. The guide emphasizes best practices such as using environment variables, avoiding hardcoded keys, and maintaining clean event-handling logic by avoiding unnecessary useEffect hooks.

What it does

  • Provides a step-by-step workflow for PostHog setup
  • Demonstrates client-side initialization via instrumentation-client.ts
  • Shows how to implement server-side tracking for API routes
  • Guides user identification during authentication flows
  • Includes patterns for error tracking and feature flag usage
  • Offers a reference project structure for Pages Router applications

When to use it

  • When adding product analytics to a new or existing Next.js Pages Router application
  • When needing to track user behavior across both client and server boundaries
  • When implementing feature flags or session replay in a Next.js environment
  • When you need to ensure consistent event tracking patterns across your codebase

Advantages

  • Follows established patterns for Next.js Pages Router
  • Ensures secure handling of project tokens via environment variables
  • Promotes clean React code by discouraging misuse of useEffect
  • Supports both client-side and server-side event correlation

Usage examples

“How do I initialize PostHog in my Next.js Pages Router app?”
The skill directs you to create an instrumentation-client.ts file and configure it using your project token from environment variables.
“Where should I place event tracking code for user actions?”
The skill advises placing capture calls directly within event handlers rather than inside useEffect hooks.
“How do I track events on the server side in my API routes?”
The skill provides a pattern for using a server-side PostHog client to capture events in files located within the pages/api/ directory.
“How do I identify users after they log in?”
The skill shows how to use the posthog.identify() method within your authentication context or login logic.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/posthog/integration-nextjs-pages-router/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip integration-nextjs-pages-router.zip -d .agents/skills

Documentation by PostHog

PostHog integration for Next.js Pages Router

This skill helps you add PostHog analytics to Next.js Pages Router applications.

Workflow

Follow these steps in order to complete the integration:

  1. basic-integration-1.0-begin.md - PostHog Setup - Begin ← Start here

  2. basic-integration-1.1-edit.md - PostHog Setup - Edit

  3. basic-integration-1.2-revise.md - PostHog Setup - Revise

  4. basic-integration-1.3-conclude.md - PostHog Setup - Conclusion

Reference files

  • references/EXAMPLE.md - Next.js Pages Router example project code

  • references/next-js.md - Next.js - docs

  • references/identify-users.md - Identify users - docs

  • references/basic-integration-1.0-begin.md - PostHog setup - begin

  • references/basic-integration-1.1-edit.md - PostHog setup - edit

  • references/basic-integration-1.2-revise.md - PostHog setup - revise

  • references/basic-integration-1.3-conclude.md - PostHog setup - conclusion

The example project shows the target implementation pattern. Consult the documentation for API details.

Key principles

  • Environment variables: Always use environment variables for PostHog keys. Never hardcode them.

  • Minimal changes: Add PostHog code alongside existing integrations. Don't replace or restructure existing code.

  • Match the example: Your implementation should follow the example project's patterns as closely as possible.

Framework guidelines

  • For Next.js 15.3+, initialize PostHog in instrumentation-client.ts for the simplest setup

  • For feature flags, use useFeatureFlagEnabled() or useFeatureFlagPayload() hooks - they handle loading states and external sync automatically

  • Add analytics capture in event handlers where user actions occur, NOT in useEffect reacting to state changes

  • Do NOT use useEffect for data transformation - calculate derived values during render instead

  • Do NOT use useEffect to respond to user events - put that logic in the event handler itself

  • Do NOT use useEffect to chain state updates - calculate all related updates together in the event handler

  • Do NOT use useEffect to notify parent components - call the parent callback alongside setState in the event handler

  • To reset component state when a prop changes, pass the prop as the component's key instead of using useEffect

  • useEffect is ONLY for synchronizing with external systems (non-React widgets, browser APIs, network subscriptions)

Identifying users

Identify users during login and signup events. Refer to the example code and documentation for the correct identify pattern for this framework. If both frontend and backend code exist, pass the client-side session and distinct ID using X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID headers to maintain correlation.

Error tracking

Add PostHog error tracking to relevant files, particularly around critical user flows and API boundaries.

Files

references/identify-users.md

Identify users - Docs

Linking events to specific users enables you to build a full picture of how they're using your product across different sessions, devices, and platforms.

This is straightforward to do when capturing backend events, as you associate events to a specific user using a distinct_id, which is a required argument.

However, in the frontend of a web or mobile app, a distinct_id is not a required argument — PostHog's SDKs will generate an anonymous distinct_id for you automatically and you can capture events anonymously, provided you use the appropriate configuration.

To link events to specific users, call identify:

PostHog AI

Web
posthog.identify(
  'distinct_id',  // Replace 'distinct_id' with your user's unique identifier
  { email: '[email protected]', name: 'Max Hedgehog' } // optional: set additional person properties
);
Android
PostHog.identify(
    distinctId = distinctID, // Replace 'distinctID' with your user's unique identifier
    // optional: set additional person properties
    userProperties = mapOf(
        "name" to "Max Hedgehog",
        "email" to "[email protected]"
    )
)
iOS
PostHogSDK.shared.identify("distinct_id", // Replace "distinct_id" with your user's unique identifier
                           userProperties: ["name": "Max Hedgehog", "email": "[email protected]"]) // optional: set additional person properties
React Native
posthog.identify('distinct_id', { // Replace "distinct_id" with your user's unique identifier
    email: '[email protected]', // optional: set additional person properties
    name: 'Max Hedgehog'
})
Dart
await Posthog().identify(
  userId: 'distinct_id', // Replace "distinct_id" with your user's unique identifier
  userProperties: {
    email: "[email protected]", // optional: set additional person properties
    name: "Max Hedgehog"
});

Events captured after calling identify are identified events and this creates a person profile if one doesn't exist already.

Due to the cost of processing them, anonymous events can be up to 4x cheaper than identified events, so it's recommended you only capture identified events when needed.

How identify works

When a user starts browsing your website or app, PostHog automatically assigns them an anonymous ID, which is stored locally.

Provided you've configured persistence to use cookies or localStorage, this enables us to track anonymous users – even across different sessions.

By calling identify with a distinct_id of your choice (usually the user's ID in your database, or their email), you link the anonymous ID and distinct ID together.

Thus, all past and future events made with that anonymous ID are now associated with the distinct ID.

This enables you to do things like associate events with a user from before they log in for the first time, or associate their events across different devices or platforms.

Using identify in the backend

Although you can call identify using our backend SDKs, it is used most in frontends. This is because there is no concept of anonymous sessions in the backend SDKs, so calling identify only updates person profiles.

Best practices when using identify

1. Call identify as soon as you're able to

In your frontend, you should call identify as soon as you're able to.

Typically, this is every time your app loads for the first time, and directly after your users log in.

This ensures that events sent during your users' sessions are correctly associated with them.

You only need to call identify once per session, and you should avoid calling it multiple times unnecessarily.

If you call identify multiple times with the same data without reloading the page in between, PostHog will ignore the subsequent calls.

2. Use unique strings for distinct IDs

If two users have the same distinct ID, their data is merged and they are considered one user in PostHog. Two common ways this can happen are:

  • Your logic for generating IDs does not generate sufficiently strong IDs and you can end up with a clash where 2 users have the same ID.

  • There's a bug, typo, or mistake in your code leading to most or all users being identified with generic IDs like null, true, or distinctId.

PostHog also has built-in protections to stop the most common distinct ID mistakes.

3. Reset after logout

If a user logs out on your frontend, you should call reset() to unlink any future events made on that device with that user.

This is important if your users are sharing a computer, as otherwise all of those users are grouped together into a single user due to shared cookies between sessions.

We strongly recommend you call reset on logout even if you don't expect users to share a computer.

You can do that like so:

PostHog AI

Web
posthog.reset()
iOS
PostHogSDK.shared.reset()
Android
PostHog.reset()
React Native
posthog.reset()
Dart
Posthog().reset()

If you also want to reset the device_id so that the device will be considered a new device in future events, you can pass true as an argument:

Web

PostHog AI

posthog.reset(true)
4. Person profiles and properties

You'll notice that one of the parameters in the identify method is a properties object.

This enables you to set person properties.

Whenever possible, we recommend passing in all person properties you have available each time you call identify, as this ensures their person profile on PostHog is up to date.

Person properties can also be set being adding a $set property to a event capture call.

See our person properties docs for more details on how to work with them and best practices.

We recommend you call identify as soon as you're able, typically when a user signs up or logs in.

This doesn't work if one or both platforms are unauthenticated. Some examples of such cases are:

  • Onboarding and signup flows before authentication.

  • Unauthenticated web pages redirecting to authenticated mobile apps.

  • Authenticated web apps prompting an app download.

In these cases, you can use a deep link on Android and universal links on iOS to identify users.

  1. Use posthog.get_distinct_id() to get the current distinct ID. Even if you cannot call identify because the user is unauthenticated, this will return an anonymous distinct ID generated by PostHog.

  2. Add the distinct ID to the deep link as query parameters, along with other properties like UTM parameters.

  3. When the user is redirected to the app, parse the deep link and handle the following cases:

  • The user is already authenticated on the mobile app. In this case, call posthog.alias() with the distinct ID from the web. This associates the two distinct IDs as a single person.

  • The user is unauthenticated. In this case, call posthog.identify() with the distinct ID from the web. Events will be associated with this distinct ID.

As long as you associate the distinct IDs with posthog.identify() or posthog.alias(), you can track events generated across platforms.

Further reading

Community questions

Ask a question

Was this page useful?

HelpfulCould be better

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
PostHog
Publisher
PostHog (Official)
Source
PostHog/skills · skills/posthog/integration/skills/nextjs-pages-router · commit a5d30e7
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Also distributed in
PostHog/skills

AutoGineer is not affiliated with or endorsed by PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download integration-nextjs-pages-router.zip