Cet article a été initialement publié sur medium.com

Avoir des utilisateurs qui se promènent dans votre application pour parcourir son contenu, regarder des vidéos, et cela tout en vivant une expérience personnalisée semble aujourd’hui être LE modèle à suivre pour n’importe quelle plateforme basée sur du contenu. Quelle technologie se cache derrière ce genre de fonctionnalité ?

C’est la question à laquelle nous allons répondre au fil de cette suite de 3 articles.

En partant du premier évènement tracké et en allant jusqu’à la dernière requête de recommandation, notre objectif est de montrer précisément comment implémenter une architecture permettant de mettre en place une telle fonctionnalité.

Dans cette optique, nous avons créé une application d’exemple qui récupère du contenu depuis l’API YouTube. Elle permet ainsi aux utilisateurs de consulter et suivre des chaînes mais aussi de regarder et liker des vidéos. Cette application va être utilisée tout au long de cette suite d’articles pour illustrer nos propos.

Nous avons pris la décision technique d‘utiliser Mixpanel pour suivre nos utilisateurs, et Amazon Web Services (AWS S3, Glue and Personalize) pour construire cette architecture de recommandation de contenu.

Si vous êtes plutôt intéressé par la création d’un pipeline d’ETL avec AWS Glue pour transformer un dataset, vous pouvez directement lire le second article : La recommandation de A à Z [2/3] : transformer la donnée avec AWS Glue.

Enfin, si ce qui vous intéresse réellement est l’implémentation d’un moteur de recommandation à l’aide de AWS Personalize, le dernier article est fait pour vous : La recommandation de A à Z [3/3]: créer et exposer un modèle AWS Personalize.

Avant de commencer, assurez vous d’avoir un compte Mixpanel avec la fonctionnalité de Data Pipelines active. De même, il vous faudra un compte AWS avec la facturation configurée.

C’est parti!

Qu’est-ce que Mixpanel?

D’après Mixpanel,

Mixpanel est un outil qui vous permet d’analyser la façon dont les utilisateurs interagissent avec votre produit connecté à Internet. Il est conçu pour rendre les équipes plus efficaces en permettant à chacun d’analyser les données des utilisateurs en temps réel pour identifier les tendances, comprendre le comportement des utilisateurs et prendre des décisions concernant votre produit. Il utilise un modèle centré sur l’utilisateur et basé sur les événements qui relie chaque interaction à un seul utilisateur. Le modèle de données de Mixpanel est construit sur les concepts d’utilisateurs, d’événements et de propriétés.

Du point de vue d’un développeur/entrepreneur, Mixpanel est un outil très puissant quand il s’agit d’analyser et de comprendre comment vos utilisateurs intéragissent avec votre produit (votre application). Il est possible de créer des cohortes, des tableaux de bord, de gérer vos utilisateurs, …, et de tout connecter avec pleins d’autres produits ou services. Par exemple, vous pouvez créer des cohortes et connecter Mixpanel à Braze pour créer une campagne de communication basée sur ces cohortes.

Mixpanel offre un SDK disponible pour de nombreuses plateformes (Java, Python, Android, IOS, …, et même React Native et Flutter) et très simple d’utilisation. Vous avez seulement besoin de spécifier l’ID de votre projet Mixpanel pour commencer à envoyer des évènements.

Traquez vos utilisateur avec Mixpanel

Grâce à Mixpanel, il vous est possible de traquer les utilisateurs de votre service.

Concrètement, cela signifie que chaque utilisateur se voit associé un identifiant unique, et toutes ses actions sont liées à cet ID. De cette manière, chaque utilisateur a un profil contenant toutes les informations dont vous avez besoin dans votre projet Mixpanel, et celui-ci est relié à un historique des évènements que vous avez traqué.

Un évènement Mixpanel peut réprésenter n’importe interactions de vos utilisateurs que vous jugez intéressante dans votre application. Par exemple, il peut s’agir d’un like sur une publication, l’achat d’un article ou même tout simplement la connexion de l’utilisateur à l’application.

Voici un exemple d’évènement :

Comme vous pouvez le voir, un évènement porte un nom que vous pouvez chosir (ici likeEvent). Ensuite, chaque évènement est accompagné d’une liste de propriétés qui peuvent être séparées en deux catégories :

• les propriétés personalisées
• les propriétés de Mixpanel

Il est possible de mettre n’importe quelle information dont vous avez besoin dans les propriétés d’un évènement, cela correspond aux propriétés personnalisées. Ensuite, Mixpanel ajoute automatiquement des propriétés à vos évènements, tel que l’identifiant unique de l’utilisateur qui a déclenché l’évènement et d’autres informations comme par exemple le moment auquel l’évènement à eu lieu.

Voyons maintenant à quoi ressemble le tracking en termes de code avec le SDK Mixpanel !

Le SDK Mixpanel donne accès à des bibliothèques pour des langages/frameworks variés tels que Python, React Native et Node.js. Il est donc aussi bien possible de travailler côté client que côté serveur.

Dans notre cas, nous avons créé une application à l’aide de Flutter qui permet aux utilisateurs d’intéragir avec du contenu YouTube (vidéos, chaînes et playlists). C’est pourquoi les echantillons de code suivants sont des exemples réalisé avec la bibliothèque Flutter du SDK Mixpanel.

Tout d’abord, il faut créer une instance Mixpanel avant de pouvoir commencer le tracking :

De cette manière, vous avez accès à votre instance Mixpanel partout dans votre application. Nous avons choisi cette approche étant donné que chaque écran de notre application peut déclencher des évènements Mixpanel.

Remarque : vérifiez bien l’url que vous spécifiez, ici nous utilisons api-eu.mixpanel.com puisque nous sommes en Europe.

Traquer des évènements

Traquer des évènements avec le SDK est aussi simple que ça :

Cet exemple traque un like d’un utilisateur sur une vidéo de notre application. Le premier paramètre est le nom à donner à l’évènement. Ensuite, le paramètre properties est un objet dans lequel vous pouvez ajouter vos propre propriétés. Par exemple, ici nous avons ajouté des informations concernant la vidéo (liké?) telles son auteur et le titre.

Traquer des utilisateurs

Traquer les utilisateurs à l’aide du SDK est un peu plus délicat en termes de logique, mais cela reste aussi que pour les évènements du côté du code. Si vous les détails du fonctionnement vous intéressent, nous vous invitont à lire la documentation. Pour notre application d’exemple, nous avons fait le choix de ne pas gérer l’identité des utilisateur comme ce serait fait pour une application en production avec un backend étant donné qu’il s’agit juste d’un exemple.

Pour gérer l’identité des utilisateurs nous avons donc simplement utilisé ce bout de code :

Pour choisir quel utilisateur est traqué dans notre application, nous avons implémenté un écran de connexion simple qui permet directement de choisir l’identifiant de l’utilisateur. Cet identifiant unique est transmis à la méthode identify pour lier tous les futurs évènement à cet utilisateur. Appeler cette méthode avec un identifiant inexistant va juste créer un nouveau profil utilisateur du côté de Mixpanel, ce qui ne pose pas de problème pour notre exemple.

Générer des données pour un projet Mixpanel

Souvenez-vous, l’objectif final de cette série d’articles est d’entraîner une solution de recommandation personnalisée en se basant sur les données que l’on traque à l’aide de Mixpanel. Pour atteindre cet objectif, une quantité de données importante est nécessaire.

Cependant, notre application d’exemple est uniquement utilisée par les développeurs (nous) pour la tester. Cela n’est donc évidemment pas suffisant pour obtenir un nombre important d’utilisateurs et d’évènement à exploiter.

Heureusement pour nous, le SDK Mixpanel offre un support pour Python, il nous a donc suffit de créer un script de génération d’utilisateurs et d’évènements. Nous n’avons pas jugé nécessaire d’ajouter le code correspondant ici, étant donné que c’est très similaire à ce qui est illustré pour Dart plus haut.

Configurer un pipeline de données

La fonctionnalité de pipelines de données de Mixpanel vous permet de connecter vos projets Mixpanel à votre data lake dans le Cloud pour différents fournisseurs tels que Google Cloud et Amazon Web Services. Ici, nous allons utiliser cette fonctionnalité pour connecter notre projet au stockage d’Amazon Web Services.

Pour gérer les pipelines de données de Mixpanel, c’est par ici. Nous voulons créer un pipeline pour exporter nos utilisateurs et nos évènements vers AWS S3. Cela se passe dans la section Data Pipelines API en bas du menu de gauche :

Cliquez sur l’option Create pipeline pour commencer la création de notre export vers S3.

Tout d’abord, il faut renseigner notre secret API token à la requête pour créer un pipeline pour le bon projet Mixpanel :

Vous pouvez trouver ce bouton à droite de l’URL de la requête. Votre project API secret est récupérable dans les paramètres de votre projet, dans la section Access Keys :

Ceci étant fait, il est maintenant possible de choisir un type de pipeline. Ce que nous voulons ici est un pipeline vers AWS S3, c’est pourquoi on sélectionne ‘AWS S3 or Glue’ dans le menu déroulant :

Nous pouvons maintenant nous intéresser à la configuration du pipeline. LA première chose demandée est le type, mais ici un seul type est disponible (aws) et il est renseigné par défaut donc aucune action n’est nécessaire.

Ensuite, il faut choisir une valeur pour le paramètre trial. Cette valeur mise à true vous donnera une configuration par défaut de votre pipeline. Dans notre cas, nous la mettons à false comme cette configuration ne correspond pas à nos besoins.

Remarque : La valeur par défaut est censée être false mais est en fait mise à true lorsque l’on arrive sur la page, soyez donc attentif quand vous voulez retirer cette fonctionnalité.

Le paramètre suivant, data schema type, concerne le type de schéma des données à exporter, qui peut être monoschema ou multischema. Étant donné que nos évènements ne possèdent pas les mêmes propriétés il est plus approprié de les stocker dans des tables différentes, donc nous choisissons multischema.

Pour continuer, une source de données (data source) nous est demandée pour le pipeline que l’on créé. Il est possible de choisir en users and events. Pour notre application d’exemple, nous avons besoin d’exporter les données de chacune de ces sources vers S3. Cela signifie que nous allons devoir créer 1 pipeline de données pour chaque source. Ne vous inquiétez pas, la configuration est quasiment identique et aussi simple pour les deux.

Le paramètre sync vaut false par défaut. Le passer à true permet de mettre à jour automatiquement les données précédemment exportées dès qu’il y a un changement dans les données du projet Mixpanel. Nous choisissons de mettre true. Cela peut se révéler utile si par exemple vous envoyez votre évènement immédiatement au moment où il occure mais qu’il vous faut ensuite y ajouter une propriété à laquelle vous n’aviez pas encore accès (appel API) au moment de l’envoi.

Remarque : Au moment ou nous écrivons cet article, mettre sync à true n’est pas possible pour un pipeline ayant pour source de données les utilisateurs.

Les deux paramètres suivants, from_date et to_date, permettent simplement d’exporter les données correspondant à une fenêtre temporelle fixée. Nous n’allons pas utiliser cette fonctionnalité ici, bien qu’elle puisse se révéler utile si, par exemple, vos évènements et utilisateurs les plus anciens sont juste des données de test que vous ne souhaitez pas exporter. Pour avoir une fenêtre indéfinie et exporter des donées “pour toujours”, il suffit de laisser to_date vide et de mettre la date de création de votre projet pour from_date (qui est un paramètre obligatoire).

Pour une fenêtre indéfinie, nous pouvons ensuite choisir à quelle fréquence exporter nos données avec le paramètre frequency. Nous choisissons hourly, et c’est d’ailleurs l’une des raisons pour lesquelles nous avons mis trial à false. En effet, la configuration d’essai met la fréquence à daily, or nous ne souhaitons pas attendre une journée entière pour que nos données arrive sur S3.

Le dernier ensemble de paramètres à propos des données Mixpanel, events et where, vous offrent la possibilité de filtrer les données à envoyer à l’aide des noms d’évènements et de leurs propriétés. Nous ne l’utiliserons pas ici étant donné que nous voulons exporter toutes nos données d’un coup mais cela peut être utile selon vos besoins.

Ensuite, choisissez un data format comme ci-dessous :

On peut choisir entre parquet ou json, dans notre cas nous optons pour json.

Maintenant, nous pouvons commencer à donner au pipeline des informations à propos de S3 et Glue. Voici les informations pricipales qui sont requises par le pipeline :

Le s3_prefix sera le nom du dossier racine qui va contenir vos données importées.

Pour le role, quelques étapes supplémentaires sont nécessaires. La documentation de Mixpanel les explique parfaitement, mais nous allons voir une version légèrement plus courte ici. En bref, vous allez devoir créer une policy et un role directement liés au compte AWS principal de Mixpanel, pour l’autoriser à écrire dans votre destination S3.

Pour commencer, rendez-vous sur le portail AWS et ouvrez la console IAM. Vous allez devoir créer une policy (avec le nom de votre choix), ce qui va vous autoriser à lire et écrire dans S3 (PutObject, GetObject, ListBucket et DeleteObject).

Après la création de cette policy, il faut l’associer à un nouveau role dédié à Mixpanel. Retournez à votre console IAM, allez dans la section roles et cliquez sur “create role”. Ensuite, sélectionnez “Another AWS Account” comme type d’entité de confiance (trusted entity). Saisissez l’ID du compte Mixpanel : 485438090326. Vous pouvez maintenant associer la policy que vous avez créé à ce role, et valider la création. Enfin, il vous reste à changer la relation de confiance de ce role : trouvez votre role, cliquez dessus, allez à “Trust relationships” puis “Edit trust relationship”.

Dans l’éditeur JSON, vous avez juste à mettre à jour l’objet “Principal” à sa ligne “AWS” avec l’ARN suivant :

arn:aws:iam::485438090326:user/mixpanel-export.

Et c’est tout !

Les dernières valeurs à remplir concernent le chiffrement S3 que nous n’utilisaons pas ici, et la configuration de Glue. Nous avons dans un premier temps essayé d’utiliser Glue, mais nous l’avons finalement retiré du pipeline et utilisé plus tard dnas la console AWS. Ceci sera expliqué plus loin dans cet article.

Pour terminer, vous pouvez créer votre pipeline en cliquant sur le bouton “Send” en haut de la page ou alors en copiant la requête sur la droite de la page pour la lancer avec votre outil préféré (curl par exemple).

Remarque : vérifiez bien l’URL utilisée dans la requête, par défaut c’est data.mixpanel.com mais comme nous sommes en Europe, cette valeur par défaut ne fonctionne pas. Si vous travaillez depuis l’Europe utilisez l’URL suivante : data-eu.mixpanel.com.

Mixpanel va maintenant exporter vos données chaque heure ou jour selon votre configuration.

Les fichiers de votre bucket S3 suivront ce motif : s3://{votre-bucket}/[prefixe]/{mixpanel_project_id}/{mixpanel_event_name}/{year}/{month}/{day}/your-dataset.json.gz.

Par exemple dans notre cas : s3://mixpanel-export/lm_/123456789/likeevent/2021/05/15/un-dataset.json.gz.

Maintenant que nos données sont continuellement exportées vers notre bucket S3, il est temps de de référencer leur structure et de créer notre jeu de données !

Referencez vos données avec Glue Data Catalog

Qu’est-ce que AWS Glue et Glue Data Catalog?

Comme nous le verrons dans le prochain article de cette série, il est possible d’utiliser AWS Glue pour référencer et traiter nos données. Dans cet article, nous n’allons pas essayer de définir exactement ce qu’est Glue. Nous dirons simplement que c’est le “service d’intégration de données” d’AWS, ce qui correspond globalement à de l’ETL et des outils autour de l’ETL. Glue permet de visualiser, préparer, structurer et étudier vos données.

Le Glue Data Catalog est la partie de AWS Glue dédiée à la structuration de vos données. Il se comporte comme une base de données NoSQL, où vous enregistrez des bases de données et des tables. Chaque table est décrite pas un schéma (les colonnes d’un jeu de données), et référence un chemin vers l’endroit où est localisée la donnée. Ce chemin peut soit être un chemin vers un bucket AWS S3, soit une référence vers AWS Kinesis/Apache Kafka (Glue Data Catalog peut aussi être utilisé pour structurer vos pipelines d’évènements).

Ceci étant fait, ces tables peuvent être utilisées dans pleins d’autres services d’AWS (Athena, Glue Jobs que nous verront dans le prochain article, mais aussi beaucoup d’autres) et sont très efficaces pour simplifier la façon dont vous accédez à vos données.

Glue Data Catalog et Mixpanel

Dans les étapes précédentes, nous avions choisi de ne pas sélectionner l’option de Mixpanel qui créé des tables Glue Data Catalog (au niveau des pipelines). Au cours de notre exploration du service, nous avons rencontré des problème en fonctionnant avec cette option.

Dans le Glue Data Catalog, il est possible de partitionner vos données, et la partition dans laquelle un enregistrement est localisé est symbolisée par une clé de partition pour chaque enregistrement dans la table. Dnas notre cas, Mixpanel créé une hiérarchie de dossiers basée sur la date de sortie des données. Ainsi, pour un export de 8h à 9h le 20 mai 2021, les données en sortie seront localisées dans s3://…/évènement/2021/05/20/contenu.json. Mixpanel créée donc bien une partition basée sur la date. Cependant, quand on lui demande de créer une entrée Glue Data Catalog (la base de données et les tables), il créé seulement les tables avec le schéma et le lien vers le répertoire de base des évènements dans S3, sans aucune clé de partition pour la date. En conséquence, quand vous voulez accéder à ces données, vos outils ne savent pas où regarder pour les trouver étant donné qu’ils ne connaissent aucune partition et aucune structure associé à celles-ci.

C’est pourquoi nous devons référencer nos données par nous-mêmes, et c’est exactement ce à quoi servent les Glue Crawlers. Les AWS Glue Crawlers sont des programmes conçus pour parcourir une arborescencede fichier entière et ainsi découvrir comment est structurée la donnée. Ensuite, ils peuvent alors créer ou mettre à jour les table de Glue Data Catalog pour mettre en accord les chemins et les schémas des données.

Créer des Crawlers (Analyseurs)

Pour créer votre premier crawler, il vous suffit d’aller dans AWS Glue et de sélectionner l’onglet “Crawlers”. Ensuite, cliquez sur le bouton “Add Crawler” et c’est parti !

Après avoir choisi le nom de votre Crawler, vous pouvez continuer en configurant son comportement à l’exploration de vos données.

Notre source est un data store, et il est possible que Mixpanel écrive plusieurs fois dans le même dossier (nous l’avons configuré pour exporter les données toutes les heures), c’est pourquoi nous choisissons d’explorer tous les dossiers (crawl all folders). Un crawler peut être lancé plusieurs fois si vos données changent de structure au court du temps.

Ensuite il faut configurer la connection à la source de données. Ici, nous pouvons choisir entre différents classiques : JDBC driver, AWS DynamoDB, … ou AWS S3. Nous choisissons le dernier.

En cliquant sur “Add Connection”, une nouvelle fenêtre s’ouvre. Ces champs sont simples à remplir, faites simplement attention au VPC et ses sous-réseaux. Assurez-vous que le VPC que vous associez à cette connexion a accès à AWS S3 (c’est normalement le cas par défaut).

Une fois que c’est fait, il reste à choisir quel type d’évènement Mixpanel on veut explorer, et sélectionner le répertoire principal où sont stockées les données associées.

Pour finir, il vous faut associer un role à ce crawler. Assurez-vous de créer un role avec accès au bucket que votre crawler va analyser, et que le crawler a aussi accès à la console Glue. Pour ce faire, créez une policy qui peut lire dans votre S3. Ensuite, créez un role avec un nom commençant par “AWSGlueServiceRole-” (obligatoire), et fini par ce que vous voulez. Pour finir, attachez la policy créée et la policy “AWSGlueServiceRole” à votre role.

L’étape suivante concerne la fréquence de lancement de vos crawlers, ensuite vous pouvez configurer comment votre donnée va être envoyée vers votre base de données AWS Glue (vous pouvez en créer une ici en cliquant sur “add database”). Personnelement, nous préférons utiliser un préfixe, ce qui permet de reconnaître et regrouper des tables plus facilement. Une option importante dans notre cas est “Create a single schema for each S3 path”. C’est ce qui va indiquer aux crawlers de regrouper les données similaire en un seul schéma et de les partitionner. Au lieu d’obtenir un schéma pour chaque dossier (donc chaque date), vous aurez donc un seul schéma mais partitionné par dates. Dans les options additionnelles de configuration, vous pouvez choisir ce qu’il se passe si le schéma des données change au cours du temps, etc.

Vous avez maintenant fini ! Vous pouvez maintenant lancer vos crawlers. Une fois que c’est fait, vous avez enfin une entrée dans votre Glue Data Catalog Table !

Et plus important, vos données sont maintenant partitionnées.

Vous pouvez renommer des champs selon vos souhaits. Ici, partition_0 est l’année, partition_1 le mois et partition_2 le jour.

À propos des tarifs

Pour terminer cet article, nous allons vous donner des pistes sur le prix des différents outils que nous avons utilisé et qui sont donc présentés ici.

Mixpanel

La tarification de Mixpanel est transparente jusqu’à 100k utilisateurs actifs mensuels. Au delà, comme pour beaucoup d’entreprises, il faut prendre contact avec leurs équipes commerciales.
De plus, cette tarification est très progressive (à partir de 20€/mois) et offre une palette complète de services très avancés. Cela en fait une recommandation idéale.

Glue

Nous n’allons pas traiter toute la tarification de Glue mais seulement ce que nous avons utilisé jusqu’ici.

Le prix de stockage de Glue Data Catalog est très simple, vous ne paierez rien si vous ne dépassez pas les 1M d’objets stockés et 1M de requêtes chaque mois. Si vous dépassez ces limites, vous devrez alors payer 1.00$ pour chaque 100K objets au dessus de 1M, et 1.00$ pour chaque million de requêtes additionnel.

Pour les crawlers, l’unité de mesure utilisée par AWS est le DPU-heure.

Une seule unité de traitement des données (DPU) fournit 4 vCPU et 16 Go de mémoire. 

Vous paierez le temps d’exécution de vos crawlers par tranche de 1 seconde, avec chaque exécution facturée comme si elle a au moins durée 10 minutes.

Ces fonctionnalités de Glue ne vont pas vous coûter cher pour ce que nous en faisons ici. Par exemple, vous n’aurez besoin de lancer vos crawlers qu’une seule fois, puis uniquement lorsque vos schémas de données seront amenés à changer.

Conclusion

Pour conclure pour ce premier article de cette série, nous avons vu que traquer des utilisateurs avec Mixpanel est assez grâce au SDK Mixpanel. Ensuite, l’export des données à l’aide des pipelines de données Mixpanel s’est révélé tout aussi simple à mettre en place. En bref, la partie la plus délicate est de bien savoir comment sont structurées vos données pour bien mettre en place leur stockage (ici avec Glue Data Catalog and S3).

La seule chose qui devrait rester obscure à la fin de cet article est la tarification de Mixpanel, qui est vraiment spécifique aux besoins de votre projet.

Maintenant que nous avons nos donnée stockées dans le Cloud, nous sommes prêts à travailler dessus et continuer notre voyage vers la recommandation avec l’article suivant : La recommandation de A à Z [2/3] : transformer la donnée avec AWS Glue.

Si vous êtes déjà un utilisateur expérimenté de AWS Glue, vous pouvez passer le prochain article et directement aller lire le dernier de la série : La recommandation de A à Z [3/3] : transformer la donnée avec AWS Glue.

Merci !