Wie man die Feature-Adoption misst

Die Feature-Adoption-Rate ist der Anteil der berechtigten Nutzer, die ein Feature tatsächlich verwenden. Die Formel ist einfach — Adoptierende geteilt durch die Population, die es adoptieren könnte — aber die Zahl ist bedeutungslos, bis Sie drei Dinge festlegen: wer als berechtigt zählt (Breite), wie intensiv sie es nutzen (Tiefe) und über welchen Zeitraum (Zeit). Machen Sie das falsch, liefern Sie ein Dashboard aus, das 80% anzeigt, wenn die ehrliche Zahl 12% ist. Dies ist ein How-to: instrumentieren Sie das Feature, berechnen Sie die drei Metriken und handeln Sie danach.

Voraussetzungen

• Ein Analytics-Tool, das Custom-Events erfasst, die an eine stabile Nutzer-/Account-ID gebunden sind — Amplitude, Mixpanel, Heap oder Pendo. Heap erfasst Clicks automatisch (weniger Instrumentierung im Vorfeld, unsauberere Event-Taxonomie); Amplitude und Mixpanel benötigen explizite track()-Aufrufe (mehr Arbeit, sauberere Daten).
• Eine definierte „berechtigte Population”. Nicht jeder Nutzer kann jedes Feature nutzen — ein Feature hinter einem Enterprise-Plan hat als Nenner die Enterprise-Seats, nicht alle Seats. Schreiben Sie diese Regel auf, bevor Sie irgendetwas berechnen.
• Eine Definition dessen, was „das Feature nutzen” bedeutet, als ein oder mehrere konkrete Events, nicht als Seitenaufruf. Die Seite zu öffnen ist keine Adoption; die Kernaktion abzuschließen schon.

Schritt 1 — instrumentieren Sie die Kernaktion, nicht die Seite

Lösen Sie ein einziges benanntes Event bei der Aktion aus, die den Wert des Features liefert. Bei einem Massenexport-Feature ist das Event bulk_export_completed, nicht export_page_viewed. Fügen Sie in Amplitude oder Mixpanel den Aufruf track('bulk_export_completed', { row_count, format, account_id }) im Success-Callback des Exports hinzu, nachdem die Datei generiert wurde — niemals beim Button-Click, denn Clicks umfassen Fehler und Rage-Clicks. In Pendo oder Heap können Sie stattdessen das DOM-Element im Erfolgszustand taggen, aber ein serverseitiges Event ist zuverlässiger, weil es Ad-Blocker und Client-Crashes übersteht.

Hängen Sie account_id und plan_tier als Event-Eigenschaften an, damit Sie den Nenner später auf berechtigte Accounts filtern können. Ohne diese können Sie die Breite über alle Nutzer berechnen, aber nie über die berechtigte Population — und die Zahl der berechtigten Population ist die, auf die es ankommt.

Schritt 2 — berechnen Sie die drei Formeln

Breite = Adoptierende / berechtigte Nutzer       (haben sie es überhaupt angefasst?)
Tiefe  = Kernaktionen / Adoptierenden            (wie stark stützen sie sich darauf?)
Zeit   = Adoptierende innerhalb von N Tagen nach Berechtigung / berechtigte Nutzer dieses Cohorts

• Breite ist die schlagzeilenrelevante Adoption-Rate. Ein Adoptierender ist jeder berechtigte Nutzer, der das Kern-Event mindestens einmal im Zeitfenster ausgelöst hat. Die Breite beantwortet „ist dieses Feature überhaupt angekommen?”
• Tiefe trennt ein Feature, das Leute einmal ausprobieren, von einem Feature, von dem Leute abhängen. Berechnen Sie sie nur über die Adoptierenden (nicht die gesamte Basis), sonst maskiert eine niedrige Breite eine hohe Tiefe. Ein Feature mit 15% Breite und 40 Aktionen pro Adoptierenden pro Monat ist ein Power-User-Feature, kein Fehlschlag — behandeln Sie es anders als eines mit 15% Breite und 1,2 Aktionen.
• Zeit bis zur Adoption ist die Breite, gemessen an einer Cohort-Uhr. „Welcher Anteil der Accounts, die im März berechtigt wurden, hat das Feature innerhalb von 30 Tagen genutzt?” Dies ist die Metrik, die Ihnen sagt, ob Ihr Onboarding das Feature sichtbar macht, und es ist die, die die meisten Teams überspringen.

Durchgerechnetes Beispiel: Ein Feature ist auf 500 Enterprise-Accounts beschränkt. In einem 30-Tage-Fenster haben 145 das Kern-Event ausgelöst und insgesamt 1.160 Kernaktionen erzeugt. Breite = 145 / 500 = 29%. Tiefe = 1.160 / 145 = 8 Aktionen pro Adoptierenden. Wenn nur 60 der 145 innerhalb von 30 Tagen nach Erlangung der Berechtigung adoptiert haben, beträgt die Zeit bis zur Adoption(30T) = 60 / 500 = 12%.

Schritt 3 — wählen Sie das Zeitfenster bewusst

Das Zeitfenster ist nicht kosmetisch. Ein täglich genutztes Feature (ein Dashboard) sollte über ein rollierendes aktives Fenster von 7 oder 28 Tagen gemessen werden — wer es letztes Quartal genutzt hat, ist heute kein Adoptierender. Ein quartalsweise genutztes Feature (ein Compliance-Export) braucht ein 90-Tage-Fenster, sonst berichten Sie Churn, der nur Saisonalität ist. Stimmen Sie das Fenster auf die natürliche Kadenz des Features ab, schreiben Sie es in die Metrik-Definition und vergleichen Sie niemals zwei Features, die über unterschiedliche Fenster gemessen wurden.

Schritt 4 — setzen Sie die Nenner-Untergrenze

Bei einem Feature, das jünger als ein Release-Zyklus ist, wächst die berechtigte Population noch, sodass die Breite künstlich durch Accounts gedrückt wird, die gestern berechtigt wurden. Schließen Sie Accounts aus, die kürzer als die natürliche Kadenz des Features berechtigt sind (z. B. verwerfen Sie Accounts, die kürzer als 28 Tage berechtigt sind, bei einem wöchentlich genutzten Feature). Berichten Sie die Breite über die gereifte Population und die Zeit bis zur Adoption über das vollständige Cohort — sie beantworten unterschiedliche Fragen.

Wie gut aussieht

Es gibt keinen universellen Benchmark; die Adoption-Rate ist Feature-spezifisch. Ein Kern-Workflow-Feature im Bereich von 40-60% Breite ist gesund; ein Power-User- oder Admin-Feature, das bei 5-15% Breite liegt, kann vollständig erfolgreich sein, wenn die Tiefe unter den wenigen, die es adoptieren, hoch ist. Die Zahl, die Sie alarmieren sollte, ist ein Feature mit sowohl niedriger Breite als auch niedriger Tiefe nach einem vollständigen Kadenz-Fenster — das ist ein Feature, das niemand brauchte, und die Handlung ist, es einzustellen oder neu zu bauen, nicht stärker auf Enablement zu drücken.

Auf die Daten reagieren

• Niedrige Breite, hohe Tiefe — Discovery-Problem. Wer es findet, liebt es. Machen Sie es im Onboarding und in-app sichtbar (Pendo-Guides, Empty-State-Prompts), messen Sie dann die Zeit bis zur Adoption erneut.
• Hohe Breite, niedrige Tiefe — flacher Wert oder ein Feature zur einmaligen Nutzung. Wenn es wiederkehrend sein sollte, greift der Aktivierungsmoment nicht; untersuchen Sie den Abbruch bei der zweiten Nutzung.
• Niedrige Breite, niedrige Tiefe, vollständiges Fenster verstrichen — Kandidat zum Einstellen. Bestätigen Sie es mit einer Churn-/Expansion-Kreuztabelle, bevor Sie es einstellen, aber investieren Sie kein Enablement weiter in ein Feature, das die berechtigte Population abgelehnt hat.

Häufige Fallstricke

• Seitenaufrufe als Adoption. page_viewed zu zählen bläht die Breite mit allen auf, die versehentlich hineingeklickt haben. Schutz: Das Kern-Event feuert im Success-Callback der wertliefernden Aktion, niemals bei Navigation oder Click.
• Nenner = alle Nutzer. Durch die Gesamtzahl der Accounts zu teilen, wenn das Feature plan-gebunden ist, unterschätzt die Adoption unter denen, die es tatsächlich nutzen können. Schutz: Filtern Sie den Nenner nach plan_tier/Entitlement, gesetzt in Schritt 1.
• Kein Fenster oder nicht zusammenpassende Fenster. Eine lebenslang kumulierte „hat es jemals genutzt”-Zahl geht nur nach oben und sagt nichts über die aktuelle Gesundheit aus. Schutz: Definieren Sie ein rollierendes Fenster, das auf die Kadenz des Features abgestimmt ist (Schritt 3), und vergleichen Sie niemals Features, die über unterschiedliche Fenster gemessen wurden.
• Breite und Tiefe zusammen gemittelt. „Durchschnittliche Aktionen pro Nutzer” über die gesamte Basis zu berichten, vermischt Adoptierende und Nicht-Adoptierende zu einer bedeutungslosen Mitte. Schutz: Berechnen Sie die Tiefe nur über die Adoptierenden.

Verwandt

• NRR vs GRR — Adoption ist ein Frühindikator für die Retention
• Pendo — In-app-Guides, um die Adoption von Features mit niedriger Breite zu fördern
• Amplitude — Cohort- und Funnel-Analyse für die Zeit bis zur Adoption