Figma plugin · product tooling

Trackinator

A Figma plugin that defines analytics tracking directly in design, generates code and keeps teams synchronized through live status.

Role: Product & development: concept and solo implementation
Timeframe: ~1.5 years · 4 prototypes

Context

Starting point & problem

Defining tracking events is slow, hard to keep organized, error-prone and difficult to maintain in many teams. Analysts typically maintain event names, parameters and screens in Google Sheets, Confluence or Miro, separate from the actual product design. Tables, tickets and implementation drift apart, causing unclear event names, missing parameters and high coordination effort between design, development, QA and analytics.

Trackinator moves the definition to where the product flow is already visible: directly into Figma. The plugin does not just solve the basic problem; it fundamentally changes the workflow. Definition, code generation, implementation, QA approval and release analysis run through one tool where the design is the source of truth.

Role

My role & scope

Concept and implementation as standalone product tooling, from problem analysis and architecture to a working plugin.

Built iteratively over roughly 1.5 years and four prototypes: every iteration reduced the workflow further to its core and sharpened the data architecture.

Architecture

Decisions & trade-offs

Figma nodes as the source of truth for event definitions.

Why: Tracking definitions live where the design is created: visible to all collaborators and versioned with the design instead of scattered across Sheets, Confluence or Miro.
Trade-off: Coupling to the Figma plugin sandbox and its API/CSP boundaries. Cloud access, for example, requires a proxy in the sandbox.

Multi-layer storage architecture: node-local first, then Firestore (drafts, then team), then BigQuery.

Why: Local node definitions stay fast to edit, a user-scoped drafts outbox allows work across multiple files, Firestore keeps the team in sync and BigQuery serves reporting and downstream systems. Each layer has a clear purpose.
Trade-off: Drift between layers must be actively detected (quality scans, storage drift checks) instead of being guaranteed by a single database.

Generated tracking code instead of manual implementation.

Why: Definitions produce code that developers can integrate directly in the right place. This eliminates copying errors between definition and implementation and turns the definition into executable truth.
Trade-off: The generator must stay closely aligned with the event schema and be maintained per target platform.

Binding Dev/QA flow with implementation status directly on the event.

Why: Every event carries a platform-specific status across the full lifecycle, maintained by Dev and QA in guided queues. This ensures the right tracking is implemented in the right place and makes it visible which tracking is actually live.
Trade-off: The status is only as reliable as its maintenance. The flow requires discipline from the team.

Events assigned to release versions.

Why: Stable event identity across all versions (with an isLatest flag) makes it possible to connect tracking to specific releases and compare releases retrospectively.
Trade-off: Versioning creates more documents and migration paths instead of simple in-place editing.

Auto-tracking through a central component registry.

Why: Tracking-relevant components are detected through the registry and prefilled with event suggestions. This scales tracking across large files without tagging every element manually.
Trade-off: Suggestion quality depends on a maintained registry and clean component matching.

Implementation

Technical highlights

Figma plugin built with React 19 + TypeScript, Zod schemas and a postMessage bridge between sandbox and UI
Generated tracking code directly from event definitions, usable by developers without copying by hand
Role-based workspaces (Admin/Dev/QA/Analyst) with platform-specific Dev/QA queues
Implementation status per platform across the full lifecycle (defined, dev, QA, release, live)
Auto-tracking via component registry: automatic detection of tracking-relevant components
Release versioning with stable event identity for retrospective release comparisons
Team-wide synchronization through Firestore (user-scoped drafts outbox, then team-scoped events)
Reporting connection to BigQuery (dual-write legacy + V2) through a Cloud Run microservice
Quality scans with rule engine for sync drift, schema and structure problems

Stack

Technologies used

ReactTypeScriptZodFigma Plugin APIFirestoreBigQueryCloud RunTailwind CSS

Outcome

Impact

Trackinator turned a scattered, error-prone process into one continuous workflow: event definition, code generation, implementation, QA approval and release analysis happen in one place, with the design as the source of truth.

The project shows my strength at the intersection of product, engineering and data: a real tool with roles, team synchronization, lifecycle status tracking, code generation and technical integration with analytics systems.

Reflection

What I would decide differently today

Across four prototypes I learned how much value lies in consistently reducing a product to the core workflow, and how important it is to actively handle drift between local definition, team sync and reporting from the start.

Individual areas such as the analytics heatmap intentionally remained proof-of-concept; the productive focus is on definition, synchronization and the Dev/QA lifecycle.

Sounds like a profile that fits your project?

Check availability More projects