home / skills / agents-inc / skills / api-analytics-setup-posthog
This skill helps you configure PostHog analytics and feature flags in a Next.js App Router monorepo with client and server setup.
npx playbooks add skill agents-inc/skills --skill api-analytics-setup-posthogReview the files below or copy the command above to add this skill to your agents.
---
name: api-analytics-setup-posthog
description: PostHog analytics and feature flags setup
---
# PostHog Analytics & Feature Flags Setup
> **Quick Guide:** One-time setup for PostHog in Next.js App Router monorepo. Covers `posthog-js` client provider, `posthog-node` server client, environment variables, and Vercel deployment. PostHog handles both analytics AND feature flags with a generous free tier (1M events + 1M flag requests/month).
---
<critical_requirements>
## CRITICAL: Before Using This Skill
> **All code must follow project conventions in CLAUDE.md** (kebab-case, named exports, import ordering, `import type`, named constants)
**(You MUST use `NEXT_PUBLIC_` prefix for client-side PostHog environment variables)**
**(You MUST create PostHogProvider as a 'use client' component - posthog-js requires browser APIs)**
**(You MUST call `posthog.shutdown()` or `posthog.flush()` after server-side event capture to prevent lost events)**
**(You MUST use `defaults: '2025-11-30'` or `capture_pageview: 'history_change'` for automatic SPA page tracking)**
**(You MUST use a single PostHog organization for all monorepo apps - projects are usage-based, not per-project pricing)**
</critical_requirements>
---
**Auto-detection:** PostHog setup, posthog-js, posthog-node, PostHogProvider, analytics setup, feature flags setup, event tracking setup, NEXT_PUBLIC_POSTHOG_KEY
**When to use:**
- Initial PostHog setup in a Next.js App Router project
- Configuring PostHogProvider for client-side analytics
- Setting up posthog-node for server-side/API route event capture
- Deploying to Vercel with PostHog environment variables
**When NOT to use:**
- Event tracking patterns (use `backend/analytics.md` for that)
- Feature flag usage patterns (use `backend/feature-flags.md` for that)
- Complex multi-environment setups with separate staging/production projects
**Key patterns covered:**
- PostHog project creation (single org for monorepo)
- Client-side setup with PostHogProvider
- Server-side setup with posthog-node
- Environment variables configuration
- Vercel deployment integration
- Initial dashboard recommendations
**Detailed Resources:**
- For code examples, see [examples/](examples/):
- [core.md](examples/core.md) - Provider setup, layout integration, user identification
- [server.md](examples/server.md) - Server client singleton, API routes, Hono middleware
- [deployment.md](examples/deployment.md) - Environment variables, Vercel deployment
- For decision frameworks and anti-patterns, see [reference.md](reference.md)
---
<philosophy>
## Philosophy
PostHog is a **product analytics + feature flags platform** that consolidates multiple tools into one. It's open-source, can be self-hosted, and has a generous free tier. For solo developers and small teams, PostHog eliminates the need for separate analytics (Mixpanel/Amplitude) and feature flag (LaunchDarkly) services.
**Core principles:**
1. **One platform for analytics + feature flags** - Reduces tool sprawl and cost
2. **Usage-based pricing** - Pay for what you use, not per-project
3. **Autocapture by default** - Automatic event tracking reduces manual instrumentation
4. **Server and client SDKs** - Full coverage for SSR and client-side apps
**When to use PostHog:**
- Need both analytics and feature flags in one platform
- Want generous free tier (1M events + 1M flag requests/month)
- Prefer open-source with self-host option
- Building product analytics (funnels, retention, sessions)
**When NOT to use PostHog:**
- Need advanced A/B testing with statistical rigor (use Statsig)
- Require real-time event streaming (use Segment)
- Need complex user journey mapping (use Amplitude)
- Already have established analytics + flag tools
</philosophy>
---
<patterns>
## Core Patterns
### Pattern 1: PostHog Project Setup
Create a single PostHog organization for your monorepo. You can either use one project for all apps or create separate projects per app.
#### Organization Structure
```
PostHog Organization: "Your Company"
├── Project: "Main App" (or separate per app)
│ ├── API Key: phc_xxx
│ └── Host: https://us.i.posthog.com (or eu.i.posthog.com)
```
#### Getting API Keys
1. Sign up at [posthog.com](https://posthog.com)
2. Create a new organization (or use existing)
3. Create a project for your app(s)
4. Copy the Project API Key from Settings > Project > API Keys
```bash
# Example API key format
phc_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```
**Why good:** Single organization pools billing across all projects, 6 projects included on paid tier, usage-based pricing means you're not penalized for multiple apps
---
### Pattern 2: Client-Side Setup
Install dependencies and configure for Next.js App Router.
#### Installation
```bash
# Install client-side SDK
bun add posthog-js
```
#### Environment Variables
```bash
# apps/client-next/.env.local
# PostHog Configuration
NEXT_PUBLIC_POSTHOG_KEY=phc_your_project_api_key_here
NEXT_PUBLIC_POSTHOG_HOST=https://us.i.posthog.com
```
#### Setup Options
**Next.js 15.3+:** Use `instrumentation-client.js` (simpler, recommended)
**Next.js < 15.3:** Use PostHogProvider component (traditional approach)
See [examples/core.md](examples/core.md) for both approaches with full implementation examples.
**Why good:** `defaults: "2025-11-30"` enables automatic SPA page/leave tracking, `person_profiles: "identified_only"` reduces event costs, debug mode in development aids troubleshooting
---
### Pattern 3: Server-Side Setup with posthog-node
Install and configure the Node.js SDK for server-side event capture in API routes and Hono middleware.
#### Installation
```bash
# Install server-side SDK
bun add posthog-node
```
#### Environment Variables
```bash
# apps/client-next/.env.local (or apps/server/.env.local)
# Server-side PostHog (no NEXT_PUBLIC_ prefix needed)
POSTHOG_API_KEY=phc_your_project_api_key_here
POSTHOG_HOST=https://us.i.posthog.com
```
Create a server client singleton for reuse across API routes. See [examples/server.md](examples/server.md) for the full implementation including API route and Hono middleware examples.
#### Serverless Options
**Option 1:** Use `captureImmediate()` - simplest, awaits HTTP request directly
**Option 2:** Use `capture()` + `await flush()` - batched, requires explicit flush
**Why good:** Singleton prevents multiple client instances, flushInterval/flushAt configure batching, shutdown function for graceful cleanup, captureImmediate for simple serverless usage
</patterns>
---
<critical_reminders>
## CRITICAL REMINDERS
> **All code must follow project conventions in CLAUDE.md** (kebab-case, named exports, import ordering, `import type`, named constants)
**(You MUST use `NEXT_PUBLIC_` prefix for client-side PostHog environment variables)**
**(You MUST create PostHogProvider as a 'use client' component - posthog-js requires browser APIs)**
**(You MUST call `posthog.shutdown()` or `posthog.flush()` after server-side event capture to prevent lost events)**
**(You MUST use `defaults: '2025-11-30'` or `capture_pageview: 'history_change'` for automatic SPA page tracking)**
**(You MUST use a single PostHog organization for all monorepo apps - projects are usage-based, not per-project pricing)**
**Failure to follow these rules will cause lost analytics events, broken tracking, or security vulnerabilities.**
</critical_reminders>
---
## Sources
- [PostHog Next.js Documentation](https://posthog.com/docs/libraries/next-js)
- [PostHog Node.js Documentation](https://posthog.com/docs/libraries/node)
- [PostHog Hono Integration](https://posthog.com/docs/libraries/hono)
- [Vercel + PostHog Guide](https://vercel.com/kb/guide/posthog-nextjs-vercel-feature-flags-analytics)
- [PostHog JavaScript Configuration](https://posthog.com/docs/libraries/js/config)
- [PostHog SPA Pageview Tracking](https://posthog.com/tutorials/single-page-app-pageviews)
This skill sets up PostHog analytics and feature flags for a Next.js App Router monorepo. It provides client-side PostHogProvider wiring, a server-side posthog-node singleton, environment variable conventions, and Vercel deployment guidance. The goal is reliable event capture and unified feature flagging across monorepo apps.
The skill inspects your Next.js app for missing PostHog client or server SDK setup and generates the PostHogProvider (a 'use client' component) plus a server singleton using posthog-node. It enforces environment variable naming (NEXT_PUBLIC_ for browser keys), recommends SPA page-tracking defaults, and adds graceful shutdown/flush calls to avoid lost events. It also documents a single-organization strategy so projects share billing and quota appropriately.
Do client and server keys use the same environment variable names?
No. Client keys must be exposed as NEXT_PUBLIC_POSTHOG_KEY and NEXT_PUBLIC_POSTHOG_HOST. Server keys should use POSTHOG_API_KEY and POSTHOG_HOST and must not be public.
What prevents lost events on serverless platforms?
Use captureImmediate() or call capture() followed by await posthog.flush() or posthog.shutdown() before the function exits to ensure events are sent.