Internal tool: Metric tracking
Automating metric tracking with AI
Quick read
Project overview
Created a metric tracking system that helped designers, developers and project managers decide what features to track and how to track them. When using the TARS framework to track feature success, it became obvious that teams needed to do the setup work themselves before handing over to the data team. I created a Claude skill that removed that manual process, while still leaving the user in control of deciding what to track, but with the upfront "why" behind tracking something. It converted a laborious manual process into an efficient, automated flow that avoided the blank canvas and improved delivery.
Responsibilities
Concept, design, build (self-initiated)
Target users
Designers, PMs and developers setting up feature analytics
Problem statement
Setting up tracking was slow, manual, and easy to skip under pressure.
Having experienced the problem myself first hand, tracking event triggers with features was time consuming for me, developers, and the various colleagues involved. Deciding what to track and why turned into a few hours of making sure we were tracking the right thing. However, the hard part was never the tagging. It was communicating to the team what we should tag and what that ultimately looked like. I tried annotating flows, building tables in Excel, and screenshotting each component to give enough context to the team, writing up the why. It worked, but it was slow, repetitive, and it didn't scale.
Current known pains
- Identifying what to track was manual effort
- Screenshotting and highlighting each component in Figma
- Not knowing what was a priority to track
- Tracking was sometimes half-implemented due to time constraints
- Inconsistent event names across features
- Handoff to development was a separate manual step
Approach
Automate the labour, not the decision.
I had witnessed the problem first hand: working with the team this way wasn't efficient or reliable. I needed a better, more consistent way to tackle this. I decided to brain dump my ideas into a Claude project, capturing everything from the people involved to the pains I'd witnessed in my earlier iterations of tracking. The goal was to remove the manual labour of the tracking process, not the decision.
Who needed what
- Developers needed to understand what to track and the priority
- Product (design/PM) needed to understand the why behind tracking, and whether it was meaningful when measuring the feature's success
- The data team needed to build dashboards based on the data we tracked, and needed visibility into it
- Scalability: anyone else using the skill would need onboarding or additional support
- The user leveraging the skill needed to remain in control and make the decision
Solution
Design & Build
Using Claude, I built a skill called TARS-tracking that talks to the Figma MCP. Thinking back to the manual process of capturing component screenshots, I got Claude to read a Figma file, isolate the specific components, and extract them as SVGs into a structured table. For each component, Claude suggests the event name, the rationale for why it's worth tracking, a priority on what needs to be tracked, and where it needs to be implemented. Giving the user full control, I iterated quickly and added functionality so users can change table fields, customise elements, and delete entire rows. This table was split into four categories: Discovery, Retention, Activation, and Error + Friction.
Core principles
- Designer stays the decision-maker on what's tracked
- Every tracked item carries a reason and a priority
- Output doubles as a dev handoff with implementation location
- HTML output is editable, not static
This turned what was once a static tracking Excel spreadsheet into a fully customisable, dynamic, working HTML page. It became the source of truth we could share with the wider team when discussing the feature's tracking. The plan and the conversation lived in one place.
Metrics
Faster setup, more reliable tracking
Automating the manual parts of tracking setup freed up time, reduced errors, and made instrumentation something that ships with every feature, not just when there's bandwidth.
90 → 10 min
Faster setup per feature
Initial tracking setup per feature went from a manual screenshot-and-annotate task to a quick review
Zero
Manual screenshots
Screenshotting, highlighting, and writing up rationale by hand is replaced by an automated, structured table.
1
Source of truth
The editable HTML output doubles as a live collaboration surface for devs and PMs, not just a handoff doc
Outcomes
Learnings and reflection
Automating the tracking setup removed one of the most friction-heavy steps in launching a feature. What used to take the best part of a day (annotating flows, building tables manually, writing rationale) became a guided review of a generated output.
The shift in focus from producing the plan to reviewing it changed how tracking conversations happened. It became easier to involve devs and PMs earlier, and the shared artefact meant everyone was working from the same source of truth.
What changed
- Tracking setup went from hours to minutes
- Instrumentation now consistent across features
- The plan became a shared team artefact
What I learned
- Automating the labour while keeping the judgement is the right line to draw
- A reusable output format saves more time than any single setup
- Making tracking easy is what makes it actually happen
