Wie entscheidet man, welche Ereignisse verfolgt werden sollen?

Dies ist Teil fünf der fünfteiligen Serie über Kundendaten . Hier sind Teil eins , zwei , drei und vier .

Beginnen Sie damit, Fragen zu stellen.

Um zu entscheiden, welche Ereignisse nachverfolgt und welche Daten gesammelt werden sollen, müssen Sie Fragen auflisten, die Sie zu Ihren Benutzern und deren Produktnutzung haben.

Sie werden feststellen, dass es so viel gibt, was Sie wissen möchten, sobald Sie anfangen, Ihre Fragen aufzulisten. Fragen erzeugen mehr Fragen, und wenn das passiert, werden Sie wahrscheinlich alle Antworten auf einmal erhalten wollen. Aufgrund dessen, wie sich dieser Prozess bei den meisten Menschen anfühlt, bezeichnen wir diese Fragen als brennende Fragen .

Wenn Sie nicht so denken, möchten Sie wahrscheinlich nicht viel wissen oder sind von Ihren Annahmen überzeugt. Lassen Sie sich davon jedoch nicht davon abhalten, Fragen zu stellen – Sie könnten angenehm überrascht oder völlig enttäuscht sein, wenn Sie die Antworten erfahren.

Es ist viel einfacher, Fragen zu Daten zu stellen, sobald Sie in der Lage sind, die Daten zu visualisieren – aber dies kann auch kontraproduktiv sein, wenn Sie weiterhin Berichte erstellen oder Daten visualisieren, ohne zuerst die brennenden Fragen zu stellen.

Brennende Fragen

Brennende Fragen können einfach sein wie „Wie viele Benutzer haben sich in den letzten 7 Tagen angemeldet?“ oder komplex wie „wie viele Benutzer aus der SaaS-Branche haben sich in den letzten 7 Tagen angemeldet und einen anderen Benutzer in ihre Organisation eingeladen ?“

Wenn Sie über brennende Fragen nachdenken, hilft es, die folgenden Aktionen aufzulisten:

• Aktionen, die ein Benutzer ausführen muss, um den Aha-Moment zu erreichen (Aktivierungsereignis)
• Aktionen, die anzeigen, dass ein Benutzer bereit ist, einen Kauf zu tätigen oder ein Konto zu aktualisieren
• Aktionen, die das Benutzerengagement fördern und einen Benutzer binden
• Aktionen, die signalisieren, dass ein Benutzer nicht genug Wert aus dem Produkt zieht
• Aktionen, die möglicherweise dazu führen, dass ein Benutzer abgewandert wird

Es ist auch ein guter Zeitpunkt, das Produkterlebnis zu hinterfragen und über Ihre Kernangebote nachzudenken. Die folgenden Fragen gelten für die meisten technischen Produkte:

• Wie lange ist die Time-to-Value bzw. wie lange brauchen User bis zum Aha-Moment?
• Welche verschiedenen Wege gehen Benutzer nach der Anmeldung?
• Was sind die Reibungspunkte in der User Journey?
• Welche Funktionen werden von aktiven Benutzern am häufigsten verwendet?
• Welche Funktionen werden von zahlenden Nutzern am wenigsten genutzt?
• Welche Funktionen führen zur Umwandlung von kostenlosen Benutzern in zahlende Benutzer?

Ereignisse und Ereigniseigenschaften

Sobald Sie eine Liste der brennenden Fragen haben (zwischen 5 und 10 ist eine gute Zahl für den Anfang), können Sie mit dem wichtigsten Schritt fortfahren – dem Definieren von Ereignissen und Ereigniseigenschaften.

Hier beginnen Sie schließlich mit der Erstellung eines Datenverfolgungsplans.

Neben den Kernereignissen sollten Sie auch über die verschiedenen Daten nachdenken, die Sie sammeln möchten, wenn ein bestimmtes Ereignis stattfindet. Dieses Handbuch enthält Beispiele für einige häufige Ereignisse und zugehörige Eigenschaften, die einen Kontext dafür bieten, wie man über diesen Prozess nachdenkt.

Im Folgenden werden einige weitere Dinge behandelt, die Sie wissen müssen, bevor Sie mit der Erstellung eines Tracking-Plans beginnen.

Klicks, Aufrufe und Prozesse

Es ist sehr wichtig, die Unterschiede zwischen Klicks, Aufrufen und Prozessen zu berücksichtigen, die in Ihrem Produkt stattfinden – jeder angeklickte Button, jede aufgerufene Seite oder jeder abgeschlossene Prozess kann als eindeutiges Ereignis nachverfolgt werden.

In einigen Fällen kann ein Ereignis auch als eines der drei Ereignisse verfolgt werden – ein Seitenaufruf, ein Klick auf eine Schaltfläche oder ein Prozessabschluss.

Sehen wir uns das anhand eines hypothetischen Anmeldeablaufs genauer an:

Zuerst klickt der Benutzer auf die Dabei kann das durchgeführte Ereignis entweder als Button-Klick (Anmelde-Button auf der Startseite) oder als Seitenaufruf (Anmeldeseite) getrackt werden.

Als Nächstes füllt der Benutzer das Registrierungsformular aus, klickt auf die Wenn alles gut geht, erreicht die Übermittlung die Datenbank und eine neue Zeile wird erstellt.

Hier kann das durchgeführte Ereignis als Schaltflächenklick (Senden-Schaltfläche), Seitenaufruf (Dankeseite) oder Prozessabschluss (neue Zeile in der Datenbank) nachverfolgt werden.

Wie Sie Ereignisse verfolgen, hängt daher vollständig von Ihren Anwendungsfällen ab, und manchmal kann es sogar sinnvoll sein, einen Klick auf eine Schaltfläche sowie einen Seitenaufruf oder den Abschluss eines Prozesses gleichzeitig zu verfolgen.

and sign up Wenn Ihr Ziel jedoch darin besteht, das Benutzerverhalten zu verstehen, sollten Sie Ereignisredundanz vermeiden, indem Sie sicherstellen, dass eine Benutzeraktion nicht mehrfach nachverfolgt wird ( Anmeldeschaltfläche angeklickt und Seite angesehen

. Um Seitenaufrufe zu verfolgen, können Sie für jede Seite ein eindeutiges Ereignis angeben, z. B. . Dadurch wird Ihre Ereignisliste jedoch lächerlich lang, wenn Sie die Seitenaufrufe für jede einzelne Seite verfolgen möchten.

Anstatt für jede Seite ein separates Ereignis zu definieren, können Sie ein generisches Ereignis mit dem Namen „ Seite angesehen “ mit Ereigniseigenschaften wie folgt angeben:

Schaltfläche angeklickt

Wie Seitenaufrufe sollten auch Klicks auf Schaltflächen über ein generisches Ereignis wie Schaltfläche angeklickt mit den zugehörigen Eigenschaften wie unten nachverfolgt werden:

Prozess abgeschlossen

Prozesse finden als Ergebnis einer Interaktion mit einer Datenbank statt, bei der Daten entweder geschrieben (in eine bestimmte Tabelle) oder (aus einer Tabelle) abgerufen werden – wenn die Interaktion fehlschlägt, schlägt der Prozess fehl.

Daher ist das Verfolgen des Abschlusses eines Prozesses die zuverlässigste Methode zum Verfolgen von Ereignissen, die auf dem Abschluss einer Interaktion mit der Datenbank beruhen.

Hier ist ein viel zu häufiges Szenario:

Ein Benutzer klickt nach dem Ausfüllen des Anmeldeformulars auf die Schaltfläche „Senden“, nur um einen Validierungsfehler wie „Das Passwort muss ein Sonderzeichen enthalten“ anzuzeigen. Hier hat der Benutzer das Ereignis Button Clicked ausgeführt, aber den Anmeldevorgang tatsächlich nicht abgeschlossen.

Wenn der Benutzer auf die Senden-Schaltfläche klickt, aber ein serverseitiger Fehler auftritt, schlägt der Vorgang ähnlich fehl und die Benutzerdaten gelangen nicht in die Datenbank. Obwohl der Benutzer das Anmeldeformular erfolgreich übermittelt hat, blieb der Anmeldevorgang unvollständig.

Daher ist es wichtig, über den gesamten Prozess (oder die Datenbankinteraktion) nachzudenken, der abgeschlossen sein sollte, wenn ein Ereignis stattfindet.

Darüber hinaus müssen Sie auch wissen, ob sich ein Benutzer für Ihr Produkt anmeldet, aber seine E-Mail-Adresse nicht verifiziert. Eine Möglichkeit, dies zu tun, besteht darin, zu überprüfen, ob sich Benutzer nach der Anmeldung anmelden (was nur passieren kann, nachdem die E-Mail-Adresse verifiziert wurde). Aber dann könnte es Benutzer geben, die die E-Mail verifizieren, sich aber nie anmelden.

Ein besserer Ansatz könnte daher darin bestehen, zwei separate Ereignisse zu verfolgen – Signed Up (Anmeldevorgang abgeschlossen) und Dadurch erfahren Sie auch, wie viele Personen sich anmelden, aber ihre E-Mail-Adresse nicht bestätigen, sodass Sie die Bestätigungs-E-Mail nach ein oder zwei Tagen erneut senden können.

Clientseitige vs. serverseitige Ereignisse

Ereignisse wie Klicks und Aufrufe, die nicht auf Datenbankinteraktionen (oder Backend-Prozessen) angewiesen sind, sind im Wesentlichen clientseitige Ereignisse.

Clientseitige Events finden ausschließlich auf dem Client (bzw. dem Gerät des Nutzers) statt und werden auch als Frontend-Events bezeichnet.

Andererseits werden Ereignisse, die auf Backend-Prozesse angewiesen sind, als serverseitige Ereignisse bezeichnet. Wie der Name schon sagt, finden serverseitige Ereignisse auf einem Server statt, wenn eine Datenbankinteraktion erfolgreich abgeschlossen wurde.

Serverseitige Ereignisse werden auch als Backend-Ereignisse bezeichnet.

Die Kenntnis des Unterschieds zwischen clientseitigen und serverseitigen Ereignissen hilft beim Instrumentierungsprozess, da die beiden Arten von Ereignissen normalerweise von verschiedenen Personen in einer Organisation implementiert werden.

Es ist immer hilfreich, die Ereignisquelle in Ihrem Tracking-Plan anzugeben, selbst wenn ein Full-Stack-Entwickler mit der Implementierung beider Arten von Ereignissen beauftragt ist.

Ereignisverfolgung nächste Schritte

Damit sind wir am Ende der fünfteiligen Serie zu Kundendaten angelangt. Beginnen Sie mit einem kostenlosen Amplitude-Konto, um noch heute mit der Verfolgung Ihrer Ereignisse zu beginnen.