triaging-web-analytics-support

작성자: posthog

웹 분석 지원 티켓을 처음부터 끝까지 분류합니다: 인앱 대화 제품과 해당 Zendesk 미러에서 열린 티켓을 열거하고, 각각을 다음 중 하나로 분류합니다…

npx skills add https://github.com/posthog/posthog --skill triaging-web-analytics-support

Triaging web analytics support tickets

The job: turn a pile of open support tickets into (a) reply drafts grounded in code or data, and (b) draft PRs for real bugs. Most reported "bugs" are explainable semantics; most real bugs show up in error tracking or raw data before they show up in the code. Diagnose before writing code, and always determine which layer a symptom lives in before proposing a fix.

1. Enumerate the queue

Tickets live in the conversations product and are queryable via the PostHog MCP execute-sql tool against system.support_tickets (project 2, US). Zendesk mirrors carry full comment history in the data warehouse. See references/ticket-queries.md for ready-to-run SQL: open-ticket scans, keyword filters, full Zendesk comment extraction (the child_events JSON pattern), and resolving a requester email to an org/team across US and EU regions.

Slack channel #support-web-analytics mirrors new Zendesk tickets; the in-app ticket link in each message carries the conversations UUID.

2. Classify the shape, then run its playbook

Detailed walk-throughs with worked examples are in references/diagnostic-playbooks.md. The shapes:

ShapeTrigger phrasesFirst move
Frontend crash"everything crashes", exception ID, stack traceError tracking lookup; sourcemapped frames name the file. Check both US and EU projects
Two numbers don't match"two different bounce rates", "insight X disagrees with tile Y"Semantics first, not code: event-level vs session-entry scoping, "landing vs containing", any-event vs entry-event filters explain most of these
Count drop over time"pageviews declined", "tracking loss"Layer split: raw stored counts vs query-side exclusion. $pageview vs $pageleave ratio, UA segmentation, SDK version pin. Bot-shaped traffic disappearing is common and is not a PostHog bug
Tracker not loading / undercounts competitor"numbers lower than ", GTM, consent, ad blockersRuntime loading audit with Playwright against their live site: load method, first-request timing, blocklist simulation. See references/loading-audit.md
Ad-platform integration error"can't re-add source", OAuth errors, "no conversions"Source re-creation paths, OAuth failure modes (for example Microsoft AADSTS650052), attribution join keys (exact campaign name + normalized source, both UTMs required for the fallback)
Channel type misclassification"shows as Direct", "wrong channel"posthog/models/channel_type/channel_definitions.json + the decision tree in posthog/hogql/database/schema/channel_type.py; unknown source + stripped referrer falls through to Direct

Two cross-cutting rules:

  • Determine the layer before the fix. Capture → ingestion → stored events → query-time classification → UI. A drop in raw count() can't be caused by query-time bot exclusion; a classification change can't alter stored counts. State which layer the evidence points at.
  • Check for prior art before building. Search open issues/PRs and the channel history; several recurring asks (self-referral exclusion, AI channel type, OAuth error surfacing) have open issues with context that changes the right response.

3. Produce artifacts

  • Reply drafts: ground every claim in a file:line, a query result, or a doc link. Offer the customer the aligned filter/property instead of only explaining why they're "wrong" (for example: session $entry_utm_campaign instead of event utm_campaign).
  • Fix PRs: one worktree + branch per fix, conventional commit, draft PR using the repo template. Public-repo safety: describe bugs generically; never include customer names, Zendesk numbers, or customer traffic volumes. Slack/ticket links behind auth are acceptable as origin context.
  • Session note: keep a running triage note (.notes/) with one section per ticket and an explicit "action left" marker per ticket, so a human can pick up the queue.

4. Verification tools

  • Runtime loading audits and traffic simulation: references/loading-audit.md.
  • Production query-side checks (per-team event series, UA splits, ingestion warnings): the querying-production-databases-via-metabase skill covers prod-us and prod-eu access.
  • Error tracking: MCP query-error-tracking-issues-list / query-error-tracking-issue-events with verbosity: stack gives sourcemapped frames.

posthog의 다른 스킬

error-tracking-hono
posthog
PostHog 오류 추적 for Hono
tuning-incremental-sync-config
posthog
동기화의 구성은 ExternalDataSchema에 저장되며, external-data-schemas-partial-update를 통해 언제든지 변경할 수 있습니다. 대부분의 변경은 비파괴적이며(다음 동기화에 적용됨), 일부 변경(sync_type 전환, 기본 키 변경)은 동기화된 데이터 손상을 방지하기 위해 신중한 처리가 필요합니다.
playwright-test
posthog
플레이라이트 테스트를 작성하고, 실행이 잘 되며, 불안정하지 않도록 하세요.
error-tracking-ruby
posthog
PostHog Ruby 오류 추적
authoring-log-alerts
posthog
PostHog 프로젝트의 서비스에 유용하고 노이즈가 적은 로그 알림을 작성합니다. 사용자가 로그에 대한 알림 설정을 요청하거나 추가해야 할 알림을 제안할 때 사용하세요.
making-scenes-tab-aware
posthog
Guides converting PostHog frontend scenes to be tab aware for internal scene tabs. Use when adding or refactoring a `SceneExport` scene, fixing state leaking…
posthog-survey-creator
posthog
PostHog에서 안내 대화를 통해 설문조사를 생성하고 구성합니다. 사용자가 설문조사를 만들거나, 사용자 피드백을 수집하거나, 실행하려 할 때 이 스킬을 사용하세요.
authoring-scouts
posthog
PostHog Signals 스카우트를 작성, 편집 및 조정하는 방법 — 프로젝트를 스캔하고 Signals 인박스에 보고서를 작성하는 예약된 에이전트입니다. 사용자가…