Onboarding conversations playbook

Audit this customer's PostHog account and write a notebook for the customer. Last 30 days. Switch to SQL mode.

Rules:

• Batch independent queries, run them in parallel.
• Discover schema on demand: SELECT * FROM <table> LIMIT 3, or system.information_schema.tables / columns.
• Always verify: if a table errors or looks empty when you expected data, check system.information_schema.columns before concluding.
• Filter bots: AND getBotName(properties.$raw_user_agent) = '' on every events query. Never isLikelyBot or $virt_is_bot: they flag every non-browser SDK and drop whole mobile and backend products.
• Internal and test users: apply test_account_filters from SELECT * FROM system.teams (an array of {key, type, value, operator}; type: event maps to properties.<key>, type: person to person.properties.<key>). If empty, say internal traffic cannot be separated.
• Count people with uniqExact(person_id), never distinct_id.
• system.* entity tables return deleted and archived rows. Filter every count: deleted = 0 for actions, cohorts, dashboards, feature_flags; deleted = 0 AND saved = 1 for insights; archived = 0 for experiments; surveys have no flag, judge by start_date and end_date.
• LIMIT 10 on any top-N. Apply bot and test filters to non-events tables only where those fields exist.
• Where things live: events by default, except replay → raw_session_replay_events (on/off state); heatmaps → heatmaps; logs → logs; LLM prompt/response bodies → posthog.ai_events. Billing and delivery meters → app_metrics (app_source + metric_name + count). Ingestion problems → system.ingestion_warnings. Warehouse syncs → system.source_sync_jobs joined to system.source_schemas. Query volume → query_log. Everything the customer created → system.*.
• Always consider billing (posthog.com/pricing) for each area's optimization.

Snapshot first:

SELECT
 count() AS total_events,
 countIf(event = '$pageview') AS pageviews,
 countIf(event = '$pageleave') AS pageleaves,
 countIf(event = '$autocapture') AS autocapture,
 countIf(event = '$exception') AS exceptions,
 countIf(event LIKE '$ai_%') AS ai_events,
 countIf(event = '$feature_flag_called') AS flag_evals,
 countIf(event = 'survey sent') AS survey_sends,
 countIf(event = '$identify') AS identify_events,
 countIf(event = '$set') AS set_events,
 countIf(event = '$groupidentify') AS groupidentify_events,
 countIf(event = '$web_vitals') AS web_vitals,
 countIf(person_mode IN ('full', 'force_upgrade')) AS identified_events,
 uniqExact(person_id) AS people,
 uniqExact(properties.$session_id) AS sessions,
 uniqExact(properties.$lib) AS sdk_count,
 groupUniqArray(10)(properties.$lib) AS sdks
FROM events
WHERE timestamp >= now() - INTERVAL 30 DAY
 AND getBotName(properties.$raw_user_agent) = ''

Analyze each area. Each carries a value read (getting the most from it) and a cost read (what it costs, how to cut). Prefix each finding subheading :large_green_circle: working well, :large_yellow_circle: worth attention, or :red_circle: needs action. If an area is unused, consider how it might be used in this project. State each finding only once. Always inline link to documentation:

1. Instrumentation: SDKs and versions (properties.$lib, $lib_version; old versions miss cost controls like replay minimum duration and flag bootstrapping); autocapture vs named-event share; identified vs anonymous (person_mode); identify()/$set/$groupidentify each about once per session (compare totals to sessions). Ingestion warnings (system.ingestion_warnings type and timestamp; cannot_merge_already_identified means identify ran on already-identified users, spending events for nothing). Custom events no saved insight references (they bill but are never analyzed; cross-check flags, cohorts, experiments before suggesting removal). Dev or staging leakage (properties.$host localhost or staging domains billing here means point them at a separate project). If autocapture is a large share with few named actions, name the potential specific actions or custom events to create that don't already exist (actions apply retroactively).
2. Product analytics: top events, paths, week-over-week retention, drop-off, spikes, DAU/WAU, dashboards, alerts, subscriptions, gaps in measurement. Which event names and libraries drive the most billable volume.
3. Web analytics: enabled, data flowing, conversion goals, core web vitals.
4. Session replay. Three-state read:

SELECT
 uniqExactIf(session_id, min_first_timestamp >= now() - INTERVAL 30 DAY) AS recordings_30d,
 uniqExact(session_id) AS recordings_all_time,
 minIf(min_first_timestamp, min_first_timestamp >= '2015-01-01') AS first_recording,
 maxIf(max_last_timestamp, max_last_timestamp <= now()) AS latest_recording
FROM raw_session_replay_events

30d > 0: recording now. all-time > 0 but 30d = 0: stopped, give the last date and name candidates. Both 0: never recorded. latest_recording will show if it was turned off and when. When replay is active, assess the minimum-duration lever from session_replay_events (session_id, dateDiff('second', start_time, end_time), console_error_count) if its count roughly matches the read above: a high share under 2 to 5 seconds is bounce recordings they pay for.

5. Heatmaps: group by type so the real values surface. See total, active vs stale. Run:

SELECT type, count() AS interactions, count(DISTINCT current_url) AS urls
FROM heatmaps WHERE timestamp >= now() - INTERVAL 30 DAY
GROUP BY type ORDER BY interactions DESC

6. Feature flags: total, active vs stale (created before the window with zero $feature_flag_called in it, but server local-eval flags may not emit the event, so caveat it), evaluation distribution by $feature_flag key and $lib, server vs client, at 100% for 30+ days, flag-shaped cases that should be experiments. Cost is per /flags request, not per flag: the lever is cutting request volume (local evaluation, polling cadence, bootstrapping), not archiving individual flags.
7. Experiments: running (system.experiments: start_date set, end_date null, archived = 0) and how long; one running for months is usually decided, ship the winner and stop it. Sample sizes, statistical health.
8. Surveys: running (system.surveys), response rate per survey (survey shown vs survey sent, grouped by properties.$survey_name), targeting, response limits. Always-on surveys quietly accrue billable responses.
9. Error tracking: capturing exceptions, grouping, assignment, alerts. Top exception types come from $exception_list, not $exception_type (that scalar is null ~80% of the time and fakes a null-type flood); extract the first with JSONExtractString(arrayElement(JSONExtractArrayRaw(JSONExtractString(properties, '$exception_list')), 1), 'type'). Ingested vs rate-limited (app_metrics, app_source = 'exceptions'). Suppression rules drop matches before they bill.
10. LLM observability: $ai_generation/$ai_span/$ai_trace/$ai_embedding volume, generations, traces, cost by model (properties.$ai_model, sum(toFloat(properties.$ai_total_cost_usd))), latency. Deeply instrumented agents emit far more spans and traces than generations. Confirm senders are real users, not PostHog AI usage by admins.
11. Data warehouse: external sources, sync health, joins with events. Rank schemas by total rows_synced over the window. Look for full_refresh vs sync frequency (system.source_sync_jobs: rows_synced, status; join system.source_schemas on schema_id = id for name, sync_type). full_refresh on a large table re-bills every row each sync.
12. CDP, destinations, transformations, workflows: enabled inventory (system.hog_functions: type, enabled, deleted). Destination deliveries and batch-export rows (app_metrics, app_source 'hog_function' and 'batch_export'); the billed meter is metric_name = 'billable_invocation', not failed/succeeded/triggered (those are delivery outcomes), so size cost from that and read a 100%-failure rate as a delivery problem to fix, not a bill. Workflows (system.hog_flows, filter by status). Transformations act on future events only; a filtered delivery is skipped by its own filters, which is free and good. only metric_name = 'billable_invocation' bills; failed, filtered, triggered, and fetch do not (a 100%-failing destination shows zero billable_invocation). A dead destination is a delivery fix, never a cost saving: do not rank it as one.
13. Platform, queries and logs: query volume app vs personal API key (query_log, is_personal_api_key_request; an API spike usually means an automation polling too often). Logs GB ingested and dropped (app_metrics, app_source = 'logs').
14. Revenue: billing connected and joined to usage. If not, connect Stripe or Chargebee as a warehouse source and join to events in SQL.
15. Cohorts: count, static vs dynamic, usage. Dynamic cohorts with behavioral or lifecycle criteria can't target feature flags, experiments, or surveys; flag any that do and recommend a static duplicate or a person property to target instead.
16. What they're not using yet: one inventory across system.* shows coverage and the best untapped plays (saved insights, dashboards, notebooks, actions, cohorts, annotations, saved SQL views data_modeling_views, feature flags, running experiments, early access features, running surveys, recording collections session_recording_playlists, error suppression rules, warehouse sources, active batch exports, enabled hog_functions and hog_flows, insight alerts alerts and log alerts logs_alerts, integrations). Count with the right filter per table. A zero is an opportunity, not a failure.

Write the notebook

• Renders only: h1-3 headings, bold, inline code (but not in bolded sentences), fenced code blocks, bullets, links, emojis. Anything needing alignment goes in a code block.
• Open with an ## At a glance space-aligned table (columns: Area, Main Finding, Next Step). Each area is separated by underlined of ─.
• Embed all relevant data as a table in fenced code blocks. Do not embed insights directly. Format every table as a simple table: space-aligned columns with the header underlined by a line of ─, never pipe-delimited.
• Use headings for hierarchy. Each subheading states primary finding (":large_yellow_circle: Autocapture is 60% of your events, turn it into actions").
• Recommendations: 5 h3 headings ordered by impact, each with the action, why, and a docs link.
• Untapped opportunities: 3 to 5 h3 headings forward-looking plays. has to be something new that wasn't covered before.
• Frame cost findings as efficiency and savings, not waste or blame. Rank recommendations purely by impact; give fewer than five rather than pad.
• At the end of the notebook, add all the SQL queries used in separate code blocks for each area.
• Sentence case, no em dashes or en dashes. Never use --- or any dividers between sections; separate them with 2 blank lines and the next heading only. Output as one continuous block.
• After drafting the notebook, validate that all formatting rules in this section have been met. Fix, and only then save the notebook.

1. Instrumentation health

• What SDKs are sending data? (web, mobile, server-side, etc.)
• What's the ratio of auto-captured events vs. custom events?
• Are there any custom events that appear to be duplicates or redundant?
• Are there events with very low volume that might be broken or deprecated?
• Are person profiles being created?
• What's the identified vs. anonymous user ratio?

2. Feature flag usage

• How many feature flags exist?
• How many are active vs. stale?
• Which flags have the most evaluations?
• Which have the fewest?
• Are any flags being evaluated server-side vs. client-side?
• Can you tell?
• Are there flags that have been at 100% rollout for more than 30 days that could be cleaned up?

3. Product usage patterns

• What are the top 20 most frequent events?
• What are the most common user paths? (entry point to key actions)
• What does retention look like week over week?
• Are there obvious drop-off points in any user flows?
• What's the DAU/WAU ratio (stickiness)?

4. Session replay

• Is session replay active?
• How many recordings were there in the last 30 days?
• What's the average session duration?
• Are there minimum duration filters set, or are very short sessions being recorded?
• What's the rage click and dead click volume?

5. Underutilized PostHog features

• Are they using experiments?
• If not, are there flags that look like they could be experiments?
• Is web analytics enabled and collecting data?
• Are surveys being used?
• Is error tracking / exception capture active?
• Are any data warehouse sources connected?
• Are cohorts being used?
• How many exist?

6. Cost optimization

• What products are driving the most usage? (events, recordings, flags)
• Are there any quick wins to reduce noise? (short session filtering, dropping low-value events at ingestion, disabling stale flags)

Summarize findings with a prioritized list of recommendations:

• what's working well
• what needs attention
• what untapped opportunities exist

Follow-up with: Now go look at their business and domain. What should they be doing to get more use and value out of PostHog?