Die Aufgabe in einem Satz
Ein Growth Engineer ist die Person, die Growth messbar macht. Er instrumentiert das Produkt, sodass jede relevante Aktion zu einem Event wird, pflegt einen Tracking-Plan, der diese Events einheitlich benennt, und schließt die Lecks im Funnel, die die Daten sichtbar machen. Unter den acht Rollen steht er neben dem Growth PM: Der PM entscheidet, was getestet wird, der Engineer macht den Test messbar. Sein Code dient Experimenten, nicht der Produkt-Roadmap.
Was er tatsächlich liefert
Der Großteil der Arbeit ist Infrastruktur, die der Rest des Teams nie sieht. Das Team von PostHog beschreibt einen Growth Engineer als jemanden, der Code schreibt, um Geschäftsmetriken zu bewegen, statt Features zu bauen – Gerüste für A/B-Tests, Funnel-Fixes, das Tracking, das Ihnen sagt, ob überhaupt etwas funktioniert hat.
- Einen Funnel abbilden – Registrierung, Aktivierung, Upgrade – und jeden Schritt instrumentieren, damit Abbrüche sichtbar werden.
- Das fehlende Event ergänzen. Das klassische Beispiel ist ein `subscription_started`, das nie jemand angebunden hat, sodass Umsatz im Funnel unsichtbar bleibt.
- Den Tracking-Plan prüfen: doppelte Events streichen, uneinheitliche Namen korrigieren, dokumentieren, was jede Eigenschaft bedeutet.
- Die internen Tools und Integrationen bauen – Webhooks, Syncs, Dashboards –, mit denen andere Rollen auf Basis der Daten handeln können.
Der Tracking-Plan ist das Ergebnis
Alles Weitere hängt an sauberen Events. Amplitude nennt die Event-Taxonomie das Fundament guter Analytics: eine einheitliche Namenskonvention, abgestimmte Eigenschaften, eine einzige verlässliche Quelle. Segment beschreibt den Tracking-Plan als lebendes Dokument dessen, was Sie tracken und warum. Stimmt er, lesen Profile, Segmente und Journeys alle aus demselben verlässlichen Datenstrom. Stimmt er nicht, lügt jeder Bericht still vor sich hin.
Warum die Rolle ein Multiplikator ist
Ein Growth Engineer verantwortet selten eine eigene Metrik. Sein Ergebnis ist die Fähigkeit des Teams, Metriken überhaupt zu bewegen. Wenn der Performance Marketer ein Segment mit hohem LTV an eine Werbeplattform synchronisieren will oder der Data Analyst einen Kohortenbericht braucht, der nicht auf Vermutungen beruht, ist der Engineer der Grund, warum diese Daten existieren und verlässlich sind. Einmal instrumentiert, liest jede Rolle dieselben Events. Dieser Multiplikator ist der Grund, warum die Rolle kein Nice-to-have ist.
Growth Engineer vs. Product Engineer
Beide schreiben Code; die Frage, die sie beantworten, ist eine andere. Ein Product Engineer fragt, ob das Feature funktioniert. Ein Growth Engineer fragt, ob das Feature die Zahl bewegt – und instrumentiert das Produkt so, dass man es sehen kann. Er liefert schneller und pragmatischer, denn ein Tracking-Fix, der erst nächstes Quartal live geht, hat Ihnen nichts beigebracht.
Was ein Growth Engineer mit fromHello macht
Das First-Party-Snippet von fromHello erfasst page_viewed und session_started von selbst, dazu element_visible, Klicks, abgeschickte Formulare und Scrolltiefe, sobald Sie sie als Trigger einrichten, ganz ohne Code. Ihr Code sendet die Events, die zählen, etwa subscription_started, aus dem Browser oder mit einem API-Schlüssel aus Ihrem Backend. Das Snippet lädt keine Pixel von Drittanbietern. Jedes Event landet im Profil der Person, dynamische Segmente werden bei jedem Event neu berechnet, und Journeys werden durch Events ausgelöst: der oben gezeigte Weg vom Erfassen bis zum Trigger, ganz konkret. Event-Eigenschaften lassen sich auf das Profil abbilden, und ein Webhook-Schritt bindet den Rest Ihres Stacks an. Über den MCP-Server von fromHello kann der KI-Client, den Sie bereits nutzen, etwa Claude Code oder Cursor, die eingehenden Events und Eigenschaften auflisten, eine Eigenschaft auf das Profil abbilden oder ein Segment erstellen; kein KI-Tool verschickt eine Nachricht. Zum Vergleich mit einem Tool, das Sie kennen, siehe fromHello vs. Customer.io.