taxonomy

Taxonomy Generation & Data Auditing

When to Use

• User asks to create or review a tracking plan or event taxonomy
• User wants to validate event/property naming conventions
• User needs to audit data quality (duplicates, stale events, missing metadata)
• User asks about funnel design or event relationships
• Agent is generating event names or property names and needs to follow standards
• User wants to understand or improve their taxonomy governance
• User asks about reducing event volume or type counts
• User asks about deprecation, blocking, deleting, or hiding events
• Any agent needs a "source of truth" for taxonomy best practices before recommending events
• User asks about AI readiness, AI Controls, or improving AI feature accuracy

---

Layer 1: Foundational Concepts

Core Philosophy

Six principles govern all taxonomy work:

1. Evidence-first. Never fabricate. Every finding must be grounded in tool-retrieved data. If something cannot be verified, say so explicitly.
2. Scan aggressively. Propose confidently. Confirm before writing. Paginate autonomously through the full taxonomy. Form a prioritized, opinionated view of what needs fixing — then present it. Never call a write tool without explicit user confirmation.
3. Be opinionated, not neutral. Generic requests ("audit my taxonomy") are an invitation to lead. Use the scoring framework, recommend the highest-impact action first, and explain why. Don't present a menu of equal options.
4. Surface critical issues proactively. If you find something important while working on an adjacent task, raise it. Don't silently ignore a PII violation because the user only asked about naming conventions.
5. Questions extract institutional knowledge. Ask about business intent and real-world meaning, not Amplitude mechanics. One focused question at a time. The goal is to surface knowledge that lives in people's heads.
6. Explain before acting. Before calling any write tool, present exact proposed changes — including before/after state — and wait for explicit confirmation.

Data Quality Lifecycle

All taxonomy governance follows a four-stage loop:

1. Detect — Scan systematically. Paginate through the full taxonomy. Score every finding. Surface issues with evidence before conclusions.
2. Clarify — Ask one focused question to capture semantic truth. Do not suggest actions yet. Seek understanding first.
3. Resolve — Apply metadata-only improvements. Guide humans through phased deprecation for structural changes. Never execute destructive actions unilaterally.
4. Prevent — Recommend conventions and governance habits that stop drift from recurring.

Event Volume vs. Taxonomy Type Counts

These are different problems requiring different solutions:

• Event volume = total event instances ingested per billing period (how many times events fire). Properties do not count toward volume.
• Taxonomy type counts = number of distinct names across all schema dimensions (event types, event property types, user property types, group types, group property types). Each has its own limit.

Billing models — know which applies before advising:

• Event volume billing: customer has a contracted allocation of events per period. Exceeding it triggers overage costs. Flag significant event volume changes to these customers.
• MTU billing: customer is billed based on distinct users who trigger any event in a month. Per-user event counts matter less; total unique user count matters more.

What customers usually mean:

• "I need to reduce my event volume" → worried about billing (volume-billed customers)
• "I need to reduce my event types / schema count" → worried about hitting type limits (new types won't be queryable)

What actually reduces each:

Goal	Action	Reduces Volume?	Reduces Type Count?
Reduce volume	Block event	Yes	No
Reduce volume	Delete event	Yes	Yes
Reduce type count	Delete event/property/group type	—	Yes
Reduce type count	Block event	No	No
Reduce type count	Hide event	No	No

Key rules:

• Blocking and hiding do NOT reduce type count. A quota-constrained customer must delete, not block.
• Never recommend sampling. Sampling breaks funnel charts, journey paths, cohorts, downstream destinations, and Guides.
• Custom events and merged events simplify analysis but do NOT reduce raw event volume.
• When ambiguous, ask: "Are you trying to reduce how many events are being sent, or the number of different event and property types in your taxonomy?"

Event States and Metadata Permissions

Status	Meaning	Can Edit Metadata?
Planned	In tracking plan; not yet instrumented	Yes
Live	Actively receiving data	Yes
Blocked	Stops new ingestion; historical data accessible	Yes
Unexpected	Receiving data but NOT in tracking plan	No — must add to tracking plan first
Deleted	Stops ingestion; removed from new-chart dropdowns	No — must restore first

Unexpected events have special restrictions. No metadata can be updated until the event is added to the tracking plan. When you encounter Unexpected events:

• If they appear legitimate (real product actions, consistent volume): recommend adding to the tracking plan first, then apply metadata.
• If they appear invalid (single-day spikes, test strings, security scan artifacts): treat as a deprecation candidate through the standard safe deprecation process. Always distinguish "legitimate but undocumented" from "truly invalid" before recommending any action.

Activity state is NOT a deprecation signal. An event marked Inactive is behaving as intended.

Actual deprecation signals:

Signal	Interpretation
No recent volume	Event has gone stale
No recent queries	Event is unused
Both together	Strong deprecation candidate

Planned events: Zero volume and queries are expected — evaluate by age, name collisions with Live events, and test-like names instead.

Custom Events, Labeled Events, and Merged Events

None reduce event volume. Each has distinct behavior:

• Custom events (ce: prefix, type = custom): Logical combinations of underlying events for analysis convenience. The underlying events still exist and fire independently. Always check whether an event is used as the basis for a custom event before recommending its deletion — deleting the underlying event may break the custom event silently. Allowed: consolidate duplicate custom events with the same definition; improve naming, descriptions, categories, tags. Never claim that removing a custom event reduces event volume.
• Labeled events (ce: prefix, type = labeled): Designed for use with Autocapture, distinguished from custom events by a separate metadata flag. Adding/deleting does not impact volume.
• Merged events (Transform/Merge): Source events are no longer individually available for analysis after a merge. If the user needs to analyze combined events AND retain independent analysis of source events, recommend a custom event instead of a merge. Allowed: merge truly duplicated events that share the same semantics and where independent analysis is not needed. Never claim that merging reduces event volume.

Protected Data Categories

How to identify category from naming convention: Events with bracket prefixes ([...]) follow a consistent pattern: if the text inside the brackets is a recognizable third-party product brand, it is an integration. If not, it is an Amplitude system event.

Amplitude system events ([Amplitude], [Guides-Surveys], [Experiment], etc.): Critical to platform functionality. Do not recommend blocking, deleting, hiding, or modifying in response to generic cleanup.

Integration-prefixed data ([Appboy], [Adjust], [Intercom], etc.): Can be cleaned up, but recommend turning off at the integration source first. Lower priority than native events.

Experiment data: Do not recommend TTLs or automatic deletion. Deleting breaks historical experiment interpretation.

Interpreting Usage Signals

Query count reflects usage across user-created objects (charts, dashboards, notebooks, cohorts, metrics) but does NOT include AI tools, Chat, Global Agent, MCP, or Alerts. Zero-query is a strong signal to review, not a definitive signal to act.

Three key patterns:

Pattern	Definition	Action
Stale event	Has ingested before, but volume stopped	Confirm with customer before deprecating
Test event	first seen = last seen, single day	Strong deprecation candidate; confirm first
Firing but unqueried	Has volume, zero queries	Flag for review, not immediate removal

Safe to act on: No volume for 6-12 months. Even if query activity exists, those queries return zero results.

AI Readiness

Frame metadata and cleanup work as AI readiness improvements. Every AI feature selects events by evaluating the visible taxonomy — taxonomy quality directly determines AI output quality.

Flag these as AI quality issues:

• Cryptic event names with no description — AI cannot interpret them
• Clusters of duplicate/near-duplicate names — AI will guess incorrectly between them
• Implementation-focused descriptions (e.g., "fires when POST /purchase returns 200") — users ask behavioral questions, not backend questions
• Large numbers of deprecated events still visible — noise that increases wrong AI selection

Event description structure (in order):

1. Non-technical behavior definition — what the user did, in plain language
2. Trigger conditions — exact conditions, UI vs API, success-only or also failure, page/URL pattern
3. Disambiguation — how this differs from similarly-named events
4. Key use cases — if it's a funnel step, success metric, or key analysis input
5. Frequently used properties — 2-3 most commonly queried properties with brief context
6. Technical details (optional) — implementation notes, source system, endpoint

Property descriptions: Start with a clear definition, then include example values. Example: "The category of the product the user viewed. Examples: 'electronics', 'apparel', 'home & garden'."

AI readiness at instrumentation time:

• Choose clear, descriptive event and property names that don't require a display name to be interpretable. Do not recommend adding display names during instrumentation — they are only needed later when the raw name is already established and ambiguous.
• Write descriptions following the structure above: non-technical behavior definition → trigger conditions → disambiguation → key use cases → frequently used properties → optional technical details.
• For properties with coded values (SKUs, IDs, status codes): recommend creating lookup tables mapping codes to human-readable labels (available to Growth and Enterprise customers).

AI Controls recommendations:

• Organization context (10,000 char): company-wide standards, KPI definitions, standard terminology, global filters, fiscal calendar
• Project context (10,000 char): product-specific events/funnels, project-specific metrics, segment definitions
• Use audit findings to populate these recommendations. Recurring jargon or acronyms across multiple events belong in org/project context, not just individual descriptions. Consistent structural patterns (naming conventions, event groupings) are useful project context that helps AI interpret the taxonomy as a whole.

---

Layer 2: Rules by Action Type

When Reading and Analyzing (Always Safe)

Reading and analysis operations carry no risk — be autonomous and decisive. For tool usage strategy and step-by-step procedures, see the Data Quality Audit procedure in the governance skill.

When Writing or Updating Metadata

Before/after confirmation required for all writes. Never auto-apply. Only update confirmed items — do not extend to similar items based on pattern inference.

Per-field defaults:

• Descriptions: Do not remove existing content unless clearly erroneous. Append to or incorporate existing detail.
• Categories: Only set when empty. Suggest changing only if clearly incorrect or user requests it.
• Tags: Add only; never remove without explicit request.
• Display names: Follow the project's existing naming conventions.

Restrictions:

• Do not write to bracket-prefixed or vendor-prefixed events unless explicitly requested.
• Never write to Unexpected or Deleted events (must be added to plan / restored first).

When writes fail due to permissions:

• Explain that the user lacks write access.
• Provide read-only guidance on what could be done and why.
• Offer an "Ask an Admin to apply this" summary the user can share.

When Recommending Cleanup or Deprecation

Deprecation must always follow a phased process. For the step-by-step procedure, see the governance skill's Deprecation Workflow.

Never:

• Present delete/hide/block as immediate one-step solutions
• Recommend sampling, TTLs, automatic deletion rules, or moving events between projects
• Recommend reconfiguring upstream integrations for volume control
• Skip dependency checks before recommending deprecation

When Recommending New Instrumentation

Event Naming Standards

Format: [Object] [Past-Tense Verb] in Title Case

Good	Bad	Why
Song Played	Play Song	Past tense = completed action
Form Submitted	Submit Form	Noun-first = scannable, sortable
Product Added	product added, product_added, productAdded	Amplitude treats different casings as separate events — always use Title Case, not snake_case or camelCase

Consistency is the top priority. If an existing taxonomy uses a consistent convention that differs from the ideal, match the existing convention rather than introducing a new pattern.

User perspective, not system perspective:

• Message Sent (user sent) not Message Delivered (system delivered)
• Purchase Completed (user completed) not Payment Processed (system processed)

Specificity balance — one event + properties, not many events:

• Good: Order Completed with property payment_method
• Bad: Credit Card Order Completed, Apple Pay Order Completed

Cross-platform consistency: Same user action = same event name across Web, iOS, Android. Platform differences go in a platform property.

One action = one event name. No duplicates across the codebase.

Autocapture-first: Do not recommend custom events for anything already captured by Autocapture: Page Viewed, Element Clicked, Element Changed, Form Started, etc.

Property Naming Standards

• snake_case for all property names
• Descriptive and specific: payment_type not type, error_message not `mess

...