Ce projet pilote utilisant des traqueurs de localisation pour analyser le comportement des visiteurs a été mis en œuvre dans deux supermarchés avec un fort trafic. Le responsable du département informatique représentait le supermarché et a fourni toutes les autorisations pour installer et maintenir le projet pilote.
Par conséquent, nous avons eu l'autorisation de connecter notre système externe au FTP du supermarché et à leurs systèmes serveur, où tous les reçus du supermarché étaient enregistrés, nous permettant d'utiliser ces enregistrements.
L'idée
L'idée clé était d'envoyer des offres promotionnelles ciblées aux visiteurs du supermarché. Ces offres pouvaient être à long terme ou à court terme, envoyées chaque fois que le supermarché avait besoin de vendre certains produits sélectionnés dès que possible.
Initialement, la principale tâche était d'obtenir des informations à partir de chaque reçu d'acheteur. Plus tard, ces informations ont formé une base de données commune des préférences de produits pour des milliers de clients du magasin.
En d'autres termes, l'acheteur choisirait une gamme de biens, paierait pour eux à la caisse, et 30-40 minutes plus tard nous aurions les informations sur leurs achats dans notre service.
L'idée technique était d'installer du matériel directement à l'entrée de l'espace commercial. L'intention ici était de suivre les entrées des clients réguliers.
Flux d'implémentation du projet
- Un visiteur entre dans le magasin. Sa carte est scannée par le lecteur à l'entrée, mais, comme il se trouve, nous ne savons rien de lui – il n'y a aucune information. Mais justement, c'est que après ce visiteur « propre » effectue un achat, notre cloud est mis à jour en jusqu'à une demi-heure avec les données de ce visiteur – et nous avons le sentiment de ses préférences d'achat.
- Nous traitons ensuite ces informations et les sauvegardons dans une base de données commune. Nous créons un grand groupe de profils d'utilisateurs, nous permettant de travailler avec des gros volumes de données.
- Par exemple, si le client X achète du lait d'une certaine marque, puis achète du yaourt produit par le même fabricant, alors cela est reconnu comme faisant partie du groupe de produits laitiers. En retour, ce groupe de produits laitiers peut être compatible avec d'autres groupes de biens pour diverses raisons (les informations sont analysées par nous). Cela signifie que nous pouvons envoyer une offre de viande fumée au client X, et nous pouvons être certains, basés sur notre analyse approfondie, que le client achètera cette viande avec une probabilité de 70%.
- Les probabilités sont calculées après examen des millions de reçus. De cette façon, nous avons identifié certaines interconnexions entre les achats, ce qui était important pour maximiser les ventes.
- L'étape finale de tout ce processus est l'offre elle-même, la promotion. Lorsque le client X visite le magasin quelques jours plus tard, nous savons déjà quelle offre lui envoyer (si une telle proposition a été préparée par le département marketing, bien sûr).
Le Serveur de Notifications reçoit des données en continu du Serveur de Promotion Marketing, donc toutes les nouvelles offres du supermarché qui doivent être montrées à un certain groupe de visiteurs avec des cartes sont déployées au bon moment.
Marketing Derrière le Service
Le département marketing nous envoie les données concernant environ 2000 articles. En général, le département marketing fixe un certain délai pour publier un groupe particulier de biens.
Par exemple, un acheteur Y entre dans le magasin et, tenant compte de notre analyse de leur comportement d'achat passé, nous pouvons conclure qu'ils aiment le vin et les chips. Nous transmettons cette information au Serveur de Promotion Marketing. Ensuite, les spécialistes du centre marketing examinent s'il existe des offres de produits disponibles qui pourraient être publicités pour le visiteur Y. Le centre forme le texte du message publicitaire, donne un signal au Serveur de Notifications et envoie finalement un message à Y avec une offre publicitaire. Le point est que le service marketing sait quelle offre envoyer. Simply put, une offre peut être conçue pour les amateurs de lait, tandis qu'une autre pourrait être envoyée aux fans de poisson.
Le Serveur de Promotion Marketing fonctionnait sur la base de Node.js en conjonction avec MongoDB. Il conservait également toutes les informations que le supermarché partageait sur les entreprises publicitaires.
Ensuite, l'algorithme de fréquence prend le relais – à qui montrons-nous plus souvent des messages, à qui moins fréquemment ? Afin de ne pas ennuyer les acheteurs auxquels nous envoyons souvent des messages, nous ralentissons un peu et n'envoyons que ceux qui ont rarement reçu nos messages.
Implémentation technique
Des lecteurs hautement sensibles ont été installés sur les rayons dans les supermarchés ; initialement, nous utilisions des lecteurs RFID RQ3. Les visiteurs du supermarché avaient des cartes de fidélité avec des balises RFID uniques. La carte elle-même était appliquée à la caisse lors des achats pour un certain montant, ou selon tout autre programme commercial.
En conséquence, lorsque l'acheteur potentiel entrait dans le supermarché, nous avions déjà leurs informations à portée de main.
L'idée était de transférer immédiatement toutes les offres commerciales du magasin vers les téléphones et applications. Cependant, cela réduirait considérablement le nombre de visiteurs pouvant l'utiliser. Cette situation a relevé le niveau : nous devions implémenter la meilleure solution afin que même les personnes âgées puissent utiliser le courrier commercial. Donc le défi du supermarché envers nous était de couvrir au moins 60% de tous les clients stationnaires du magasin.
Par conséquent, le canal de communication de masse devait être basé sur des notifications SMS ou USSD.
Un visiteur entrerait dans le magasin et sa carte serait scannée avec un lecteur spécial. Notre serveur recevrait alors un signal (via l'application basée sur Node.js, qui a été remplacée par Python), soulevant la question de savoir si une promotion serait utile dans ce cas. Y avait-il un schéma pour le client ou non ? … Si une offre était disponible pour l'acheteur, il recevrait un SMS.
Où étaient stockées toutes les données ?
Nous avons utilisé CouchDB pour le stockage des données. Plus tard, nous avons changé le système en Couchbase pour plus de commodité.
Comment le travail des microservices était organisé ? Le traitement des données, donc les profils, modèles et schémas appartenant aux utilisateurs – ce module travaillait directement avec la base de données et analysait également ses données. Ici, nous avons utilisé une combinaison de logique + Python + Couchbase. C'est-à-dire que le protocole MTP a été installé – les services externes communiquaient avec lui, et un API Restfull régulier basé sur Node.js a été installé. Il recevait toutes les demandes provenant des balises venant de nos serveurs Arduino, passant par des canaux 3G. La tâche de l'API RestFull était simplement d'obtenir des données et rien de plus. Ici, il transférait les informations via le protocole MTP vers le stockage.
En d'autres termes, il y avait un certain nombre de tâches, et le service qui travaillait avec la base de données les recevait comme file d'attente pour traitement (que), où toutes les tâches étaient traitées de manière synchrone.
Le serveur de notification était connecté à Twilio, ainsi qu'à un serveur de notifications push. Sa tâche était d'obtenir le numéro de téléphone ou l'UID du dispositif mobile et d'envoyer le texte désigné.
Nous avions une connexion au service Python en arrière-plan, qui se connectait périodiquement aux serveurs FTP Node.js, et téléchargeait des centaines de milliers d'enregistrements et de hachages supplémentaires. Environ un million d'enregistrements ont été téléchargés et stockés dans Couchbase. Une fois par heure, il traitait une certaine quantité de données pour créer certains groupes d'utilisateurs avec les préférences claires des clients.
La Prochaine Étape D'Intégration Et De Test
À la deuxième phase de développement, nous devions installer plus de lecteurs dans différentes zones pour envoyer un ensemble d'offres. L'objectif principal, tel que défini par le supermarché, était de fournir aux promoteurs des canaux de communication supplémentaires sans surcharger l'espace commercial avec la publicité.
La direction du supermarché voulait voir à quel point cette campagne publicitaire serait efficace par rapport aux méthodes marketing alternatives (par exemple, bannières, prospectus, etc.).
Nous devions suivre comment le message publicitaire affecte le résultat de l'achat. Par exemple, des messages publicitaires avec le texte hypothétique « acheter du saucisson » ont été envoyés à environ 10 mille clients potentiels pendant une certaine période. Il était nécessaire de calculer combien de saucisson a été vendu pendant cette période, par rapport aux résultats précédents. Selon les résultats obtenus, nous pouvions tirer certaines conclusions. Une analogie au modèle de coût par action en ligne sur Internet pourrait être appliquée ici où le client ne paie que lorsque des actions spécifiques sont effectuées par les utilisateurs/visiteurs.
Pour tester cette phase, 20 visiteurs du supermarché ont reçu des balises RFID, et leur tâche était de simuler le comportement des visiteurs ordinaires du supermarché.
Résumé
Bien que cela puisse sembler futuriste, les recommandations/promotions orientées vers les visiteurs apparaîtront dans tous les grands supermarchés de détail dans l'année à venir. Amazon a déjà prouvé que beaucoup de processus en détails peuvent être automatisés avec leurs magasins Amazon Go . L'attention et la fidélité des visiteurs constituent le « coffre d'or » pour lequel les entreprises modernes se disputent maintenant.