posthog/ai-plugin

creating-box-plot-insights

- Creates product analytics or SQL-backed box plot insights in PostHog.

View source
Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

Creating box plot insights

Box plots need distribution data, not an already-aggregated average or total. Choose the simplest query type that can express the user's question.

Choose the query type

Use a standard product analytics box plot when all of these are true:

  • The source is an event, action, or warehouse table supported by Trends.
  • One numeric property contains the values to distribute.
  • The user wants the distribution over a normal time interval.

Use a SQL box plot when the user needs custom grouping, joins, derived values, or bespoke SQL. Read querying-posthog-data before writing HogQL, then use references/sql-examples.md as a starting point.

Do not use SQL only to reproduce a standard Trends query.

Standard product analytics box plot

  1. Identify the event or action and its numeric property. Confirm the property is numeric before saving.
  2. Build an InsightVizNode whose source is a TrendsQuery:
  • Set the series event or action.
  • Set math_property to the numeric property.
  • Set trendsFilter.display to BoxPlot.
  • Choose the date range and interval that match the question.
  1. Run the query with posthog:query-trends.
  2. If it returns distribution rows, save it with posthog:insight-create.
  3. Read it back with posthog:insight-get and confirm the property, interval, and display.

A box plot without a numeric math_property is invalid. Do not substitute event counts unless counts are the values the user wants to distribute.

SQL box plot

The SQL must return one pre-aggregated row for each X-axis and series pair. Calculate the summary in the database. Never calculate percentiles from the limited result rows in the client.

Required numeric roles:

  • minimum
  • 25th percentile
  • median
  • mean
  • 75th percentile
  • maximum

The easiest result shape uses these aliases:

text
x, series, min, p25, median, mean, p75, max

x and series are optional:

  • Set xAxisColumn to null for one overall distribution or one box per series.
  • Set seriesColumn to null for one series.

Validate the HogQL with posthog:execute-sql before saving. Check that:

  • Every required statistic is numeric.
  • min <= p25 <= median <= p75 <= max for every row.
  • The mean is between the minimum and maximum.
  • Each X-axis and series pair appears once.
  • There are at most 200 series and 10,000 X-axis by series cells.

Then save this shape with posthog:insight-create:

json
{
  "query": {
    "kind": "DataVisualizationNode",
    "source": {
      "kind": "HogQLQuery",
      "query": "<validated HogQL>"
    },
    "display": "BoxPlot",
    "chartSettings": {
      "boxPlot": {
        "xAxisColumn": "x",
        "seriesColumn": "series",
        "minColumn": "min",
        "p25Column": "p25",
        "medianColumn": "median",
        "meanColumn": "mean",
        "p75Column": "p75",
        "maxColumn": "max",
        "excludeOutliers": true
      }
    }
  }
}

Use the actual aliases when the query uses different names. Do not map the six statistics as six Y-axis series.

Verify the saved insight

  1. Read the saved insight with posthog:insight-get.
  2. Run it with posthog:insight-query.
  3. Confirm the result still has the expected columns and one row per box.
  4. Report the insight link, the numeric value being distributed, and the grouping choices.

If an individual row has a missing or invalid summary, PostHog omits that box while keeping valid boxes visible. Fix the SQL when omitted boxes are not expected.

Related skills

  • querying-posthog-data - required before authoring or changing the HogQL for a SQL box plot.
  • formatting-insight-axes - use when the value axis needs currency, duration, percentage, or other formatting.
  • building-a-dashboard - use when the box plot should be placed with other insights on a dashboard.
from this repository

More skills

All skills
posthog
Official

assessing-heatmaps

Assesses what a page's heatmap is telling you and recommends concrete changes. Pulls click / rageclick / scroll-depth data for a URL, names the hot elements by cross-referencing autocapture events on the same page, and can create a saved heatmap the user opens in PostHog, then summarizes the behavior and proposes improvements.\nTRIGGER when: user asks what a heatmap shows, why people aren't clicking something, where users rage-click, how far they scroll, what to change on a page based on heatmap/click data, or to 'analyze/assess/review the heatmap' for a URL.\nDO NOT TRIGGER when: the user only wants to create a saved heatmap screenshot with no analysis (use heatmaps-saved-create directly), or is asking about session replay in general (use investigating-replay).

installs
1
GitHub stars
80
Updated
Sep 4
posthog
Official

auditing-endpoints

Audit every endpoint in a PostHog project for staleness, failed materialisations, and unused materialised versions. Use when the user asks "what endpoints can I clean up?", "are any of my endpoints broken?", "which materialised versions are still being called?", or wants a one-shot cleanup pass over the Endpoints product. Produces a prioritised report grouped by issue type, with recommended actions but does not modify anything without explicit confirmation.

installs
1
GitHub stars
80
Updated
Sep 4
posthog
Official

auditing-experiments-flags

Audit PostHog experiments and feature flags for configuration issues, staleness, and best-practice violations. Read when the user asks to audit, health-check, or review experiments or feature flags, check flag hygiene, or verify experiment setup.

installs
1
GitHub stars
80
Updated
Sep 4
posthog
Official

authoring-data-quality-checks

Adds and runs data quality checks (dbt-test style assertions) on a project's warehouse tables and saved-query views: not-null, uniqueness, accepted values, referential integrity, row-count bounds, freshness, and custom HogQL. Use when asked to test a model, validate a view, check for nulls or duplicates, add data quality checks, find out why a number looks wrong, or judge whether a warehouse table is trustworthy before using it in an analysis. To describe what data means (metrics, certifications, joins), see setting-up-data-catalog instead. Trigger terms: data quality, data test, dbt test, not null check, uniqueness check, freshness check, referential integrity, row count check, validate model, is this table trustworthy.

installs
1
GitHub stars
80
Updated
Sep 4