posthog-provisioning-and-query
Use when provisioning or reading PostHog analytics via its API — creating a project, wiring the browser SDK, or querying metrics/funnels with HogQL. Covers the org→project model, the two key types (personal vs project-public), the ingestion-vs-management host split, and how to avoid creating a redundant project when one already exists. Triggers include "set up PostHog", "create a PostHog project", "track events in PostHog", "read PostHog analytics", "PostHog funnel", "provision analytics".
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 13
- Forks
- 4
01 前言 Front Matter
- name
- posthog-provisioning-and-query
- description
- Use when provisioning or reading PostHog analytics via its API — creating a project, wiring the browser SDK, or querying metrics/funnels with HogQL. Covers the org→project model, the two key types (personal vs project-public), the ingestion-vs-management host split, and how to avoid creating a redundant project when one already exists. Triggers include "set up PostHog", "create a PostHog project", "track events in PostHog", "read PostHog analytics", "PostHog funnel", "provision analytics".
03 SKILL.md 正文
PostHog Provisioning & Query
Provision and read PostHog entirely over its REST API. Verified against PostHog Cloud (2026-07).
The model (get these straight first)
- Account → Organization(s) → Project(s). A project (a.k.a. "team") is the isolation unit — one project per site/app/funnel. Orgs are the billing/team boundary; you rarely need a new org, usually a new project.
- Two key types, do not confuse them:
- Personal API key (
phx_…, secret) — used server-side for the management API and HogQL queries, withAuthorization: Bearer <key>. Scope it (query:read,project:read) for least privilege; a broad "management" key also works but is overpowered for read-only query use. - Project API key (
phc_…, PUBLIC) — the browser SDK key, safe to ship to clients asNEXT_PUBLIC_POSTHOG_KEY.
- Personal API key (
- Host split: browser ingestion host is
https://us.i.posthog.com(EU:eu.i.posthog.com); the management/query host ishttps://us.posthog.com(EU:eu.posthog.com). Using the wrong one is a common silent failure.
ALWAYS check for an existing project first
Before creating anything, look at where the app already sends events (its NEXT_PUBLIC_POSTHOG_KEY / POSTHOG_PROJECT_ID in the host's env). Many sites already have a project — creating a second one splits analytics and leaves a confusing empty project. List what a key can see:
curl -s https://us.posthog.com/api/organizations/ -H "Authorization: Bearer $POSTHOG_PERSONAL_API_KEY" \
| jq '.results[] | {id, name, teams: [.teams[] | {project_id, api_token, name}]}'
If a suitable project exists, reuse it (segment a new funnel by event name, not a new project).
Create a project (only if none fits)
ORG=<organization_id> # from the list above
curl -s -X POST "https://us.posthog.com/api/organizations/$ORG/projects/" \
-H "Authorization: Bearer $POSTHOG_PERSONAL_API_KEY" -H 'Content-Type: application/json' \
-d '{"name":"My Project"}'
# response → { "id": <numeric project id>, "api_token": "phc_…" (public browser key), ... }
Set NEXT_PUBLIC_POSTHOG_KEY = <api_token>, POSTHOG_PROJECT_ID = <id>, NEXT_PUBLIC_POSTHOG_HOST = https://us.i.posthog.com in the host env (build-time for NEXT_PUBLIC_*).
Browser tracking
Initialize the SDK only if the key is present; capture pageviews manually on route change if the router doesn't. Emit a stable event contract you can query later, e.g. offer_viewed, offer_checkout_started, cta_clicked {location,label,href}, paid. Server components can't use the browser SDK — fire a client "ping" component for view events, and count server-side metrics in your own store.
Read metrics with HogQL
// POST {mgmtHost}/api/projects/{projectId}/query/ — Bearer personal key, scope query:read
const res = await fetch(`https://us.posthog.com/api/projects/${projectId}/query/`, {
method: "POST",
headers: { Authorization: `Bearer ${personalKey}`, "Content-Type": "application/json" },
body: JSON.stringify({ query: { kind: "HogQLQuery",
query: `SELECT count() AS events, count(DISTINCT person_id) AS visitors
FROM events WHERE timestamp > now() - INTERVAL ${days} DAY` } }),
});
// runs synchronously (blocking is the default; no async polling).
// response → { results: any[][], columns, types } — results[0] = [events, visitors]
person_id is the standard unique-users column on the events table. Both /api/projects/{id}/ and /api/environments/{id}/ work; prefer projects for compatibility with older self-hosted instances. Bound the request with a timeout and surface PostHog's error message on non-2xx.
Optional: create a funnel insight
POST /api/projects/{id}/insights/ with a funnel spec (steps offer_view → checkout_started → paid). Best-effort — never abort provisioning if it fails.
Safety
- Treat the personal/management key as a secret — write it to the host env, never print or commit it.
- The
phc_project key is public by design (it's in the browser bundle) — don't treat a leak of it as a secret incident, but don't reuse it as a personal key. - Verify a key with a cheap read (
GET /api/organizations/) before relying on it; confirm it can query the specific project id you'll use.
04 同仓库更多 Skills
tailscale-generation-skill-authoring
This skill should be used when the user asks to "create a Tailscale generation skill", "add a local generation skill", "document a generation endpoint", "add an image generation provider", "add a TTS provider", "add video generation", "add 3D generation", or needs guidance on where HivemindOS Tailscale or local generation providers belong in the shared skills shelf.
localtts
This skill should be used when the user asks to "generate local TTS", "use local text to speech", "use remote TTS over Tailscale", "make speech audio", "add a TTS provider", "use Qwen3-TTS", or needs TTS endpoint setup through local or HivemindOS Tailscale routes.
karpathy-guidelines
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
comfyui-image-generation
This skill should be used when the user asks to "generate images", "generate images with ComfyUI", "use local ComfyUI", "use remote ComfyUI", "use Z-Image", "add an image generation provider", or needs image-generation endpoint setup through local or HivemindOS Tailscale routes.
wrangler
Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.
workers-best-practices
Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge.