Big Data : pourquoi l’architecture de vos outils est cruciale ?

Big Data : pourquoi l’architecture de vos outils est cruciale ?

Chaque seconde, vos visiteurs interagissent avec votre site laissant derrière eux une quantité d’informations phénoménale que vous pouvez ensuite utiliser pour leur créer des expériences sur-mesure. Devant un tel défi, autant s’assurer que les technologies que vous utilisez sont en mesure de traiter correctement ce volume de données ! 

Le « Big Data » n’est pas juste un buzzword. Notre architecture a entièrement été construite dans le but précis de pouvoir évoluer avec les dernières avancées technologiques et de manier facilement des quantités de données colossales.

Aujourd’hui, nous vous dévoilons les fondations de Kameleoon et les raisons de nos partis pris technologiques.

Ça y est, le smart data est enfin arrivé

Le défi des marketeurs n’est plus de collecter la donnée, mais de mieux l’exploiter. Vous accueillez en effet des milliers voire des millions de visiteurs sur votre site chaque mois et récoltez au moins autant d’informations sur leur comportement de navigation.

C’est pour vous donner ce pouvoir et faciliter votre prise de décision que le développement des solutions de Kameleoon se concentre depuis 2009 sur l’analyse et l’activation des données comportementales, contextuelles, démographiques ou encore issues de votre DMP ou de votre CRM. C’est notre cœur de métier, que ce soit via l’A/B testing, la personnalisation ou nos algorithmes de machine learning pour identifier les segments visiteurs qui comptent pour votre marque.

machine_learning_architecture_big_data

Aujourd’hui, et nous ne sommes pas les seuls à le dire, nous pouvons vous proposer la meilleure solution du marché pour mener vos campagnes de personnalisation et vos tests A/B, aussi complexes soient-ils.

L’agence Cartelis a réalisé un benchmark des 4 meilleures solutions d’A/B testing. Kameleoon en sort vainqueur.

Elasticsearch vs SQL, PHP : pourquoi nos choix technologiques sont importants pour vous ?

La technologie évolue vite, très vite. Et au risque de faire grincer des dents, beaucoup de technologies qui régnaient en maître au début des années 2000 sont devenues quasi obsolètes aujourd’hui (comme les bases SQL) ou sont inadaptées à des traitements en temps réel (comme le PHP ou autres langages généralement utilisés pour des sites web).

Le débat n’est pas de remettre en question la qualité de ces piliers du web, mais leur légitimité dans les écosystèmes actuels des entreprises. Par ailleurs, les nouvelles problématiques des entreprises quant à la gestion des données nécessitent une mise à niveau des installations en interne.

C’est pourquoi nous avons fait le choix d’intégrer des technologies plus stables et évolutives (à l’inverse des technologies SQL et PHP) que sont Elasticsearch et le NoSQL (#nosql) pour construire une architecture saine et pérenne, capable de répondre à l’ensemble des besoins de nos clients et de résister à l’épreuve du temps. 

SQL vs. NoSQL

Les bases de données SQL sont au cœur du développement d’Internet depuis les années 70s. Et des sites comme Google, Facebook, Twitter ou YouTube reposent encore en partie sur des bases SQL. Seulement, ce sont des bases inadaptées aux contraintes du temps réel.

Lorsque le volume de données à traiter devient trop important, ce type de base de données fonctionne au ralenti. Sur un outil de personnalisation de l’expérience utilisateur, les conséquences pour vos visiteurs sont directes. Lorsque vous créez des personnalisations avancées en réconciliant des parcours cross-device ou remontant des informations de votre DMP ou CRM,  la promesse du temps réel est impossible à tenir.

Il existe deux solutions pour palier ce problème :

1. Constamment faire monter sa base de donnée SQL en grade avec des mises à jour hardware, au risque de créer de l’instabilité et compromettre l’intégrité des données exploitées.

2. Distribuer la charge des données sur différentes bases avec des caractéristiques bien définies. C’est le pari que nous avons fait chez Kameleoon avec une structure NoSQL.

Le NoSQL (qui signifie en fait Not Only SQL) a été amorcé par quelques-uns des géants cités ci-dessus. Pourquoi ? Parce qu’ils ont réalisé qu’une meilleure allocation de la donnée était la meilleure façon d’exploiter les volumes de données massifs.

Cette vidéo d’introduction sur le sujet SQL vs. NoSQL (en anglais) d’Alan Perkins (Director of Technology de Rackspace) expose bien les différences entre les deux.

Et en application, comment Kameleoon gère les données visiteurs ?

1. Un visiteur lambda arrive sur votre site. Toutes ses données de visites (comportementales, contextuelles, etc.) sont enregistrées automatiquement en local sur le LocalStorage de son navigateur. Cela permet immédiatement de délivrer des expériences personnalisées, sans même nécessiter d’appel à un serveur distant.

2. Toutes ces données sont également enregistrées par Kameleoon via un de nos serveurs. Une fois que la visite est considérée comme finie (après 30 minutes d’inactivité), les données sont immédiatement envoyées à l’infrastructure de stockage.

Voyons maintenant comment se déroule le stockage de données.

3. Avec le NoSQL, nous avons déployé deux plateformes de stockage de données :

  • Elasticsearch : c’est à la fois une brique de stockage et un moteur de recherche étudiés pour exploiter la donnée en temps réel. Cela permet d’envoyer des rapports vers le back-office de Kameleoon pour obtenir des analyses, mais aussi, lorsque c’est pertinent, de récupérer des données côté navigateur. Comme par exemple dans le cas de la réconciliation d’historiques cross-device, où il est nécessaire de télécharger depuis un serveur les informations de visites passées réalisées sur un device différent. Ou bien dans le cas d’une connexion avec une plateforme de « push » d’évènements temps réel en dehors du site web (#no, solutions de type Segment, appel téléphonique à un call center, etc.). Ces évènements sont automatiquement reliés avec la visite courante sur le site web et vous pouvez y activer des personnalisations.
  • Cassandra : on y stocke l’ensemble des données de visite. Cela nous permet de réaliser des analyses avancées qui ne nécessitent pas d’immédiateté, sans impacter les performances de la première plateforme de stockage, Elasticsearch.

Le fait est que les architectures basées sur le NoSQL tendent à remplacer leurs ainés sur le web pour deux simples raisons :

  • elles sont capables d’évoluer et de s’adapter aux dernières innovations
  • elles peuvent gérer de plus grandes quantités de données

Ces technologies changent la donne pour nous et nos clients.

Jean-Noel Rivasseau - architecture big data kameleoon“Le volume de données que nous traitons est gigantesque. Plutôt que de prendre le risque d’être emprisonné dans la logique d’optimisation continue d’un système obsolète, nous avons choisi très tôt de faire le pari de mettre en place une architecture plus moderne et saine avec le NoSQL. C’est pourquoi Kameleoon peut traiter d’immenses volumes de données et tenir la promesse du temps réel.

Jean Noël Rivasseau, Fondateur et CTO de Kameleoon.

Demandez votre démonstration !

Si vous ne croyez que ce que vous voyez, demandez une démonstration de nos solutions d’optimisation de l’expérience utilisateur. Cela vous permettra d’entrevoir l’étendue des possibilités que vous offre un tel outil.

demande de démo kameleoon

Gregoire est Head of Marketing à Kameleoon. Il est responsable du lancement des nouveaux produits et de la croissance de l'écosystème Kameleoon.

Des articles qui pourraient vous intéresser