home / skills / agents-inc / skills / api-analytics-setup-posthog

api-analytics-setup-posthog skill

/src/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-posthog

Review the files below or copy the command above to add this skill to your agents.

Files (6)
SKILL.md
7.8 KB
---
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)

Overview

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.

How this skill works

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.

When to use it

  • Initial analytics and feature-flag setup for a Next.js App Router monorepo
  • Adding client-side instrumentation with posthog-js and a PostHogProvider
  • Capturing server-side events in API routes, server components, or middleware with posthog-node
  • Preparing a Next.js app for Vercel deployment with PostHog env vars
  • Consolidating analytics and flags into a single PostHog organization for cost control

Best practices

  • Always prefix client keys with NEXT_PUBLIC_ and keep server keys private
  • Implement PostHogProvider as a 'use client' React component (posthog-js requires browser APIs)
  • Use defaults: '2025-11-30' or capture_pageview: 'history_change' for SPA page tracking
  • Create a server singleton for posthog-node to avoid multiple client instances and configure batching/flush behavior
  • Call posthog.flush() or posthog.shutdown() after server captures to prevent lost events
  • Use a single PostHog organization for all monorepo projects to pool billing and simplify usage limits

Example use cases

  • Bootstrap analytics for a new Next.js app in a monorepo using the provided provider and env var examples
  • Track sign-up and purchase events from both client and server code paths with consistent event names
  • Use feature flags to gate new UI components across multiple apps from one PostHog project
  • Deploy on Vercel with NEXT_PUBLIC_POSTHOG_KEY and POSTHOG_API_KEY configured in project settings
  • Add Hono or custom server middleware that captures requests and flushes before response

FAQ

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.