Every analytics platform accumulates events like evt_42, lvl_up_v2, or purchase_flow_step_3b, names that made sense to whoever shipped them and mean nothing to anyone else six months later.
A new PM opens the event list, finds four hundred entries, and has no way to tell which ones matter without pinging an engineer who half-remembers writing the tracking call. That single Slack message, repeated across a team for a year, is the real cost of undocumented telemetry, and it's a cost most studios never actually measure.
This guide covers why event documentation decays so quickly in practice, how AI can infer what an event means from its properties and sample payloads rather than requiring someone to write it all down by hand, and how a self-documenting schema speeds up onboarding, tightens governance, and, increasingly, becomes a requirement for AI agents that now query your analytics directly.
What Undocumented Events Actually Cost You
Undocumented events fail quietly, in the form of decisions never made because nobody was confident enough in what the data meant to act on it. A growth analyst who isn't sure whether tutorial_skip_2 fires on a manual skip or a timeout will avoid building a report around it. A new hire spends their first two weeks reverse-engineering the event taxonomy from source code instead of shipping their first dashboard. Cross-team requests stall while someone tracks down the one engineer who remembers the context, and that engineer eventually leaves, taking the undocumented knowledge with them.
None of this shows up as a line item anywhere, which is exactly why it persists. But in the end, you get slower analysis, duplicated events that a team creates because they couldn't find the existing one, and a general erosion of trust in the data, where 'I'm not sure what that event means' becomes an acceptable answer instead of a problem to fix.
Why Manual Documentation Falls Behind
Most teams try to solve this with a wiki page or a shared spreadsheet, and it works. The problem isn't effort; it's that manual documentation, and the event schema live in two different places, updated by two different processes, on two different timelines. An engineer ships a new property on an existing event during a sprint; the doc update is a separate, unglamorous ticket that loses every prioritization conversation to actual feature work. Multiply that by dozens of events shipped per release, and the documentation is stale within weeks, then wrong, then actively misleading, which is worse than having no documentation at all.
The structural fix isn't a better wiki; it's removing the manual step. If documentation can be generated from the event's actual shape, name, properties, and real sample payloads, rather than being typed by hand and left to drift, it stays accurate because it's derived from the same source that defines the event's real behavior.
How AI Infers Event Meaning from Properties and Payloads
This is where AI does something a static schema file can't: it reads an event the way a human analyst would, by looking at its name, its property keys and types, and a sample of real payloads, then infers a plain-language description of what the event represents and when it likely fires.
- Name and property patterns. An event called purchase_complete with amount, currency, and sku properties has an unambiguous shape; an AI model can generate an accurate description without any human input, just as an experienced analyst would recognize the pattern instantly.
- Sample payload distributions. For ambiguous events, looking at dozens or hundreds of real payloads reveals patterns a name alone can't, for example, whether a property value is always one of a small enum or varies freely, which distinguishes a status flag from a free-text field.
- Cross-event context. Events don't exist in isolation. An AI model that sees tutorial_start, tutorial_step_2, and tutorial_complete in sequence can infer that a fourth event, tutorial_abandon, likely represents a mid-flow exit, even before a human documents the relationship.
- Confidence flagging. Where a description is inferred with lower certainty, for example, a genuinely ambiguous event name with sparse properties, the system can flag it for human review rather than presenting a guess as a settled fact.
The output isn't a replacement for human judgment on genuinely novel events; it's a first draft that's right often enough to eliminate most of the manual documentation burden, with a clear signal for the cases that still need a person to weigh in.
Faster Onboarding, Cleaner Governance
Once event descriptions are generated automatically and kept in sync with the schema, the team members can explore the event list and understand what's being tracked.
This matters more as teams scale. A five-person studio can hold the event taxonomy in a few people's heads. A fifty-person studio with several game teams sharing an analytics instance cannot.
AI Agents Need Documentation Too
There's a newer reason self-documenting schemas matter: AI agents and copilots increasingly query analytics platforms directly, generating a report or answering a question by reading the schema, just as a human analyst would. An agent encountering evt_42 without a description has the same problem as a new hire, except they can't walk over and ask an engineer. A schema that's already self-documented is immediately usable by both human and AI audiences, without a separate integration effort for each.
How devtodev's AI Custom Event Descriptions Work
devtodev's AI custom event descriptions generate plain-language explanations for every event in your schema automatically, drawing on event names, property structures, and real payload samples, and surface them directly in the event list and report builder rather than in a separate document that goes stale.
Descriptions update as the underlying event evolves, so the documentation tracks the schema rather than lagging behind. This sits alongside devtodev's broader AI Analytics capabilities and pairs naturally with getting insights from all sources for teams consolidating events from multiple platforms into one schema, and diving deeper into data for the exploratory analysis that a well-documented event list makes possible.
For a studio migrating from an undocumented legacy schema, the practical starting point is simple: turn on AI descriptions, review the low-confidence flags first since those are the events most likely to be misunderstood today, and let the rest populate automatically. Most teams find the bulk of their event backlog documented within a day, not a quarter.
Stop Guessing, Start Shipping
An undocumented schema doesn't just slow down onboarding; it quietly caps how confidently your team, and increasingly your AI tools, can act on the data you're already collecting. A self-documenting schema turns that data into something anyone, human or AI agent, can actually use.
Or request a live demo to see AI event descriptions applied to your own analytics schema.