Was sind die Bestandteile von Ereignisdaten?

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

Kundendaten umfassen Ereignisdaten und Entitätsdaten – das wissen Sie bereits, wenn Sie den ersten Teil durchgearbeitet haben (Was sind Kundendaten?).

In diesem Handbuch lernen Sie die Komponenten von Ereignisdaten, die bevorzugte Namenskonvention zum Definieren von Ereignissen, die Kategorien von Entitätsdaten und die zwei Haupttypen von Entitäten kennen.

Ereignisdaten

Da Sie wahrscheinlich bereits Waren online gekauft haben, beginnen wir mit einem E-Commerce-Beispiel.

Wenn Sie mit einer E-Commerce-App (Web oder Handy) interagieren, kaufen Sie normalerweise ein Produkt, indem Sie es in Ihren Warenkorb legen, zur Kasse gehen und die Zahlung abschließen – dies sind Ereignisse, die Sie ausführen, wenn Sie einen Artikel kaufen die App.

Die Reise des Käufers ist jedoch nicht so einfach und es gibt mehrere andere Ereignisse, die stattfinden können, wie zum Beispiel:

• Ein Produkt wird angesehen
• Der Warenkorb wird angezeigt
• Ein Produkt wird aus dem Warenkorb entfernt
• Ein Gutschein wird angewendet
• Eine Adresse wird ausgewählt
• Eine Zahlungsmethode wird ausgewählt
• Eine Bestellung ist abgeschlossen

Und so weiter.

Häufige Ereignisse wie „In den Warenkorb legen“, „Zur Kasse gehen “ und „Zahlung ausführen“ kommen einem sofort in den Sinn, aber um das Benutzerverhalten zu verstehen, muss man auch andere Ereignisse wie die oben erwähnten verfolgen.

Die Entscheidung, welche Ereignisse nachverfolgt werden sollen, und die Benennung der Ereignisse unter Verwendung einer geeigneten Namenskonvention sind die ersten beiden Schritte beim Sammeln von Ereignisdaten.

Was sind die nächsten zwei Schritte?

Schön, dass du gefragt hast!

Jedes Ereignis wird von Ereigniseigenschaften (oder Ereignisattributen ) begleitet, die mehr Kontext zu einem Ereignis bieten. Die Entscheidung, welche Eigenschaften einem Ereignis zugeordnet werden sollen, und die Benennung dieser Eigenschaften sind die nächsten beiden Schritte beim Sammeln von Ereignisdaten.

Was ist in einem Namen?

Wenn es um Daten geht, alles.

Eine angemessene Namenskonvention oder Taxonomie hebt gute Daten von schlechten Daten ab und ermöglicht es den Beteiligten zu verstehen, was sie sehen. Andererseits ist das Fehlen einer standardisierten Taxonomie eine der Hauptursachen dafür, dass Datensätze verzerrt oder durch Redundanz aufgebläht werden.

Wenn Sie mit Kundendaten arbeiten, ist es außerdem einer der größten Fehler, die Sie machen können, wenn Sie bei der Benennung von Ereignissen und Ereigniseigenschaften keine einheitliche Groß- und Kleinschreibung beibehalten – einer, der langfristige Auswirkungen haben kann. Eine gute Namenskonvention sollte immer von strengen Richtlinien für die Schreibweise begleitet werden.

Hier ist der Grund:

Add to Cart, added_to_cart, productAdded, add to cart, Added to cart, Product Added sind verschiedene Möglichkeiten, dasselbe Ereignis zu definieren.

Obwohl nichts davon per se falsch ist und es keine festgelegten Regeln für die Benennung von Ereignissen und Eigenschaften gibt, gibt es Best Practices, die man befolgen sollte.

Die Benennungskonvention für Objektaktionen ist so ziemlich zum Industriestandard geworden, und das aus gutem Grund – sie beschreibt eindeutig die Aktion, die bereits stattgefunden hat. Produkt hinzugefügt bedeutet definitiv, dass auf ein Objekt (Produkt) eine Aktion (hinzugefügt) folgt.

Erfahren Sie mehr über das Einrichten einer einheitlichen Taxonomie für Ihre Veranstaltungen .

Bestandteile von Ereignisdaten

Es gibt zwei Schlüsselkomponenten eines Ereignisses – eine Entität (eine oder mehrere) und Ereigniseigenschaften.

Das Zuordnen von Entitätsdaten wie user_id zu einem Ereignis liefert Informationen über den Benutzer, der das Ereignis ausgeführt hat.

In Ermangelung einer eindeutigen Kennung wie user_id bleiben Ereignisdaten anonym und es gibt keine Möglichkeit zu wissen, wer dieses Ereignis durchgeführt hat. In ähnlicher Weise muss im Kontext von B2B-SaaS, wo ein Benutzer potenziell mehreren Organisationen angehören kann, die Organisations -ID mit Ereignissen verknüpft werden, um zu wissen, wo Ereignisse stattfinden.

Neben Entitäten gibt es weitere Informationen, die zum Zweck der Analyse und Segmentierung gesammelt werden können, wenn Ereignisse stattfinden.

Zurück zum E-Commerce-Beispiel: Wenn ein Produkt gekauft wird, müssen Sie nicht nur wissen , wer den Kauf getätigt hat, sondern Sie müssen auch wissen, welches Produkt wann zu welchem ​​Preis gekauft wurde .

Diese zusätzlichen Informationen werden in Form von Ereigniseigenschaften gesammelt.

Im ersten Teil dieser Serie wurde erwähnt, dass Ereignisdaten drei Schlüsselelemente umfassen:

• Die Aktion oder das Ereignis, das stattgefunden hat
• Der Zeitstempel oder das genaue Datum und die Uhrzeit, wann das Ereignis stattfand
• Der Zustand oder alle anderen mit dem Ereignis verknüpften Eigenschaften (bekannt als Ereigniseigenschaften)

Sehen wir uns das Ereignis Product Added an (der Name in richtiger Schreibweise gemäß dem Objektaktions-Framework für das Ereignis Add to Cart ) und nehmen wir an, dass es von einem Benutzer am 1. Januar 2020 um 10:00 Uhr UTC ausgeführt wurde. Die bei der Veranstaltung erhobenen Daten umfassen Folgendes:

• Die Aktion: Produkt hinzugefügt
• Der Zeitstempel: 1577872800 (Unix-Zeitstempel für den ABZ 7.99 ( Der Status: 0123 ABZ 7,99 ( In diesem Beispiel sind die Eigenschaften, die dem Ereignis „ Produkt hinzugefügt “ zugeordnet sind , user_id, product_id, price und Quantity , die jeweils weitere Informationen über das Ereignis bereitstellen. Der Zeitstempel ist mit dem Ereignis verknüpft, um zu wissen, wann es stattgefunden hat.

  Es ist auch nützlich, einen Namen für den Zeitstempel anzugeben, der im Wesentlichen eine Ereigniseigenschaft ist. Dies ist nicht zwingend erforderlich, da die Standardpraxis darin besteht, den Zeitstempel als Zeitstempel mit jedem Ereignis zu verknüpfen, wenn Daten an Tools von Drittanbietern gesendet werden. Die Angabe eines eindeutigen Namens für die Eigenschaft, die den Zeitstempel speichert, kann jedoch auf lange Sicht hilfreich sein, wenn Sie mit historischen Ereignisdaten arbeiten müssen.

  Die empfohlene Taxonomie für Zeitstempel ist der Ereignisname gefolgt von „at“: product_added_at für das Ereignis Produkt hinzugefügt.

  Sie haben vielleicht schon bemerkt, dass snake_case verwendet wird, um Ereigniseigenschaften zu definieren, was es einfach macht, Ereignisnamen von Ereigniseigenschaften zu unterscheiden. Denken Sie jedoch daran, dass es hier keine vordefinierten Regeln gibt und Sie auswählen sollten, was für Sie und Ihr Team am besten geeignet ist.

  Hier ist ein letzter Blick auf die Eigenschaften, die mit dem Ereignis „Produkt hinzugefügt“ verknüpft sind, und die Datentypen jeder dieser Eigenschaften:

  

  Die Angabe des Datentyps für jede Eigenschaft stellt die Datenkonsistenz sicher und vereinfacht den Instrumentierungsprozess.

  

  Nebenbemerkung: Es ist gut zu bedenken, dass Es sollte nun klar sein, dass das Sammeln von Ereignisdaten die folgenden Schritte umfasst:

  • Entscheiden, welche Ereignisse verfolgt werden sollen
  • Benennen dieser Ereignisse unter Verwendung einer geeigneten Namenskonvention
  • Entscheiden, welche Eigenschaften jedem Ereignis zugeordnet werden sollen
  • Benennen dieser Eigenschaften unter Verwendung einer geeigneten Namenskonvention

  Der nächste (und letzte) Teil dieser Serie befasst sich mit der Entscheidung, welche Ereignisse verfolgt und welche Daten gesammelt werden sollen.

  Sie sollten jedoch eine gute Vorstellung davon haben, was Sie erwarten können, wenn Sie sich Ereignisdaten ansehen (ob in einem Tracking-Plan vor der Instrumentierung oder in einem Datenziel wie Ihrem Produktanalysetool).

  Einige allgemeine Ereignisse und ihre Eigenschaften

  Bevor Sie fortfahren, werfen Sie einen Blick auf einige häufige Ereignisse und Eigenschaften, die von den meisten technischen Produkten verfolgt werden.

  

  Entitätstypen

  Es ist an der Zeit, sich eingehend mit verschiedenen Entitäten und ihren Eigenschaften zu befassen. Wenn Sie dies noch nicht getan haben, gehen Sie diesen Leitfaden durch, um zu verstehen, wie sich Entitätsdaten auf Ereignisdaten beziehen.

  Im ersten Teil dieser Serie wurde erwähnt, dass von Benutzern geteilte Daten unter Entitätsdaten fallen. Das stimmt zwar, aber nicht alle Entitätsdaten werden von den Benutzern selbst geteilt – Entitätsdaten können auch generiert werden.

  Entitätsdaten umfassen Eigenschaften, die der Entität zugeordnet sind – wenn Benutzer die Entität ist, werden alle Informationen über einen Benutzer in Form von Benutzereigenschaften gesammelt.

  User_id wird standardmäßig für jeden Benutzer generiert, um Benutzer zu identifizieren (und dient als Kennung für Ereignisse).

  Vergessen Sie jedoch vorerst Ereignisse und denken Sie an die verschiedenen Informationen, die sich ausschließlich auf Benutzer beziehen und Ihnen etwas über ihre Eigenschaften mitteilen.

  Arten von Entitätsdaten

  Entitätsdaten können in die folgenden Buckets kategorisiert werden (auch in Teil 3 dieser Serie erwähnt):

  • Persönlich identifizierbare Informationen wie Demografische Daten wie Persona wie Präferenzen wie Produktspezifische Daten wie Die Datenelemente unter jedem Bucket fallen unter Benutzereigenschaften. Mit anderen Worten, Benutzereigenschaften speichern verschiedene Details und Merkmale über Benutzer, sodass Sie sie identifizieren und mehr über sie erfahren können.

    Während die meisten Informationen direkt vom Benutzer stammen, werden bestimmte Benutzereigenschaften im Laufe der Zeit automatisch als Ergebnis der Produktnutzung generiert.

    Aber werden nicht auch Ereignisdaten durch die Produktnutzung generiert?

    Es ist sicher – Benutzereigenschaften sind zusätzliche Details zu einem Ereignis, die gesammelt werden, wenn das Ereignis stattfindet. Werfen wir einen Blick auf das Signed Up -Ereignis und seine Eigenschaften:

    

    Wie Sie sehen können, stellen alle mit diesem Ereignis verknüpften Eigenschaften Details zu Benutzern bereit – Details, die entweder von den Benutzern selbst geteilt werden ( first_name, last_name, email, phone, country ) oder automatisch generierte Details ( signed_up_at, user_id ).

    Es ist hilfreich, Folgendes zu beachten:

    • Einige Ereignisse wie „Angemeldet“ oder „E- Die meisten Benutzereigenschaften mit Ausnahme von Zeitstempeln und Kennungen können geändert werden. Ein Benutzer kann seinen Namen, seine E-Mail-Adresse, sein Telefon, seinen Standort, seine Branche, seine berufliche Rolle usw. ändern. Der Zeitpunkt der Anmeldung (signed_up_at) oder die eindeutige Kennung (user_id) kann jedoch nicht vom Benutzer geändert werden.

    Benutzereigenschaften im Vergleich zu Organisationseigenschaften

    Bei Verbraucher-Apps sind verbrachte Zeit, gekaufte Produkte, gespielte Songs oder angesehene Videos Eigenschaften, die dem Benutzer zugeordnet sind und als Benutzereigenschaften gespeichert werden, deren Werte mit zunehmender Nutzung ständig aktualisiert werden.

    Im Kontext von B2B-SaaS sind Benutzer und Organisation die Hauptentitäten, und die erfassten Ereignisse sind an einen Benutzer oder eine Organisation (oder beides) gebunden.

    Es könnte andere Gruppeneinheiten wie Teams oder Projekte geben, an die bestimmte Daten gebunden sind, wie es bei den meisten Produktivitätstools der Fall ist – der Prozess der Erfassung von Organisationsdaten ist auch in solchen Fällen anwendbar.

    Werfen wir einen Blick auf einige allgemeine Benutzereigenschaften, die für B2B-SaaS-Produkte relevant sind:

    

    Wenn ein Benutzer Teil einer Organisation ist, sind viele wichtige Informationen an die Organisation und nicht an den Benutzer gebunden.

    Einige allgemeine Organisationseigenschaften (auch als Gruppeneigenschaften bezeichnet) lauten wie folgt:

    

    Es ist wichtig zu bedenken, dass die Organization_id auch als Kennung fungiert und mit Ereignissen verknüpft werden sollte, um zu wissen, unter welcher Organisation ein bestimmtes Ereignis stattgefunden hat.

    Beachten Sie die folgenden Aussagen, um zwischen Benutzereigenschaften und Organisationseigenschaften zu unterscheiden:

    • Alle Informationen, die dabei helfen, Benutzerkohorten zu definieren – woher sie kommen, wer sie sind, was ihr Ziel ist oder was sie in einem Produkt tun – werden als Benutzereigenschaft gespeichert.
    • Alle Informationen, die bei der Segmentierung von Konten oder Organisationen helfen – der Kontotyp, der generierte Umsatz, die verwendeten Produkte oder Funktionen, die verbrauchten Ressourcen oder die Anzahl der Benutzer, die Teil davon sind – werden als Organisationseigenschaft gespeichert ( oder Gruppeneigentum).

    Sobald Sie zwischen den oben genannten unterscheiden können, wird es einfach, neue Einheiten (wie Teams oder Projekte) in den Mix einzubringen.

    Nächste Schritte

    Sie sollten jetzt ein klares Verständnis dafür haben, wie Sie Ereignisse und ihre zugehörigen Eigenschaften definieren und die Eigenschaften jeder Entität (Benutzer und Organisation) angeben.

    Beginnen Sie mit einem kostenlosen Amplitude-Konto, um noch heute mit der Definition von Ereignissen und der Organisation Ihrer Daten zu beginnen.