Il semble que le domaine de la publicité en ligne devrait être aussi avancé et automatisé que possible sur le plan technologique. Bien sûr, parce que des géants et des experts dans leur domaine comme Yandex, Mail.Ru, Google et Facebook y travaillent. Mais il s’est avéré qu’il n’y a pas de limite à la perfection et qu’il y a toujours quelque chose à automatiser.
Groupe de communication Dentsu Aegis Network Russie est le plus grand acteur du marché de la publicité numérique et investit activement dans la technologie, en essayant d'optimiser et d'automatiser ses processus commerciaux. L'un des problèmes non résolus du marché de la publicité en ligne est la tâche de collecter des statistiques sur les campagnes publicitaires des différentes plateformes Internet. La solution à ce problème a finalement abouti à la création d'un produit D1.Numérique (lire comme DiVan), dont nous voulons parler du développement.
Pourquoi?
1. Au moment du démarrage du projet, il n'existait pas sur le marché un seul produit prêt à l'emploi qui résolvait le problème de l'automatisation de la collecte de statistiques sur les campagnes publicitaires. Cela signifie que personne d’autre que nous ne satisfera nos besoins.
Des services tels que Improvado, Roistat, Supermetrics, SegmentStream offrent une intégration avec les plateformes, les réseaux sociaux et Google Analitycs, et permettent également de créer des tableaux de bord analytiques pour une analyse et un contrôle pratiques des campagnes publicitaires. Avant de commencer à développer notre produit, nous avons essayé d'utiliser certains de ces systèmes pour collecter des données sur des sites, mais malheureusement, ils n'ont pas pu résoudre nos problèmes.
Le principal problème était que les produits testés étaient basés sur des sources de données, affichant des statistiques de placement par site, et n'offraient pas la possibilité de regrouper des statistiques sur les campagnes publicitaires. Cette approche ne nous a pas permis de visualiser les statistiques de différents sites en un seul endroit et d'analyser l'état de la campagne dans son ensemble.
Un autre facteur était qu'au début, les produits étaient destinés au marché occidental et ne permettaient pas l'intégration avec les sites russes. Et pour les sites avec lesquels l'intégration a été mise en œuvre, toutes les métriques nécessaires n'étaient pas toujours téléchargées avec suffisamment de détails, et l'intégration n'était pas toujours pratique et transparente, surtout lorsqu'il était nécessaire d'obtenir quelque chose qui n'était pas dans l'interface système.
En général, nous avons décidé de ne pas nous adapter aux produits tiers, mais avons commencé à développer les nôtres...
2. Le marché de la publicité en ligne croît d'année en année et, en 2018, en termes de budgets publicitaires, il a dépassé le marché de la publicité télévisée traditionnellement le plus important. Il y a donc une échelle.
3. Contrairement au marché de la publicité télévisée, où la vente de publicité commerciale est monopolisée, de nombreux propriétaires individuels d'inventaires publicitaires de différentes tailles opèrent sur Internet avec leurs propres comptes publicitaires. Étant donné qu'une campagne publicitaire s'exécute généralement sur plusieurs sites à la fois, pour comprendre l'état de la campagne publicitaire, il est nécessaire de collecter des rapports de tous les sites et de les combiner en un seul grand rapport qui montrera l'ensemble de la situation. Cela signifie qu’il existe un potentiel d’optimisation.
4. Il nous a semblé que les propriétaires d'inventaires publicitaires sur Internet disposent déjà de l'infrastructure pour collecter des statistiques et les afficher dans les comptes publicitaires, et qu'ils pourront fournir une API pour ces données. Cela signifie qu’il est techniquement possible de le mettre en œuvre. Disons tout de suite que cela s'est avéré pas si simple.
De manière générale, tous les prérequis à la mise en œuvre du projet nous paraissaient évidents, et nous avons couru pour donner vie au projet...
Grand plan
Pour commencer, nous avons formé une vision d’un système idéal :
- Les campagnes publicitaires du système d'entreprise 1C doivent y être automatiquement chargées avec leurs noms, périodes, budgets et emplacements sur diverses plateformes.
- Pour chaque placement au sein d'une campagne publicitaire, toutes les statistiques possibles doivent être automatiquement téléchargées depuis les sites où le placement a lieu, comme le nombre d'impressions, de clics, de vues, etc.
- Certaines campagnes publicitaires sont suivies à l'aide d'une surveillance tierce par des systèmes dits de diffusion de publicité tels qu'Adriver, Weborama, DCM, etc. Il existe également en Russie un compteur Internet industriel - la société Mediascope. Selon notre plan, les données provenant d'une surveillance indépendante et industrielle devraient également être automatiquement chargées dans les campagnes publicitaires correspondantes.
- La plupart des campagnes publicitaires sur Internet visent certaines actions cibles (achat, appel, inscription à un essai routier, etc.), qui sont suivies à l'aide de Google Analytics, et dont les statistiques sont également importantes pour comprendre l'état de la campagne et doit être chargé dans notre outil.
La première crêpe est grumeleuse
Compte tenu de notre engagement envers les principes flexibles du développement logiciel (agile, tout), nous avons décidé de d'abord développer un MVP, puis d'avancer de manière itérative vers l'objectif visé.
Nous avons décidé de créer MVP basé sur notre produit DANBo (Conseil du réseau Dentsu Aegis), qui est une application web contenant des informations générales sur les campagnes publicitaires de nos clients.
Pour MVP, le projet a été simplifié au maximum en termes de mise en œuvre. Nous avons sélectionné une liste limitée de plateformes d'intégration. Il s'agissait des principales plates-formes telles que Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB et des principaux systèmes de diffusion de publicité Adriver et Weborama.
Pour accéder aux statistiques des sites via l'API, nous avons utilisé un seul compte. Un responsable de groupe client qui souhaitait utiliser la collecte automatique de statistiques sur une campagne publicitaire devait au préalable déléguer l'accès aux campagnes publicitaires nécessaires sur les sites au compte de la plateforme.
Vient ensuite l'utilisateur du système DANBo devait télécharger dans le système Excel un fichier d'un certain format, qui contenait toutes les informations sur le placement (campagne publicitaire, plateforme, format, période de placement, indicateurs prévus, budget, etc.) et les identifiants des campagnes publicitaires correspondantes sur le sites et compteurs dans les systèmes de diffusion de publicité.
Franchement, cela avait l’air terrifiant :
Les données téléchargées ont été enregistrées dans une base de données, puis des services distincts ont collecté à partir d'eux des identifiants de campagne sur les sites et téléchargé des statistiques sur ceux-ci.
Pour chaque site, un service Windows distinct a été écrit, qui passait une fois par jour sous un compte de service dans l'API du site et téléchargeait des statistiques pour les ID de campagne spécifiés. La même chose s'est produite avec les systèmes de diffusion de publicité.
Les données téléchargées étaient affichées sur l'interface sous la forme d'un petit tableau de bord personnalisé :
De manière inattendue pour nous, MVP a commencé à travailler et a commencé à télécharger des statistiques actuelles sur les campagnes publicitaires sur Internet. Nous avons implémenté le système sur plusieurs clients, mais en essayant de le faire évoluer, nous avons rencontré de sérieux problèmes :
- Le principal problème était la complexité de la préparation des données à charger dans le système. De plus, les données de placement devaient être converties dans un format strictement fixe avant le chargement. Il était nécessaire d'inclure les identifiants d'entités de différents sites dans le fichier de téléchargement. Nous sommes confrontés au fait qu'il est très difficile pour des utilisateurs techniquement non formés d'expliquer où trouver ces identifiants sur le site et où dans le fichier il faut les saisir. Compte tenu du nombre d'employés des services qui mènent des actions sur les sites et du chiffre d'affaires, cela s'est traduit par un énorme soutien de notre part, dont nous n'étions absolument pas satisfaits.
- Un autre problème était que toutes les plateformes publicitaires ne disposaient pas de mécanismes permettant de déléguer l'accès aux campagnes publicitaires à d'autres comptes. Mais même si un mécanisme de délégation était disponible, tous les annonceurs ne seraient pas disposés à accorder l'accès à leurs campagnes à des comptes tiers.
- Un facteur important a été l'indignation suscitée parmi les utilisateurs par le fait que tous les indicateurs prévus et les détails de placement qu'ils entrent déjà dans notre système comptable 1C, ils doivent les saisir à nouveau. DANBo.
Cela nous a donné l'idée que la principale source d'informations sur le placement devrait être notre système 1C, dans lequel toutes les données sont saisies avec précision et à temps (le fait est que les factures sont générées sur la base des données 1C, donc saisie correcte des données dans 1C est une priorité pour tout le monde (KPI). C'est ainsi qu'est né un nouveau concept du système...
Concept
La première chose que nous avons décidé de faire a été de séparer le système de collecte de statistiques sur les campagnes publicitaires sur Internet en un produit distinct - D1.Numérique.
Dans le nouveau concept, nous avons décidé de charger dans D1.Numérique des informations sur les campagnes publicitaires et les emplacements qu'elles contiennent à partir de 1C, puis extrayez les statistiques des sites et des systèmes AdServing vers ces emplacements. Cela était censé simplifier considérablement la vie des utilisateurs (et, comme d'habitude, ajouter plus de travail aux développeurs) et réduire la quantité de support.
Le premier problème que nous avons rencontré était de nature organisationnelle et était lié au fait que nous ne pouvions pas trouver de clé ou de signe permettant de comparer les entités de différents systèmes avec les campagnes et les placements de 1C. Le fait est que le processus dans notre entreprise est conçu de telle manière que les campagnes publicitaires sont saisies dans différents systèmes par différentes personnes (planificateurs média, acheteurs, etc.).
Pour résoudre ce problème, nous avons dû inventer une clé hachée unique, DANBoID, qui relierait les entités de différents systèmes entre elles et qui pourrait être identifiée assez facilement et de manière unique dans les ensembles de données téléchargés. Cet identifiant est généré dans le système interne 1C pour chaque placement individuel et est transféré aux campagnes, placements et compteurs sur tous les sites et dans tous les systèmes AdServing. La mise en œuvre de la pratique consistant à mettre DANBoID dans tous les emplacements a pris un certain temps, mais nous avons réussi à le faire :)
Ensuite, nous avons découvert que tous les sites ne disposent pas d'une API pour collecter automatiquement des statistiques, et même ceux qui disposent d'une API ne renvoient pas toutes les données nécessaires.
À ce stade, nous avons décidé de réduire considérablement la liste des plateformes d'intégration et de nous concentrer sur les principales plateformes impliquées dans la grande majorité des campagnes publicitaires. Cette liste comprend tous les plus grands acteurs du marché de la publicité (Google, Yandex, Mail.ru), des réseaux sociaux (VK, Facebook, Twitter), des principaux systèmes d'AdServing et d'analyse (DCM, Adriver, Weborama, Google Analytics) et d'autres plateformes.
La majorité des sites que nous avons sélectionnés disposaient d’une API qui fournissait les métriques dont nous avions besoin. Dans les cas où il n'y avait pas d'API ou ne contenait pas les données nécessaires, nous utilisions les rapports envoyés quotidiennement à notre bureau par courrier électronique pour charger les données (dans certains systèmes, il est possible de configurer de tels rapports, dans d'autres, nous nous sommes mis d'accord sur le développement de tels rapports). pour nous).
En analysant les données de différents sites, nous avons découvert que la hiérarchie des entités n'est pas la même dans les différents systèmes. De plus, les informations doivent être téléchargées avec des détails différents à partir de différents systèmes.
Pour résoudre ce problème, le concept SubDANBoID a été développé. L'idée de SubDANBoID est assez simple, on marque l'entité principale de la campagne sur le site avec le DANBoID généré, et on télécharge toutes les entités imbriquées avec des identifiants uniques de site et on forme SubDANBoID selon le principe DANBoID + identifiant du premier niveau entité imbriquée + identifiant de l'entité imbriquée de deuxième niveau +... Cette approche nous a permis de connecter des campagnes publicitaires dans différents systèmes et de télécharger des statistiques détaillées sur celles-ci.
Nous avons également dû résoudre le problème de l’accès aux campagnes sur différentes plateformes. Comme nous l'avons écrit ci-dessus, le mécanisme de délégation de l'accès à une campagne à un compte technique distinct n'est pas toujours applicable. Nous avons donc dû développer une infrastructure d'autorisation automatique via OAuth utilisant des tokens et des mécanismes de mise à jour de ces tokens.
Plus loin dans l’article, nous tenterons de décrire plus en détail l’architecture de la solution et les détails techniques de la mise en œuvre.
Architecture des solutions 1.0
Lors du démarrage de la mise en œuvre d'un nouveau produit, nous avons compris qu'il fallait immédiatement prévoir la possibilité de connecter de nouveaux sites, nous avons donc décidé de suivre la voie de l'architecture des microservices.
Lors de la conception de l'architecture, nous avons séparé les connecteurs de tous les systèmes externes - 1C, plateformes publicitaires et systèmes de diffusion de publicité - en services distincts.
L'idée principale est que tous les connecteurs vers les sites ont la même API et sont des adaptateurs qui amènent l'API du site à une interface qui nous convient.
Au centre de notre produit se trouve une application Web, qui est un monolithe conçu de telle manière qu'il peut être facilement désassemblé en services. Cette application est responsable du traitement des données téléchargées, de la collecte des statistiques de différents systèmes et de leur présentation aux utilisateurs du système.
Pour communiquer entre les connecteurs et l'application web, nous avons dû créer un service supplémentaire, que nous avons appelé Connector Proxy. Il remplit les fonctions de découverte de services et de planificateur de tâches. Ce service exécute chaque nuit des tâches de collecte de données pour chaque connecteur. Écrire une couche de service était plus simple que connecter un courtier de messages, et pour nous il était important d'obtenir le résultat le plus rapidement possible.
Pour plus de simplicité et de rapidité de développement, nous avons également décidé que tous les services seront des API Web. Cela a permis d’assembler rapidement une preuve de concept et de vérifier que l’ensemble de la conception fonctionne.
Une tâche distincte, plutôt complexe, consistait à configurer l'accès pour collecter les données de différents comptes, qui, comme nous l'avons décidé, devraient être effectuées par les utilisateurs via l'interface Web. Il se compose de deux étapes distinctes : d'abord, l'utilisateur ajoute un jeton pour accéder au compte via OAuth, puis configure la collecte de données pour le client à partir d'un compte spécifique. L'obtention d'un token via OAuth est nécessaire car, comme nous l'avons déjà écrit, il n'est pas toujours possible de déléguer l'accès au compte souhaité sur le site.
Pour créer un mécanisme universel de sélection d'un compte sur les sites, nous avons dû ajouter une méthode à l'API des connecteurs qui renvoie le schéma JSON, qui est rendu sous une forme à l'aide d'un composant JSONEditor modifié. De cette façon, les utilisateurs pouvaient sélectionner les comptes à partir desquels télécharger des données.
Pour respecter les limites de requêtes qui existent sur les sites, nous combinons les demandes de paramètres au sein d'un même token, mais nous pouvons traiter différents tokens en parallèle.
Nous avons choisi MongoDB comme stockage des données chargées à la fois pour l'application Web et pour les connecteurs, ce qui nous a permis de ne pas trop nous soucier de la structure des données dans les premières étapes de développement, lorsque le modèle objet de l'application change tous les deux jours.
Nous avons vite découvert que toutes les données ne s'intègrent pas bien dans MongoDB et, par exemple, il est plus pratique de stocker des statistiques quotidiennes dans une base de données relationnelle. Par conséquent, pour les connecteurs dont la structure de données est plus adaptée à une base de données relationnelle, nous avons commencé à utiliser PostgreSQL ou MS SQL Server comme stockage.
L'architecture et les technologies choisies nous ont permis de construire et de lancer le produit D1.Digital relativement rapidement. En deux ans de développement de produits, nous avons développé 23 connecteurs vers des sites, acquis une expérience inestimable en travaillant avec des API tierces, appris à éviter les pièges de différents sites, qui avaient chacun le sien, contribué au développement d'API pour au moins 3 sites , a téléchargé automatiquement des informations sur près de 15 000 campagnes et pour plus de 80 000 emplacements, a collecté de nombreux retours des utilisateurs sur le fonctionnement du produit et a réussi à modifier plusieurs fois le processus principal du produit, sur la base de ces retours.
Architecture des solutions 2.0
Deux ans se sont écoulés depuis le début du développement D1.Numérique. L'augmentation constante de la charge sur le système et l'émergence de plus en plus de nouvelles sources de données ont progressivement révélé des problèmes dans l'architecture de la solution existante.
Le premier problème est lié à la quantité de données téléchargées depuis les sites. Nous avons été confrontés au fait que la collecte et la mise à jour de toutes les données nécessaires auprès des plus grands sites commençaient à prendre trop de temps. Par exemple, la collecte des données du système de diffusion de publicité AdRiver, avec lequel nous suivons les statistiques de la plupart des emplacements, prend environ 12 heures.
Pour résoudre ce problème, nous avons commencé à utiliser toutes sortes de rapports pour télécharger des données à partir de sites, nous essayons de développer leur API avec les sites afin que la vitesse de son fonctionnement réponde à nos besoins et de paralléliser autant que possible le téléchargement des données.
Un autre problème concerne le traitement des données téléchargées. Désormais, lorsque de nouvelles statistiques de placement arrivent, un processus en plusieurs étapes de recalcul des métriques est lancé, qui comprend le chargement des données brutes, le calcul des métriques agrégées pour chaque site, la comparaison des données provenant de différentes sources entre elles et le calcul des métriques récapitulatives pour la campagne. Cela entraîne beaucoup de charge sur l'application Web qui effectue tous les calculs. Plusieurs fois, au cours du processus de recalcul, l'application a consommé toute la mémoire du serveur, environ 10 à 15 Go, ce qui a eu l'effet le plus néfaste sur le travail des utilisateurs avec le système.
Les problèmes identifiés et les projets ambitieux de développement ultérieur du produit nous ont conduits à reconsidérer l'architecture de l'application.
Nous avons commencé avec les connecteurs.
Nous avons remarqué que tous les connecteurs fonctionnent selon le même modèle, nous avons donc construit un framework de pipeline dans lequel pour créer un connecteur il suffisait de programmer la logique des étapes, le reste était universel. Si un connecteur nécessite une amélioration, nous le transférons immédiatement vers un nouveau framework en même temps que le connecteur est amélioré.
En parallèle, nous avons commencé à déployer des connecteurs vers Docker et Kubernetes.
Nous avons planifié le passage à Kubernetes depuis assez longtemps, expérimenté les paramètres CI/CD, mais n'avons commencé à bouger que lorsqu'un connecteur, en raison d'une erreur, a commencé à consommer plus de 20 Go de mémoire sur le serveur, tuant pratiquement d'autres processus. . Au cours de l’enquête, le connecteur a été déplacé vers un cluster Kubernetes, où il est finalement resté, même après la correction de l’erreur.
Assez rapidement, nous avons réalisé que Kubernetes était pratique et, en six mois, nous avons transféré 7 connecteurs et Connectors Proxy, qui consomment le plus de ressources, vers le cluster de production.
Suite aux connecteurs, nous avons décidé de changer l'architecture du reste de l'application.
Le principal problème était que les données proviennent des connecteurs vers les proxys en gros lots, puis atteignent le DANBoID et sont envoyées à l'application Web centrale pour traitement. En raison du grand nombre de recalculs de métriques, la charge sur l'application est importante.
Il s'est également avéré assez difficile de surveiller l'état des tâches individuelles de collecte de données et de signaler les erreurs se produisant dans les connecteurs vers une application Web centrale afin que les utilisateurs puissent voir ce qui se passait et pourquoi les données n'étaient pas collectées.
Pour résoudre ces problèmes, nous avons développé l'architecture 2.0.
La principale différence entre la nouvelle version de l'architecture est qu'au lieu de l'API Web, nous utilisons RabbitMQ et la bibliothèque MassTransit pour échanger des messages entre services. Pour ce faire, nous avons dû réécrire presque complètement Connectors Proxy, pour en faire Connectors Hub. Le nom a été modifié car le rôle principal du service n'est plus de transmettre les requêtes aux connecteurs et inversement, mais de gérer la collecte de métriques des connecteurs.
À partir de l'application Web centrale, nous avons séparé les informations sur les placements et les statistiques des sites en services distincts, ce qui a permis d'éliminer les recalculs inutiles et de stocker uniquement les statistiques déjà calculées et agrégées au niveau du placement. Nous avons également réécrit et optimisé la logique de calcul des statistiques de base basées sur des données brutes.
Dans le même temps, nous migrons tous les services et applications vers Docker et Kubernetes pour rendre la solution plus facile à faire évoluer et plus pratique à gérer.
Où sommes-nous actuellement
Produit d'architecture 2.0 de preuve de concept D1.Numérique prêt et fonctionnant dans un environnement de test avec un ensemble limité de connecteurs. Il ne reste plus qu'à réécrire 20 connecteurs supplémentaires sur une nouvelle plate-forme, à tester que les données sont correctement chargées et que toutes les métriques sont calculées correctement, et à déployer l'intégralité de la conception en production.
En fait, ce processus se fera progressivement et nous devrons abandonner la rétrocompatibilité avec les anciennes API pour que tout continue de fonctionner.
Nos plans immédiats incluent le développement de nouveaux connecteurs, l'intégration avec de nouveaux systèmes et l'ajout de mesures supplémentaires à l'ensemble des données téléchargées à partir des sites connectés et des systèmes de diffusion de publicité.
Nous prévoyons également de transférer toutes les applications, y compris l'application web centrale, vers Docker et Kubernetes. Combiné à la nouvelle architecture, cela simplifiera considérablement le déploiement, la surveillance et le contrôle des ressources consommées.
Une autre idée est d'expérimenter le choix de la base de données pour stocker les statistiques, actuellement stockée dans MongoDB. Nous avons déjà transféré plusieurs nouveaux connecteurs vers les bases de données SQL, mais là la différence est presque imperceptible, et pour les statistiques agrégées par jour, qui peuvent être demandées pour une période arbitraire, le gain peut être assez sérieux.
En général, les projets sont grandioses, passons à autre chose :)
Auteurs de l'article R&D Dentsu Aegis Network Russie : Georgy Ostapenko (), Mikhaïl Kotsik ()
Source: habr.com