Comment mettre en place des analytics sur votre application mobile ?

Bravo Kevin
Mar 19, 2018 · 18 min read

Ce petit guide est destiné à toutes les startups / PME / Freelance qui travaillent sur une application mobile et qui souhaitent mettre en place des analytics.

Il ne s’agit pas d’une « bible » de « ce qu’il faut absolument faire » mais plutôt d’un retour d’expérience après avoir travaillé avec différentes entreprises (en interne & freelance) dans la mise en place de stratégies analytiques.

Les analytics mobile, bien que proches à première vue de ce qu’on ferait pour un site web, ont leurs propres spécificités et demande donc de fonctionner différemment.

Vos objectifs

La première chose à laquelle penser quand vous souhaitez mettre en place des analytics pour votre application mobile c’est pourquoi ?

Alors plus que la question globale « à quoi ça sert de mettre des analytics » ? Je parle surtout de votre mission.

Il y a un concept que j’apprécie particulièrement, The Golden Circle.

Je ne vais pas vous faire un cours là dessus, bien que je vous invite à aller regarder le TED : https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=fr

Gardez bien en tête la mission de votre startup, de votre produit. Le “Pourquoi”. Qu’est ce qui vous motive au quotidien et ce qui devrait être transmis à l’utilisateur final ?

C’est très important car c’est cette mission, ce « pourquoi » qui va vous permettre de comprendre quels sont vos objectifs d’analyse.

Un exemple simple : Imaginons que vous êtes une app de rencontre.

Pourquoi existez-vous ? Pour permettre de belles rencontres, tout simplement.

On peut détailler et cela varie selon l’application. Mais l’idée est là.

Maintenant, si votre mission est d’amener les gens à se rencontrer vous savez que l’un de vos objectifs sera que chacun de vos utilisateurs fasse des rencontres. Donc vos statistiques de rencontre réelles sont très importantes.

Comment cela peut être possible ? Il faut déjà amener les utilisateurs à discuter entre eux.

Donc vos statistiques de conversations par utilisateur , ainsi que leur durée est importante.

Et on peut descendre encore de quelques niveaux pour arriver aux statistiques basiques : le nombre de sessions, la rétention globale, etc..

Comment construire vos objectifs à partir de cette réflexion en escalier ?

Le plus simple est de définir quelques objectifs globaux, chiffrés ou non.

Quelques exemples :

  • Créer 5% de rencontres réelles sur le volume de conversations
  • Une moyenne de 2 conversations par utilisateur par semaine
  • Amener les utilisateurs à partager certains profils pour leurs amis célibataires
  • etc..

Ces objectifs peuvent être basés sur des mauvaises hypothèses au départ, de toute façon ils vont évoluer. Mais ils permettent déjà de réfléchir aux données à tracker et surtout aux funnels (on y reviendra) que vous allez construire.

En général, les objectifs sont repensés au fil des mois, après analyse du comportement des utilisateurs, de leurs feedbacks et de l’évolution du produit.

Je trouve cet exemple intéressant, car “5% de rencontres réelles” est un vrai challenge : Il nous est impossible de savoir si l’utilisateur n’a pas pris le numéro de téléphone de quelqu’un et l’a rencontré par la suite.

Alors oui, il existe d’autres moyens (via le produit, des feedback inApp ou autre..). Mais déjà y penser dans le plan analytics est important : je pourrais par exemple créer un événement « envoi de numéro » lorsque je détecte 10 caractères décimaux (ex: 0770153632) qui se suivent dans le contenu d’un message envoyé 😉

Votre plan de tracking

Une fois vos objectifs bien définis, il faut faire un plan de tracking (ou plan de taggage).

Ce plan correspond à un tableau Excel qui contient l’ensemble des évènements que vous souhaitez tracker.

Il est très important de garder ce document à jour : en général il va servir de référence à vos développeurs pour l’intégration d’évènements, et il vous servira à vérifier que tout fonctionne bien.

Dans mon activité, je m’occupe généralement de faire le plan et d’intégrer le code sur le projet, mais cela ne pose pas de problèmes que les deux tâches soient découpées dans deux équipes différentes.

Quand je dis évènement, je m’explique :

Lorsque votre utilisateur ouvre votre application, c’est un évènement. Quand il envoie un message à un utilisateur, c’est aussi un évènement. Idem lorsqu’il appuie sur un bouton, change d’onglet, etc..

Je ne dis pas qu’il faut tracker tous les évènements, au contraire ! Mais il est important de comprendre ce terme pour la suite.

Vous pouvez décomposer ces évènements en trois grandes parties :

  • Les « App Screen » : L’action de voir un écran spécifique de votre application (exemple: le launchscreen, ou la page de récupération de mot de passe)
  • Les people updates : Votre utilisateur change de rang, car il a gagné un niveau sur votre application, ou il vient de prendre la version premium. En bref : tout ce qui touche à un changement sur votre utilisateur
  • Les actions : On met un peu tout le reste ici, il s’agit de toutes les actions que peut effectuer l’utilisateur sur votre application (booker un rdv, matcher un utilisateur, liker un post, commenter, etc..)

Concernant la forme du plan, inutile de réinventer la roue, Mixpanel & Amplitude propose des plans par défaut qui vous serviront de base (libre à vous d’y ajouter des colonnes en plus).

De mon côté, j’ai trouvé plutôt utile d’ajouter quelques colonnes :

  • Exemple : Indique un exemple de valeur stockée
  • Code : le code à intégrer sur le projet
  • State iOS / State Android : pour les tests, je mets OK ou un commentaire s’il y a un souci
  • Date : Pas la date de création, mais plutôt la date à laquelle j’ai vérifié que ça marchait bien, cela permet souvent de remonter les problèmes dans une version suivante.

Maintenant, concrètement qu’est ce qu’il faut tracker ?

En général on a la volonté de tracker tous les évènements, tout ce que l’utilisateur fait sur l’application et ce n’est pas une mauvaise idée.

Il faut simplement faire attention à le faire correctement, c’est là ou intervient une leçon fondamentale dans les analytics mobiles : les propriétés.

Une propriété est une « variable », un attribut associé à votre évènement qui va vous donner une information complémentaire sur votre évènement.

Par exemple, si vous avez une app de musique, vous allez ajouter l’évènement « jouer un morceau »

Mais cet évènement seul, n’est pas très utile. Vous voulez peut-être faire des statistiques globales sur le nombre de morceaux joués, mais aussi leur durées, les artistes et morceaux les plus écoutés, etc..

Pour cela, on va ajouter des propriétés à mon évènement playSong.

par exemple :

  • artist : artiste du morceau
  • duration : temps d’écoute
  • name: nom du morceau
  • category : style (country, folk, rap, etc.)

Mais il serait aussi, éventuellement possible d’ajouter :

  • fullListen : est-ce que le morceau a été écouté jusqu’à la fin ? (en effet une duration ne suffit pas, tous les morceaux n’ont pas la même durée)
  • mode : si votre application a un « background mode » vous voulez savoir si l’utilisateur écoute son morceau hors de votre app (avec le lecteur de l’iPhone par exemple) ou non.

L’idée est d’être exhaustif dans ce que vous voulez savoir sur un évènement, si vous oubliez quelque chose vous perdez de la data.

On vient de voir les propriétés sur un évènement, mais il y a également des propriétés sur les utilisateurs.

Un utilisateur a un âge, un sexe, une ville d’origine, etc..

Attention aux données sensibles : date de naissance, nom / prénom, mail, etc.. c’est rarement utile sur des analytics, car cela ne permet pas d’avoir des infos pertinentes (qui serviront à améliorer le produit). Mixpanel permet d’exploiter ces données (pour faire des emails personnalisés par exemple), du coup cela dépend surtout de l’outil et de l’usage.

À côté de ces propriétés basiques, vous pouvez également tracker des propriétés qui vont évoluer avec l’activité de votre utilisateur :

  • nombreDeMorceauxJoués : Nombre de morceaux que votre utilisateur a joués en tout depuis sa première utilisation
  • premium : indique si votre utilisateur a un abonnement payant ou pas sur votre app
  • nombreAlbumsCrées: Le nombre d’albums qu’il a créés depuis sa première session

Etc..

La différence avec les propriétés d’évènements se situe aussi dans le traitement des données : vous pourrez faire des dashboards d’analyse de vos utilisateurs (globalement) et non pas vous concentrer sur des évènements, c’est très utile et vous permet d’un coup d’oeil de comprendre la composition de vos utilisateurs.

Je vous donne un template de plan de tracking que vous pouvez télécharger :
https://docs.google.com/spreadsheets/d/1RTczCZKvh5s5dnXczv1oBwKncQA529X3qMpF7kntaD8/edit?usp=sharing

Très largement inspiré de celui de Mixpanel, je l’ai juste mis en français et ajouté mes propriétés perso. Libre à vous de le dupliquer et le modifier.

Une fois le plan de tracking crée, il faut le confronter à vos développeurs. C’est très important.

Dans votre esprit tout est plutôt simple, mais vos développeurs va peut être trouver des évènements impossibles à tracker comme vous le souhaiter (notamment à cause de la structure du code) et c’est normal. Il faut rapidement intégrer les développeurs dans le processus de réflexion pour comprendre ce qui pourrait poser problème.

Une fois les évènements intégrés, il faut le tester. Prenez bien le temps de tester chaque ligne, iOS, puis Android. Vérifiez s’il n’y a pas de doublon, etc..

Inutile de tout retester après chaque nouvelle version, même si c’est très fortement recommandé. Surtout si vous faites des modifications importantes dans le code.

Petite parenthèse pour l’intégration du code :

Encore une fois, inutile de réinventer la roue. Vos développeurs auront sans doute leur propre méthode pour ajouter les tags, je recommande quand même de faire une classe générique qui gère tous les évènements par type (une fonction pour les appscreen, une fonction pour les events, etc..)

Cela vous permettra de gérer les requêtes au même endroit. Sans oublier qu’il vous suffira de deux, trois lignes de code pour envoyer les mêmes informations sur Mixpanel, Firebase, etc.. de quoi gagner de précieuses heures de travail.

Je vous parle de ça, car au début j’intégrais les lignes une par une et c’était assez long, mais maintenant je fais toujours une classe générique pour le bonheur des développeurs avec qui je travaille.

Quels outils ?

Certains seront un peu surpris que je ne parle pas de Google Analytics, de mon coté j’ai utilisé l’outil et je le trouve top, mais je ne pense pas que ce soit très adapté aux applications mobile.

À la place, je vous recommande d’intégrer :

Mixpanel

Mixpanel est un très bon outil d’analytics mobile, il permet non seulement d’analyser le comportement utilisateur au travers des différentes notions qu’on a vu, mais il permet aussi de coupler sa partie analytique à différents leviers de rétention comme les notifications push, e-mail, inApp Messages, etc..

Un exemple : Imaginez l’application Medium.

Je commence à écrire un article sur Medium, je passe quelques jours à le peaufiner, mais je ne le publie pas tout de suite.

Avec Mixpanel, Medium pourrait détecter l’ évènement “écrisUnArticle” et le fait que je n’ai jamais posté celui-ci, et pourrait donc me relancer avec une notification push : “Plus que quelques lignes pour partager ton article à des millions de lecteurs”.

Mixpanel permet de gérer les notifications push sur la plateforme, sans qu’il y ait des interventions des développeurs, il remplace un peu le “backend”.

Mixpanel possède de nombreux autres atouts, je vous invite à lire le super article de Robin sur le sujet en français : https://robinherzog.fr/16-lecons-que-jai-apprises-apres-un-an-de-mixpanel/

Au niveau du pricing, il faut savoir que cela devient très vite très cher.

Pensez à calculer combien pourrait vous coûter l’outil selon vos besoins, sachant que le produit est décomposé en deux parties (donc deux services à payer indépendamment) Analytics et People.

Vous pouvez toutefois commencer à le tester gratuitement.

Amplitude

Amplitude est limité aux analytics et ne propose pas de service de notifications push, d’email ou autre comme Mixpanel.

Il est toutefois possible de coupler Amplitude avec OneSignal par exemple : https://onesignal.com/

Mais vos options de ciblages seront bien plus limitées.

Concernant les pricing, Amplitude propose quelques fonctionnalités payantes (et une augmentation du volume d’évènement max) mais vous pourrez pratiquement tout faire avec la version gratuite (cela m’étonnerait que vous atteigniez le quota de volume qu’ils proposent).

Si jamais vous souhaitez accéder à la version payante : jusqu’à présent c’était plutôt réservé à des entreprises avec des budgets élevés, mais depuis quelques semaines, Amplitude semble proposer une offre startup accessible ici : https://amplitude.com/startups

Il y a de nombreux autres outils, mon choix pour cet article se limite à ces deux-là car je considère qu’ils couvrent tous les cas possibles et permettent de réaliser n’importe quel dashboard. Mais je vous invite toutefois à tous les tester !

Je me suis personnellement fait une testApp où j’ai intégré tous les outils analytics que j’ai trouvés, pour tester et comprendre leur fonctionnement individuel. Cela me permet de mieux choisir l’outil qui correspond à chaque projet.

Car votre structure d’entreprise est également importante dans le choix de l’outil, prenez le temps les premiers mois d’en intégrer plusieurs (avec une classe générique ce ne sera pas long) et d’enlever ceux que vous n’utilisez pas au fur et à mesure.

Vous pouvez jeter un coup d’oeil à :

Pour les équipes plutôt techniques, il est possible que vous ayez des besoins extrêmement spécifiques en termes d’analyse, qui ne soit pas possible sur Amplitude ou Mixpanel.

Une solution est de tracker tous les évènements sur une base de données (personnellement j’aime bien le NoSQL donc je fais ça sur Firebase) et de créer un dashboard web (Firebase Admin + Functions par exemple) qui vous permet de faire vos requêtes très spécifiques.

Vos dashboards

Vous avez fait votre plan de tracking, intégré & testé, des semaines ont passé, ça y est vous avez de la data !🎉

La première chose à faire est de regarder vos objectifs, construisez des tableaux par rapport à vos objectifs de départ. Ces objectifs sont des interrogations auxquelles vous devez essayer de répondre.

Pour cela, vous pouvez faire différents types de “tableaux” basés sur les concepts suivants :

Les captures qui vont suivre exploitent de “fausses données” sur Amplitude. Le même type de rendu est tout à fait possible sur d’autres outils.

  • Funnels : Défini un parcours spécifique dans votre application (de l’inscription à la première écoute d’un morceau par exemple, ou la création d’un album, le partage d’un morceau, etc.)
  • Sessions : Affiche les sessions par rapport à leur durée, distance, récurrence, etc.(Attention : une session n’est pas toujours définie de la même façon selon l’outil, et selon la plateforme, iOS ou Android)
  • Utilisateurs : Démontre la composition de vos utilisateurs par sexe, âge, propriété (people property qu’on évoquait un peu plus haut)
  • Évènements: Représente un flux d’évènement sur une période donnée, en général vous pouvez faire parler les données pour afficher un peu ce que vous voulez (nb d’utilisateurs / jour, nb utilisateur qui jouent au moins 3 morceaux / semaine, etc..)

Mixpanel, Amplitude, etc. vont chacun avoir leurs outils de mesure dédiés qui vous permettront d’avoir des informations supplémentaires, libre à vous de les explorer et de comprendre comment utiliser chacun d’entre eux.

Quand vous allez commencer, ce sera assez simple d’avoir des bonnes idées de tableaux à créer, mais je vous invite très fortement à prendre une feuille et un stylo et à bien réfléchir à ce que vous voulez tracker, mais surtout ce que vous voulez améliorer.

En effet, l’objectif final de toutes ces données, ce n’est pas de vous satisfaire d’un peu de DataViz (bien qu’on adore tous ça) , mais surtout de trouver des pistes d’améliorations du produit et de comprendre comment votre utilisateur utilise votre produit au quotidien.

Pour cela, il y a un concept que j’aime beaucoup qui s’appelle l’AARRR.

Il s’agit d’un framework, plébiscité par les growth hackers, qui constitue l’ensemble des “phases” par lesquelles va passer votre utilisateur.

Je ne vais pas en parler ici, mais vous trouverez de super ressources sur internet pour le comprendre, comme cette vidéo (pas très récente mais encore vraie) :
https://www.youtube.com/watch?v=s2EBIai6rvM

Ce qu’on a besoin de retenir pour cet article c’est les 5 étapes:

  • Acquisition : Comment vous amenez l’utilisateur à télécharger votre application ?
  • Activation : Comment vous amenez l’utilisateur à s’inscrire sur votre produit ? A s’engager pour la première fois.
  • Retention : Comment vous faites pour que votre utilisateur revienne chaque jour utiliser votre app ?
  • Referral : Comment vous amenez l’utilisateur à partager votre app ?
  • Revenue : Comment vous monétisez votre utilisateur ?

Chaque phase amène des tableaux différents.

Par exemple pour l’ Activation: il va falloir jeter un coup d’oeil au funnel d’onboarding, la première utilisation de votre application.

La Retention: Est-ce que votre utilisateur revient sur votre app au fil du temps ? Si oui, pour quelles raisons / fonctionnalités ?

L’ Acquisition: Il faut que vous affichiez la source d’arrivée de vos utilisateurs, pour comprendre quel canal marche le mieux.

Concernant ce dernier, on parle ici d’ “attribution”, il s’agit de comprendre d’où vient l’installation de mon app : une campagne de pub sur facebook ? Un article sur medium ? etc..

Pour bien tracker l’attribution, il y a différentes façons de faire, on parle généralement de “deeplink” sur mobile et je ne peux vous recommander qu’un outil :

Je pense faire un article sur ce sujet prochainement, mais vous avez déjà la documentation de branch qui est assez complète et pleins de contenus en anglais sur le web.

Ce ne sont que quelques exemples, ma conclusion sur cette partie c’est de bien garder en tête vos objectifs de départ, et d’ajouter des objectifs par “phase”, l’idée étant que dans un produit il ne faut pas juste se concentrer sur le fait de garder l’utilisateur le plus longtemps possible, mais aussi de comprendre quelle a été sa première expérience ? Qu’est-ce qu’il n’a pas compris ? Qu’est-ce qu’il n’a pas utilisé et pourquoi ?

Il est aussi important de définir ce que sont vos “core users” c’est-à-dire les utilisateurs actifs qui reviennent régulièrement sur votre application. Une fois que vous aurez réussi à définir ces utilisateurs-là, vous pourrez les analyser pour comprendre pourquoi ils reviennent, quelles fonctionnalités ils utilisent, combien de fois par mois, etc..

Quelques idées de dashboards que j’ai mis en place chez des clients et qui nous a permis de faire évoluer le produit :

  • Onboarding Funnel: Fondamental, il correspond à un ensemble d’évènements qui seront déclenchés lors de la première session de votre utilisateur.
    En général c’est Première ouverture d’app -> Démarre l’inscription -> Fini inscription -> accède à la home (une fois inscrit) et puis vous mettez en face différentes actions possibles sur votre application (pour voir quelle action l’utilisateur effectue en premier)
    Ce funnel peut être défini sur une même session, ou sur une durée de conversion (par exemple 1h, une journée).
    En général les résultats sont assez différents et laissent paraitre un comportement spécifique selon chaque cas. Ce funnel vous permet aussi de voir si votre processus d’inscription n’est pas trop lourd (vous demandez peut-être trop d’informations dès le début et l’utilisateur est découragé)
  • Est-ce que votre utilisateur effectue l’action X ? : Lorsque vous intégrez une nouvelle fonctionnalité, il est important de voir quel pourcentage de vos utilisateurs l’utilisent. Il y a pas mal de blogpost là dessus, en général il est très fortement conseillé de penser à supprimer une fonctionnalité lorsque le % d’usage est faible, ou du moins de modifier celle-ci, la façon d’y accéder, etc.. Ça peut simplement vouloir dire que personne ne sait que cette fonctionnalité existe.
  • Retention par rapport à une fonctionnalité : La rétention globale c’est important, mais vous pouvez aussi analyser les utilisateurs qui reviennent en fonction des actions qu’ils effectuent : peut-être qu’un utilisateur qui créer un album musical sur votre application revient 2 fois plus qu’un utilisateur qui n’en a jamais fait. Il serait alors intéressant d’amener un nouvel utilisateur (par le biais d’un mini-onboarding) à créer son premier album assez rapidement.
    C’est ce tableau qui m’a permis de découvrir avec un de mes clients que des utilisateurs qui avaient fait l’action X dans leur première session, revenaient 5 fois plus que ceux qui ne l’avaient pas fait. On a alors simplement ajouté l’action X dans l’onboarding initial de l’application (avant même l’inscription). Cela a permis d’augmenter la rétention globale.
    Il ne faut pas oublier que l’attention sur mobile est très faible, la première impression est fondamentale.
  • Les termes les plus recherchés et le % de clic après recherche: Imagineons que vous faites une application d’art numérique : des fresques dessinées à la main qu’on peut commander sur votre application (avec toutes les features classiques d’un réseau social : like, partage, etc..)
    On a tous une façon différente de chercher sur un moteur de recherche, certains chercheront par artiste, d’autres par “thème” mais certains feront peut être une recherche “à la google”, je m’explique :
    Il y a quelques mois j’ai eu le privilège d’aller dans les locaux de La Fourchette site et application qui permet de réserver les meilleurs restaurants en Europe.
    La Fourchette expliquait qu’ils avaient réalisé que leurs utilisateurs ne font pas des recherches comme prévu, mais tapait des termes comme “restaurants avec des sushis” ou “escalope milanaise”, etc. Cependant ce type de recherche ne renvoyait pas de résultat, car ce n’était pas prévu. Analyser les termes permet simplement de comprendre si votre moteur de recherche est adapté à l’usage.
    Chez un de mes précédents client, on a réalisé un “manque” dans le moteur de recherche inApp et on a décidé d’ajouter un système de “tags” qui était sélectionnable pendant l’auto-complete, cela a grandement amélioré la pertinence des recherches et réduit le nombre d’exit.

Ces quelques exemples sont très basiques, et je suis certain que vous trouverez des dizaines d’insights en testant les outils.


Avant de vous quitter, je vous dévoile une astuce qui vous permet d’obtenir des données démographiques très intéressantes sans avoir à demander aucune information à vos utilisateurs (légalement bien sûr).

En général, quand vous développez une app vous pensez tout de suite au “Login”, il vous permettra d’obtenir un e-mail sur lequel solliciter l’utilisateur et quelques informations (spécialement si vous utilisez un Facebook Login).

Personnellement, je ne suis pas fan du login dès la première version, car il faut faire attention : demander une connexion à l’utilisateur dès la première utilisation peut être un frein. Alors oui, si vous vous appelez Tinder ou Zenly il n’y a pas vraiment de soucis, mais quand vous lancez votre application au début, chaque utilisateur potentiel est une denrée rare. Ce serait dommage de lui faire peur dès la première utilisation.

Facebook possède une solution analytics, qui vous permet non seulement d’avoir des informations d’usage (comme Mixpanel et Amplitude) mais aussi des données d’utilisateurs (c’est à dire des données facebook : âge, sexe, ville, centres d’intérêt, etc..). Pour cela il suffit simplement d’ajouter un Facebook Connect, module de connexion facebook.

Facebook propose justement plusieurs SDK (ça parlera à vos développeurs) qui s’intègrent dans votre application. Ces SDK permettent de faire du login facebook, login avec numéro de téléphone (appelé AccountKit), des partages sur facebook (ShareKit), etc..

L’astuce, c’est que ces données d’utilisateurs (âge, sexe, etc..) peuvent être récupéré sans même intégrer facebook connect.🔥

le SDK FacebookCore, que vous pouvez intégrer à votre app permet d’envoyer les données démographiques de l’utilisateur automatiquement sur Facebook Analytics (il suffit juste de créer une app dans facebook developers)

Autrement dit : mon utilisateur ouvre mon app, à aucun moment il a l’impression de s’inscrire / se connecter, et pourtant j’ai déjà récupéré toutes ses données facebook.

Alors il y a une limite : Je n’ai ni son Nom ni son Prénom, et pas d’email.
Facebook ne me donne aucune donnée qui me permet de l’identifier en tant qu’individu. C’est normal.

Mais à côté de ça, je sais que mon utilisateur moyen est un homme entre 25 et 34 ans :

Quel niveau d’étude il a, s’il est marié..

Et je sais même que 40% des utilisateurs de mon application aiment la page facebook Miaam !

Sans aucune connexion demandée..

En général, quand je bosse sur un lancement d’app, je couple cette astuce avec un Firebase Anonymous login (qui me permet d’avoir un identifiant unique pour chaque utilisateur).

Pour info Facebook vous permet d’accéder à ces données à partir d’un certain nombre d’utilisateurs ayant installé votre application (1000 / 2000).

Je vais m’arrêter là, mais n’hésitez pas à me joindre si vous avez un projet mobile où déjà une app sur laquelle vous voulez mettre en place des analytics. Ce sera un plaisir d’en parler avec vous autour d’un café !

bravo.kevin.contact@gmail.com
+33 (0)7 70 15 36 32

Si vous aimez le post, n’oubliez pas de laisser des “claps” ! 👏👏👏

Bravo Kevin

Written by

Innovation Lead @Phiture. Passionate about mobile apps & games, data and burgers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade