Clean up your Amplitude event taxonomy in one console

Build me an event taxonomy cleanup console for Amplitude. My product and data team opens it during tracking plan reviews, works through the event list together on a call, and fixes problems in place instead of exporting everything to a spreadsheet. Every change it makes is written straight back to Amplitude.

The main view is a review queue: one row per event type. Build it by combining Amplitude's Get Event Types (which gives the event name, taxonomy status, description, category, and whether it is deleted) with List Events with Current Week Stats (which gives current week volume, unique users, and DAU percent), joined on the event name. Show columns for event name, current week volume, unique users, DAU percent, taxonomy status, description, and category. Every column sorts. Default the sort so the events most likely to need attention float to the top: zero volume first, then unverified, then missing a description. Events that appear in one source but not the other should still show up, with the missing side rendered as unknown rather than silently dropped.

Above the queue, show a header scorecard with total events, percent verified, and how many have not fired in 30 days. Read the note further down about how to compute the 30 day number honestly.

Give the queue three toggle filters that combine: zero volume this week, unverified, and missing a description. Add a free text search on the event name, and always show how many rows match the current filter set so it is obvious how much of the list is being hidden.

Add a cluster panel that finds near duplicate event names. Normalize each name by lowercasing it and treating dashes, underscores, spaces, and dots as the same separator, then group events whose normalized names are identical and show any group with two or more members. This is the panel that catches sign-up, sign_up, and user_sign-up all tracking the same action, which is the classic taxonomy problem: the duplicates split one metric across several lines and make conversion look worse than it is. Within a cluster, show each member's weekly volume side by side so the reviewer can see which variant is the real one, and let them act on any member row directly from the panel without going back to the main queue.

Every row is editable inline. The status control offers exactly Amplitude's four values: verified, unverified, blocked, and hidden. The description and category are editable too, with category as a dropdown. All three save through Update Event Type, which is a partial update, so send only the field that changed and map each status onto whatever fields that operation exposes. Use optimistic updates with a per row saving and saved indicator, and revert the cell with a visible error if the write fails.

Support bulk selection with row checkboxes plus a select all matching the current filter, then let the user apply one status to the whole selection. This part needs care: Amplitude's Taxonomy API allows only 4 concurrent requests and 7,200 cost units per hour, and every POST, PUT, or DELETE costs 2 units. Apply bulk changes in small sequential batches with no more than a few requests in flight and a brief pause between batches, never as one big parallel fan out. Show a progress indicator listing which events succeeded and which failed, let the user cancel partway through, and leave the already applied changes in place when they do.

Manage categories from inside the console. Populate the category dropdown with Get Event Categories, let the user add a new category inline while editing a row using Create Event Category, and let them rename an existing one with Update Event Category.

Retiring an event uses Delete Event Type, which soft deletes it. Always show a confirmation step first, naming the event and its current week volume so nobody deletes something that is still firing. A bulk delete confirms with the full list of names and requires an explicit confirm. Keep deleted events reachable behind their own filter with a Restore button wired to Restore Event Type.

When an event is broken rather than dead, a button on the row files a Linear issue with Create Issue. Prefill the title as a tracking bug for that event name, and prefill the description with the volume evidence: current week volume, unique users, DAU percent, and the current status, description, and category. Let the reviewer edit the title and body and pick the engineering team, populated from Linear's List Teams, before submitting. Once created, show the issue key and link on the row so the team can see it was already reported.

Track everything done during the current review session: events verified, blocked, hidden, descriptions rewritten, events deleted, events restored, and tickets filed. Persist this session log so it survives a page reload. A Share summary button opens a preview of the message, lets the user pick a Slack channel populated from List Channels, edit the text, and post it with Slack's Send a Message. Format the message in Slack mrkdwn with the headline counts and a few notable items, such as the highest volume event that was deleted and links to any tickets filed.

One important note on the 30 day dormancy number. The available Amplitude data gives current week volume, not a last triggered date, so do not pretend to know something you cannot read. Compute what you can directly, which is how many events had zero volume this week, and on every load store a snapshot of each event's weekly volume in app storage. Use that accumulating history to show how many consecutive weeks an event has been silent, and label the scorecard tile accordingly: until about a month of snapshots exists, show the dormant figure as not fired this week and note that the history is still building. Once there is enough history, the tile becomes a true 30 day figure.

Use app storage for the weekly volume snapshots, the session logs, and each user's preferred Linear team and Slack channel so they are not re-picked at every review.