Figma-Plugin · Produkt-Tooling

Trackinator

Ein Figma-Plugin, das Analytics-Tracking direkt im Design definiert, daraus Code generiert und teamweit bis zum Live-Status synchron hält.

Rolle: Produkt & Entwicklung: Konzeption und alleinige Umsetzung
Zeitraum: ~1,5 Jahre · 4 Prototypen

Kontext

Ausgangslage & Problem

Das Definieren von Tracking-Events ist in den meisten Teams langsam, unübersichtlich, fehleranfällig und kaum wartbar. Analyst:innen pflegen Eventnamen, Parameter und Screens typischerweise in Google Sheets, Confluence oder Miro, also getrennt vom eigentlichen Produktdesign. Tabellen, Tickets und Implementierung driften auseinander, es entstehen unklare Eventnamen, fehlende Parameter und hoher Abstimmungsaufwand zwischen Design, Entwicklung, QA und Analytics.

Trackinator verlegt die Definition dorthin, wo der Produktfluss ohnehin sichtbar ist: direkt in Figma. Das Plugin löst dieses Grundproblem nicht nur, es verändert den gesamten Arbeitsablauf grundlegend. Definition, Code-Generierung, Implementierung, QA-Abnahme und Release-Auswertung laufen über ein einziges Werkzeug, in dem das Design die Source of Truth ist.

Rolle

Meine Rolle & Rahmen

Konzeption und Umsetzung als eigenständiges Produkt-Tooling, von der Problemanalyse über die Architektur bis zum lauffähigen Plugin.

Über rund 1,5 Jahre in vier Prototypen iterativ entwickelt: jeder Durchlauf hat den Workflow weiter auf den Kern reduziert und die Datenarchitektur geschärft.

Architektur

Entscheidungen & Trade-offs

Figma-Nodes als Source of Truth für Event-Definitionen.

Warum: Tracking-Definitionen leben dort, wo das Design entsteht: sichtbar für alle Kollaborator:innen und versioniert mit dem Design, statt verstreut in Sheets, Confluence oder Miro.
Trade-off: Bindung an die Figma-Plugin-Sandbox und ihre API-/CSP-Grenzen. Cloud-Zugriffe brauchen z. B. einen Proxy in der Sandbox.

Mehrschichtige Speicher-Architektur: Node-lokal, dann Firestore (Drafts, dann Team), dann BigQuery.

Warum: Lokale Node-Definitionen bleiben schnell editierbar, eine user-scoped Drafts-Outbox erlaubt Arbeit über mehrere Files, Firestore hält das Team synchron und BigQuery bedient Reporting und Downstream-Systeme. Jede Schicht hat einen klaren Zweck.
Trade-off: Drift zwischen den Schichten muss aktiv erkannt werden (Quality-Scans, Storage-Drift-Check) statt durch eine einzige Datenbank garantiert zu sein.

Generierten Tracking-Code bereitstellen statt manueller Implementierung.

Warum: Aus den Definitionen wird Code generiert, den Entwickler:innen einfach einbinden und an der richtigen Stelle verbauen können. Das eliminiert Abschreibfehler zwischen Definition und Implementierung und macht die Definition zur ausführbaren Wahrheit.
Trade-off: Der Generator muss eng am Event-Schema bleiben und pro Zielplattform gepflegt werden.

Verbindlicher Dev/QA-Flow mit Implementierungsstatus direkt am Event.

Warum: Jedes Event trägt pro Plattform einen Status über den gesamten Lebenszyklus, den Dev und QA in einer geführten Queue pflegen. So wird sichergestellt, dass das richtige Tracking an der richtigen Stelle eingebaut wird, und es ist jederzeit sichtbar, welche Trackings tatsächlich live sind.
Trade-off: Der Status ist nur so verlässlich wie seine Pflege. Der Flow setzt Disziplin im Team voraus.

Events einzelnen Release-Versionen zuordnen.

Warum: Eine stabile Event-Identität über alle Versionen (mit isLatest-Flag) erlaubt es, Trackings konkreten Releases zuzuordnen und verschiedene Releases rückwirkend zu vergleichen und auszuwerten.
Trade-off: Versionierung erzeugt mehr Dokumente und Migrationspfade statt einfacher In-Place-Bearbeitung.

Auto-Tracking über eine zentrale Component-Registry.

Warum: Tracking-relevante Komponenten werden anhand der Registry automatisch erkannt und mit vorausgefüllten Event-Vorschlägen versehen. Das skaliert Tracking über große Files, ohne jedes Element von Hand taggen zu müssen.
Trade-off: Die Vorschlagsqualität hängt an einer gepflegten Registry und sauberem Component-Matching.

Umsetzung

Technische Highlights

Figma-Plugin auf React 19 + TypeScript mit Zod-Schemas und einer postMessage-Bridge zwischen Sandbox und UI
Generierter Tracking-Code direkt aus den Event-Definitionen, von Entwickler:innen ohne Abschreiben einbaubar
Rollenbasierte Workspaces (Admin/Dev/QA/Analyst) mit plattformspezifischen Dev/QA-Queues
Implementierungsstatus pro Plattform über den gesamten Lebenszyklus (definiert, dev, QA, release, live)
Auto-Tracking via Component-Registry: automatische Erkennung tracking-relevanter Komponenten
Release-Versionierung mit stabiler Event-Identität für rückwirkende Release-Vergleiche
Teamweite Synchronisation über Firestore (user-scoped Drafts-Outbox, dann team-scoped Events)
Reporting-Anbindung an BigQuery (Dual-Write Legacy + V2) über einen Cloud-Run-Microservice
Qualitäts-Scans mit Regel-Engine für Sync-Drift, Schema- und Strukturprobleme

Stack

Eingesetzte Technologien

ReactTypeScriptZodFigma Plugin APIFirestoreBigQueryCloud RunTailwind CSS

Ergebnis

Wirkung

Trackinator hat einen verstreuten, fehleranfälligen Prozess in einen durchgängigen Workflow verwandelt: Event-Definition, Code-Generierung, Implementierung, QA-Abnahme und Release-Auswertung passieren an einem Ort, mit dem Design als Source of Truth.

Das Projekt zeigt meine Stärke an der Schnittstelle von Produkt, Engineering und Data: ein reales Werkzeug mit Rollenmodell, teamweiter Synchronisation, Lifecycle-Status-Tracking, Codegenerierung und technischer Anbindung an Analytics-Systeme.

Reflexion

Was ich heute anders entscheiden würde

Über vier Prototypen hinweg habe ich gelernt, wie viel Wert in der konsequenten Reduktion auf den Kern-Workflow liegt, und wie wichtig es ist, Drift zwischen lokaler Definition, Team-Sync und Reporting von Anfang an aktiv zu behandeln.

Einzelne Bereiche wie die Analytics-Heatmap sind bewusst als Proof-of-Concept stehen geblieben; der produktive Fokus liegt auf Definition, Synchronisation und dem Dev/QA-Lifecycle.

Klingt nach einem Profil, das zu deinem Projekt passt?

Verfügbarkeit anfragen Weitere Projekte