From 5300985ce7e902cad1472b21c6d3e11f6f69edd5 Mon Sep 17 00:00:00 2001 From: "releaser-ai-plugin[bot]" <273148615+releaser-ai-plugin[bot]@users.noreply.github.com> Date: Thu, 14 May 2026 12:34:39 +0000 Subject: [PATCH] chore: sync skills (agent-skills-v0.94.0, context-mill@v1.13.0) --- .claude-plugin/plugin.json | 2 +- .codex-plugin/plugin.json | 2 +- .cursor-plugin/plugin.json | 2 +- gemini-extension.json | 2 +- skills/.sync-manifest | 2 + skills/managing-path-cleaning-rules/SKILL.md | 180 +++++++++++++++++ skills/planning-user-interviews/SKILL.md | 187 ++++++++++++++++++ .../references/example-error-tracking.md | 4 +- .../references/example-logs.md | 2 +- .../references/example-session-replay.md | 8 +- .../references/example-sessions.md | 2 +- 11 files changed, 381 insertions(+), 12 deletions(-) create mode 100644 skills/managing-path-cleaning-rules/SKILL.md create mode 100644 skills/planning-user-interviews/SKILL.md diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index beee7e1..744673c 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "posthog", "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Claude Code. Optionally capture Claude Code sessions to PostHog LLM Analytics.", - "version": "1.1.21", + "version": "1.1.22", "author": { "name": "PostHog", "email": "hey@posthog.com", diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json index 653d836..a748b41 100644 --- a/.codex-plugin/plugin.json +++ b/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "posthog", - "version": "1.0.20", + "version": "1.0.21", "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Codex", "author": { "name": "PostHog", diff --git a/.cursor-plugin/plugin.json b/.cursor-plugin/plugin.json index 82f6460..cc92e8c 100644 --- a/.cursor-plugin/plugin.json +++ b/.cursor-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "posthog", "displayName": "PostHog", - "version": "1.1.17", + "version": "1.1.18", "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Cursor", "author": { "name": "PostHog", diff --git a/gemini-extension.json b/gemini-extension.json index 11f168d..a3bccd0 100644 --- a/gemini-extension.json +++ b/gemini-extension.json @@ -1,6 +1,6 @@ { "name": "posthog", - "version": "1.0.19", + "version": "1.0.20", "description": "Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from Gemini CLI", "mcpServers": { "posthog": { diff --git a/skills/.sync-manifest b/skills/.sync-manifest index f377bd6..a2d8096 100644 --- a/skills/.sync-manifest +++ b/skills/.sync-manifest @@ -31,7 +31,9 @@ instrument-product-analytics investigate-metric investigating-replay managing-experiment-lifecycle +managing-path-cleaning-rules managing-subscriptions +planning-user-interviews querying-posthog-data setting-up-a-data-warehouse-source signals diff --git a/skills/managing-path-cleaning-rules/SKILL.md b/skills/managing-path-cleaning-rules/SKILL.md new file mode 100644 index 0000000..33fa475 --- /dev/null +++ b/skills/managing-path-cleaning-rules/SKILL.md @@ -0,0 +1,180 @@ +--- +name: managing-path-cleaning-rules +description: 'Inspects URL paths and proposes, tests, orders, and applies project-level path cleaning rules so dynamic segments (numeric IDs, UUIDs, slugs, dates) collapse into readable aliases. Use when the user says "clean the paths", "normalize URLs", "group similar pages", "too many distinct paths", "/users/123 and /users/456 are the same page", "set up path cleaning", or asks why a Web analytics or Paths breakdown is fragmented across thousands of nearly-identical URLs. Covers regex syntax (re2), alias placeholder convention, rule ordering, the test workflow, and applying rules via the project-settings-update MCP tool.' +--- + +# Managing path cleaning rules + +Path cleaning rules normalize `$pathname` and `$entry_pathname` so that pages +sharing the same template (`/users/123/profile`, `/users/456/profile`, …) collapse +into one row (`/users//profile`) in Web analytics tiles, Paths insights, and +any HogQL query that calls `apply_path_cleaning`. They are the right answer when +a breakdown is fragmented across thousands of near-identical URLs. + +This skill teaches you how to: + +- recognize when path cleaning is the right tool +- inspect real paths to find what needs cleaning +- write `regex` + `alias` rules in re2 syntax with the project's placeholder + convention +- test rules before saving them +- order rules so specific patterns aren't swallowed by generic ones +- apply the rules via MCP + +## Data model + +`Team.path_cleaning_filters` is a JSON list of `PathCleaningFilter` objects: + +```json +{ + "regex": "/users/\\d+/profile", + "alias": "/users//profile", + "order": 0 +} +``` + +- **`regex`** — a [re2](https://github.com/google/re2/wiki/Syntax) pattern. No + need to escape `/`. Anchor with `^` / `$` when you mean it. +- **`alias`** — the literal replacement. Use angle-bracket placeholders + (``, ``, ``, ``) by convention so the cleaned path stays + human-readable. The alias is _not_ a regex template — backreferences are not + supported. +- **`order`** — integer. Rules apply **sequentially** in `order` ascending, + each rule's output feeds the next. + +Application is `replaceRegexpAll(pathname, regex, alias)` per rule, chained. +Source: `posthog/hogql/property.py:613`. + +## Workflow + +### 1. Confirm path cleaning is the right move + +Ask yourself: is the user complaining about cardinality (too many distinct paths +in a chart), or do they want a per-URL drill-down? Path cleaning is for the +former. If they want per-URL data, suggest a property filter on `$pathname` +instead. + +### 2. Inspect the real paths + +Don't guess at patterns — query them. With the `execute-sql` MCP tool: + +```sql +SELECT properties.$pathname AS path, count() AS views +FROM events +WHERE event = '$pageview' + AND timestamp > now() - INTERVAL 7 DAY +GROUP BY path +ORDER BY views DESC +LIMIT 200 +``` + +Scan the result for: + +- numeric IDs: `/users/123`, `/orders/4242` +- UUIDs: `/sessions/8f3c1a3b-…` +- slugs: `/posts/why-i-love-posthog` +- dates: `/archive/2024-09-12` +- locales: `/en-US/`, `/fr-FR/` +- pagination: `?page=3`, `/page/3/` + +### 3. Draft regex + alias + +| Pattern | Example match | `regex` | `alias` | +| ------------------- | ---------------------- | ---------------------------- | ---------------------- | +| Numeric segment | `/users/123/profile` | `/users/\d+/profile` | `/users//profile` | +| UUID v4 | `/sessions/8f3c1a3b-…` | `/sessions/[0-9a-f-]{36}` | `/sessions/` | +| Slug | `/posts/why-posthog` | `/posts/[a-z0-9-]+$` | `/posts/` | +| ISO date | `/archive/2024-09-12` | `/archive/\d{4}-\d{2}-\d{2}` | `/archive/` | +| Locale prefix | `/en-US/about` | `^/[a-z]{2}-[A-Z]{2}/` | `//` | +| Trailing query/page | `/blog?page=3` | `\?page=\d+$` | (empty alias drops it) | + +Anchoring rules of thumb: + +- start the regex with `^` only when the segment must be at the beginning of + the path +- end with `$` to keep a generic rule (e.g. `\d+$`) from matching mid-path + segments + +### 4. Test before saving + +Three options, pick one: + +- **Settings page tester**: `/settings/project#path_cleaning` has a built-in + "test path" input that replays the full ordered chain. +- **Project HogQL** (via `execute-sql`): + + ```sql + SELECT replaceRegexpAll('/users/42/profile', '/users/\d+/profile', '/users//profile') + ``` + + Chain `replaceRegexpAll` calls in the same order the rules will run if you + want to verify multi-rule interaction. + +- **Built-in AI helper**: there is already an `AiRegexHelper` modal accessible + from the rule editor (`Help me with Regex` button) that turns natural + language into a regex. Suggest it to the user when they say "I don't know + regex" — but always validate the output against real paths via the tester. + +### 5. Order rules from most-specific to most-general + +Sequential application means a generic rule placed first will swallow +everything that should have hit a specific rule. + +```text +order=0 /users/me/profile → /users/me/profile (specific, runs first) +order=1 /users/\d+/profile → /users//profile +order=2 /users/[a-z0-9-]+ → /users/ (catch-all, runs last) +``` + +If `/users/[a-z0-9-]+` ran first it would also match `/users/me/profile` and +make the more specific rule unreachable. + +### 6. Apply via MCP + +Use the `project-settings-update` tool with the full list (the field is +replaced, not merged): + +```json +{ + "path_cleaning_filters": [ + { "regex": "/users/me/profile", "alias": "/users/me/profile", "order": 0 }, + { "regex": "/users/\\d+/profile", "alias": "/users//profile", "order": 1 }, + { "regex": "/users/[a-z0-9-]+", "alias": "/users/", "order": 2 } + ] +} +``` + +Always **read the existing rules first** (project settings include +`path_cleaning_filters`) and merge — overwriting silently destroys whatever the +team has already configured. + +## Where the rules apply + +When the user (or a HogQL query) opts in: + +- Web analytics: the **Path cleaning** toggle in the page header + (`PathCleaningToggle.tsx`) +- Paths insights: the path cleaning toggle in the insight filters +- HogQL: any query that calls `apply_path_cleaning(path_expr, team)` + +The rules are stored once per project — they are not insight-scoped. + +## Common pitfalls + +- **Backreferences in `alias` need double-escaping** — ClickHouse's + `replaceRegexpAll` supports `\0` (whole match) and `\1`–`\9` (capture + groups). In a JSON field or SQL string literal the backslash must be + doubled, so use `\\1` in `path_cleaning_filters` / HogQL to get the `\1` + backreference at the ClickHouse layer. +- **Forgetting `$`** — `\d+` without an end anchor matches every numeric run + in any path, so `/blog/2024-09-12/post` becomes + `/blog/--/post` when you only meant to match the year + segment. Use `\d+$` or `\d+(/|$)` depending on intent. +- **Escaping `/`** — re2 does not require it. `\/` works but adds noise. +- **Case sensitivity** — re2 is case-sensitive by default. Use `(?i)` at the + start of the pattern for case-insensitive matching, e.g. `(?i)/users/\d+`. +- **Replacing the whole list** — `path_cleaning_filters` is overwrite, not + append. Always start from the current list. +- **Rules apply globally** — adding a rule can change historical numbers in + every Web analytics / Paths chart that has cleaning enabled. Warn the user + before applying anything destructive. diff --git a/skills/planning-user-interviews/SKILL.md b/skills/planning-user-interviews/SKILL.md new file mode 100644 index 0000000..a8e0b4f --- /dev/null +++ b/skills/planning-user-interviews/SKILL.md @@ -0,0 +1,187 @@ +--- +name: planning-user-interviews +description: 'Plan a user interview topic in PostHog — pick who to target (cohort, emails, or PostHog distinct IDs), draft what to ask about, and prepare the voice-agent context plus a question list. Use when the user asks to "talk to users", "check how users feel about X", "interview some customers", "set up a user interview", "run a user-research call", "find users to ask about Y", or otherwise wants qualitative feedback through a conversation. Walks the user through targeting (cohorts-list, persons-list, or accepting emails / distinct IDs directly), captures the topic, and prompts for agent context and questions before calling user-interview-topics-create. Do NOT trigger when the user is uploading a recorded interview audio file (that''s the separate UserInterview/transcript flow) or only browsing existing topics with user-interview-topics-list.' +--- + +# Planning user interviews + +Use this skill when someone asks to set up a user interview — to talk to customers, check sentiment, or gather qualitative feedback through a voice conversation. The plan is captured as a `UserInterviewTopic` that a voice agent will later run through. + +## What a complete topic needs + +Before calling `user-interview-topics-create`, gather these: + +1. **Who to interview** — at least one of: + - `interviewee_cohort` — an existing cohort ID + - `interviewee_emails` — list of email addresses + - `interviewee_distinct_ids` — list of PostHog distinct IDs +2. **What to ask about** — `topic` (required free text) +3. **How the agent should frame the conversation** — optional `agent_context` (extra system prompt) +4. **The questions to work through** — optional ordered `questions` list + +The API rejects topics with no targeting, so at least one of the three audience fields must be set. They can be combined — a cohort plus a handful of extra emails is fine. + +## Step 1: Clarify intent + +If the request is vague, ask: + +- **Which feature or behavior?** "checkout" might be the button click, the page view, or the payment submission — narrow it down to one event. +- **What do you want to learn?** Why they bounced? What confused them? What alternatives they tried? The goal shapes both the audience and the questions. +- **Which kind of users?** Heavy users (what works), drop-offs (what blocks adoption), at-risk users (what breaks retention), or a mix. + +Skip these questions only when the user has already answered them. + +## Step 2: Pick the audience + +Map what the user said to one of these paths: + +- **They named a cohort** ("our power users", "trial signups last week") — use `cohorts-list` filtered by name to find the cohort, confirm the match, and pass the cohort ID as `interviewee_cohort`. +- **They described the kind of person but no cohort exists** — offer to either create the cohort first (`cohorts-create`) or fall back to finding people by behavior (see below). +- **They gave email addresses or distinct IDs** — accept them directly. Skip the cohort lookup. +- **They described a behavior, not a cohort** ("users who tried checkout but didn't finish", "people who used to use dark mode and stopped") — find them by querying their events (see below). +- **They were vague** ("a few customers", "some power users") — ask which they prefer: + - Pick an existing cohort → `cohorts-list` + - Look up specific persons by name or email → `persons-list` with a search query + - Find users by behavior → see below + - Paste a list of email addresses + +Each email passes through DRF email validation (display-name format `Paul D'Ambra ` is accepted alongside plain `paul@x.com`). + +### Finding users by behavior + +When the user describes who they want to talk to in behavioral terms, find them in the project's own data: + +1. **Find the right event.** Call `read-data-schema` to list events that actually exist in the project. Don't guess event names from training data — PostHog event taxonomies are bespoke. Match the user's description to one or two candidate events; if multiple plausible matches exist, list them and ask which behavior they care about. +2. **Query for users.** Call `execute-sql` with HogQL. Filter by the chosen event over the last 60 days, group by person — prefer `person.properties.email` (directly usable as `interviewee_emails`), fall back to `distinct_id` (for `interviewee_distinct_ids`). Keep both kinds of rows. The aggregates in each template (`event_count`, `last_seen`, `days_since_last_seen`) are what feed Step 5's per-interviewee context. Replace `` with the chosen event, and `` with `person.properties.email` or `distinct_id`: + - **Heavy users** — `SELECT AS id, count() AS event_count, max(timestamp) AS last_seen, dateDiff('day', max(timestamp), now()) AS days_since_last_seen FROM events WHERE event = '' AND timestamp > now() - INTERVAL 60 DAY GROUP BY HAVING count() >= 5 ORDER BY count() DESC LIMIT 20` + - **Drop-offs** (tried once or twice and never came back) — `SELECT AS id, count() AS event_count, max(timestamp) AS last_seen, dateDiff('day', max(timestamp), now()) AS days_since_last_seen FROM events WHERE event = '' AND timestamp > now() - INTERVAL 60 DAY GROUP BY HAVING count() <= 2 AND dateDiff('day', max(timestamp), now()) > 14 ORDER BY count() ASC LIMIT 20` + - **At-risk** (was active, now dormant) — `SELECT AS id, count() AS event_count, max(timestamp) AS last_seen, dateDiff('day', max(timestamp), now()) AS days_since_last_seen FROM events WHERE event = '' AND timestamp > now() - INTERVAL 60 DAY GROUP BY HAVING count() >= 3 AND dateDiff('day', max(timestamp), now()) > 14 ORDER BY days_since_last_seen DESC LIMIT 20` +3. **Build a balanced sample.** Unless the user asked for one specific segment, mixing 5 heavy users + 3 drop-offs + 2 at-risk users yields the most actionable interviews: you learn what works, what blocks adoption, and what breaks retention. Adjust counts to match what the user actually wants. + +Pass the email rows as `interviewee_emails` and the distinct-ID rows as `interviewee_distinct_ids` — both can be set on the same topic. Keep `event_count` and `days_since_last_seen` per person so Step 5 can synthesise context like "used checkout 47 times in last 60 days; last seen 2 days ago". + +## Step 3: Capture the topic + +`topic` is one or two sentences describing what the interview is about. Infer from context where possible — don't ask the user to repeat themselves. + +Example: "ask trial users why they didn't convert" → `topic: "Why trial users didn't convert in the first 14 days"`. + +## Step 4: Prepare the voice agent + +Two fields shape what the agent actually does on the call. **Always ask about both before creating the topic.** + +### Always ask: what questions do they want to ask? + +`questions` is an ordered list the agent works through. Anchors, not a script — the agent will adapt phrasing. Keep them open-ended: + +- ✅ "What made you decide to try PostHog?" +- ❌ "Did you like PostHog?" + +If the user already listed questions in their original request, use those and confirm. Otherwise, ask explicitly: _"What questions do you want the agent to ask?"_ + +If the user can't think of any, suggest 3–5 open-ended questions drawn from the `topic` and offer them for review before creating. + +The field is technically optional in the API, but don't skip it silently — an interview with no questions is rarely useful. + +Question templates by research goal: + +- **Why users dropped off / churned**: + - "Tell me about the last time you tried [feature] — what were you trying to do?" + - "Walk me through what happened step-by-step." + - "What did you expect vs what actually happened?" + - "What made you stop or decide not to continue?" + - "What would need to change for you to use [feature] regularly?" +- **Why heavy users love a feature**: + - "Tell me about how you use [feature] — what problem does it solve for you?" + - "Walk me through your typical workflow." + - "What would you do if [feature] didn't exist?" + - "What almost made you not use it when you first tried?" + - "What's one thing you wish it did differently?" +- **Why someone hasn't tried a feature yet**: + - "Have you noticed [feature] in the product?" + - "What's stopped you from trying it?" + - "What would have to be true for it to be worth trying?" + +### Always offer: extra context to guide the interview + +`agent_context` is optional, but a few sentences here make the conversation dramatically better. Always offer the user the chance to provide it, e.g.: + +> _"Want to give the agent any extra context? Things like tone, what to avoid, or background on the interviewee help guide the conversation. It's optional."_ + +Useful kinds of context: + +- **Tone**: "warm and conversational", "skip pleasantries — this is a 10-minute call" +- **Constraints**: "don't promise feature delivery", "do not discuss pricing" +- **Background the agent should know**: "the user just churned from the Scale plan; be empathetic", "this person tried PostHog 6 months ago and bounced" +- **Persona**: "you are Sam, a PostHog product researcher" + +If the user declines, that's fine — leave `agent_context` empty and continue. + +## Calling user-interview-topics-create + +Once you have the pieces: + +```json +{ + "topic": "Why trial users churned in week 2", + "interviewee_cohort": 42, + "interviewee_emails": ["paul@acme.com"], + "agent_context": "Be warm. The interviewee just churned — don't pitch.", + "questions": [ + "What were you hoping PostHog would help with?", + "Where did you get stuck?", + "What would have made you stay?" + ] +} +``` + +After creation, capture the returned topic ID — you'll need it for Step 5 and for handing off to the voice agent. + +## Step 5: Optionally attach per-interviewee context + +The topic-level `agent_context` applies to every interviewee. If the user knows something specific about individual interviewees that should shape that one conversation, attach it as a per-interviewee row via `user-interview-topics-interviewees-create`. This is optional — most topics won't need it. + +Each row pairs an `interviewee_identifier` (must match one of the emails or distinct IDs in the parent topic's targeting) with an `agent_context` string. At most one row per (topic, interviewee). A user can have zero rows. + +Good per-interviewee context looks like: + +- "uses the replay product but has never used summarization" +- "churned from Scale plan last month — be empathetic, don't pitch" +- "founder, very technical, skip basic product explanations" + +After Step 4 succeeds, ask the user: _"Want to add per-interviewee context? Useful when individual people have very different backgrounds. You can either dictate the rows or paste a CSV."_ + +If you found the audience via behavioral query in Step 2, you already have per-person context (usage counts, dormancy windows). Use it: e.g. `"used checkout 47 times in last 60 days; last seen 2 days ago"` for heavy users, `"tried checkout once 18 days ago, never returned"` for drop-offs. + +### Accepting CSV input + +If the user pastes a CSV, expect two columns: `identifier,context`. Either with or without a header row. Examples: + +```csv +paul@acme.com,uses replay but never summarization +steve@apple.com,founder; very technical; skip product basics +``` + +Or with a header: + +```csv +identifier,context +abc-distinct-id-1,churned from Scale last month — be empathetic +``` + +Parse the CSV, then call `user-interview-topics-interviewees-create` once per row with the captured `topic_id`. Skip blank lines. Quote-escape commas inside the context cell — standard CSV rules. + +If a row's identifier isn't present in the parent topic's `interviewee_emails` or `interviewee_distinct_ids`, warn the user before creating — the voice agent looks up context by exact string match, so a mismatched identifier just gets ignored at runtime. + +## Edge cases + +- **No users match the behavioral query.** Possible reasons: the event isn't firing, the date range is too narrow, or no users have email addresses captured as person properties. Offer to widen the date range, try a different event, or fall back to cohorts / explicit emails. +- **Users matched but few have emails.** PostHog stores whatever the SDK captures. If only a handful of matching users have email addresses on their person profile, surface the count and ask: take the smaller sample, fall back to `interviewee_distinct_ids` (the agent can still reach them via in-app delivery), or skip the behavioral query and let the user paste emails directly. +- **Ambiguous event name.** If `read-data-schema` returns multiple candidates (e.g. `checkout_started`, `checkout_completed`, `checkout_abandoned`), list them with counts and let the user pick the behavior they want to understand. Don't pick silently. +- **User asks to interview only drop-offs (or only one segment).** That works, but flag the tradeoff: interviewing only drop-offs tells you what's broken without telling you what works. Recommend including 2–3 successful users for contrast unless the user has a reason for the narrower sample. + +## What this skill is not for + +- **Uploading a recorded interview** — that's the separate `UserInterview` model (`user_interviews_create` with an audio file). Different flow, different model. +- **Listing existing topics** — `user-interview-topics-list` handles that directly with `search`, `limit`, and `offset`. No skill needed. +- **Analyzing transcripts after the interview** — out of scope here; that lives with the recorded `UserInterview` flow. diff --git a/skills/querying-posthog-data/references/example-error-tracking.md b/skills/querying-posthog-data/references/example-error-tracking.md index 7af4759..b775130 100644 --- a/skills/querying-posthog-data/references/example-error-tracking.md +++ b/skills/querying-posthog-data/references/example-error-tracking.md @@ -10,13 +10,13 @@ SELECT count(DISTINCT uuid) AS occurrences, count(DISTINCT nullIf($session_id, '')) AS sessions, count(DISTINCT coalesce(nullIf(toString(person_id), '00000000-0000-0000-0000-000000000000'), distinct_id)) AS users, - sumForEach(arrayMap(bin -> if(and(greater(timestamp, bin), lessOrEquals(dateDiff('seconds', bin, timestamp), divide(dateDiff('seconds', toDateTime(toDateTime('2026-05-08 01:25:35.268897')), toDateTime(toDateTime('2026-05-09 01:25:35.269594'))), 20))), 1, 0), arrayMap(i -> dateAdd(toDateTime(toDateTime('2026-05-08 01:25:35.268897')), toIntervalSecond(multiply(i, divide(dateDiff('seconds', toDateTime(toDateTime('2026-05-08 01:25:35.268897')), toDateTime(toDateTime('2026-05-09 01:25:35.269594'))), 20)))), range(0, 20)))) AS volumeRange, + sumForEach(arrayMap(bin -> if(and(greater(timestamp, bin), lessOrEquals(dateDiff('seconds', bin, timestamp), divide(dateDiff('seconds', toDateTime(toDateTime('2026-05-13 11:47:44.488619')), toDateTime(toDateTime('2026-05-14 11:47:44.489221'))), 20))), 1, 0), arrayMap(i -> dateAdd(toDateTime(toDateTime('2026-05-13 11:47:44.488619')), toIntervalSecond(multiply(i, divide(dateDiff('seconds', toDateTime(toDateTime('2026-05-13 11:47:44.488619')), toDateTime(toDateTime('2026-05-14 11:47:44.489221'))), 20)))), range(0, 20)))) AS volumeRange, argMin(tuple(uuid, distinct_id, timestamp, properties), timestamp) AS first_event, argMax(properties.$lib, timestamp) AS library FROM events AS e WHERE - and(equals(event, '$exception'), isNotNull(e.issue_id), equals(properties.tag, 'max_ai'), greaterOrEquals(timestamp, toDateTime(toDateTime('2026-05-08 01:25:35.268897'))), lessOrEquals(timestamp, toDateTime(toDateTime('2026-05-09 01:25:35.269594'))), or(greater(position(lower(properties.$exception_types), lower('constant')), 0), greater(position(lower(properties.$exception_values), lower('constant')), 0), greater(position(lower(properties.$exception_sources), lower('constant')), 0), greater(position(lower(properties.$exception_functions), lower('constant')), 0), greater(position(lower(properties.email), lower('constant')), 0), greater(position(lower(person.properties.email), lower('constant')), 0))) + and(equals(event, '$exception'), isNotNull(e.issue_id), equals(properties.tag, 'max_ai'), greaterOrEquals(timestamp, toDateTime(toDateTime('2026-05-13 11:47:44.488619'))), lessOrEquals(timestamp, toDateTime(toDateTime('2026-05-14 11:47:44.489221'))), or(greater(position(lower(properties.$exception_types), lower('constant')), 0), greater(position(lower(properties.$exception_values), lower('constant')), 0), greater(position(lower(properties.$exception_sources), lower('constant')), 0), greater(position(lower(properties.$exception_functions), lower('constant')), 0), greater(position(lower(properties.email), lower('constant')), 0), greater(position(lower(person.properties.email), lower('constant')), 0))) GROUP BY id ORDER BY diff --git a/skills/querying-posthog-data/references/example-logs.md b/skills/querying-posthog-data/references/example-logs.md index 382e8a2..c9c2049 100644 --- a/skills/querying-posthog-data/references/example-logs.md +++ b/skills/querying-posthog-data/references/example-logs.md @@ -23,7 +23,7 @@ SELECT FROM logs WHERE - and(and(greaterOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-09 00:00:00')))), lessOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-10 00:00:00'))))), 1, greaterOrEquals(timestamp, toDateTime('2026-05-08 01:25:38.402844')), indexHint(like(lower(body), '%timeout%')), ilike(toString(body), '%timeout%'), in(severity_text, tuple('warn', 'error', 'fatal'))) + and(and(greaterOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-09 00:00:00')))), lessOrEquals(toStartOfDay(time_bucket), toStartOfDay(assumeNotNull(toDateTime('2025-12-10 00:00:00'))))), 1, greaterOrEquals(timestamp, toDateTime('2026-05-13 11:47:46.901754')), indexHint(like(lower(body), '%timeout%')), ilike(toString(body), '%timeout%'), in(severity_text, tuple('warn', 'error', 'fatal'))) ORDER BY timestamp DESC, uuid DESC diff --git a/skills/querying-posthog-data/references/example-session-replay.md b/skills/querying-posthog-data/references/example-session-replay.md index 86001ce..d0aa533 100644 --- a/skills/querying-posthog-data/references/example-session-replay.md +++ b/skills/querying-posthog-data/references/example-session-replay.md @@ -19,17 +19,17 @@ SELECT sum(s.console_error_count) AS console_error_count, max(s.retention_period_days) AS retention_period_days, plus(dateTrunc('DAY', start_time), toIntervalDay(coalesce(retention_period_days, 30))) AS expiry_time, - date_diff('DAY', toDateTime('2026-05-09 01:25:39.591112'), expiry_time) AS recording_ttl, - greaterOrEquals(max(s._timestamp), toDateTime('2026-05-09 01:20:39.590287')) AS ongoing, + date_diff('DAY', toDateTime('2026-05-14 11:47:47.864519'), expiry_time) AS recording_ttl, + greaterOrEquals(max(s._timestamp), toDateTime('2026-05-14 11:42:47.863619')) AS ongoing, round(multiply(divide(plus(plus(plus(divide(sum(s.active_milliseconds), 1000), sum(s.click_count)), sum(s.keypress_count)), sum(s.console_error_count)), plus(plus(plus(plus(sum(s.mouse_activity_count), dateDiff('SECOND', start_time, end_time)), sum(s.console_error_count)), sum(s.console_log_count)), sum(s.console_warn_count))), 100), 2) AS activity_score FROM raw_session_replay_events AS s WHERE - and(greaterOrEquals(s.min_first_timestamp, toDateTime('2026-05-06 00:00:00.000000')), lessOrEquals(s.min_first_timestamp, toDateTime('2026-05-09 01:25:39.590452'))) + and(greaterOrEquals(s.min_first_timestamp, toDateTime('2026-05-11 00:00:00.000000')), lessOrEquals(s.min_first_timestamp, toDateTime('2026-05-14 11:47:47.863790'))) GROUP BY session_id HAVING - and(greaterOrEquals(expiry_time, toDateTime('2026-05-09 01:25:39.591005')), equals(max(s.is_deleted), 0), greater(active_seconds, 5.0)) + and(greaterOrEquals(expiry_time, toDateTime('2026-05-14 11:47:47.864340')), equals(max(s.is_deleted), 0), greater(active_seconds, 5.0)) ORDER BY start_time DESC, session_id DESC diff --git a/skills/querying-posthog-data/references/example-sessions.md b/skills/querying-posthog-data/references/example-sessions.md index c27d03d..313d0a0 100644 --- a/skills/querying-posthog-data/references/example-sessions.md +++ b/skills/querying-posthog-data/references/example-sessions.md @@ -13,7 +13,7 @@ SELECT FROM sessions WHERE - and(less($start_timestamp, toDateTime('2026-05-09 01:25:44.964556')), greater($start_timestamp, toDateTime('2026-05-08 01:25:39.965353'))) + and(less($start_timestamp, toDateTime('2026-05-14 11:47:53.227730')), greater($start_timestamp, toDateTime('2026-05-13 11:47:48.228426'))) ORDER BY $start_timestamp DESC LIMIT 50000