Yelp CityHeartbeat, quelles sont les tendances dans mon quartier ?

Par Arthur Bourgeois, Lucie Crucq, Célia Hocine et Jonathan Pathmanathan, élèves du Parcours Data Science de l’IMT Atlantique.

Permettre à ses utilisateurs de trouver le meilleur restaurant, coiffeur ou garagiste dans une ville, c’est la mission de Yelp. Créé en 2004, Yelp rassemble aujourd’hui plus de 115 millions d’avis sur son site et attire toujours plus de visiteurs par mois, principalement aux Etats-Unis où il se positionne en leader en matière de recommandations.

Comme d’autres avant eux, Yelp fait aujourd’hui appel à des personnes extérieures à son équipe pour développer de nouvelles idées afin de mieux répondre aux besoins de ses utilisateurs. L’entreprise a lancé le “Dataset Challenge” : un échantillon des données collectées par Yelp est mis à disposition des internautes, qui ont pour défi de trouver une façon innovante de les utiliser.

Dans le cadre de notre parcours “Data Science” à l’IMT Atlantique, nous avons eu pour mission de proposer un projet innovant basé sur les données du Dataset Challenge. Encadré par une équipe de professeurs experts dans les domaines de l’informatique, de l’analyse des données et de l’économie, nous nous sommes donc lancés dans la valorisation des données de Yelp.

CityHeartbeat : vers un nouveau service B2B

Très tôt dans notre réflexion, nous avons décidé de nous orienter vers un service à destination non pas des consommateurs, mais plutôt des commerçants. En effet, Yelp propose déjà de nombreux services aux consommateurs : recherche d’un business avec plusieurs filtres, écriture d’avis, système de notations sur de nombreux aspects du commerce…

En ce qui concerne les commerçants, Yelp offre des services pour attirer plus de clients : mise en avant du business sur le site (Yelp Ads) et proposition de bons de réductions type Groupon (Yelp Deals). Mais il manque selon nous des services pour aider les commerçants qui ne sont pas encore installés.

Elèves rigoureux et bien organisés que nous sommes, nous avons appliqué la méthode CRISP-DM pour structurer notre projet. Cette méthode est un pilier indispensable pour la réussite d’un projet de fouilles de données. Pour rappel, la méthode CRISP consiste en plusieurs phases :

  1. La compréhension du business qui permet de fixer les objectifs du projet en se posant les questions métiers
  2. La compréhension des données qui consiste en la découverte des données à notre disposition ainsi qu’à leur exploration
  3. La préparation des données qui est une phase de nettoyage et réorganisation des données, et si nécessaire de création de nouvelles valeurs calculées à partir d’autres données
  4. La modélisation pour la sélection du modèle de fouille de données ainsi que ses paramètres
  5. L’évaluation qui consiste à juger les performances du modèle et comparer les résultats produits avec les objectifs à atteindre
  6. Le déploiement à la fin du projet, phase pendant laquelle la solution est installée et de nouvelles pratiques sont mises en place suite aux conclusions tirées du projet.

En utilisant cette méthodologie, nous avons ainsi abandonné notre idée initiale : aider des commerçants à trouver la “recette” d’un business qui fonctionne était certes une belle idée, mais la phase de compréhension des données nous a permis de nous rendre compte que nous ne disposions pas des bonnes informations pour répondre à cette problématique. De plus, il était assez complexe de définir ce qu’était un commerce qui “fonctionne”, un critère trop subjectif.

Aidés par nos tuteurs, nous avons finalement pivoter et fait émerger une problématique un peu différente. Nous cherchons à exploiter les données pour répondre à une demande centrée sur le gérant d’un commerce. Un nouvel entrant qui souhaite s’installer dans un quartier a besoin d’informations sur les commerces de ce quartier, la fréquentation de ceux-ci, leur type, leurs notes et commentaires ainsi que leur catégorie de prix.

Notre future solution permettrait donc l’exploration d’un quartier pour permettre à un gérant de prendre mesure de la concurrence et d’observer les caractéristiques des business avec le plus de succès sur Yelp. Notre produit CityHeartbeat est né.

Nous avons passé un long moment à réfléchir sur les questions auxquelles devait répondre notre produit. Selon nous, deux questions principales intéressent un business qui souhaite s’installer : qui sont les concurrents déjà installés et qui sont les consommateurs qui viennent dans ce quartier ?

Quelles données pour une étude de marché ?

Après avoir défini nos objectifs, nous sommes passés à la phase 2 de la méthode : la compréhension des données.

Nous avions à notre disposition plusieurs tables regroupant des données par thème : la table business qui regroupe de très nombreuses données sur les commerces : leurs horaires d’ouverture, leur localisation, leur catégorie, leur note et des informations sur les services proposés ; la table checkin qui regroupe le nombre de visiteurs par période de temps pour chaque business ; la table reviews qui regroupe les avis des visiteurs ; la table users qui regroupe des informations sur les visiteurs.

Une première exploration de ces données nous a permis de nous rendre compte de plusieurs choses.

Premièrement, la table users n’est pas très utile dans notre cas car elle ne regroupe que des informations relatives à la communauté Yelp (nombre d’amis, commentaires des autres Yelpers…) et non pas des informations démographiques qui nous aideraient à qualifier les visiteurs d’un quartier… mais c’est un peu normal, non ?

Deuxièmement, la table des reviews nous paraît difficilement exploitable dans un premier temps, mis à part pour calculer le nombre d’avis par business. De plus, la date de l’avis ne veut pas dire grand chose car un utilisateur peut donner son avis plusieurs jours après sa visite.

Troisièmement, la table business, mise à plat, contient plus de 1000 informations différentes pour caractériser un business, ce qui rend sa manipulation difficile.

Enfin, nous remarquons que beaucoup d’informations, car non obligatoires, ne sont pas remplies : par exemple tous les restaurants n’ont pas rempli le champ “drive-thru” pour indiquer s’ils offrent ou non ce service. “Seulement 1% des business renseignent la case restrictions diététiques, ce qui la rend impossible à analyser” nous confie Célia, Data Quality Manager.

Suite à cette exploration, nous prenons deux décisions : utiliser uniquement les informations avec un taux de remplissage élevé pour garantir des informations pertinentes et partitionner la table business en sous-tables ne contenant que quelques colonnes pour faciliter et accélérer la manipulation des données.

Nous pouvons maintenant établir la liste des indicateurs que nous souhaitons suivre dans notre outil. CityHeartbeat permettra de visualiser :

  • la répartition des business en fonction de leurs coordonnées GPS sur une carte ;
  • leur nombre de checkins, leur nombre de reviews et leur note moyenne pour comprendre si ces business sont “performants” au sens de Yelp ;
  • des données sur les catégories de business et leur gamme de prix ;
  • des données sur les services proposés par les business (par exemple la livraison) et leurs horaires d’ouverture .

En ce qui concerne les consommateurs, nous ne pouvons rien afficher pour le moment mis à part leur nombre (grâce aux checkins).

Un POC interactif

Afin de réaliser notre tableau de bord, nous avons choisi l’outil Tableau Software, d’une part car nous connaissions déjà cet outil et d’autre part car c’est un outil puissant qui permet d’effectuer des calculs et d’en visualiser les résultats en temps réel. Il permet également une grande liberté dans la manipulation des données, les différents types de graphiques ainsi que les filtres. Dans un premier temps, par souci de simplification, notre première version de CityHeartbeat ne permet que d’observer les restaurants de la ville de Phoenix.

Le tableau de bord est très facile à prendre en main et la navigation y est intuitive. Il permet de répondre aux objectifs métiers que nous nous étions fixés et toute l’information capitale est synthétisée et présentée de la façon la plus parlante possible.

L’utilisateur peut rapidement visualiser où se trouvent les restaurants grâce à une carte de la ville observée. En fonction de la taille du point représentant le restaurant, l’utilisateur peut connaître sa fréquentation, et en fonction de la couleur allant du rouge au vert, il peut connaître la note donnée par les Yelpers. Un panel de filtres sur le côté de la carte permet de filtrer les restaurants de la zone : par leur catégorie, leurs horaires d’ouvertures et leur distance au point central de la zone étudiée.

L’outil permet également à l’utilisateur d’avoir une description globale des restaurants présents dans la zone choisie : comment sont réparties les enseignes en fonction de leur prix et de leur catégorie, combien de restaurants proposent certains services.

L’utilisateur peut aussi évaluer le poids du quartier par rapport à la ville entière : en effet, il peut voir quel pourcentage des checkins et des avis de la ville sont contenus dans la zone étudiée.

L’outil n’en est pour l’instant qu’à un stade de premier prototype. Nous avons plusieurs idées pour l’améliorer.

Premièrement, nous ne sommes pas totalement satisfaits de la façon dont la zone à explorer est définie. Aujourd’hui, nous utilisons une ville, un point de cette ville et nous calculons la distance entre chaque business de la ville et ce point central. L’utilisateur peut ensuite décider de réduire le rayon de la zone à explorer en diminuant la distance maximum au point choisi. Ce n’est pas la solution la plus pratique d’un point de vue utilisateur. La solution idéale serait de choisir une ville, puis un quartier de cette ville. Cela pose cependant plusieurs problèmes : les quartiers sont de taille très différente selon les villes (un “zoom” à l’intérieur du quartier serait alors nécessaire), de forme peu pratique à manier, et l’information du quartier n’est pas toujours disponible dans les données de Yelp.

Ensuite, comme cet outil est destiné à un commerçant qui cherche à s’installer, nous pourrions proposer plus d’options visant à lui permettre de comprendre pourquoi un business attire plus de personnes qu’un autre, en plus des checkins et de sa note. Entre autres, nous pourrions afficher une sélection d’avis : par exemple ceux qui sont notés les plus utiles, cools et drôles.

Nous pensions également indiquer quels sont les business qui ont souscrit à Yelp Ads ou Yelp Deals dans la zone observée, l’idée étant que de tels business devraient avoir une plus grande fréquentation, grâce à l’augmentation de leur visibilité. Cela pourrait idéalement inciter l’utilisateur de CityHeartbeat à souscrire lui-même à ces offres.

Dans tous les cas, nous sommes limités par les données en notre possession : certaines informations qui nous paraîtraient intéressantes ne sont pas assez remplies pour être exploitables, nous manquons d’informations sur la démographie des consommateurs… Nous devons également faire attention à ne pas montrer trop d’informations différentes sur notre tableau de bord, ce qui gênerait la lisibilité de l’outil.

Comment garantir nos revenus

En tant que membres de l’équipe Dynamic Solutions and Optimization de Yelp, notre mission n’est pas seulement d’améliorer le produit Yelp mais également de garantir des revenus. C’est la raison pour laquelle il est important de trouver un bon business model à notre projet.

Nous avons adopté un mode de vente en mensualités, avec une période d’essai où les interactions avec le tableau de bord seraient limitées pour donner envie à l’utilisateur d’acheter la version complète.

Notre produit pourrait en fait intéresser à la fois les commerçants qui souhaitent s’installer mais également des commerçants déjà implantés qui aimeraient se comparer facilement à leurs concurrents. Cela représente un nombre conséquent d’utilisateurs potentiels, sachant que rien qu’à Paris, 3 restaurants ouvrent chaque jour !

Ce que nous retenons de ce projet

Ce projet nous a permis de nous rendre compte de plusieurs choses.

Premièrement, ce n’est pas une légende : dans un projet de manipulation de données, ce n’est pas la modélisation ou la visualisation qui prennent le plus de temps.

Ici nous avons passé la majorité de notre temps à définir les objectifs de notre projet, puis à préparer les données. Une fois ces étapes passées, visualiser les données avec Tableau nous a semblé presque facile !

Ensuite, nous avons été confrontés au problème du big data, et là non plus, ce n’est pas une légende : la solution classique, mono serveur, que nous avions choisie pour la manipulation des données en Python, s’est heurtée à la quantité des données à manipuler (surtout le nombre de colonnes dans les datasets). En effet, nous n’avons pas utilisé d’architecture Big Data, et nous avons vite compris que le nombre important de calculs demandés nécessitait de changer de paradigme ! Faute de temps, nous avons donc contourné le problème en divisant les tables en sous-tables plus petites et donc faciles à manipuler, mais nous aurions cependant pu nous tourner vers des outils dédiés au Big Data comme Spark sur la plateforme Big Data TeraLab mise à notre disposition.

En conclusion, notre première version de CityHeartbeat s’est avérée fonctionnelle, facile à utiliser et pertinente. Pour évaluer sa performance, nous soumettrons un questionnaire de satisfaction à nos clients qui participeront bien entendu à l’évolution continuelle de la solution.

Affaire à suivre…

Retour d’expérience sur notre mission intitulée « Mise à disposition d’une boîte à outils pour Data Scientist ».

Par Quentin MARINIE et Fabien VIOSSAT, étudiants 3A IMT Atlantique.

social network concept

Sur Facebook, ce sont près de 10 milliards de messages et 4,75 milliards de partages qui sont enregistrés chaque jour. Sur Twitter, le maximum de tweets par seconde est de 143 199. Si l’on rapporte ces chiffres à la courte durée de vie de ces entreprises (respectivement 12 et 10 ans) on se rend compte de l’importance croissante des réseaux sociaux dans notre vie de tous les jours. Mais très certainement vous-même appartenez à d’autres réseaux sociaux ou communautés telles que Wikipédia, Copains d’avant, Instagram, LinkedIn ou encore la communauté de votre fournisseur de forfait téléphonique.

Ces nouvelles solutions de communication ont un potentiel énorme mais les entreprises font alors face à de nouvelles problématiques : Comment gérer des millions d’individus ? Comment savoir si un forum ou une communauté est en « bonne santé » ?

Ce sont les questions auxquelles Standing On Giants, fournisseur de plate-formes pour communautés et filiale de Telefonica (UK), tentent de répondre en collaboration avec le département LUSSI de Télécom Bretagne. Il nous a donc été proposé (Quentin MARINIE et Fabien VIOSSAT) dans le cadre du Projet Ingénieur de la filière ISA de mener une phase de cadrage de cette mission. Encadrés par Mme Cécile Bothorel et M. Laurent Brisson, tous deux enseignants-chercheurs dans ce même département, nous avons pu entamer la phase préliminaire du projet. Cet article constitue notre retour d’expérience sur notre mission intitulée « Mise à disposition d’une boîte à outils pour Data Scientist ».

Ancrer son travail dans la durée…

Présents sur les réseaux sociaux depuis plusieurs années, nous nous sommes aperçus que nous étions purement et simplement novices dans l’analyse de leur utilisation. Guidés par nos tuteurs, nous nous sommes intéressés aux statistiques ainsi qu’à la théorie des graphes qui, comme dans de nombreux cas, permettent de solutionner nombre de problèmes. Lecture de thèses, recherche d’ouvrages ou d’articles sur internet mais encore prise en main d’un serveur, découvertes de packages sur différents langages ont été notre quotidien. Les premiers instants s’apparentaient donc à un état de l’art du domaine, nous avons ainsi pu donner une orientation initiale au projet.

Cette démarche s’inscrivant dans une mission durable, nous devions constamment donner une traçabilité à nos recherches, rédiger des documents présentant nos résultats ou encore proposer des tutoriels sur l’utilisation de méthodes.

En effet, un des points importants était la pérennité des résultats : notre étude ne durant que 6 mois et la mission étant destinée à durer plus longtemps, nous nous devions de laisser des traces pour garantir la bonne compréhension de nos travaux.

Où chercher ? Que chercher ?

Un des intérêts d’une telle mission est que d’une semaine à l’autre, avec l’obtention de résultats, il est nécessaire de réorienter les recherches. Des réunions étaient donc prévues avec nos tuteurs de manière à présenter ces résultats, discuter de ceux-ci et enfin fixer les prochains objectifs.

S5_2016_Mission

Il a par conséquent fallut effectuer de nombreux tests sans savoir s’ils allaient être concluants. Comme prévu, nombres d’entre eux se sont révélés peu intéressants pour la poursuite de l’étude. Cet aspect peu motivant était pourtant nécessaire.

Nous avons certainement autant appris de nos échecs que de nos découvertes.

La présence de nos encadrants était bien évidemment essentielle, dotés d’une plus grande expérience dans ces domaines, leurs intuitions se sont souvent révélées utiles et vraies. Cet appui nous a permis d’avancer bien plus vite que par nos simples recherches et, avec plus de recul, nous réalisons que le projet final a très peu à voir avec l’idée initiale que nous en avions.

Le bon outil pour le bon usage !

Neo4J, Python, R, NetworkX voici les premières pistes que nous avions pour explorer les graphes. Après une première prise en main de certains et une recherche sur d’autres logiciels, langages ou packages, nous avons sélectionnés ceux qui nous paraissaient à première vue les plus adaptés. Par la suite, nous avons dû approfondir nos recherches sur ces solutions.

Quelle solution convient la mieux à nos objectifs ? Un package présent sur Python et R est-il mieux documenté ou plus efficace sur l’un ou l’autre des langages ? Là encore de nombreux tests ont été réalisés sur nos propres machines avec à nouveau des tentatives non concluantes mais permettant de comparer les différentes solutions.

Cependant, nous avons assez rapidement fait face aux limites de nos ordinateurs. N’étant pas en possession des datasets de Standing On Giants, nous avons testés différents algorithmes classiques d’études de graphes (clustering, proximité, centralité, taille de cliques…) sur des s5_2016_Scalabitydatasets trouvés sur internet et aux caractéristiques bien différentes (de 4000 individus à près de 10 millions). En concertation avec nos encadrants, nous nous sommes alors vus attribuer un serveur de calcul du département LUSSI. L’idée étant de tester la scalabilité des packages sur des graphes de dimensions semblables à ceux susceptibles d’être fournis par Standing On Giants. Nous voulions ainsi tenter de trouver des liens ou des généralisations entre le temps d’exécution de certains algorithmes gourmands en ressources et les paramètres même du graphe. Tout cela ayant pour finalité de pouvoir donner une évaluation du temps d’exécution d’un algorithme sur un graphe uniquement en fonction de ses paramètres (cf. notre article sur ce même blog). Un serveur de 128 Go de RAM et 32 cœurs a alors été mis à notre disposition pour la durée du projet.

De l’art d’utiliser un serveur !

L’utilisation de ce serveur nous a réservé quelques surprises. Entre les problèmes de connexion au serveur lui-même, les problèmes de connexion internet via tunnel SSH, les mises en place problématiques de nos environnements R et Python ou encore les scripts qui semblent tourner sans fin, il nous a fallu nous accrocher. Initialement, cela nous semblait tout aussi simple que de prendre en main un terminal sous Ubuntu mais nous nous sommes alors rendu compte qu’une tâche aussi banale qu’importer un fichier s’avérait compliquée. ferme_serveursUne fois le serveur et ses configurations mieux maîtrisées, les scripts ont pu être lancés (en tout une trentaine entre R et Python) dont certains ont été abandonnés car trop longs. De plus, une partie des résultats était à nouveau inexploitable ou n’apportaient pas d’informations quant aux relations entre temps d’exécution et paramètres du graphe (diamètre, densité, réciprocité…). Un serveur n’est pas aussi transparent qu’un ordinateur physique et cela implique pour son utilisation une grande maîtrise de ce dernier et des compétences d’administrateur système !

Ce qu’on en retient

Il y a donc différents aspects qui ressortent de ce projet.

Tout d’abord, il fut très intéressant de travailler sur une mission concrète d’entreprise d’autant plus lorsqu’elle a trait à des problématiques actuelles.

En effet, l’utilisation de la théorie des graphes pour décrire les réseaux sociaux est en pleine expansion et avoir pu en apprendre un peu plus auprès d’enseignants-chercheurs a été très enrichissant.

Cette approche assez exploratoire nous a également apporté un aperçu du travail effectué en recherche dans les différents laboratoires de Télécom ou même d’ailleurs.

Il n’est pas simple de devoir remettre souvent ses résultats en question et d’accepter que certaines tâches effectuées n’auront pas d’utilité pour la suite du projet. Enfin, et plus personnellement, cela nous a permis d’élargir notre domaine de connaissance : théorie des graphes, utilisation d’un serveur de calcul, découvertes de packages, lecture des thèses. Tous ces éléments ont fait de ce projet une expérience réellement intéressante et nous souhaiterions remercier nos deux encadrants, Cécile Bothorel ainsi que Laurent Brisson, de nous avoir soutenus, supportés et guidés lors de cette mission.