Échelle et performances
Dans cet article, nous expliquerons comment la plateforme Didomi est conçue pour évoluer selon les besoins de votre organisation et comment optimiser notre technologie pour fonctionner sur vos sites web et vos applications.
Mise à l'échelle de la plateforme Didomi
Dans les sections ci-dessous, nous présentons les moyens par lesquels certaines parties de la plateforme Didomi font évoluer ses technologies :
Script
Le code JavaScript de Didomi est hébergé de manière statique sur AWS S3 et diffusé via Amazon CloudFront avec réplication dans tous ses points de présence dans le monde (y compris en Espagne). Didomi n'a aucun serveur unique dans ce chemin, et nous sommes convaincus que CloudFront peut évoluer sans problème.
La bannière, la fenêtre contextuelle et la gestion des balises (déclenchement de toute balise tierce nécessitant le consentement, l'API CMP de l'IAB, etc...) se font sans aucune requête serveur (le consentement est mis en cache localement dans un cookie), de sorte que l'expérience utilisateur finale de votre organisation n'est pas impactée.
Serveurs back-end
Didomi envoie des requêtes HTTP lorsque le consentement est collecté ou pour compter les pages vues (nous échantillonnons le nombre de pages vues en comptant entre 10 % et 20 %). Ces requêtes sont asynchrones et se produisent toujours après toutes les opérations front-end, de sorte que, même en cas d'échec, cela n'aurait aucun impact sur l'utilisateur final. Cela signifie également que si les serveurs Didomi étaient indisponibles, l'expérience de vos utilisateurs finaux ne serait pas impactée et le consentement serait stocké localement puis envoyé à nos serveurs ultérieurement.
Les serveurs back-end sont surveillés 24 heures sur 24, 7 jours sur 7, avec des alertes via New Relic et AWS CloudWatch afin de garantir que Didomi est informé en cas de problème. Nous faisons évoluer automatiquement ces serveurs afin d'ajouter (ou de retirer) des serveurs à notre infrastructure selon les besoins tout au long de la journée ou lors de l'arrivée de nouveaux clients.
En règle générale, Didomi ne surveille pas les clients individuellement (nous pouvons le faire exceptionnellement de temps à autre), car nous nous concentrons sur le fait de garantir que toute notre infrastructure est élastique, peut évoluer sans aucune intervention humaine, et que l'indisponibilité de nos serveurs n'impacte pas le parcours critique de collecte/gestion du consentement pour les utilisateurs finaux. Nous savons que nous pouvons gérer 10 fois plus de trafic qu'aujourd'hui sans aucun problème (et cette croissance s'est produite plusieurs fois au cours des derniers mois).
Performance de la plateforme Didomi
La règle générale chez Didomi est une obligation de minimiser l'impact de notre présence sur les sites web. Afin d'y parvenir, nous avons mis en place les mesures suivantes :
Utiliser un CDN (AWS CloudFront) et mettre notre SDK en cache de manière agressive afin de garantir qu'il soit distribué le plus rapidement possible partout dans le monde grâce à des points de présence locaux.
Réduire au minimum le nombre de requêtes HTTP que nous envoyons à nos serveurs. Le chargement initial (la première fois qu'un utilisateur final charge notre SDK) prend généralement deux requêtes HTTP, et les chargements ultérieurs du SDK ne nécessitent pas de requêtes HTTP pour la gestion du consentement. Nous intégrons la géolocalisation de l'utilisateur final ainsi que toute configuration spécifique à vos sites web dans une version de notre SDK propre au site web afin d'éviter des allers-retours supplémentaires.
Mettre en cache localement toutes les informations relatives au consentement dans des cookies afin de garantir que nous puissions répondre immédiatement aux demandes de consentement sur la page. Cela signifie que nous ne retardons pas le chargement de vos balises publicitaires en chargeant des données depuis nos serveurs.
Pour les éditeurs non européens, nous restons autant que possible en retrait pour les utilisateurs finaux non européens et déclenchons immédiatement toutes les balises dont nous pouvons être responsables, sans aucune requête à nos serveurs. Dans ces cas, nous chargeons une version spécifique de notre SDK qui n'inclut pas tous les composants d'interface utilisateur afin d'être plus légère : son seul rôle est de déclencher toutes les balises aussi rapidement que possible. Avec une configuration supplémentaire, nous pouvons également éviter complètement de charger notre SDK pour les utilisateurs finaux non européens et vous permettre de configurer Google Tag Manager de manière à ce qu'il n'y ait aucun délai/condition pour les utilisateurs finaux non européens.
Le SDK Didomi est déployé avec l'attribut "async" afin de garantir qu'il ne bloque pas votre contenu.
Mis à jour