Instrument Product Analytics

PostHogOfficialCreated by PostHog

Skill
Tool integration
Data and AI
MIT
Low risk

From the author

Add PostHog product analytics events to track user behavior. Use after implementing new features or reviewing PRs to ensure meaningful user actions are captured. Also handles initial PostHog SDK setup if not yet installed.

— the description by PostHog

AutoGineer summary

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

This skill provides a structured, multi-step workflow to integrate PostHog product analytics into a wide variety of software projects. It guides the user through detecting the project's framework, installing the appropriate SDK, initializing the service, and strategically placing event capture calls. The skill emphasizes non-intrusive implementation, requiring that new analytics code be added alongside existing logic without altering the project's fundamental architecture. It also covers user identification, error tracking, and secure environment variable management.

What it does

Detects the project's framework and language to determine the correct PostHog SDK.
Handles initial SDK installation and initialization based on framework-specific patterns.
Identifies key user actions and business-critical events for tracking.
Implements event capture calls and user identification logic.
Configures environment variables securely for API tokens and host URLs.
Verifies the integration and performs targeted linting on modified files.

When to use it

After implementing new features that require tracking for product analytics.
When reviewing pull requests to ensure meaningful user behaviors are captured.
During the initial setup of a new project that needs product analytics.
When migrating or adding analytics to an existing application.

Advantages

Supports a broad range of frontend, backend, and mobile frameworks.
Ensures consistent event naming and property usage across the codebase.
Prioritizes non-breaking changes and minimal impact on existing code structure.
Automates the complex setup of environment variables and SDK initialization.

Usage examples

“Add PostHog analytics to my Next.js project.”: The agent will analyze the project structure, install the PostHog SDK, initialize it in the appropriate client/server files, and prompt you to identify key events to track.
“I need to track user signups and errors in my Django backend.”: The agent will locate your authentication logic, add identify calls, implement exception capture, and ensure the PostHog project tokens are managed via environment variables.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/posthog/instrument-product-analytics/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip instrument-product-analytics.zip -d .agents/skills

Documentation by PostHog

Add PostHog product analytics events

Use this skill to add product analytics events (capture calls) that track meaningful user actions in new or changed code. Use it after implementing features or reviewing PRs to ensure key user behaviors are captured. If PostHog is not yet installed, this skill also covers initial SDK setup. Supports any framework or language.

Supported frameworks and languages: Next.js, React Router, Nuxt, Vue, TanStack Start, SvelteKit, Astro, Angular, Django, Flask, FastAPI, Laravel, PHP, Ruby on Rails, Go, Elixir, Android, iOS, Flutter, React Native, Expo, and more.

Instructions

Follow these steps IN ORDER:

STEP 1: Analyze the codebase and detect the platform.

Look for dependency files (package.json, pubspec.yaml, Podfile, Package.swift, requirements.txt, Gemfile, composer.json, go.mod, mix.exs, etc.) to determine the framework and language.

Look for lockfiles (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb, go.sum, pubspec.lock, Podfile.lock, Package.resolved, mix.lock) to determine the package manager.

Check for existing PostHog setup. If PostHog is already installed and initialized, skip to STEP 5.

STEP 2: Research integration. (Skip if PostHog is already set up.) 2.1. Find the reference file below that matches the detected framework — it is the source of truth for SDK initialization, provider setup, and event capture patterns. Read it now. 2.2. If no reference matches, fall back to your general knowledge and web search. Use posthog.com/docs as the primary search source.

STEP 3: Install the PostHog SDK. (Skip if PostHog is already set up.)

Add the PostHog SDK package for the detected platform. Do not manually edit package.json — use the package manager's install command.

STEP 4: Initialize PostHog. (Skip if PostHog is already set up.)

Follow the framework reference for where and how to initialize. This varies significantly by framework (e.g., instrumentation-client.ts for Next.js 15.3+, AppConfig.ready() for Django, create_app() for Flask).

STEP 5: Plan event tracking.

From the project's file list, select between 10 and 15 files that might have interesting business value for event tracking, especially conversion and churn events.
Also look for files related to login that could be used for identifying users, along with error handling.
Find any existing posthog.capture() code. Make note of event name formatting. Don't duplicate existing events; supplement them.
Track actions only, not pageviews (those can be captured automatically). Exceptions can be made for "viewed"-type events at the top of a conversion funnel.
Server-side events are REQUIRED if the project includes any instrumentable server-side code (API routes, server actions, webhook handlers, payment/checkout completion, authentication endpoints).

STEP 6: Implement event capture.

For each planned event, add posthog.capture() calls with useful properties.
If a file already has existing integration code for other tools or services, don't overwrite or remove that code. Place PostHog code below it.
Do not alter the fundamental architecture of existing files. Make additions minimal and targeted.
You must read a file immediately before attempting to write it.

STEP 7: Identify users.

Add PostHog identify() calls on the client side during login and signup events. Use the contents of login and signup forms to identify users on submit.
If both frontend and backend exist, pass the client-side session and distinct ID using X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID headers to the server-side code. On the server side, make sure events have a matching distinct ID.

STEP 8: Add error tracking.

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

STEP 9: Set up environment variables.

Check if the project already has PostHog environment variables configured (e.g. in .env, .env.local, or framework-specific env files). If valid values already exist, skip this step.
If the PostHog project token is missing, use the PostHog MCP server's projects-get tool to retrieve the project's api_token. If multiple projects are returned, ask the user which project to use. If the MCP server is not connected or not authenticated, ask the user for their PostHog project token instead.
For the PostHog host URL: check the projects-get MCP response for a region field — US maps to https://us.i.posthog.com, EU maps to https://eu.i.posthog.com. If the region is not available from the MCP response or from existing project configuration, ask the user: "Are you on PostHog US Cloud or EU Cloud?" Do not assume US Cloud.
Write these values to the appropriate env file using the framework's naming convention.
Reference these environment variables in code instead of hardcoding them.

STEP 10: Verify and clean up.

Check the project for errors. Look for type checking or build scripts in package.json.
Ensure any components created were actually used.
Run any linter or prettier-like scripts found in the package.json, but ONLY on the files you have edited or created during this session. Never run formatting or linting across the entire project's codebase.

Reference files

references/EXAMPLE-next-app-router.md - next-app-router example project code
references/EXAMPLE-next-pages-router.md - next-pages-router example project code
references/EXAMPLE-react-react-router-6.md - react-react-router-6 example project code
references/EXAMPLE-react-react-router-7-framework.md - react-react-router-7-framework example project code
references/EXAMPLE-react-react-router-7-data.md - react-react-router-7-data example project code
references/EXAMPLE-react-react-router-7-declarative.md - react-react-router-7-declarative example project code
references/EXAMPLE-nuxt-3-6.md - nuxt-3-6 example project code
references/EXAMPLE-nuxt-4.md - nuxt-4 example project code
references/EXAMPLE-vue-3.md - vue-3 example project code
references/EXAMPLE-react-tanstack-router-file-based.md - react-tanstack-router-file-based example project code
references/EXAMPLE-react-tanstack-router-code-based.md - react-tanstack-router-code-based example project code
references/EXAMPLE-tanstack-start.md - tanstack-start example project code
references/EXAMPLE-sveltekit.md - sveltekit example project code
references/EXAMPLE-astro-static.md - astro-static example project code
references/EXAMPLE-astro-view-transitions.md - astro-view-transitions example project code
references/EXAMPLE-astro-ssr.md - astro-ssr example project code
references/EXAMPLE-astro-hybrid.md - astro-hybrid example project code
references/EXAMPLE-angular.md - angular example project code
references/EXAMPLE-django.md - django example project code
references/EXAMPLE-flask.md - flask example project code
references/EXAMPLE-fastapi.md - fastapi example project code
references/EXAMPLE-python.md - python example project code
references/EXAMPLE-laravel.md - laravel example project code
references/EXAMPLE-php.md - php example project code
references/EXAMPLE-ruby-on-rails.md - ruby-on-rails example project code
references/EXAMPLE-ruby.md - ruby example project code
references/EXAMPLE-android.md - android example project code
references/EXAMPLE-swift.md - swift example project code
references/EXAMPLE-react-native.md - react-native example project code
references/EXAMPLE-expo.md - expo example project code
references/next-js.md - Next.js
references/react-router-v6.md - React router v6
references/react-router-v7-framework-mode.md - React router v7 framework mode (remix v3)
references/react-router-v7-data-mode.md - React router v7 data mode
references/react-router-v7-declarative-mode.md - React router v7 declarative mode
references/nuxt-js-3-6.md - Nuxt.js (v3.0 to v3.6)
references/nuxt-js.md - Nuxt.js
references/vue-js.md - Vue.js
references/tanstack-start.md - Tanstack start
references/svelte.md - Svelte
references/astro.md - Astro
references/angular.md - Angular
references/django.md - Django
references/flask.md - Flask
references/python.md - Python
references/posthog-python.md - PostHog python SDK
references/dotnet.md - .net
references/elixir.md - Elixir
references/go.md - Go
references/laravel.md - Laravel
references/php.md - Php
references/ruby-on-rails.md - Ruby on rails
references/ruby.md - Ruby
references/android.md - Android
references/ios.md - Ios
references/usage.md - Ios SDK usage
references/configuration.md - Ios SDK configuration
references/flutter.md - Flutter
references/react-native.md - React native
references/identify-users.md - Identify users
references/COMMANDMENTS.md - Framework-specific rules the integration must follow

Each framework reference contains SDK-specific installation, initialization, and usage patterns. Find the one matching the user's stack.

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 docs: Follow the framework reference's initialization and capture patterns exactly.

Files

ATTRIBUTION.mdAdded by AutoGineer970 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md9.6 KiB
references/COMMANDMENTS.md1.5 KiB
references/EXAMPLE-android.md49.8 KiB
references/EXAMPLE-angular.md23.1 KiB
references/EXAMPLE-astro-hybrid.md27.5 KiB
references/EXAMPLE-astro-ssr.md27.6 KiB
references/EXAMPLE-astro-static.md19.6 KiB
references/EXAMPLE-astro-view-transitions.md23.3 KiB
references/EXAMPLE-django.md30.7 KiB
references/EXAMPLE-expo.md35.1 KiB
references/EXAMPLE-fastapi.md40.9 KiB
references/EXAMPLE-flask.md32.4 KiB
references/EXAMPLE-laravel.md59.3 KiB
references/EXAMPLE-next-app-router.md17.6 KiB
references/EXAMPLE-next-pages-router.md19.1 KiB
references/EXAMPLE-nuxt-3-6.md22.3 KiB
references/EXAMPLE-nuxt-4.md28.9 KiB
references/EXAMPLE-php.md13.0 KiB
references/EXAMPLE-python.md11.6 KiB
references/EXAMPLE-react-native.md46.0 KiB
references/EXAMPLE-react-react-router-6.md13.5 KiB
references/EXAMPLE-react-react-router-7-data.md20.1 KiB
references/EXAMPLE-react-react-router-7-declarative.md15.0 KiB
references/EXAMPLE-react-react-router-7-framework.md32.5 KiB
references/EXAMPLE-react-tanstack-router-code-based.md19.6 KiB
references/EXAMPLE-react-tanstack-router-file-based.md18.3 KiB
references/EXAMPLE-ruby-on-rails.md38.0 KiB
references/EXAMPLE-ruby.md10.0 KiB
references/EXAMPLE-sveltekit.md18.6 KiB
references/EXAMPLE-swift.md18.8 KiB
references/EXAMPLE-tanstack-start.md29.9 KiB
references/EXAMPLE-vue-3.md17.9 KiB
references/android.md33.3 KiB
references/angular.md16.5 KiB
references/astro.md15.8 KiB
references/configuration.md17.2 KiB
references/django.md14.9 KiB
references/dotnet.md25.8 KiB
references/elixir.md17.6 KiB
references/flask.md8.1 KiB
references/flutter.md42.8 KiB
references/go.md20.1 KiB
references/identify-users.md12.2 KiB
references/ios.md8.0 KiB
references/laravel.md13.1 KiB
references/next-js.md18.3 KiB
references/nuxt-js-3-6.md11.4 KiB
references/nuxt-js.md15.1 KiB
references/php.md23.7 KiB
references/posthog-python.md69.3 KiB
references/python.md52.2 KiB
references/react-native.md59.9 KiB
references/react-router-v6.md13.6 KiB
references/react-router-v7-data-mode.md13.5 KiB
references/react-router-v7-declarative-mode.md13.7 KiB
references/react-router-v7-framework-mode.md20.2 KiB
references/ruby-on-rails.md19.7 KiB
references/ruby.md25.5 KiB
references/svelte.md14.6 KiB
references/tanstack-start.md12.8 KiB
references/usage.md29.2 KiB
references/vue-js.md13.4 KiB

references/configuration.md

AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

iOS SDK configuration

Canonical URL: https://posthog.com/docs/libraries/ios/configuration

Cloud region: This page uses US Cloud hosts. For an EU Cloud project, use https://eu.i.posthog.com instead of https://us.i.posthog.com (ingestion host).

Autocapture configuration

You can enable or disable autocapture through the PostHogConfig object.

Tracing headers

Use tracingHeaders to connect iOS network requests to backend events, errors, and LLM traces captured by a server-side PostHog SDK:

let configuration = PostHogConfig(projectToken: "<ph_project_token>", host: "https://us.i.posthog.com")
configuration.tracingHeaders = ["api.example.com"]
PostHogSDK.shared.setup(configuration)

Hostnames are matched exactly and should not include protocols, paths, ports, or wildcard subdomains. Matching URLSession requests include X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID when those values are available.

Tracing headers require method swizzling, so configuration.enableSwizzling must remain true.

Flush configuration

The iOS SDK uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your mobile app.

You can configure how many events queue before flushing with flushAt. Setting this to 1 will send events immediately and will use more battery. The default is 20.

You can also configure the flush interval with flushIntervalSeconds (default 30), after which queued events are sent regardless of how many have been gathered:

configuration.flushAt = 1
configuration.flushIntervalSeconds = 30

You can also manually flush the queue to start sending events immediately instead of waiting for the next batch:

PostHogSDK.shared.capture("logged_out")
PostHogSDK.shared.flush()

Flushing is best-effort and asynchronous – it starts sending queued events in the background but doesn't wait for the request to finish, so it isn't a delivery guarantee.

Amending, dropping or sampling events

Since version 3.28.0, you can provide a BeforeSendBlock function when initializing the SDK to amend, drop or sample events before they are sent to PostHog.

⚠️ Note: This replaces the deprecated propertiesSanitizer option and provides more flexibility in modifying events. You can achieve the same functionality as propertiesSanitizer by using a BeforeSendBlock that mutates the event's properties in place.

🚨 Warning: Amending and sampling events is advanced functionality that requires careful implementation. Core PostHog features may require 100% of unmodified events to function properly. We recommend only modifying or sampling your own custom events if possible, and preserving all PostHog internal events in their original form.

Redacting information in events

BeforeSendBlock gives you one place to edit or redact information before it is sent to PostHog. For example:

Redact URLs in event properties

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Redact URLs
    if let url = event.properties["url"] as? String {
        event.properties["url"] = url.map { _ in "*" }.joined()
    }
    return event
}

Redact sensitive information from event properties

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Redact sensitive information
    if let email = event.properties["email"] as? String {
        event.properties["email"] = email.map { _ in "*" }.joined()
    }

    return event
}

Drop events by event name

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Drop all events named "Stale Event"
    if event.event == "Stale Event" {
        return nil
    }
    return event
}

Filter autocaptured screen views

You can stop specific screens from being autocaptured by filtering them in your before-send hook. Return null for any $screen event whose $screen_name matches a screen you don't want to track, and it's dropped before being sent – keeping unwanted screen views out of your event log.

Because it's just a function, you can filter however you like – an ignorelist (drop the screens you name), an allowlist (invert the check to capture only the screens you name), or any custom rule such as a name prefix, a regex, or a check against the event's properties.

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

let ignoredScreens: Set<String> = ["Splash", "Debug"]

config.setBeforeSend { event in
    if event.event == "$screen",
       let screenName = event.properties["$screen_name"] as? String,
       ignoredScreens.contains(screenName) {
        return nil
    }
    return event
}

Sampling events

Sampling lets you choose to send only a percentage of events to PostHog. It is a good way to control your costs without having to completely turn off features of the SDK.

Sample events by event name

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Sample 10% of Sampled Event events
    if event.event == "Sampled Event" {
        if Double.random(in: 0...1) < 0.1 {
            event.properties["$sample_type"] = ["sampleByEvent"]
            event.properties["$sample_threshold"] = 0.1
            event.properties["$sampled_events"] = ["Sampled Event"]
            return event
        }
        return nil
    }
    return event
}

Chaining multiple BeforeSendBlocks

You can provide an array of BeforeSendBlock functions to be called one after the other:

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend(
    // First block: Drop all events named "Stale Event"
    { event in
        if event.event == "Stale Event" {
            return nil
        }
        return event
    },
    // Second block: Redact sensitive information
    { event in
        if let email = event.properties["email"] as? String {
            event.properties["email"] = email.map { _ in "*" }.joined()
        }
        return event
    }
)

Note: When chaining beforeSend blocks, order is important. The first block is executed first and the mutated event is passed along to the second block, and so on. If at any point in the chain the event is dropped, any subsequent blocks will not be executed.

Setting up app groups

Configure App Groups: Set up an App Group in Xcode for your main app and extension targets
Configure PostHog: Use the same App Group identifier in all targets:

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")
config.appGroupIdentifier = "group.com.yourcompany.yourapp"
PostHogSDK.shared.setup(config)

Method swizzling

Method swizzling is a technique that enables the SDK to intercept and modify method calls at runtime to provide advanced features like screen view tracking, element interactions, session replay, surveys, and more.

Method swizzling is enabled by default, but can be disabled by setting the relevant config option to false in the PostHogConfig object:

Feature	Description	Config option
Screen view tracking	Automatically captures when view controllers are presented	`config.captureScreenViews`
Element interactions	Automatically tracks user interactions with UI elements	`config.captureElementInteractions`
Rage clicks	Automatically captures `$rageclick` events for rapid repeated taps in the same area (iOS/macCatalyst, UIKit)	`config.rageClickConfig.enabled`
Session replay	Records user sessions	`config.sessionReplay`
Surveys	Displays surveys at appropriate times	`config.surveys`
Advanced metrics tracking	Provides more precise session ID calculation and rotation by detecting user activity and idleness	N/A

Disabling all method swizzling

Since version 3.34.0, you can opt out of all swizzling using the enableSwizzling configuration option. When you disable swizzling, the SDK disables the features listed above.

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")
config.enableSwizzling = false
PostHogSDK.shared.setup(config)

Note: When method swizzling is disabled, features that depend on it will not work even if they are individually enabled in the config. For example, if you set config.sessionReplay = true and config.enableSwizzling = false, session replay will not be enabled.

Session metrics management

Method swizzling is particularly important for accurate session metrics tracking. With swizzling enabled, the SDK can better detect user activity and idle times to provide a better session rotation.

With swizzling disabled, the SDK only uses application open/backgrounded events to detect user activity, which can lead to a sub-optimal session calculation.

Custom keyboard extensions

Custom keyboard extensions have stricter security rules than other extension types. To use PostHog in a custom keyboard, the keyboard must have Open Access permission enabled. This permission is required for network requests and write access to shared containers.

Users must explicitly grant Open Access in Settings > General > Keyboard > Keyboards > [Your Keyboard] > Allow Full Access.

All configuration options

The PostHogConfig object contains several other settings you can toggle:

Attribute	Description
`flushAt` Type: Integer Default: `20` (`5` on tvOS)	The number of queued events that the posthog client should flush at. Setting this to `1` will not queue any events and will use more battery.
`flushIntervalSeconds` Type: TimeInterval Default: `30`	The amount of time to wait before each tick of the flush timer, in seconds. Smaller values will make events delivered in a more real-time manner and also use more battery. A value smaller than 10 seconds will seriously degrade overall performance.
`maxQueueSize` Type: Integer Default: `1000` (`100` on tvOS)	The maximum number of items to queue before starting to drop old ones. This should be a value greater than zero, the behavior is undefined otherwise.
`maxBatchSize` Type: Integer Default: `50`	Number of maximum events in a batch call.
`maxRetries` Type: Integer Default: `3`	Maximum number of consecutive flush attempts before the entire queue is dropped to avoid infinite retries against a permanently-broken backend (e.g. wrong API key, exhausted quota, deterministic 5xx). Increments on every retriable failure including HTTP 413 cap halving; resets on a successful 2xx response.
`captureApplicationLifecycleEvents` Type: Boolean Default: `true`	Whether the posthog client should automatically make a capture call for application lifecycle events, such as "Application Installed", "Application Updated" and "Application Opened".
`captureScreenViews` Type: Boolean Default: `true`	Whether the posthog client should automatically make a screen call when a view controller is added to a view hierarchy. Because the underlying implementation uses method swizzling, we recommend initializing the posthog client as early as possible (before any screens are displayed), ideally during the Application delegate's applicationDidFinishLaunching method.
`enableSwizzling` Type: Boolean Default: `true`	Enable method swizzling for SDK functionality that depends on it. When disabled, functionality that requires swizzling (like autocapture, screen views, session replay, surveys) will not be installed.
`captureElementInteractions` Type: Boolean Default: `false`	(UIKit only) Whether the posthog client should automatically make a capture call when the user interacts with an element in a screen.
`rageClickConfig` Type: Object Default: `.init()`	(iOS/macCatalyst, UIKit) Rage click detection configuration. Includes `enabled` (default `true`), `minimumTapCount` (default `3`), `thresholdPoints` (default `30`), and `timeoutInterval` (default `1.0`). Works independently of `captureElementInteractions`. Available in version 3.51.0+.
`sendFeatureFlagEvent` Type: Boolean Default: `true`	Send a `$feature_flag_called` event when a feature flag is used automatically.
`preloadFeatureFlags` Type: Boolean Default: `true`	Preload feature flags automatically.
`evaluationContexts` Type: Array of Strings Default: `undefined`	Evaluation context tags that constrain which feature flags are evaluated. When set, only flags with matching evaluation context tags (or no evaluation context tags) will be returned. See evaluation contexts documentation for more details. Available in version 3.38.0+. The legacy parameter `evaluationEnvironments` (version 3.33.0+) is also supported for backward compatibility.
`debug` Type: Boolean Default: `false`	Logs the SDK messages to the Xcode console.
`optOut` Type: Boolean Default: `false`	Prevents capturing any data if enabled.
`getAnonymousId` Type: Function Default: `undefined`	Hook that allows for modification of the default mechanism for generating anonymous id (which as of now is just random UUID v7).
`dataMode` Type: Enum Default: `.any`	Controls when queued data is flushed. Use `.wifi` to flush only on Wi-Fi; `.cellular` is a legacy value and behaves like `.any`.
`personProfiles` Type: Enum Default: `.identifiedOnly`	Determines the behavior for processing user profiles.
`setDefaultPersonProperties` Type: Boolean Default: `true`	Automatically set common device and app properties (such as `$app_version`, `$os_name`, and `$device_type`) as person properties for feature flag evaluation. See property overrides for more details.
`sessionReplay` Type: Boolean Default: `false`	Enable Recording of Session Replays.
`sessionReplayConfig` Type: Object Default: `.init()`	Session Replay configuration. See Session Replay installation for more details.
`tracingHeaders` Type: Array of Strings Default: `nil`	Exact hostnames that should receive PostHog tracing headers when the SDK instruments `URLSession` requests.
`errorTrackingConfig` Type: Object Default: `.init()`	Error Tracking configuration. See the error tracking docs for more details.
`logs` Type: Object Default: `.init()`	Structured Logs configuration. See Logs installation for more details.
`surveysConfig` Type: Object Default: `.init()`	Surveys configuration, including custom survey delegates and display language overrides.
`urlSessionConfiguration` Type: URLSessionConfiguration Default: `.default`	Custom `URLSessionConfiguration` used by the SDK for PostHog API requests.
`appGroupIdentifier` Type: String Default: `nil`	The identifier of the App Group that should be used to store shared analytics data. PostHog will try to get the physical location of the App Group's shared container, otherwise fallback to the default location.
`reuseAnonymousId` Type: Boolean Default: `false`	Whether the SDK should reuse the anonymous Id between user changes. When enabled, a single Id will be used for all anonymous users on this device.
`surveys` Type: Boolean Default: `true`	Enable Surveys.
`setBeforeSend` Type: Function Default: `undefined`	Hook that allows for amending, sampling, or dropping events before they are sent to PostHog.
`bootstrap` Type: `PostHogBootstrapConfig` Default: `nil`	Seeds identity (`distinctId`, `isIdentifiedId`) and feature-flag state (`featureFlags`, `featureFlagPayloads`) before the first `/flags` response. Bootstrapped identity applies to the first session; only enabled flags are served, until the first `/flags` response replaces them. See SDK bootstrapping.

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.

Needs: Needs an MCP server, Needs Python, Needs Node.js

Security

What our scanner noticed· Low risk

Instructions that use the network

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/omnibus/instrument-product-analytics · commit a5d30e7

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by PostHog or PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download instrument-product-analytics.zip