Parece que o campo da publicidade en liña debería estar tecnoloxicamente o máis avanzado e automatizado posible. Por suposto, porque alí traballan xigantes e expertos no seu campo como Yandex, Mail.Ru, Google e Facebook. Pero, como se viu, non hai límite para a perfección e sempre hai algo que automatizar.
Grupo de comunicación Dentsu Aegis Network Rusia é o maior actor no mercado da publicidade dixital e está a investir activamente en tecnoloxía, tratando de optimizar e automatizar os seus procesos de negocio. Un dos problemas sen resolver do mercado da publicidade en liña converteuse na tarefa de recoller estatísticas sobre campañas publicitarias de diferentes plataformas de Internet. A solución a este problema resultou finalmente na creación dun produto D1.Dixital (léase como DiVan), cuxo desenvolvemento queremos falar.
Por que?
1. No momento do inicio do proxecto non existía no mercado nin un só produto confeccionado que resolvese o problema da automatización da recollida de estatísticas sobre campañas publicitarias. Isto significa que ninguén, excepto nós mesmos, satisfará as nosas necesidades.
Servizos como Improvado, Roistat, Supermetrics, SegmentStream ofrecen integración con plataformas, redes sociais e Google Analitycs, e tamén permiten construír paneis analíticos para unha cómoda análise e control das campañas publicitarias. Antes de comezar a desenvolver o noso produto, tentamos utilizar algúns destes sistemas para recoller datos dos sitios, pero, por desgraza, non puideron resolver os nosos problemas.
O principal problema foi que os produtos probados baseáronse en fontes de datos, mostrando estatísticas de colocación por sitio e non ofrecían a capacidade de agregar estatísticas sobre campañas publicitarias. Este enfoque non nos permitiu ver estatísticas de diferentes sitios nun só lugar e analizar o estado da campaña no seu conxunto.
Outro factor foi que nas fases iniciais os produtos estaban dirixidos ao mercado occidental e non admitían a integración con sitios rusos. E para aqueles sitios cos que se implementou a integración, todas as métricas necesarias non sempre se descargaron con suficiente detalle e a integración non sempre foi cómoda e transparente, especialmente cando era necesario conseguir algo que non está na interface do sistema.
En xeral, decidimos non adaptarnos a produtos de terceiros, pero comezamos a desenvolver o noso...
2. O mercado de publicidade en liña crece de ano en ano, e en 2018, en canto aos orzamentos publicitarios, superou ao mercado de publicidade televisivo tradicionalmente máis grande. Entón hai unha escala.
3. A diferenza do mercado de publicidade televisiva, onde a venda de publicidade comercial está monopolizada, hai moitos propietarios individuais de inventarios publicitarios de varios tamaños que operan en Internet coas súas propias contas publicitarias. Dado que unha campaña publicitaria, por regra xeral, execútase en varios sitios á vez, para comprender o estado da campaña publicitaria, é necesario recoller informes de todos os sitios e combinalos nun informe grande que mostrará a imaxe completa. Isto significa que hai potencial para a optimización.
4. Pareceunos que os propietarios do inventario publicitario en Internet xa dispoñen da infraestrutura para recoller estatísticas e visualizalas en contas publicitarias, e poderán proporcionar unha API para estes datos. Isto significa que técnicamente é posible implementalo. Digamos de inmediato que non resultou tan sinxelo.
En xeral, todos os requisitos previos para a posta en marcha do proxecto eran obvios para nós, e corremos para dar vida ao proxecto...
Gran Plan
Para comezar, formamos unha visión dun sistema ideal:
- As campañas publicitarias do sistema corporativo 1C deben cargarse automaticamente nel cos seus nomes, períodos, orzamentos e colocacións en varias plataformas.
- Para cada colocación dentro dunha campaña publicitaria, todas as estatísticas posibles deberían descargarse automaticamente dos sitios onde se está a realizar a colocación, como o número de impresións, clics, visualizacións, etc.
- Algunhas campañas publicitarias son seguidas mediante o seguimento de terceiros mediante os chamados sistemas de adserving como Adriver, Weborama, DCM, etc. Tamén hai un medidor de Internet industrial en Rusia - a empresa Mediascope. Segundo o noso plan, os datos da vixilancia independente e industrial tamén deberían cargarse automaticamente nas correspondentes campañas publicitarias.
- A maioría das campañas publicitarias en Internet están dirixidas a determinadas accións obxectivo (comprar, chamar, rexistrarse para realizar unha proba de condución, etc.), que se rastrexan mediante Google Analytics, e as estatísticas das que tamén son importantes para comprender o estado da campaña e debería cargarse na nosa ferramenta.
A primeira panqueca é irregular
Dado o noso compromiso cos principios flexibles de desenvolvemento de software (áxil, todas as cousas), decidimos desenvolver primeiro un MVP e despois avanzar cara ao obxectivo previsto de forma iterativa.
Decidimos construír MVP baseándonos no noso produto DANBo (Dentsu Aegis Network Board), que é unha aplicación web con información xeral sobre as campañas publicitarias dos nosos clientes.
Para MVP, o proxecto simplificouse na medida do posible en canto á implantación. Seleccionamos unha lista limitada de plataformas para a integración. Estas foron as principais plataformas, como Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB e os principais sistemas de publicidade Adriver e Weborama.
Para acceder ás estatísticas dos sitios a través da API, utilizamos unha única conta. Un xestor de grupo de clientes que quería utilizar a recollida automática de estatísticas nunha campaña publicitaria tiña que delegar primeiro o acceso ás campañas publicitarias necesarias nos sitios na conta da plataforma.
O seguinte é o usuario do sistema DANBo tivo que subir ao sistema Excel un ficheiro dun determinado formato, que contiña toda a información sobre a colocación (campaña publicitaria, plataforma, formato, período de colocación, indicadores previstos, orzamento, etc.) e os identificadores das correspondentes campañas publicitarias no sitios e contadores en sistemas de adserving.
Parecía, francamente, aterrador:
Os datos descargados gardáronse nunha base de datos e, a continuación, os servizos separados recolleron os identificadores de campaña nos sitios e descargaron estatísticas sobre eles.
Para cada sitio, escribiuse un servizo de Windows separado, que unha vez ao día pasaba a unha conta de servizo na API do sitio e descargaba estatísticas para os ID de campaña especificados. O mesmo ocorreu cos sistemas de adserving.
Os datos descargados mostráronse na interface en forma dun pequeno panel personalizado:
Inesperadamente para nós, MVP comezou a traballar e comezou a descargar estatísticas actuais sobre campañas publicitarias en Internet. Implementamos o sistema en varios clientes, pero ao tentar escalar, atopamos serios problemas:
- O principal problema foi a complexidade de preparar os datos para cargalos no sistema. Ademais, os datos de colocación tiveron que ser convertidos a un formato estritamente fixo antes de cargalos. Era necesario incluír identificadores de entidades de diferentes sitios no ficheiro de descarga. Estamos ante o feito de que é moi difícil para os usuarios tecnicamente sen formación explicar onde atopar estes identificadores no sitio e onde no ficheiro hai que introducirlos. Tendo en conta o número de empregados dos departamentos que realizan campañas nos sitios e a facturación, isto deu lugar a unha enorme cantidade de apoio do noso lado, co que non estabamos absolutamente satisfeitos.
- Outro problema foi que non todas as plataformas publicitarias tiñan mecanismos para delegar o acceso ás campañas publicitarias noutras contas. Pero aínda que estivese dispoñible un mecanismo de delegación, non todos os anunciantes estaban dispostos a conceder acceso ás súas campañas a contas de terceiros.
- Un factor importante foi a indignación que espertou entre os usuarios o feito de que todos os indicadores previstos e detalles de colocación que xa ingresan no noso sistema de contabilidade 1C, deben reingresar DANBo.
Isto deunos a idea de que a fonte principal de información sobre a colocación debería ser o noso sistema 1C, no que se introducen todos os datos con precisión e puntualidade (o punto aquí é que as facturas se xeran en función dos datos 1C, polo que a entrada correcta de datos en 1C). é unha prioridade para todos os KPI). Así xurdiu un novo concepto do sistema...
Concepto
O primeiro que decidimos facer foi separar o sistema de recollida de estatísticas sobre campañas publicitarias en Internet nun produto separado: D1.Dixital.
No novo concepto, decidimos cargar D1.Dixital información sobre campañas publicitarias e colocacións dentro delas desde 1C e, a continuación, extrae estatísticas dos sitios e dos sistemas AdServing a estas colocacións. Suponse que isto simplificaría significativamente a vida dos usuarios (e, como é habitual, engadiría máis traballo aos desenvolvedores) e reduciría a cantidade de soporte.
O primeiro problema que atopamos foi de carácter organizativo e estivo relacionado con que non atopamos unha chave ou sinal polo que poder comparar entidades de distintos sistemas con campañas e colocacións de 1C. O caso é que o proceso na nosa empresa está deseñado de forma que as campañas publicitarias sexan introducidas en diferentes sistemas por diferentes persoas (media planners, compras, etc.).
Para resolver este problema, tivemos que inventar unha clave hash única, DANBoID, que vincularía entidades de diferentes sistemas entre si, e que podería identificarse de forma bastante sinxela e única nos conxuntos de datos descargados. Este identificador xérase no sistema 1C interno para cada colocación individual e transfírese a campañas, localizacións e contadores en todos os sitios e en todos os sistemas AdServing. Implementar a práctica de poñer DANBoID en todas as prácticas levou algún tempo, pero conseguimos facelo :)
Despois decatámonos de que non todos os sitios teñen unha API para recoller estatísticas de forma automática, e mesmo aqueles que si teñen unha API, non devolve todos os datos necesarios.
Nesta fase, decidimos reducir significativamente a lista de plataformas para a integración e centrarnos nas principais plataformas que interveñen na gran maioría das campañas publicitarias. Esta lista inclúe todos os maiores xogadores do mercado publicitario (Google, Yandex, Mail.ru), redes sociais (VK, Facebook, Twitter), principais sistemas de análise e AdServing (DCM, Adriver, Weborama, Google Analytics) e outras plataformas.
A maioría dos sitios que seleccionamos tiñan unha API que proporcionaba as métricas que necesitabamos. Nos casos en que non existía API ou non contiña os datos necesarios, utilizabamos informes enviados diariamente ao correo electrónico da nosa oficina para cargar datos (nalgúns sistemas é posible configurar este tipo de informes, noutros acordamos o desenvolvemento deste tipo de informes). para nós).
Ao analizar os datos de diferentes sitios, descubrimos que a xerarquía de entidades non é a mesma nos distintos sistemas. Ademais, a información debe descargarse con diferentes detalles de diferentes sistemas.
Para resolver este problema, desenvolveuse o concepto SubDANBoID. A idea de SubDANBoID é bastante sinxela, marcamos a entidade principal da campaña no sitio co DANBoID xerado e cargamos todas as entidades aniñadas con identificadores únicos do sitio e formamos SubDANBoID segundo o principio DANBoID + identificador do primeiro nivel. entidade aniñada + identificador da entidade aniñada de segundo nivel +... Este enfoque permitiunos conectar campañas publicitarias en diferentes sistemas e descargar estatísticas detalladas sobre elas.
Tamén tivemos que solucionar o problema do acceso ás campañas en diferentes plataformas. Como escribimos anteriormente, o mecanismo de delegar o acceso a unha campaña nunha conta técnica separada non sempre é aplicable. Polo tanto, tivemos que desenvolver unha infraestrutura para a autorización automática a través de OAuth utilizando tokens e mecanismos para actualizar estes tokens.
Máis adiante no artigo trataremos de describir con máis detalle a arquitectura da solución e os detalles técnicos da implementación.
Arquitectura de solución 1.0
Ao comezar a implantación dun novo produto, entendemos que de inmediato necesitabamos prever a posibilidade de conectar novos sitios, polo que decidimos seguir o camiño da arquitectura de microservizos.
Ao deseñar a arquitectura, separamos os conectores de todos os sistemas externos (1C, plataformas de publicidade e sistemas de publicidade) en servizos separados.
A idea principal é que todos os conectores dos sitios teñan a mesma API e sexan adaptadores que traen a API do sitio a unha interface conveniente para nós.
No centro do noso produto atópase unha aplicación web, que é un monólito que está deseñado de forma que se pode desmontar facilmente en servizos. Esta aplicación encárgase de procesar os datos descargados, recompilar estatísticas de diferentes sistemas e presentalas aos usuarios do sistema.
Para comunicarnos entre os conectores e a aplicación web, tivemos que crear un servizo adicional, que chamamos Connector Proxy. Realiza as funcións de Service Discovery e Task Scheduler. Este servizo executa tarefas de recollida de datos para cada conector todas as noites. Escribir unha capa de servizo foi máis fácil que conectar un corredor de mensaxes, e para nós era importante obter o resultado o máis rápido posible.
Por simplicidade e velocidade de desenvolvemento, tamén decidimos que todos os servizos serán API web. Isto permitiu montar rapidamente unha proba de concepto e verificar que todo o deseño funciona.
Unha tarefa separada, bastante complexa, foi configurar o acceso para recoller datos de diferentes contas, que, como decidimos, deberían ser realizados polos usuarios a través da interface web. Consiste en dous pasos distintos: primeiro, o usuario engade un token para acceder á conta a través de OAuth e, a continuación, configura a recollida de datos para o cliente desde unha conta específica. A obtención dun token a través de OAuth é necesaria porque, como xa escribimos, non sempre é posible delegar o acceso á conta desexada no sitio.
Para crear un mecanismo universal para seleccionar unha conta dos sitios, tivemos que engadir un método á API de conectores que devolve o esquema JSON, que se representa nun formulario mediante un compoñente JSONEditor modificado. Deste xeito, os usuarios puideron seleccionar as contas das que descargar datos.
Para cumprir cos límites de solicitudes que existen nos sitios, combinamos as solicitudes de configuración nun token, pero podemos procesar diferentes tokens en paralelo.
Escollemos MongoDB como almacenamento para os datos cargados tanto para a aplicación web como para os conectores, o que nos permitiu non preocuparnos demasiado pola estrutura dos datos nas fases iniciais do desenvolvemento, cando o modelo de obxecto da aplicación cambia cada dous días.
Pronto descubrimos que non todos os datos encaixan ben en MongoDB e, por exemplo, é máis cómodo gardar estatísticas diarias nunha base de datos relacional. Polo tanto, para os conectores cuxa estrutura de datos é máis adecuada para unha base de datos relacional, comezamos a utilizar PostgreSQL ou MS SQL Server como almacenamento.
A arquitectura e tecnoloxías escollidas permitíronnos construír e lanzar o produto D1.Digital con relativa rapidez. Ao longo de dous anos de desenvolvemento de produtos, desenvolvemos 23 conectores para sitios, adquirimos unha experiencia inestimable traballando con API de terceiros, aprendemos a evitar as trampas de diferentes sitios, que cada un tiña o seu, contribuíron ao desenvolvemento da API de polo menos 3. sitios, descargaron automaticamente información sobre case 15 campañas e durante máis de 000 colocacións, recolleron moitos comentarios dos usuarios sobre o funcionamento do produto e lograron cambiar o proceso principal do produto varias veces, en función deste feedback.
Arquitectura de solución 2.0
Pasaron dous anos desde o inicio do desenvolvemento D1.Dixital. O constante aumento da carga do sistema e a aparición de máis e máis novas fontes de datos revelaron aos poucos problemas na arquitectura de solucións existente.
O primeiro problema está relacionado coa cantidade de datos descargados dos sitios. Enfrontámonos ao feito de que recoller e actualizar todos os datos necesarios dos sitios máis grandes comezou a levar demasiado tempo. Por exemplo, a recollida de datos do sistema de publicidade AdRiver, co que realizamos un seguimento das estatísticas da maioría das colocacións, leva unhas 12 horas.
Para solucionar este problema, comezamos a utilizar todo tipo de informes para descargar datos dos sitios, estamos intentando desenvolver a súa API xunto cos sitios para que a velocidade do seu funcionamento satisfaga as nosas necesidades, e paralelizar o máximo posible a descarga de datos.
Outro problema refírese ao procesamento dos datos descargados. Agora, cando chegan novas estatísticas de colocación, lánzase un proceso de recalculación de métricas en varias etapas, que inclúe a carga de datos brutos, o cálculo de métricas agregadas para cada sitio, a comparación de datos de diferentes fontes entre si e o cálculo de métricas de resumo para a campaña. Isto provoca moita carga na aplicación web que fai todos os cálculos. Varias veces, durante o proceso de recálculo, a aplicación consumiu toda a memoria do servidor, uns 10-15 GB, o que tivo o efecto máis prexudicial para o traballo dos usuarios co sistema.
Os problemas identificados e os ambiciosos plans para un posterior desenvolvemento do produto leváronnos á necesidade de reconsiderar a arquitectura da aplicación.
Comezamos cos conectores.
Observamos que todos os conectores funcionan segundo o mesmo modelo, polo que construímos un marco de pipeline no que para crear un conector só había que programar a lóxica dos pasos, o resto era universal. Se algún conector require melloras, transferímolo inmediatamente a un novo marco ao mesmo tempo que se mellora o conector.
Ao mesmo tempo, comezamos a implementar conectores para Docker e Kubernetes.
Planeamos o traslado a Kubernetes durante bastante tempo, experimentamos con configuracións CI/CD, pero comezamos a movernos só cando un conector, debido a un erro, comezou a consumir máis de 20 GB de memoria no servidor, prácticamente matando outros procesos. . Durante a investigación, o conector trasladouse a un clúster de Kubernetes, onde finalmente permaneceu, mesmo despois de que se corrixise o erro.
Axiña decatámonos de que Kubernetes era conveniente e, nun prazo de seis meses, transferimos ao clúster de produción 7 conectores e Connectors Proxy, que consumen máis recursos.
Seguindo os conectores, decidimos cambiar a arquitectura do resto da aplicación.
O principal problema foi que os datos proceden dos conectores aos proxies en grandes lotes, e despois chegan ao DANBoID e son enviados á aplicación web central para o seu procesamento. Debido ao gran número de recálculos de métricas, hai unha gran carga na aplicación.
Tamén resultou bastante difícil supervisar o estado dos traballos de recollida de datos individuais e informar de erros que se producían nos conectores a unha aplicación web central para que os usuarios puidesen ver o que estaba a suceder e por que non se recompilaban os datos.
Para resolver estes problemas, desenvolvemos a arquitectura 2.0.
A principal diferenza entre a nova versión da arquitectura é que en lugar da API web, usamos RabbitMQ e a biblioteca MassTransit para intercambiar mensaxes entre servizos. Para iso, tivemos que reescribir case completamente Connectors Proxy, converténdoo en Connectors Hub. O nome cambiouse porque o principal papel do servizo xa non consiste en reenviar solicitudes aos conectores e viceversa, senón en xestionar a colección de métricas dos conectores.
Desde a aplicación web central, separamos a información sobre colocacións e estatísticas dos sitios en servizos separados, o que permitiu desfacerse de recálculos innecesarios e almacenar só estatísticas xa calculadas e agregadas a nivel de colocación. Tamén reescribimos e optimizamos a lóxica para calcular estatísticas básicas baseadas en datos brutos.
Ao mesmo tempo, estamos migrando todos os servizos e aplicacións a Docker e Kubernetes para que a solución sexa máis fácil de escalar e máis cómoda de xestionar.
Onde estamos agora
Produto de arquitectura de proba de concepto 2.0 D1.Dixital preparado e traballando nun ambiente de proba cun conxunto limitado de conectores. Todo o que queda por facer é reescribir outros 20 conectores nunha nova plataforma, probar que os datos se cargan correctamente e que todas as métricas se calculan correctamente e lanzar todo o deseño á produción.
De feito, este proceso sucederá gradualmente e teremos que deixar a compatibilidade con versións anteriores coas API antigas para que todo funcione.
Os nosos plans inmediatos inclúen o desenvolvemento de novos conectores, a integración con novos sistemas e a adición de métricas adicionais ao conxunto de datos descargados de sitios conectados e sistemas de adserving.
Tamén pensamos transferir todas as aplicacións, incluída a aplicación web central, a Docker e Kubernetes. Combinado coa nova arquitectura, isto simplificará significativamente o despregamento, seguimento e control dos recursos consumidos.
Outra idea é experimentar coa elección da base de datos para almacenar estatísticas, que actualmente se almacena en MongoDB. Xa transferimos varios conectores novos ás bases de datos SQL, pero alí a diferenza é case imperceptible, e para as estatísticas agregadas por día, que se poden solicitar por un período arbitrario, a ganancia pode ser bastante grave.
En xeral, os plans son grandiosos, sigamos :)
Autores do artigo R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Fonte: www.habr.com