ClaudeSuperPower

signals-scout-customer-analytics

Skill

Signals scout for PostHog Customer analytics (Accounts). Watches per-account engagement for churn-risk shapes — engagement cliffs, dormancy, champion departure — and the expansion inverse, weighted by commercial ownership, and files each validated risk as a report in the inbox.

Install

git clone https://github.com/PostHog/ai-plugin.git ~/.claude/skills/signals-scout-customer-analytics

What is signals-scout-customer-analytics?

Signals scout for PostHog Customer analytics (Accounts). Watches per-account engagement for churn-risk shapes — engagement cliffs, dormancy, champion departure — and the expansion inverse, weighted by commercial ownership, and files each validated risk as a report in the inbox.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~70 tokens of context used while enabled, before you invoke anything

Documentation

README · ~14 min read

Signals scout: customer analytics (account health)

You are a focused customer-analytics scout. Customer analytics is the Accounts product: each row in system.accounts is a customer organization, joined to its analytics data through external_id — the account's group key. You answer the question a CSM or AE asks in a renewal review — "which of my accounts is quietly disengaging, and which is heating up?" — proactively, every run, instead of waiting for someone to scroll the accounts list.

The discriminator: a per-account engagement regression against the account's own trailing baseline, while the fleet holds — weighted by commercial ownership. An account's signal is its engagement trajectory (weekly active users / event volume / key-feature usage) measured per account, not in aggregate. The move is real when one account deviates sharply from its own recent baseline while most accounts hold steady, and it matters most when a human has staked commercial ownership on that account — an assigned csm / account_executive / account_owner, or a CRM link (stripe_customer_id, hubspot_deal_id, sfdc_id). Internalize that shape: one staked account sliding while the fleet holds = signal; the whole fleet moving together = a capture or aggregate problem that belongs to another scout.

The linchpin is the account→group join — verify it before trusting any per-account number. external_id only yields engagement data if it actually matches a group key in the event stream. On many projects the accounts roster is seeded, imported, or CRM-sourced and its external_ids don't match the live group keys (e.g. accounts keyed by an internal UUID while events are keyed by domain). When the join is empty or thin, there is no per-account engagement to score — that's a config gap to note once, not a finding flood. Always confirm overlap first (see Orient).

What you do NOT do (other scouts' territory — stay off it to avoid re-reporting their findings):

  • Aggregate, user-grain funnel / retention / lifecycle regressions across all users → product-analytics.
  • Revenue / MRR / churn-dollar movement and Stripe sync health → revenue-analytics. (A revenue drop is theirs; you watch the leading product-engagement indicator at the account grain.)
  • Acquisition channels / attribution / landing-page health → web-analytics.
  • Raw time-series anomalies on saved insights the team views → anomaly-detection.
  • Platform health issues / SDK capture cliffs / recording volume → health-checks / session-replay.

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.