Suede Analytics

Suede Analytics Tracking

Use this Suede measurement playbook to build tracking that supports auditable marketing and product decisions.

Initial Assessment

Check for product marketing context first: If .agents/product-marketing.md exists (or .claude/product-marketing.md, or the legacy product-marketing-context.md filename, in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

Before implementing tracking, understand:

1. Business Context - What decisions will this data inform? What are key conversions?
2. Current State - What tracking exists? What tools are in use?
3. Technical Context - What's the tech stack? Any privacy/compliance requirements?

Core Principles

1. Track for Decisions, Not Data

• Every event should inform a decision
• Avoid vanity metrics
• Quality > quantity of events

2. Start with the Questions

• What do you need to know?
• What actions will you take based on this data?
• Work backwards to what you need to track

3. Name Things Consistently

• Naming conventions matter
• Establish patterns before implementing
• Document everything

4. Maintain Data Quality

• Validate implementation
• Monitor for issues
• Clean data > more data

Tracking Plan Framework

Structure

Event Name | Category | Properties | Trigger | Notes
---------- | -------- | ---------- | ------- | -----

Event Types

For comprehensive event lists: See references/event-library.md

Event Naming Conventions

Recommended Format: Object-Action

signup_completed
button_clicked
form_submitted
article_read
checkout_payment_completed

Best Practices

• Lowercase with underscores
• Be specific: cta_hero_clicked vs. button_clicked
• Include context in properties, not event name
• Avoid spaces and special characters
• Document decisions

Essential Events

Marketing Site

Product/App

For full event library by business type: See references/event-library.md

Event Properties

Standard Properties

Best Practices

• Use consistent property names
• Include relevant context
• Don't duplicate automatic properties
• Avoid PII in properties

GA4 Implementation

Quick Setup

1. Create GA4 property and data stream
2. Install gtag.js or GTM
3. Enable enhanced measurement
4. Configure custom events
5. Mark conversions in Admin

Custom Event Example

gtag('event', 'signup_completed', {
  'method': 'email',
  'plan': 'free'
});

For detailed GA4 implementation: See references/ga4-implementation.md

Google Tag Manager

Container Structure

Data Layer Pattern

dataLayer.push({
  'event': 'form_submitted',
  'form_name': 'contact',
  'form_location': 'footer'
});

For detailed GTM implementation: See references/gtm-implementation.md

UTM Parameter Strategy

Standard Parameters

Naming Conventions

• Lowercase everything
• Use underscores or hyphens consistently
• Be specific but concise: blog_footer_cta, not cta1
• Document all UTMs in a spreadsheet

Debugging and Validation

Testing Tools

Validation Checklist

• Events firing on correct triggers
• Property values populating correctly
• No duplicate events
• Works across browsers and mobile
• Conversions recorded correctly
• No PII leaking

Common Issues

Privacy and Compliance

Privacy, consent, retention, deletion, and identifier rules vary by jurisdiction, audience, data type, contract, and platform configuration. Do not treat this skill as legal advice or declare a universal consent rule.

Before implementation:

1. Identify the actual markets, audience age, data categories, vendors, purposes, and data flows in scope.
2. Review current official regulator and platform requirements for those jurisdictions and configurations; obtain qualified privacy or legal review when the requirement is unclear or material.
3. Document the approved lawful basis or consent state, retention and deletion behavior, access controls, and prohibited properties.
4. Collect only approved data, avoid direct personal identifiers unless the reviewed design expressly allows them, and test both allowed and denied consent paths.

Output Format

Tracking Plan Document

# [Site/Product] Tracking Plan

## Overview
- Tools: GA4, GTM
- Last updated: [Date]

## Events

| Event Name | Description | Properties | Trigger |
|------------|-------------|------------|---------|
| signup_completed | User completes signup | method, plan | Success page |

## Custom Dimensions

| Name | Scope | Parameter |
|------|-------|-----------|
| user_type | User | user_type |

## Conversions

| Conversion | Event | Counting |
|------------|-------|----------|
| Signup | signup_completed | Once per session |

Task-Specific Questions

1. What tools are you using (GA4, Mixpanel, etc.)?
2. What key actions do you want to track?
3. What decisions will this data inform?
4. Who implements - dev team or marketing?
5. Are there privacy/consent requirements?
6. What's already tracked?

Tool Integrations

This pack does not ship analytics connectors. Use the user's authorized property UI, debugger, export, API, or installed connector and verify current official documentation before constructing a call.

Boundaries

• Do not claim an event, conversion, consent state, or attribution path works until a current debug or readback proves it.
• Do not mutate production tags, properties, destinations, or consent settings without explicit authorization and a rollback plan.
• Do not collect secrets, direct personal identifiers, or sensitive traits merely because a tool permits them.
• Do not decide business success from a single dashboard number; state the metric definition, window, denominator, and exclusions.

Routing

• Need experiment design or result interpretation -> use suede-ab-testing.
• Need paid-campaign decisions -> use suede-ads.
• Need pipeline and CRM attribution -> use suede-revops.
• Need organic visibility diagnosis -> use suede-seo-audit.
• From those skills, route instrumentation plans and firing verification back to suede-analytics.