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 asks to audit or review a plan or branch against "our standard", their naming settings, or their AI Context
• 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:

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

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:

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:

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. To audit names and metadata against a standard, follow "Auditing Against the Customer's Standard" below.

Whose Standard Applies

Before auditing, proposing, or reviewing names, read the customer's standard from both places:

• Data → Settings naming conventions: the workspace settings read (eventNC, propertyNC). Each has a casing and, for events, a structure (see the table below), or a custom regex. The Data UI enforces these. A setting that is empty or none is no rule.
• AI Context: the org-level and project-level text from the project-context read. Project context overrides org context.

Apply sources in this order. A later source only fills what earlier ones leave open:

Settings values, as the Data UI checks them:

Structure (events only): noun_past = Song Played, past_noun = Played Song, infinitive_noun = Play Song.

Combine rules rather than picking one: apply an AI Context rule in the Settings form. With upper_case, a required is_ boolean prefix becomes IS (IS PREMIUM), never IS_PREMIUM.

If Settings and AI Context disagree on a name's casing or structure, judge names by Settings. This holds when the user says "our standard" and when the AI Context calls itself the standard. Report the conflict once, before the findings, quoting both rules, and recommend aligning them. Switch to the AI Context rule only if the user tells you to after seeing the conflict.

If neither source has any rule, say "No customer standard found — using Amplitude's defaults" and use this skill's standards.

Auditing Against the Customer's Standard

1. Read both sources above. Start the report with the rules found, each tagged with its source.
2. Report any Settings / AI Context conflict next. Conflicts are not scored.
3. Check every event and property in scope against every rule.
4. Write each violation in this form: <event or property>: <what's wrong>. Rules: <rule text> (<source>); <rule text> (<source>). Fix: <compliant value>. List every rule the item breaks, including the one that sets its severity. <source> is one of: Data → Settings, project AI Context, org AI Context, existing convention, Amplitude default.
5. Rank with "Scoring and Prioritizing Issues": breaking a customer-declared rule (Settings or AI Context) is MEDIUM impact, HIGH if it also makes the name ambiguous or splits one concept across names. When you rank a finding HIGH, its Rules list must include the rule that made it HIGH: for a split concept, "one name per concept (Amplitude default)" on every item in the split.
6. Propose fixes as one change set for a tracking-plan branch. After the user confirms, apply it to a new branch or one the user names, never to main, and leave review and merge to the customer.
   • Planned events and properties: rename them on the branch.
   • Live (ingested) names can't be renamed in metadata. List each as an instrumentation change (High effort) with the compliant name; a display name is only a stopgap.
   • Descriptions, categories, allowed values, and required properties go on the branch.
7. If the project's Data → Settings naming convention is none (no naming rule) and the AI Context has a naming rule that one of the casing-table values expresses exactly, end the report by recommending that an admin set that value in Data → Settings. Give the exact values, for example events sentence_case + infinitive_noun and properties lower_camel_case. The Data UI checks names against Settings; it doesn't check AI Context. Warn that existing names that don't match will then show as violations in the Data UI. Skip this when the setting already has a value (report the conflict instead) and for rules a setting can't express, such as allowed values, required properties, or prefixes.

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 deletion-focused audits, use the tracking-plan-audit skill.

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

These are Amplitude's defaults. Where the customer has a rule (see "Whose Standard Applies"), theirs wins.

Event Naming Standards

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

Consistency is the top priority. If the customer has no naming rule but the taxonomy consistently uses a convention that differs from the ideal, match it 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 message
• Include units when ambiguous: video_duration_seconds, file_size_mb, price_usd
• Timestamp convention: [event_name]_at (e.g., product_added_at)
• Consistent across events: Same property name for the same concept everywhere. product_name must be product_name on every event — not name, prod_name, etc.
• Distinct names for distinct concepts: login_method and payment_method, not generic method for both
• Dot notation: Means a nested object was passed (Amplitude creates it automatically). Don't use dot notation in property names directly unless intending nested objects. During audits, a cluster of dot notation properties is a cleanup signal — check which are actually being queried. If a significant portion are unused, recommend trimming the object at the source to reduce taxonomy noise.

Property Type Standards

User Identification Standards

• Anonymous users: Set device_id only. Do NOT set user_id.
• Authenticated users: Set a unique, stable user_id per verified user. Never set before login/verification.
• Server-side events: Include a unique insert_id per event for deduplication (7-day window).
• Sessions: Use a consistent session_id within a session; for server-side, use the UNIX timestamp of the first session event.

Structural Patterns

• A/B experiments: Track as list user properties, not events
• Errors: One Error Encountered event with error_type/error_category property
• E-commerce: Use product_engagement (items in this action) + cart_contents (full cart snapshot) arrays
• B2B: Instrument at least one group type (org_id, account_id)
• Property consistency for funnels: Capture the same property (e.g., product_id) across all events in a funnel

Category Assignment

Use the Amplitude category metadata field — don't embed prefixes in event names. Common categories:

Assignment heuristics:

• If an event represents a first-time or milestone user action (signup, first purchase, first invite), prefer Lifecycle over Feature or Transaction.
• If an event records a click or view that is not a core product action, prefer Engagement over Feature.
• Integration-sourced events ([Appboy], [Adjust], etc.) may not fit neatly — assign System or Growth based on the integration's purpose, or leave unassigned.
• When the correct category is ambiguous, ask the customer rather than guessing.

Scoring and Prioritizing Issues

Three dimensions:

1. Issue Impact

2. Event Importance

• Query frequency: 30/60/90/180-day counts — high-query events affect more analyses
• Volume: High-volume = more cost and risk
• First seen: Very recent = validate early before issues compound
• Last seen: Distant = staleness signal

3. Effort

• Low: Metadata-only changes (descriptions, display names, categories, tags, hiding)
• Medium: Requires stakeholder validation or dependency checks
• High: Requires codebase changes or integration reconfiguration

Prioritization: Lead with high-impact issues on high-importance events. Stale/test events are quick wins — surface them below real data quality problems.

Health grade: (Total Points Earned / Total Points Possible) x 100%

• 0-49%: Needs Improvement
• 50-79%: Meets Expectations
• 80-100%: Exceeds Expectations

Authority Boundaries (Metadata-Only)

Allowed (non-destructive, metadata-only, with user approval):

• Update display names, descriptions, categories, tags
• Set official status
• Hide events (NOT block or delete)
• Set up Automated Tasks
• Add AI Context to project settings
• Tracking-plan edits on a branch the customer reviews and merges (planned renames, allowed values, required properties)

Not allowed:

• Blocking, deleting, merging, or transforming events
• Block/Drop filters
• Modifying ingestion pipelines or upstream integrations
• Sampling strategies of any kind

Layer 3: Detection Reference

Detection Signals and Thresholds

Default lookback: 180 days.

Exception: When customer is near quota, Stale/Single-day/Test signals become elevated priority.

Key Audit Metrics

Good vs. Bad Metadata Examples

Display names:

Descriptions:

Amplitude MCP capability selection

Inspect the connected public Amplitude MCP catalog at runtime. Tool names and wrappers can change or be exposed differently during a rollout, so select capabilities from their advertised descriptions and schemas instead of relying on names recorded in this skill.

Context and discovery

• Use the project-context capability to discover accessible project IDs and read the selected project's settings. Ask the user to choose when more than one project is available; never infer an ID from a project name.
• Use taxonomy search for event and property discovery when exposed; otherwise filter and paginate the active taxonomy reader. Use entity search for charts, dashboards, notebooks, experiments, cohorts, and saved content.
• Before any write, use the workspace or branch capability to inspect approval requirements, branch protection, permissions, and current branches.

Taxonomy reads

• Prefer the consolidated taxonomy reader when the catalog exposes one. Use its advertised discriminator to select raw events, custom/labeled events, event properties, user properties, group properties, derived properties, lookups, channels, or persisted properties.
• If the catalog exposes separate event or property readers, use only their documented filters and pagination fields. Do not invent an alias or copy parameters from another reader.
• Resolve event and property names from returned taxonomy rows. Names are case-sensitive; do not substitute display names.
• Paginate exhaustive reads through every cursor. When the response reports a total, reconcile it with the accumulated rows; otherwise require the reader's documented terminal-cursor condition. A failed or partial page is not completion.
• Use the available transformation reader when auditing event/property merges, value mappings, or other cleaning rules.

Metadata updates

• Select the event or property mutation capability only after verifying that its current schema supports the requested object type, metadata fields, branch selector, and scope.
• Read the exact current object first. Update only explicitly confirmed fields, preserve existing descriptions unless the user asks to replace them, and do not infer unsupported parameters from an older tool version.
• Event-property metadata can be global or scoped to one event. Use the schema's explicit scope control; never assume omission means global unless the current schema documents it.
• Custom/labeled event definitions are full replacements, not merges. Pass the complete verified definition and warn that renames can break references.
• Never update bracket-prefixed or vendor-prefixed system events unless the user explicitly requests it.
• Require explicit confirmation before any write and honor tracking-plan write permissions and branch protection.

Workflows

• Auditing names and metadata against a standard: "Auditing Against the Customer's Standard" (Layer 2).
• Deletion and cleanup audits: the tracking-plan-audit skill.