Experiment
Unifying Events for an ERP System
A Claude Skill that reads a user flow from Figma and produces a lean Mixpanel tracking plan: the minimal set of key events, in one naming convention shared across the products of an ERP system. The analytics standard stopped being a document nobody reads and became a process anyone on the team can run.
Figma
user flow
Claude, or any
AI agent with the skill
tracking-plan.md
The problem
Analytics consistency usually lives in a guidelines document, and it usually fails: nobody reads it, every team names events its own way, or ships an event per tap until the data answers nothing. Our ERP spans HR, CRM, project management, supply chain, and finance, and every product needed its own tracking plan in one convention that scales across products and people.
What I did
I started from what I already had: one product with well-documented events in Mixpanel, the foundation Maisara Abou-Rady built. I reverse-engineered it once with the Mixpanel MCP, pulling out the snake_case naming, the plan's structure, and the habit of pushing variation into properties instead of minting new events. Then I encoded it all into a Claude Skill that runs the same for everyone.
How the skill thinks
Give it a Figma flow and it reads behaviour, not screens: entry, progress, conversion, drop off. Only events that answer a behavioural question survive; everything else becomes a property. And it asks what the design cannot show, like where users come from, instead of guessing.
What a run produces
One markdown file a PM, a designer, and an engineer can read in a single pass. Event names stay generic and reusable; the properties carry the specifics. One open event exists and entry_point says where it started; one submit event exists and status says whether it saved or was blocked:
| Event | What it tells us | Properties |
|---|---|---|
| item_create_open | A creation was started | entry_point: fab | empty_state |
| item_create_submit | Saved, or blocked by an error | status: success | validation_error |
The result
Count it on the table above: two entry doors and a success and an error outcome would naively ship as four events. The plan ships two, one open with entry_point saying which door, one submit with status saying how it ended. A plan that took a working session now takes minutes, and when teammates ran the skill across the ERP's products, the plans came back matching.
4
Events a naive plan would ship
2
Key events in the plan
2
Properties carrying the rest
Use it yourself
The full skill, with a worked convention file you swap for your own product's.