Sembla que l'àmbit de la publicitat en línia hauria d'estar tecnològicament el més avançat i automatitzat possible. Per descomptat, perquè hi treballen gegants i experts en el seu camp com Yandex, Mail.Ru, Google i Facebook. Però, com va resultar, no hi ha límit a la perfecció i sempre hi ha alguna cosa per automatitzar.
Grup de comunicació Xarxa Dentsu Aegis Rússia és el major actor del mercat de publicitat digital i està invertint activament en tecnologia, intentant optimitzar i automatitzar els seus processos de negoci. Un dels problemes no resolts del mercat de la publicitat en línia s'ha convertit en la tasca de recollir estadístiques de campanyes publicitàries de diferents plataformes d'Internet. La solució a aquest problema va donar com a resultat la creació d'un producte D1.Digital (llegit com a DiVan), del desenvolupament del qual volem parlar.
Per què?
1. En el moment de l'inici del projecte, no hi havia al mercat ni un sol producte preparat que solucionés el problema de l'automatització de la recollida d'estadístiques de campanyes publicitàries. Això vol dir que ningú, excepte nosaltres mateixos, satisfarà les nostres necessitats.
Serveis com Improvado, Roistat, Supermetrics, SegmentStream ofereixen integració amb plataformes, xarxes socials i Google Analitycs, i també permeten construir taulers analítics per a l'anàlisi i el control còmodes de les campanyes publicitàries. Abans de començar a desenvolupar el nostre producte, vam intentar utilitzar alguns d'aquests sistemes per recollir dades dels llocs, però, malauradament, no van poder resoldre els nostres problemes.
El problema principal va ser que els productes provats es basaven en fonts de dades, mostrant estadístiques d'ubicació per lloc, i no oferien la capacitat d'agregar estadístiques de campanyes publicitàries. Aquest enfocament no ens va permetre veure les estadístiques de diferents llocs en un sol lloc i analitzar l'estat de la campanya en el seu conjunt.
Un altre factor va ser que en les etapes inicials els productes estaven dirigits al mercat occidental i no admetien la integració amb els llocs russos. I per a aquells llocs amb els quals es va implementar la integració, no sempre es descarregaven totes les mètriques necessàries amb prou detall, i la integració no sempre era còmoda i transparent, sobretot quan calia aconseguir alguna cosa que no es trobava a la interfície del sistema.
En general, vam decidir no adaptar-nos a productes de tercers, sinó que vam començar a desenvolupar els nostres...
2. El mercat de la publicitat online creix any rere any, i el 2018, pel que fa als pressupostos publicitaris, va superar el mercat de publicitat televisiva tradicionalment més gran. Per tant, hi ha una escala.
3. A diferència del mercat de publicitat televisiva, on la venda de publicitat comercial està monopolitzada, hi ha molts propietaris individuals d'inventari de publicitat de diferents mides que operen a Internet amb els seus propis comptes publicitaris. Atès que una campanya publicitària, per regla general, s'executa en diversos llocs alhora, per entendre l'estat de la campanya publicitària, cal recollir informes de tots els llocs i combinar-los en un sol informe gran que mostrarà tota la imatge. Això vol dir que hi ha potencial d'optimització.
4. Ens va semblar que els propietaris d'inventari publicitari a Internet ja disposen de la infraestructura per recopilar estadístiques i mostrar-les en comptes publicitaris, i podran proporcionar una API per a aquestes dades. Això vol dir que tècnicament és possible implementar-lo. Diguem de seguida que va resultar que no era tan senzill.
En general, tots els requisits previs per a la implementació del projecte eren evidents per a nosaltres, i vam córrer per donar vida al projecte...
Gran pla
Per començar, vam formar una visió d'un sistema ideal:
- Les campanyes publicitàries del sistema corporatiu 1C s'hi haurien de carregar automàticament amb els seus noms, períodes, pressupostos i ubicacions en diverses plataformes.
- Per a cada ubicació dins d'una campanya publicitària, totes les estadístiques possibles s'han de baixar automàticament dels llocs on s'està fent la ubicació, com ara el nombre d'impressions, clics, visualitzacions, etc.
- Algunes campanyes publicitàries es fan un seguiment mitjançant la supervisió de tercers mitjançant els anomenats sistemes d'adserving com Adriver, Weborama, DCM, etc. També hi ha un comptador d'Internet industrial a Rússia: l'empresa Mediascope. Segons el nostre pla, les dades del monitoratge independent i industrial també s'han de carregar automàticament a les campanyes publicitàries corresponents.
- La majoria de campanyes publicitàries a Internet estan dirigides a determinades accions objectiu (comprar, trucar, registrar-se per a una prova de conducció, etc.), que es fan un seguiment mitjançant Google Analytics, i les estadístiques de les quals també són importants per entendre l'estat de la campanya i s'hauria de carregar a la nostra eina.
La primera panquequeta és bruta
Tenint en compte el nostre compromís amb els principis flexibles del desenvolupament de programari (àgil, tot), vam decidir primer desenvolupar un MVP i després avançar cap a l'objectiu previst de manera iterativa.
Vam decidir construir MVP basant-nos en el nostre producte DANBo (Dentsu Aegis Network Board), que és una aplicació web amb informació general sobre les campanyes publicitàries dels nostres clients.
Per a MVP, el projecte es va simplificar el màxim possible pel que fa a la implementació. Hem seleccionat una llista limitada de plataformes per a la integració. Aquestes eren les principals plataformes, com ara Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB i els principals sistemes d'adserving Adriver i Weborama.
Per accedir a les estadístiques dels llocs mitjançant l'API, hem utilitzat un únic compte. Un gestor de grup de clients que volia utilitzar la recopilació automàtica d'estadístiques en una campanya publicitària primer havia de delegar l'accés a les campanyes publicitàries necessàries als llocs al compte de la plataforma.
El següent és l'usuari del sistema DANBo havia de pujar al sistema Excel un fitxer d'un determinat format, que contenia tota la informació sobre la col·locació (campanya publicitària, plataforma, format, període de col·locació, indicadors previstos, pressupost, etc.) i els identificadors de les campanyes publicitàries corresponents a la llocs i comptadors en sistemes de publicitat.
Semblava, francament, terrorífic:
Les dades descarregades es van desar en una base de dades i, a continuació, els serveis separats van recopilar els identificadors de la campanya als llocs d'ells i van baixar estadístiques sobre ells.
Per a cada lloc, es va escriure un servei de Windows independent, que una vegada al dia passava a un compte de servei a l'API del lloc i baixava les estadístiques dels identificadors de campanya especificats. El mateix va passar amb els sistemes de publicitat.
Les dades descarregades es mostraven a la interfície en forma d'un petit tauler personalitzat:
De manera inesperada per a nosaltres, MVP va començar a treballar i va començar a descarregar les estadístiques actuals de les campanyes publicitàries a Internet. Vam implementar el sistema en diversos clients, però quan vam intentar escalar, vam trobar problemes greus:
- El principal problema era la complexitat de preparar les dades per carregar-les al sistema. A més, les dades d'ubicació s'havien de convertir a un format estrictament fix abans de carregar. Va ser necessari incloure identificadors d'entitats de diferents llocs al fitxer de descàrrega. Ens trobem davant del fet que als usuaris sense formació tècnica és molt difícil explicar on trobar aquests identificadors al lloc i on del fitxer cal introduir-los. Tenint en compte el nombre d'empleats dels departaments que fan campanyes als llocs i la facturació, això va donar lloc a una gran quantitat de suport per part nostra, amb la qual no estàvem absolutament satisfets.
- Un altre problema va ser que no totes les plataformes publicitàries disposaven de mecanismes per delegar l'accés a les campanyes publicitàries a altres comptes. Però encara que hi hagués un mecanisme de delegació disponible, no tots els anunciants estaven disposats a concedir accés a les seves campanyes a comptes de tercers.
- Un factor important va ser la indignació que va despertar entre els usuaris pel fet que tots els indicadors previstos i detalls de col·locació que ja introdueixen al nostre sistema de comptabilitat 1C, han de tornar a entrar en DANBo.
Això ens va donar la idea que la font principal d'informació sobre la col·locació hauria de ser el nostre sistema 1C, en el qual s'introdueixen totes les dades amb precisió i a temps (el punt aquí és que les factures es generen a partir de les dades 1C, de manera que l'entrada correcta de les dades a 1C). és una prioritat per a tothom KPI). Així va sorgir un nou concepte del sistema...
Concepte
El primer que vam decidir fer va ser separar el sistema de recollida d'estadístiques sobre campanyes publicitàries a Internet en un producte separat: D1.Digital.
En el nou concepte, vam decidir carregar-nos D1.Digital informació sobre campanyes publicitàries i ubicacions dins d'elles des d'1C i, a continuació, obteniu estadístiques dels llocs i dels sistemes de publicació d'anuncis a aquestes ubicacions. Això havia de simplificar significativament la vida dels usuaris (i, com és habitual, afegir més feina als desenvolupadors) i reduir la quantitat de suport.
El primer problema que vam trobar va ser de caràcter organitzatiu i va estar relacionat amb el fet que no vam trobar una clau o un rètol pel qual podríem comparar entitats de diferents sistemes amb campanyes i ubicacions d'1C. El cas és que el procés a la nostra empresa està dissenyat de manera que les campanyes publicitàries siguin introduïdes en diferents sistemes per diferents persones (media planners, compres, etc.).
Per resoldre aquest problema, vam haver d'inventar una clau hash única, DANBoID, que enllaçaria entitats de diferents sistemes entre si, i que es pogués identificar de manera bastant fàcil i única als conjunts de dades descarregats. Aquest identificador es genera al sistema 1C intern per a cada ubicació individual i es transfereix a campanyes, ubicacions i comptadors de tots els llocs i en tots els sistemes de publicació d'anuncis. La implementació de la pràctica de posar DANBoID a totes les ubicacions va trigar un temps, però ho vam aconseguir :)
Aleshores vam descobrir que no tots els llocs tenen una API per recopilar estadístiques automàticament, i fins i tot aquells que en tenen una, no retorna totes les dades necessàries.
En aquesta fase, hem decidit reduir significativament la llista de plataformes per a la integració i centrar-nos en les principals plataformes que intervenen en la gran majoria de campanyes publicitàries. Aquesta llista inclou tots els principals actors del mercat publicitari (Google, Yandex, Mail.ru), xarxes socials (VK, Facebook, Twitter), principals sistemes d'anàlisi i AdServing (DCM, Adriver, Weborama, Google Analytics) i altres plataformes.
La majoria dels llocs que vam seleccionar tenien una API que proporcionava les mètriques que necessitàvem. En els casos en què no hi havia API o no contenia les dades necessàries, vam utilitzar informes que s'enviaven diàriament al correu electrònic de la nostra oficina per carregar dades (en alguns sistemes és possible configurar aquests informes, en d'altres vam acordar el desenvolupament de aquests informes per a nosaltres).
Quan vam analitzar dades de diferents llocs, vam descobrir que la jerarquia d'entitats no és la mateixa en diferents sistemes. A més, la informació s'ha de descarregar amb diferents detalls de diferents sistemes.
Per resoldre aquest problema, es va desenvolupar el concepte SubDANBoID. La idea de SubDANBoID és bastant simple, marquem l'entitat principal de la campanya al lloc amb el DANBoID generat, i pengem totes les entitats imbricades amb identificadors de lloc únics i formem SubDANBoID segons el principi DANBoID + identificador del primer nivell. entitat imbricada + identificador de l'entitat imbricada de segon nivell +... Aquest enfocament ens va permetre connectar campanyes publicitàries en diferents sistemes i descarregar-ne estadístiques detallades.
També hem hagut de resoldre el problema d'accés a campanyes en diferents plataformes. Com hem escrit més amunt, el mecanisme de delegació de l'accés a una campanya a un compte tècnic independent no sempre és aplicable. Per tant, vam haver de desenvolupar una infraestructura per a l'autorització automàtica mitjançant OAuth utilitzant fitxes i mecanismes per actualitzar-los.
Més endavant en l'article intentarem descriure amb més detall l'arquitectura de la solució i els detalls tècnics de la implementació.
Arquitectura de la solució 1.0
En començar la implementació d'un nou producte, vam entendre que calia preveure immediatament la possibilitat de connectar nous llocs, així que vam decidir seguir el camí de l'arquitectura de microserveis.
Quan vam dissenyar l'arquitectura, vam separar els connectors a tots els sistemes externs (1C, plataformes publicitàries i sistemes de publicitat) en serveis separats.
La idea principal és que tots els connectors dels llocs tinguin la mateixa API i siguin adaptadors que porten l'API del lloc a una interfície que ens convé.
Al centre del nostre producte hi ha una aplicació web, que és un monòlit dissenyat de manera que es pot desmuntar fàcilment en serveis. Aquesta aplicació s'encarrega de processar les dades descarregades, recopilar estadístiques de diferents sistemes i presentar-les als usuaris del sistema.
Per comunicar-nos entre els connectors i l'aplicació web, hem hagut de crear un servei addicional, que hem anomenat Connector Proxy. Realitza les funcions de descoberta de serveis i programador de tasques. Aquest servei executa tasques de recollida de dades per a cada connector cada nit. Escriure una capa de servei era més fàcil que connectar un agent de missatges, i per a nosaltres era important obtenir el resultat el més aviat possible.
Per simplicitat i velocitat de desenvolupament, també vam decidir que tots els serveis seran API web. Això va permetre muntar ràpidament una prova de concepte i verificar que tot el disseny funciona.
Una tasca separada, força complexa, va ser configurar l'accés per recollir dades de diferents comptes, que, com vam decidir, haurien de ser realitzades pels usuaris a través de la interfície web. Consisteix en dos passos diferents: primer, l'usuari afegeix un testimoni per accedir al compte mitjançant OAuth i, a continuació, configura la recollida de dades per al client des d'un compte específic. L'obtenció d'un testimoni mitjançant OAuth és necessari perquè, com ja hem escrit, no sempre és possible delegar l'accés al compte desitjat al lloc.
Per crear un mecanisme universal per seleccionar un compte dels llocs, hem hagut d'afegir un mètode a l'API de connectors que retorna l'esquema JSON, que es representa en un formulari mitjançant un component JSONEditor modificat. D'aquesta manera, els usuaris van poder seleccionar els comptes dels quals baixar les dades.
Per complir amb els límits de sol·licituds existents als llocs, combinem les sol·licituds de configuració dins d'un sol testimoni, però podem processar diferents testimonis en paral·lel.
Hem escollit MongoDB com a emmagatzematge de dades carregades tant per a l'aplicació web com per als connectors, la qual cosa ens va permetre no preocupar-nos massa per l'estructura de dades en les etapes inicials de desenvolupament, quan el model d'objectes de l'aplicació canvia cada dos dies.
Aviat vam descobrir que no totes les dades encaixen bé a MongoDB i, per exemple, és més convenient emmagatzemar les estadístiques diàries en una base de dades relacional. Per tant, per als connectors l'estructura de dades dels quals és més adequada per a una base de dades relacional, vam començar a utilitzar PostgreSQL o MS SQL Server com a emmagatzematge.
L'arquitectura i les tecnologies escollides ens van permetre construir i llançar el producte D1.Digital amb relativa rapidesa. Durant dos anys de desenvolupament de productes, vam desenvolupar 23 connectors a llocs, vam adquirir una experiència inestimable treballant amb API de tercers, vam aprendre a evitar els inconvenients de diferents llocs, que cadascun tenia el seu, vam contribuir al desenvolupament de l'API d'almenys 3. llocs web, van descarregar automàticament informació sobre gairebé 15 campanyes i durant més de 000 ubicacions, van recollir molts comentaris dels usuaris sobre el funcionament del producte i van aconseguir canviar diverses vegades el procés principal del producte, basant-se en aquest feedback.
Arquitectura de la solució 2.0
Han passat dos anys des de l'inici del desenvolupament D1.Digital. L'augment constant de la càrrega del sistema i l'aparició de fonts de dades cada cop més noves van revelar progressivament problemes en l'arquitectura de solucions existent.
El primer problema està relacionat amb la quantitat de dades baixades dels llocs. Ens vam enfrontar al fet que la recollida i l'actualització de totes les dades necessàries dels llocs més grans va començar a prendre massa temps. Per exemple, la recollida de dades del sistema d'anuncis AdRiver, amb el qual fem un seguiment de les estadístiques de la majoria de les ubicacions, triga unes 12 hores.
Per solucionar aquest problema, vam començar a utilitzar tota mena d'informes per descarregar dades dels llocs, estem intentant desenvolupar la seva API juntament amb els llocs perquè la velocitat del seu funcionament s'ajusti a les nostres necessitats, i paral·lelitzem al màxim la descàrrega de dades.
Un altre problema es relaciona amb el processament de les dades descarregades. Ara, quan arriben noves estadístiques d'ubicació, s'inicia un procés de recàlcul de mètriques en diverses etapes, que inclou la càrrega de dades en brut, el càlcul de mètriques agregades per a cada lloc, la comparació de dades de diferents fonts entre si i el càlcul de mètriques de resum per a la campanya. Això provoca molta càrrega a l'aplicació web que fa tots els càlculs. Diverses vegades, durant el procés de recàlcul, l'aplicació va consumir tota la memòria del servidor, uns 10-15 GB, la qual cosa va tenir l'efecte més perjudicial en el treball dels usuaris amb el sistema.
Els problemes identificats i els ambiciosos plans per al desenvolupament posterior del producte ens van portar a la necessitat de reconsiderar l'arquitectura de l'aplicació.
Vam començar amb connectors.
Ens vam adonar que tots els connectors funcionen segons el mateix model, així que vam construir un framework pipeline en el qual per crear un connector només calia programar la lògica dels passos, la resta era universal. Si algun connector requereix una millora, el transferim immediatament a un marc nou al mateix temps que es millora el connector.
Al mateix temps, vam començar a desplegar connectors a Docker i Kubernetes.
Vam planificar el trasllat a Kubernetes durant força temps, vam experimentar amb la configuració de CI/CD, però vam començar a moure's només quan un connector, a causa d'un error, va començar a consumir més de 20 GB de memòria al servidor, pràcticament matant altres processos. . Durant la investigació, el connector es va traslladar a un clúster de Kubernetes, on finalment va romandre, fins i tot després de corregir l'error.
Molt ràpidament ens vam adonar que Kubernetes era convenient i en sis mesos vam transferir 7 connectors i Connectors Proxy, que consumeixen més recursos, al clúster de producció.
Seguint els connectors, vam decidir canviar l'arquitectura de la resta de l'aplicació.
El problema principal era que les dades provenen dels connectors als servidors intermediaris en grans lots, i després arriben al DANBoID i s'envien a l'aplicació web central per processar-les. A causa del gran nombre de càlculs de mètriques, hi ha una gran càrrega a l'aplicació.
També va resultar bastant difícil supervisar l'estat dels treballs de recollida de dades individuals i informar d'errors que es produïen dins dels connectors a una aplicació web central perquè els usuaris poguessin veure què passava i per què no s'estaven recopilant dades.
Per resoldre aquests problemes, hem desenvolupat l'arquitectura 2.0.
La principal diferència entre la nova versió de l'arquitectura és que en comptes de l'API web, utilitzem RabbitMQ i la biblioteca MassTransit per intercanviar missatges entre serveis. Per fer-ho, vam haver de reescriure gairebé completament Connectors Proxy, convertint-lo Connectors Hub. El nom es va canviar perquè el paper principal del servei ja no és reenviar sol·licituds als connectors i tornar, sinó gestionar la col·lecció de mètriques dels connectors.
Des de l'aplicació web central, vam separar la informació sobre les ubicacions i les estadístiques dels llocs en serveis separats, cosa que va permetre desfer-se de recàlculs innecessaris i emmagatzemar només estadístiques ja calculades i agregades a nivell d'ubicació. També vam reescriure i optimitzar la lògica per calcular les estadístiques bàsiques a partir de dades en brut.
Al mateix temps, estem migrant tots els serveis i aplicacions a Docker i Kubernetes per fer que la solució sigui més fàcil d'escalar i més còmoda de gestionar.
On som ara
Producte d'arquitectura de prova de concepte 2.0 D1.Digital llest i treballant en un entorn de prova amb un conjunt limitat de connectors. Tot el que queda per fer és reescriure altres 20 connectors a una nova plataforma, provar que les dades es carreguen correctament i que totes les mètriques es calculin correctament i llançar tot el disseny a producció.
De fet, aquest procés es farà de manera gradual i haurem de deixar la compatibilitat amb les antigues API per mantenir-ho tot funcionant.
Els nostres plans immediats inclouen el desenvolupament de nous connectors, la integració amb nous sistemes i l'addició de mètriques addicionals al conjunt de dades descarregades de llocs connectats i sistemes d'adserving.
També tenim previst transferir totes les aplicacions, inclosa l'aplicació web central, a Docker i Kubernetes. Combinat amb la nova arquitectura, això simplificarà significativament el desplegament, el seguiment i el control dels recursos consumits.
Una altra idea és experimentar amb l'elecció de la base de dades per emmagatzemar les estadístiques, que actualment s'emmagatzema a MongoDB. Ja hem transferit diversos connectors nous a bases de dades SQL, però allà la diferència és gairebé imperceptible, i per a les estadístiques agregades per dia, que es poden sol·licitar durant un període arbitrari, el guany pot ser força greu.
En general, els plans són grandiosos, seguim endavant :)
Autors de l'article R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Font: www.habr.com