agentsclimarketplace

Analytics instrumentation

Skill sairam0424/MindForge/.mindforge/skills/analytics-instrumentation

MindForge: The Enterprise Agentic Framework for Claude Code & Antigravity. High-performance autonomous execution, wave-parallelism, and multi-tier governance for production-grade AI engineering.

Install
npx -y skills add sairam0424/MindForge --skill analytics-instrumentation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.6 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Skill — Analytics Instrumentation (Privacy-Aware Event Architecture)

When this skill activates

When designing event tracking systems, building data layers, creating tracking plans, instrumenting user journeys, or establishing analytics governance. Use for any task that involves measuring user behavior in a structured, privacy-respecting way.

Core principle: Track intent, not surveillance — measure what users DO to improve what you BUILD, never to manipulate or over-collect.

Mandatory actions when this skill is active

Event Taxonomy Design

  1. Naming convention (object_action format):

    Format: [object]_[action]
    Examples:
    - button_clicked
    - form_submitted
    - page_viewed
    - cart_item_added
    - search_performed
    - error_encountered
    

    Rules:

    • Always past tense for the action (clicked, not click)
    • Lowercase with underscores (snake_case)
    • Object first, action second (noun_verb)
    • Maximum 3 words total (object can be compound: cart_item_added)
    • Never include PII in event names
    • Never include dynamic values in event names (no "product_12345_viewed")
  2. Event property schema:

    {
      "event": "button_clicked",
      "properties": {
        "button_id": "string (required) — unique identifier",
        "button_text": "string (required) — visible label",
        "page_path": "string (required) — current URL path",
        "section": "string (optional) — page section containing button",
        "variant": "string (optional) — A/B test variant if applicable"
      },
      "context": {
        "timestamp": "ISO-8601 (auto)",
        "session_id": "string (auto)",
        "device_type": "string (auto)",
        "viewport_width": "number (auto)"
      }
    }
    

    Rules:

    • Separate event-specific properties from auto-collected context
    • Mark each property as required or optional
    • Include data type and brief description
    • Never include PII in properties without explicit consent flag

Tracking Plan

  1. Tracking plan structure (source of truth):

    | Event Name       | Trigger                    | Properties         | Owner    | Status       |
    |------------------|----------------------------|--------------------|----------|--------------|
    | page_viewed      | Page load complete         | page_path, title   | @fe-team | Implemented  |
    | button_clicked   | Any tracked button click   | button_id, text    | @fe-team | In Review    |
    | form_submitted   | Form submission success    | form_id, fields    | @fe-team | Planned      |
    

    Rules:

    • Every event MUST have an owner (team or individual)
    • Status lifecycle: Planned → In Review → Implemented → Validated → Deprecated
    • Review tracking plan quarterly: deprecate unused events
    • New events require tracking plan entry BEFORE implementation

Data Layer Architecture

  1. Data layer implementation:

    // Structured data layer (consumed by analytics tools)
    window.dataLayer = window.dataLayer || [];
    
    // Push events with standard structure
    window.dataLayer.push({
      event: 'button_clicked',
      properties: {
        button_id: 'cta-signup-hero',
        button_text: 'Start Free Trial',
        page_path: '/pricing'
      }
    });
    

    Rules:

    • Data layer is the SINGLE source of truth (analytics tools consume it, don't instrument directly)
    • Never push to data layer before consent is granted
    • Validate data layer pushes against schema in CI
    • Data layer must be populated server-side for critical events (don't rely solely on client JS)

Privacy-Aware Analytics

  1. Privacy requirements (non-negotiable):

    • Obtain consent BEFORE any tracking fires (banner/modal with granular choices)
    • Honor Do Not Track (DNT) header — respect user preference
    • Anonymize by default: no full IP, no fingerprinting, no cross-site tracking
    • Data retention: define maximum retention per event type (default 13 months for GDPR)
    • Right to deletion: ensure analytics pipeline can purge by user ID
    • Consent categories: necessary (no consent needed) | analytics (consent required) | marketing (separate consent)
  2. Consent implementation:

    // Only track if user has consented to analytics category
    if (consentManager.hasConsent('analytics')) {
      dataLayer.push({ event: 'page_viewed', properties: {...} });
    }
    

Funnel Measurement

  1. Funnel definition:

    Funnel: [name]
    Steps:
    1. page_viewed (page_path = '/pricing')     → Entry
    2. button_clicked (button_id = 'select-plan') → Intent
    3. form_submitted (form_id = 'payment')     → Commitment
    4. purchase_completed                        → Conversion
    
    Metrics per step:
    - Volume (count)
    - Conversion rate (step N / step N-1)
    - Drop-off rate (1 - conversion rate)
    - Time between steps (median, p95)
    

    Rules:

    • Define funnels for every critical user journey
    • Segment funnels by: device, acquisition source, user cohort, experiment variant
    • Alert on significant drop-off changes (>10% deviation from baseline)
    • Funnel steps must use the same event taxonomy

Analytics Governance

  1. Governance processes:
    • Schema validation in CI: every new event must match the tracking plan schema
    • Unused event cleanup: quarterly audit, deprecate events with <100 fires/month
    • Naming review: new events require team lead approval (prevents drift)
    • Data quality monitoring: alert on sudden volume spikes/drops (instrumentation bugs)
    • Documentation: tracking plan is the living doc, not code comments

Self-check before task completion

Before marking a task done when this skill was active:

  • Did I follow the object_action naming convention?
  • Is every event documented in the tracking plan with owner and status?
  • Does the data layer implementation gate on user consent?
  • Are PII fields excluded from event properties (or flagged for special handling)?
  • Did I define funnels for critical user journeys with per-step metrics?
  • Is there a governance process for event lifecycle management?
  • Can the schema be validated in CI (preventing undocumented events)?
  • Is data retention defined and compliant with privacy regulations?

Gives 1 of the 12 instructions most analytics metrics skills give in ~1.4k tokens

Counted across 368 of the 369 authors here whose files we hold, read 2026-08-06

  • read product marketing context before asking questionsin 18 of 368, across 12 files
  • use lowercase with underscores for event namesin 16 of 368, across 6 files
  • track events for decisions not vanity metricsin 15 of 368, across 5 files
  • use object-action format for event nameshere, and in 15 of 368, across 8 files
  • produce a tracking plan documentin 14 of 368, across 4 files
  • Call RUBE_SEARCH_TOOLS first to get current schemasin 13 of 368, across 2 files
  • establish consistent event naming conventions before implementingin 10 of 368, across 4 files
  • Verify dimension and metric compatibility before reportingin 9 of 368, across 2 files
  • Encrypt data at rest and in transitin 9 of 368, across 3 files
  • use snake_case for event namesin 9 of 368, across 5 files
  • monitor technical health during the testin 9 of 368, across 5 files
  • use consistent property namesin 8 of 368, across 4 files

Said here and by no other author read

  • mark each event property as required or optional
  • create a tracking plan entry before implementation
  • populate the data layer server-side for critical events
  • validate data layer pushes against schema in CI
  • obtain consent before any tracking fires
  • honor Do Not Track header

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.