📝 Analytics Event Taxonomy — Naming Standards That Scale

Event Taxonomy: B2B SaaS Marketing Automation, 400 Events Cleanup

An event taxonomy produces structured naming + property + governance standards. Your current state (400 inconsistent events, no governance, duplicate tracking) is classic legacy chaos. This 12-week rebuild produces clean taxonomy with 80-120 curated events, proper schemas, and ongoing governance.

Core Principles + Conventions

Naming Pattern: 'Object Action'

Use 'Noun Verb' where verb is past tense for completed actions:

Examples:

• Email Sent (not sendEmail, email_send)
• Campaign Created (not create_campaign)
• Workflow Published (not publishWorkflow)
• Signup Completed (not userSignedUp)

Why this convention:

• Scannable in Mixpanel/Amplitude interface
• Present-tense for state events ('Session Active', 'Playing Video')
• Past-tense for actions
• Reads naturally in English

Casing: Title Case With Space

• 'Campaign Created' — spaces between words, Title Case
• NOT 'campaign_created' (too engineering-y)
• NOT 'CampaignCreated' (camelCase is for code, not event names)

Properties: snake_case

• campaign_type: string
• subscriber_count: integer
• is_scheduled: boolean
• revenue_impacted: float

Property Values: Standardized

• Strings: lowercase, underscore-separated for multi-word

- ✓ 'email_campaign' ✗ 'Email Campaign'

• Enums: pre-defined list
• Booleans: true/false (not 'yes'/'no')
• Numbers: appropriate type (integer vs. float)

Timestamps: ISO 8601

• scheduled_at: '2026-04-15T10:30:00Z'
• Always UTC
• Timezone handled at display, not storage

Event Hierarchy

Organize by feature + lifecycle:

Onboarding Events

• Signup Started
• Signup Completed
• Email Verified
• Onboarding Started
• Onboarding Step Completed
• Onboarding Completed

Campaign Events

• Campaign Created
• Campaign Edited
• Campaign Scheduled
• Campaign Sent
• Campaign Paused
• Campaign Deleted

Audience Events

• Segment Created
• Segment Applied
• Segment Updated
• Contact Imported
• Contact Deleted

Workflow Events

• Workflow Created
• Workflow Step Added
• Workflow Published
• Workflow Paused
• Workflow Completed
• Workflow Error Occurred

Analytics Events

• Report Viewed
• Report Shared
• Report Exported
• Dashboard Created

Account Events

• Plan Upgraded
• Plan Downgraded
• Billing Issue Occurred
• Trial Ended

Integration Events

• Integration Connected
• Integration Disconnected
• Integration Failed

Lifecycle Meta-Events

• Session Started
• Session Ended
• User Invited
• User Activated

Total events (curated): ~80-120. Down from 400.

Common Events (Full Specifications)

Event: Campaign Created

Description: User creates a new marketing campaign.

Trigger: User clicks 'Create Campaign' in app + completes required fields.

Properties:

Owner: Product Manager — Email Campaigns

Metrics this supports:

• Activation: % of users who create first campaign within 7 days
• Engagement: campaigns created per week per user
• Feature adoption: template usage rate

Event: Workflow Published

Description: User publishes a workflow automation.

Properties:

Owner: Product Manager — Automation

Property Standards

Always-Required Properties (Global)

Every event has:

• event_id: unique identifier (auto-generated)
• user_id: authenticated user ID
• company_id: customer account ID (for B2B)
• timestamp: ISO 8601 UTC
• plan_tier: current subscription plan
• session_id: current session
• source_platform: web/ios/android/api

Conditionally-Required Properties

For events involving:

• Content: content_id + content_type
• Actions on other users: target_user_id
• Financial: revenue_amount + currency_code
• Location: country + region (when relevant)

Property Naming

• id suffix for identifiers: user_id, campaign_id
• count suffix for counts: subscriber_count
• is_* or has_* for booleans: is_scheduled, has_attachments
• Consistent across events: plan_tier not 'subscription_level'

Governance Framework

Roles

Analytics Committee (meets monthly):

• Head of Product (chair)
• Engineering lead
• Data analyst
• Product managers (rotating)

Event Owner (per event):

• Typically feature PM
• Responsible for: definition, property schema, deprecation

Process

New event request:

1. PM submits event request via template (name, purpose, properties, why needed)

2. Review in weekly taxonomy meeting (or async approval)

3. Approve or adjust

4. Engineering implements (must match approved spec)

5. QA verifies in staging

6. Production release + monitoring

Event deprecation:

1. Event unused for 90 days → auto-flag

2. Owner reviews: still needed?

3. If yes → continue. If no → deprecate.

4. Deprecation notice (2 months) before removal.

5. Archive documentation.

Quarterly review:

• All events reviewed for usage + relevance
• Duplicates identified + consolidated
• Properties audited for consistency
• Taxonomy document updated

Documentation

Single source of truth: Notion page or internal wiki, version-controlled.

Per-event entry:

• Name
• Description
• Trigger
• Properties (with types)
• Owner
• Created date
• Status (active/deprecated)
• Last reviewed date
• Related events

Implementation Plan (12-Week Rebuild)

Week 1-3: Audit + Design

• Inventory all 400 current events
• Classify: keep / consolidate / deprecate
• Design target ~100 events taxonomy
• Write full specifications

Week 4-6: Documentation + Approval

• Create event catalog
• Stakeholder reviews (PMs, eng, analysts)
• Final approval
• Schema documentation in Notion

Week 7-9: Engineering Implementation

• Update tracking code to match new taxonomy
• Test in staging
• Parallel run (old + new events) for 2 weeks
• Verify data integrity

Week 10-12: Migration + Cleanup

• Switch production to new taxonomy
• Deprecate old events (90-day retention for historical)
• Update dashboards + analyses
• Train team on new taxonomy
• Establish governance cadence

Post-launch: quarterly review + governance ongoing.

Schema Document Template

Event name: [Object Action]

Description: [1-2 sentences on what triggers it + why tracked]

Trigger: [Specific user action]

Properties:

required:
  - property_name (type): description
  - another_property (type): description

optional:
  - optional_prop (type): description

Owner: [Name + role]

Metrics supported:

• [What metrics this event enables]

Related events:

• [Events in same flow]

Status: active / deprecated / planned

Created: [date]

Last reviewed: [date]

Key Takeaways

• Cut from 400 inconsistent events to 80-120 curated events with proper schemas. Consolidation + deprecation + standards = clean analytics foundation.
• Naming convention: 'Object Action' in Title Case (e.g., 'Campaign Created'). Properties in snake_case. Past tense for actions, present for states.
• Every event has owner (typically PM) + schema (properties with types) + documentation. Single source of truth in Notion, version-controlled.
• Governance: monthly Analytics Committee review, 90-day auto-deprecation for unused events, quarterly full audit. Prevents re-slide into chaos.
• 12-week migration: Week 1-3 design, Week 4-6 documentation, Week 7-9 engineering, Week 10-12 migration. Parallel-run period ensures data continuity.