Quels sont les composants des données d'événement ?

Publié: 2022-05-12

Il s'agit de la quatrième partie de la série en cinq parties sur les données client. Voici les parties un, deux et trois.

Les données client comprennent les données d'événement et les données d'entité - vous le savez déjà si vous avez parcouru la première partie (Qu'est-ce que les données client ?).

Dans ce guide, vous découvrirez les composants des données d'événement, la convention de dénomination préférée pour définir les événements, les catégories de données d'entité et les deux principaux types d'entités.

Données d'événement

Puisque vous avez probablement acheté des choses en ligne, commençons par un exemple de commerce électronique.

Lorsque vous interagissez avec une application de commerce électronique (Web ou mobile), vous achetez généralement un produit en l'ajoutant à votre panier, en procédant à la caisse et en effectuant le paiement. Ce sont des événements que vous effectuez lorsque vous passez par le processus d'achat d'un article sur l'application.

Cependant, le parcours de l'acheteur n'est pas si simple et plusieurs autres événements peuvent avoir lieu, tels que :

Un produit est visualisé
Le panier est visualisé
Un produit est retiré du panier
Un coupon est appliqué
Une adresse est choisie
Un mode de paiement est choisi
Une commande est terminée

Etc.

Des événements courants tels que Ajouter au panier, Passer à la caisse et Effectuer un paiement viennent immédiatement à l'esprit, mais pour comprendre le comportement des utilisateurs, il faut également suivre d'autres événements comme ceux mentionnés ci-dessus.

Décider quels événements suivre et nommer les événements à l'aide d'une convention de dénomination appropriée sont les deux premières étapes du processus de collecte des données d'événement.

Quelles sont les deux prochaines étapes ?

Heureux que vous ayez demandé !

Chaque événement est accompagné de propriétés d'événement (ou attributs d'événement ) qui fournissent plus de contexte sur un événement. Décider quelles propriétés associer à un événement et nommer ces propriétés sont les deux prochaines étapes du processus de collecte des données d'événement.

Qu'est-ce qu'il y a dans un nom?

Quand il s'agit de données, tout.

Une convention de dénomination ou une taxonomie appropriée est ce qui distingue les bonnes données des mauvaises données et permet aux parties prenantes de comprendre ce qu'elles regardent. Le fait de ne pas maintenir une taxonomie normalisée, en revanche, est l'une des principales causes des ensembles de données biaisés ou gonflés par la redondance.

De plus, lorsque vous travaillez avec des données client, ne pas maintenir une casse uniforme lors de la dénomination des événements et des propriétés d'événement est l'une des plus grosses erreurs que vous puissiez commettre, une erreur qui peut avoir des ramifications à long terme. Une bonne convention de nommage doit toujours être accompagnée de directives strictes en matière de casse.

Voici pourquoi:

Ajouter au panier, added_to_cart, productAdded, add to cart, Added to cart, Product Added sont différentes manières de définir le même événement.

Bien qu'aucun de ceux-ci ne soit faux en soi et qu'il n'y ait pas de règles définies en ce qui concerne la dénomination des événements et des propriétés, il existe des bonnes pratiques que l'on devrait envisager de suivre.

La convention de dénomination objet-action est à peu près devenue la norme de l'industrie et pour cause, elle décrit clairement l'action qui a déjà eu lieu. Produit ajouté signifie définitivement qu'un objet (produit) est suivi d'une action (ajouté).

En savoir plus sur la mise en place d'une taxonomie cohérente pour vos événements .

Composants des données d'événement

Un événement comporte deux composants clés : une entité (une ou plusieurs) et des propriétés d'événement.

L'association de données d'entité telles que user_id à un événement fournit des informations sur l'utilisateur qui a exécuté l'événement.

En l'absence d'un identifiant unique comme user_id , les données d'événement resteront anonymes et il n'y aura aucun moyen de savoir qui a effectué ledit événement. De même, dans le contexte du SaaS B2B, où un utilisateur peut potentiellement faire partie de plusieurs organisations, organization_id doit être associé à des événements pour savoir où les événements ont lieu.

Outre les entités, il existe d'autres informations qui peuvent être collectées à des fins d'analyse et de segmentation lorsque des événements se produisent.

Pour en revenir à l'exemple du commerce électronique, lorsqu'un produit est acheté, en plus de savoir qui a effectué l'achat, à tout le moins, vous devez également savoir quel produit a été acheté à quel prix et quand .

Ces informations supplémentaires sont rassemblées sous la forme de propriétés d'événement .

Dans la première partie de cette série, il a été mentionné que les données sur les événements comprennent trois éléments clés :

L'action ou l'événement qui a eu lieu
L'horodatage ou la date et l'heure précises auxquelles l'événement a eu lieu
L'état ou toutes les autres propriétés associées à l'événement (appelées propriétés d'événement)

Examinons l'événement Product Added (le nom dans Proper Case selon le framework objet-action pour l'événement Add to Cart ) et supposons qu'il a été exécuté par un utilisateur le 1er janvier 2020 à 10 h UTC. Les données recueillies lorsque l'événement a eu lieu comprennent les éléments suivants :

L'action : Produit ajouté
L'horodatage : 1577872800 (horodatage Unix du ABZ 7.99 ( L'état : 0123 ABZ 7,99 ( Selon cet exemple, les propriétés associées à l'événement Product Added sont user_id, product_id, price et quantity , chacune fournissant plus d'informations sur l'événement. L' horodatage est associé à l'événement pour savoir quand il a eu lieu.

Il est également utile de spécifier un nom pour l'horodatage qui est essentiellement une propriété d'événement. Il n'est pas obligatoire de le faire car la pratique courante consiste à associer l'horodatage en tant qu'horodatage à chaque événement lors de l'envoi de données à des outils tiers ; cependant, spécifier un nom distinct pour la propriété qui stocke l'horodatage peut être utile à long terme lorsque vous devez travailler avec des données d'événements historiques.
La taxonomie recommandée pour les horodatages est le nom de l'événement suivi de « at » : product_added_at pour l'événement Product Added.

Vous avez peut-être déjà remarqué que snake_case est utilisé pour définir des propriétés d'événement, ce qui facilite la distinction entre les noms d'événement et les propriétés d'événement. Cela dit, gardez à l'esprit qu'il n'y a pas de règles prédéfinies ici et que vous devez choisir ce qui fonctionne le mieux pour vous et votre équipe.
Voici un dernier aperçu des propriétés associées à l'événement Product Added et des types de données de chacune de ces propriétés :
La spécification du type de données pour chaque propriété garantit la cohérence des données et facilite le processus d'instrumentation.

Remarque complémentaire : il est bon de garder à l'esprit que Il devrait maintenant être clair que la collecte de données d'événement comprend les étapes suivantes :
Décider quels événements suivre
Nommer ces événements en utilisant une convention de dénomination appropriée
Décider des propriétés à associer à chaque événement
Nommer ces propriétés en utilisant une convention de dénomination appropriée
La prochaine (et dernière) partie de cette série couvre le processus de décision des événements à suivre et des données à collecter.
Cependant, vous devez avoir une bonne idée de ce à quoi vous attendre lorsque vous examinez les données d'événement (que ce soit dans un plan de suivi avant l'instrumentation ou dans une destination de données telle que votre outil d'analyse de produit).
Quelques événements courants et leurs propriétés
Avant de continuer, jetez un œil à quelques événements et propriétés courants qui sont suivis par la plupart des produits technologiques.
Types d'entités
Il est temps d'examiner en profondeur différentes entités et leurs propriétés. Si vous ne l'avez pas déjà fait, parcourez ce guide pour comprendre comment les données d'entité sont liées aux données d'événement.
Dans la première partie de cette série, il a été mentionné que les données partagées par les utilisateurs relèvent des données d'entité. Bien que cela soit vrai, toutes les données d'entité ne sont pas partagées par les utilisateurs eux-mêmes. Des données d'entité peuvent également être générées.
Les données d'entité comprennent les propriétés associées à l'entité. Si l'utilisateur est l'entité, toutes les informations sur un utilisateur sont rassemblées sous la forme de propriétés utilisateur.
User_id est généré par défaut pour chaque utilisateur afin d'identifier les utilisateurs (et agit comme un identifiant pour les événements.)
Cela dit, pour le moment, oubliez les événements et pensez aux différentes informations qui concernent exclusivement les utilisateurs et vous renseignent sur leurs traits.
Types de données d'entité
Les données d'entité peuvent être classées dans les catégories suivantes (également mentionnées dans la partie 3 de cette série) :
Informations personnellement identifiables telles que Données démographiques telles que Persona tel que Préférences telles que les Données spécifiques au produit telles que les Les éléments de données sous chaque compartiment relèvent des propriétés utilisateur. En d'autres termes, les propriétés de l'utilisateur stockent divers détails et caractéristiques sur les utilisateurs, vous permettant de les identifier et d'en savoir plus à leur sujet.
Alors que la plupart des informations proviennent directement de l'utilisateur, certaines propriétés de l'utilisateur sont générées automatiquement au fil du temps en raison de l'utilisation du produit.
Mais les données d'événement ne sont-elles pas également générées en raison de l'utilisation du produit ?
C'est sûr - les propriétés de l'utilisateur sont des détails supplémentaires liés à un événement recueillis lorsque l'événement a lieu. Jetons un coup d'œil à l'événement Signed Up et à ses propriétés :
Comme vous pouvez le voir, toutes les propriétés associées à cet événement fournissent des détails sur les utilisateurs, des détails partagés par les utilisateurs eux-mêmes ( first_name, last_name, email, phone, country ) ou des détails générés automatiquement ( connected_up_at, user_id ).
Il est utile de garder à l'esprit ce qui suit :
Certains événements tels que Signed Up ou La plupart des propriétés utilisateur qui excluent les horodatages et les identifiants sont susceptibles d'être modifiées. Un utilisateur peut modifier son nom, son adresse e-mail, son téléphone, son emplacement, son secteur d'activité, sa fonction, etc. Mais l'heure de l'inscription (signed_up_at) ou l'identifiant unique (user_id) ne peut pas être modifié par l'utilisateur.
Propriétés de l'utilisateur et propriétés de l'organisation
Avec les applications grand public, le temps passé, les produits achetés, les chansons jouées ou les vidéos regardées sont des propriétés associées à l' utilisateur stockées en tant que propriétés utilisateur, dont les valeurs sont constamment mises à jour avec une augmentation de l'utilisation.
Dans le contexte du SaaS B2B, l'utilisateur et l'organisation sont les entités principales, et les événements collectés sont liés à un utilisateur ou à une organisation (ou aux deux).
Il peut y avoir d'autres entités de groupe telles qu'une équipe ou un projet avec certaines données qui leur sont liées, comme c'est le cas avec la plupart des outils de productivité - le processus de collecte des données de l' organisation est également applicable dans de tels cas.
Examinons quelques propriétés utilisateur courantes pertinentes pour les produits SaaS B2B :
Lorsqu'un utilisateur fait partie d'une organisation , de nombreuses informations importantes sont liées à l'organisation et non à l'utilisateur.
Certaines propriétés d'organisation courantes (également appelées propriétés de groupe ) sont les suivantes :
Il est important de garder à l'esprit que l' organization_id agit également comme un identifiant et doit être associé à des événements pour savoir sous quelle organisation un certain événement a eu lieu.
Garder à l'esprit les déclarations suivantes peut aider à différencier les propriétés utilisateur des propriétés de l'organisation :
Chaque élément d'information qui aide à définir les cohortes d'utilisateurs (d'où ils viennent, qui ils sont, quel est leur objectif ou ce qu'ils font à l'intérieur d'un produit) est stocké en tant que propriété utilisateur .
Chaque élément d'information qui aide à segmenter les comptes ou les organisations - le type de compte, les revenus qu'il génère, les produits ou fonctionnalités qu'il utilise, les ressources qu'il consomme ou le nombre d'utilisateurs qui en font partie - est stocké en tant que propriété de l'organisation ( ou propriété de groupe).
Une fois que vous pouvez différencier les éléments ci-dessus, il devient facile d'intégrer de nouvelles entités (telles que des équipes ou des projets) dans le mix.
Prochaines étapes
Vous devriez maintenant avoir une compréhension claire de la façon de définir les événements et leurs propriétés associées, ainsi que de spécifier les propriétés de chaque entité (utilisateur et organisation).
Pour commencer à définir des événements et à organiser vos données dès aujourd'hui, lancez-vous avec un compte Amplitude gratuit.