agentleFS
me2reshme2resh/apexyard/.claude/skills/analytics-audit/SKILL.md

analytics-audit

Skill542 starsChanged 11 days agoMITView on GitHub

Analytics audit — SDK config, event naming, funnel completeness, dashboards. Deep-dive for /launch-check analytics.

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    After printing the findings table, persist via the shared audit-history lib so the analytics trend across runs becomes legible.

    line 74

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Writing: read docs/skills/shared/writing-rule.md before you write a durable artifact.

/analytics-audit — Event Taxonomy & Coverage

Deep-dive analytics analysis. Checks that tracking is configured, events follow a naming convention, key user funnels are instrumented, and dashboards exist. Invoke when /launch-check's analytics row shows WARN or FAIL.

Process

Step 1: SDK detection

Grep for analytics SDK initialization:

  • Google Analytics / GA4: gtag, G-, UA-, analytics.js, @google-analytics
  • Mixpanel: mixpanel.init, @mixpanel
  • Amplitude: amplitude.init, @amplitude
  • PostHog: posthog.init, posthog-js
  • Plausible: plausible.io, data-domain
  • Segment: analytics.load, @segment
  • Custom: any track(, capture(, logEvent( patterns

Step 2: Event inventory

Find all tracking calls in the codebase and list them:

  • Event name
  • Where it fires (file + component/handler)
  • Properties sent with the event
  • Whether it has a consistent naming convention (snake_case, camelCase, verb_noun)

Step 3: Funnel coverage

Identify the core user funnels and check if each step is tracked:

FunnelSteps to check
Signuppage_view → form_start → form_submit → signup_complete
Activationfirst_login → key_action_completed → aha_moment
Purchase (if applicable)pricing_view → plan_select → checkout_start → payment_complete
Retentionreturn_visit → feature_usage → session_duration

Step 4: Output

ANALYTICS AUDIT — <project> @ <sha>

SDK: <GA4 / Mixpanel / PostHog / none>
Total events found: <N>
Naming convention: <consistent / inconsistent / none>

| # | Area | Status | Finding |
|----|------|--------|---------|
| E1 | SDK | PASS | GA4 initialized in _app.tsx |
| E2 | Events | WARN | 8 events found, 3 use camelCase, 5 use snake_case |
| E3 | Signup funnel | FAIL | form_submit tracked but signup_complete missing |
| E4 | Dashboard | WARN | No dashboard URL found in config or docs |

Event inventory:
  signup_start (pages/signup.tsx:42)
  form_submit (components/SignupForm.tsx:89)
  page_view (auto, GA4 enhanced measurement)
  ...

Persist the run + render trend

After printing the findings table, persist via the shared audit-history lib so the analytics trend across runs becomes legible. See docs/agdr/AgDR-0019-audit-artefact-persistence.md.

Resolve project name + score + verdict

<project-name> from apexyard.projects.yaml (or basename + /handover reminder if unregistered).

Score: score = max(0, 100 - 25*critical - 10*high - 3*medium - 1*low). Verdict by worst-severity: critical/high → fail, medium → conditional, low/none → pass.

Persist + render

source "$(git rev-parse --show-toplevel)/.claude/hooks/_lib-audit-history.sh"

# Lowercase severity in the payload — the lib expects critical/high/medium/low/info.
payload=$(mktemp); cat > "$payload" <<'EOF'
{
  "schema_version": 1,
  "findings": [
    {"id": "E2", "severity": "medium", "status": "open", "summary": "Mixed event-naming conventions (snake_case + camelCase + Title Case)"},
    {"id": "E3", "severity": "high",   "status": "open", "summary": "signup_complete event missing — can't measure conversion"},
    {"id": "E4", "severity": "medium", "status": "open", "summary": "No dashboard URL found in config or docs"}
  ]
}
EOF

# Body: per templates/audits/analytics-audit.md
body=$(mktemp); cat > "$body" <<'EOF'
... (filled-in body — findings table + Event taxonomy gap + Recommended priority) ...
EOF

ts=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
audit_run_persist "<project-name>" "analytics-audit" "$ts" "fail" 60 "$body" < "$payload"
rm -f "$payload" "$body"

audit_render_trend "<project-name>" "analytics-audit" 5

Opt-in commit

touch projects/<name>/audits/analytics-audit/.audit-history-tracked

Rules

  1. Auto-PASS for non-user-facing projects. CLIs, libraries, and internal tools don't need analytics.
  2. Don't prescribe a specific SDK. Note what's configured, check coverage, suggest improvements.
  3. Flag inconsistent naming — mixed conventions make dashboard queries painful.
  4. Privacy-aware. Flag if PII (email, name, IP) is being sent in event properties.
  5. Always persist via the lib. The persist step runs regardless of opt-in commit state.
  6. Severity vocabulary in the JSON is lowercase. The lib expects critical/high/medium/low/info.

Part of ApexYard — multi-project SDLC framework for Claude Code · MIT.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.