Zdá sa, že oblasť online reklamy by mala byť technologicky čo najvyspelejšia a automatizovaná. Samozrejme, pretože tam pracujú takí giganti a odborníci vo svojom odbore ako Yandex, Mail.Ru, Google a Facebook. Ako sa však ukázalo, dokonalosť nemá hranice a vždy je čo automatizovať.
Komunikačná skupina Dentsu Aegis Network Rusko je najväčším hráčom na trhu digitálnej reklamy a aktívne investuje do technológií a snaží sa optimalizovať a automatizovať svoje obchodné procesy. Jedným z nevyriešených problémov online reklamného trhu je úloha zbierať štatistiky o reklamných kampaniach z rôznych internetových platforiem. Riešenie tohto problému nakoniec vyústilo do vytvorenia produktu D1.Digitálne (čítaj ako DiVan), o vývoji ktorého chceme hovoriť.
Prečo?
1. V čase spustenia projektu nebol na trhu ani jeden hotový produkt, ktorý by riešil problém automatizácie zberu štatistík reklamných kampaní. To znamená, že nikto okrem nás samotných nebude napĺňať naše potreby.
Služby ako Improvado, Roistat, Supermetrics, SegmentStream ponúkajú integráciu s platformami, sociálnymi sieťami a Google Analitycs a tiež umožňujú zostaviť analytické dashboardy pre pohodlnú analýzu a kontrolu reklamných kampaní. Predtým, ako sme začali vyvíjať náš produkt, sme sa pokúsili použiť niektoré z týchto systémov na zber údajov zo stránok, ale, žiaľ, nedokázali vyriešiť naše problémy.
Hlavným problémom bolo, že testované produkty sa spoliehali na zdroje údajov, zobrazovali štatistiky umiestnení podľa stránok a neposkytovali možnosť agregovať štatistiky o reklamných kampaniach. Tento prístup nám neumožnil vidieť štatistiky z rôznych stránok na jednom mieste a analyzovať stav kampane ako celku.
Ďalším faktorom bolo, že v počiatočných fázach boli produkty zamerané na západný trh a nepodporovali integráciu s ruskými stránkami. A v prípade stránok, s ktorými bola implementovaná integrácia, neboli všetky potrebné metriky vždy stiahnuté dostatočne podrobne a integrácia nebola vždy pohodlná a transparentná, najmä keď bolo potrebné získať niečo, čo nie je v rozhraní systému.
Vo všeobecnosti sme sa rozhodli neprispôsobovať sa produktom tretích strán, ale začali sme vyvíjať vlastné...
2. Trh s online reklamou z roka na rok rastie a v roku 2018 v reklamných rozpočtoch predbehol tradične najväčší trh s TV reklamou. Existuje teda mierka.
3. Na rozdiel od trhu s TV reklamou, kde je predaj komerčnej reklamy monopolizovaný, na internete pôsobí množstvo individuálnych vlastníkov reklamného inventára rôznych veľkostí s vlastnými reklamnými účtami. Keďže reklamná kampaň spravidla beží na niekoľkých stránkach naraz, na pochopenie stavu reklamnej kampane je potrebné zhromaždiť správy zo všetkých stránok a spojiť ich do jednej veľkej správy, ktorá ukáže celý obraz. To znamená, že existuje potenciál na optimalizáciu.
4. Zdalo sa nám, že vlastníci reklamného inventára na internete už majú infraštruktúru na zbieranie štatistík a ich zobrazovanie na reklamných účtoch a budú vedieť poskytnúť API pre tieto dáta. To znamená, že je to technicky možné realizovať. Povedzme hneď, že sa ukázalo, že to nie je také jednoduché.
Vo všeobecnosti boli pre nás zrejmé všetky predpoklady na realizáciu projektu a bežali sme projekt uviesť do života...
Veľký plán
Na začiatok sme si vytvorili víziu ideálneho systému:
- Reklamné kampane z podnikového systému 1C by sa do neho mali automaticky načítať s ich názvami, obdobiami, rozpočtami a umiestnením na rôznych platformách.
- Pre každé umiestnenie v rámci reklamnej kampane by sa zo stránok, na ktorých sa umiestnenie uskutočňuje, mali automaticky stiahnuť všetky možné štatistiky, ako napríklad počet zobrazení, kliknutí, zobrazení atď.
- Niektoré reklamné kampane sú sledované pomocou monitorovania tretích strán pomocou takzvaných reklamných systémov, ako sú Adriver, Weborama, DCM atď. V Rusku existuje aj priemyselný internetový merač - spoločnosť Mediascope. Podľa nášho plánu by sa do príslušných reklamných kampaní mali automaticky načítať aj údaje z nezávislého a priemyselného monitoringu.
- Väčšina reklamných kampaní na internete je zameraná na určité cieľové akcie (nákup, telefonát, prihlásenie sa na testovaciu jazdu a pod.), ktoré sú sledované pomocou Google Analytics a štatistiky, pre ktoré sú dôležité aj pre pochopenie stavu kampane a by mal byť načítaný do nášho nástroja .
Prvá palacinka je hrubá
Vzhľadom na náš záväzok k flexibilným princípom vývoja softvéru (agilný, všetky veci) sme sa rozhodli najskôr vyvinúť MVP a potom sa iteračne posunúť k zamýšľanému cieľu.
Rozhodli sme sa vybudovať MVP na základe nášho produktu DANBo (Dentsu Aegis Network Board), čo je webová aplikácia so všeobecnými informáciami o reklamných kampaniach našich klientov.
Pre MVP bol projekt realizačne maximálne zjednodušený. Vybrali sme obmedzený zoznam platforiem na integráciu. Boli to hlavné platformy ako Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB a hlavné reklamné systémy Adriver a Weborama.
Na prístup k štatistikám na stránkach cez API sme použili jeden účet. Správca skupiny klientov, ktorý chcel použiť automatický zber štatistík o reklamnej kampani, musel najprv delegovať prístup k potrebným reklamným kampaniam na stránkach na účet platformy.
Ďalej je používateľ systému DANBo musel do systému Excel nahrať súbor určitého formátu, ktorý obsahoval všetky informácie o umiestnení (reklamná kampaň, platforma, formát, obdobie umiestnenia, plánované ukazovatele, rozpočet a pod.) a identifikátory zodpovedajúcich reklamných kampaní na stránky a počítadlá v reklamných systémoch.
Úprimne povedané, vyzeralo to hrozne:
Stiahnuté údaje sa uložili do databázy a potom z nich samostatné služby zbierali identifikátory kampaní na stránkach a sťahovali o nich štatistiky.
Pre každú stránku bola napísaná samostatná služba Windows, ktorá raz denne prechádzala pod jeden účet služby v rozhraní API stránky a sťahovala štatistiky pre zadané ID kampaní. To isté sa stalo s reklamnými systémami.
Stiahnuté údaje boli zobrazené na rozhraní vo forme malého vlastného dashboardu:
Pre nás nečakane začal fungovať MVP a začal sťahovať aktuálne štatistiky reklamných kampaní na internete. Systém sme implementovali na niekoľkých klientoch, no pri pokuse o škálovanie sme narazili na vážne problémy:
- Hlavným problémom bola náročnosť prípravy dát na načítanie do systému. Údaje o umiestnení sa tiež museli pred načítaním previesť do prísne pevného formátu. Do súboru na stiahnutie bolo potrebné zahrnúť identifikátory entít z rôznych stránok. Stretávame sa s tým, že pre technicky netrénovaných používateľov je veľmi ťažké vysvetliť, kde tieto identifikátory na stránke nájsť a kde v súbore ich treba zadať. Vzhľadom na počet zamestnancov na oddeleniach, ktoré spravujú kampane na stránkach a obrat, to malo za následok obrovskú podporu z našej strany, s ktorou sme neboli absolútne spokojní.
- Ďalším problémom bolo, že nie všetky reklamné platformy mali mechanizmy na delegovanie prístupu k reklamným kampaniam na iné účty. Ale aj keby bol k dispozícii mechanizmus delegovania, nie všetci inzerenti boli ochotní poskytnúť prístup k svojim kampaniam účtom tretích strán.
- Dôležitým faktorom bolo rozhorčenie, ktoré medzi používateľmi vzbudila skutočnosť, že všetky plánované ukazovatele a podrobnosti o umiestnení, ktoré už zadávajú do nášho účtovného systému 1C, musia znova zadať DANBo.
To nám vnuklo myšlienku, že primárnym zdrojom informácií o umiestnení by mal byť náš systém 1C, do ktorého sa všetky údaje zadávajú presne a včas (tu ide o to, že faktúry sa generujú na základe údajov 1C, takže správne zadávanie údajov do 1C je prioritou pre každého KPI). Takto vznikol nový koncept systému...
Pojem
Prvá vec, ktorú sme sa rozhodli urobiť, bolo oddelenie systému zberu štatistík o reklamných kampaniach na internete do samostatného produktu - D1.Digitálne.
V novom koncepte sme sa rozhodli naložiť do D1.Digitálne informácie o reklamných kampaniach a umiestneniach v nich od spoločnosti 1C, a potom získať štatistiky zo stránok a systémov AdServing na tieto umiestnenia. To malo výrazne zjednodušiť život používateľom (a, ako inak, pridať viac práce vývojárom) a znížiť množstvo podpory.
Prvý problém, na ktorý sme narazili, bol organizačného charakteru a súvisel s tým, že sme nevedeli nájsť kľúč alebo znak, pomocou ktorého by sme mohli porovnávať entity z rôznych systémov s kampaňami a umiestneniami od 1C. Faktom je, že proces v našej spoločnosti je navrhnutý tak, že reklamné kampane zadávajú do rôznych systémov rôzni ľudia (mediálni plánovači, nákup atď.).
Aby sme tento problém vyriešili, museli sme vynájsť jedinečný hash kľúč DANBoID, ktorý by spájal entity v rôznych systémoch dohromady a ktorý by sa dal pomerne jednoducho a jednoznačne identifikovať v stiahnutých súboroch údajov. Tento identifikátor sa generuje v internom systéme 1C pre každé jednotlivé umiestnenie a prenáša sa do kampaní, umiestnení a počítadiel na všetkých stránkach a vo všetkých systémoch AdServing. Implementácia nácviku uvádzania DANBoID na všetky umiestnenia trvala nejaký čas, ale podarilo sa nám to :)
Potom sme zistili, že nie všetky stránky majú API na automatický zber štatistík a dokonca ani tie, ktoré API majú, nevracia všetky potrebné údaje.
V tejto fáze sme sa rozhodli výrazne zredukovať zoznam platforiem pre integráciu a zamerať sa na hlavné platformy, ktoré sa podieľajú na drvivej väčšine reklamných kampaní. Tento zoznam zahŕňa všetkých najväčších hráčov na reklamnom trhu (Google, Yandex, Mail.ru), sociálne siete (VK, Facebook, Twitter), hlavné AdServing a analytické systémy (DCM, Adriver, Weborama, Google Analytics) a ďalšie platformy.
Väčšina stránok, ktoré sme vybrali, mala rozhranie API, ktoré poskytovalo metriky, ktoré sme potrebovali. V prípadoch, keď API neexistovalo alebo neobsahovalo potrebné dáta, sme na načítanie dát využívali reporty, ktoré nám boli denne zasielané na náš kancelársky email (v niektorých systémoch je možné takéto reporty nakonfigurovať, v iných sme sa dohodli na vývoji takéto správy pre nás).
Pri analýze dát z rôznych stránok sme zistili, že hierarchia entít nie je v rôznych systémoch rovnaká. Okrem toho je potrebné sťahovať informácie z rôznych systémov v rôznych detailoch.
Na vyriešenie tohto problému bol vyvinutý koncept SubDANBoID. Myšlienka SubDANBoID je celkom jednoduchá, vygenerovaným DANBoID označíme hlavnú entitu kampane na stránke a všetky vnorené entity nahráme s jedinečnými identifikátormi stránok a vytvoríme SubDANBoID podľa princípu DANBoID + identifikátor prvej úrovne vnorená entita + identifikátor vnorenej entity druhej úrovne +... Tento prístup nám umožnil prepojiť reklamné kampane v rôznych systémoch a stiahnuť si o nich podrobné štatistiky.
Museli sme vyriešiť aj problém prístupu ku kampaniam na rôznych platformách. Ako sme písali vyššie, mechanizmus delegovania prístupu ku kampani na samostatný technický účet nie je vždy použiteľný. Preto sme museli vyvinúť infraštruktúru pre automatickú autorizáciu cez OAuth pomocou tokenov a mechanizmov na aktualizáciu týchto tokenov.
Ďalej v článku sa pokúsime podrobnejšie popísať architektúru riešenia a technické detaily implementácie.
Architektúra riešenia 1.0
Pri spustení implementácie nového produktu sme pochopili, že okamžite potrebujeme zabezpečiť možnosť pripojenia nových stránok, preto sme sa rozhodli ísť cestou architektúry mikroservisov.
Pri návrhu architektúry sme rozdelili konektory na všetky externé systémy – 1C, reklamné platformy a reklamné systémy – do samostatných služieb.
Hlavnou myšlienkou je, že všetky konektory na stránky majú rovnaké API a sú to adaptéry, ktoré privádzajú API stránky do rozhrania, ktoré nám vyhovuje.
V centre nášho produktu je webová aplikácia, čo je monolit, ktorý je navrhnutý tak, aby sa dal jednoducho rozložiť na služby. Táto aplikácia je zodpovedná za spracovanie stiahnutých údajov, porovnávanie štatistík z rôznych systémov a ich prezentovanie používateľom systému.
Na komunikáciu medzi konektormi a webovou aplikáciou sme museli vytvoriť doplnkovú službu, ktorú sme nazvali Connector Proxy. Vykonáva funkcie vyhľadávania služieb a plánovača úloh. Táto služba spúšťa úlohy zhromažďovania údajov pre každý konektor každú noc. Písanie vrstvy služieb bolo jednoduchšie ako pripojenie sprostredkovateľa správ a pre nás bolo dôležité získať výsledok čo najrýchlejšie.
Pre jednoduchosť a rýchlosť vývoja sme sa tiež rozhodli, že všetky služby budú Web API. To umožnilo rýchlo zostaviť proof-of-concept a overiť, či celý návrh funguje.
Samostatnou, pomerne zložitou úlohou bolo nastavenie prístupu na zhromažďovanie údajov z rôznych účtov, ktoré, ako sme sa rozhodli, by mali vykonávať používatelia cez webové rozhranie. Pozostáva z dvoch samostatných krokov: najprv používateľ pridá token na prístup k účtu cez OAuth a potom nakonfiguruje zhromažďovanie údajov pre klienta z konkrétneho účtu. Získanie tokenu cez OAuth je nevyhnutné, pretože ako sme už písali, nie vždy je možné delegovať prístup k požadovanému účtu na stránke.
Aby sme vytvorili univerzálny mechanizmus na výber účtu zo stránok, museli sme do API konektorov pridať metódu, ktorá vracia schému JSON, ktorá je vykreslená do formulára pomocou upraveného komponentu JSONEditor. Používatelia si tak mohli vybrať účty, z ktorých budú sťahovať údaje.
Aby sme vyhoveli limitom žiadostí, ktoré existujú na stránkach, kombinujeme žiadosti o nastavenia v rámci jedného tokenu, ale paralelne môžeme spracovávať rôzne tokeny.
Ako úložisko pre načítané dáta pre webovú aplikáciu aj konektory sme zvolili MongoDB, čo nám umožnilo nerobiť si veľké starosti s dátovou štruktúrou v počiatočných fázach vývoja, kedy sa objektový model aplikácie mení každý druhý deň.
Čoskoro sme zistili, že nie všetky dáta dobre sedia v MongoDB a napríklad denné štatistiky je pohodlnejšie ukladať do relačnej databázy. Preto sme pre konektory, ktorých dátová štruktúra je vhodnejšia pre relačné databázy, začali ako úložisko používať PostgreSQL alebo MS SQL Server.
Zvolená architektúra a technológie nám umožnili pomerne rýchlo postaviť a spustiť produkt D1.Digital. Za dva roky vývoja produktu sme vyvinuli 23 konektorov pre stránky, získali neoceniteľné skúsenosti s prácou s API tretích strán, naučili sme sa vyhýbať nástrahám rôznych stránok, z ktorých každá mala svoje vlastné, prispeli k vývoju API minimálne 3 stránky, automaticky stiahli informácie o takmer 15 000 kampaniach a pre viac ako 80 000 umiestnení, zozbierali množstvo spätnej väzby od používateľov na fungovanie produktu a na základe tejto spätnej väzby sa im podarilo niekoľkokrát zmeniť hlavný proces produktu.
Architektúra riešenia 2.0
Od začiatku vývoja ubehli dva roky D1.Digitálne. Neustále zvyšovanie záťaže systému a vznik stále nových a nových zdrojov dát postupne odhalili problémy v existujúcej architektúre riešení.
Prvý problém súvisí s množstvom dát stiahnutých zo stránok. Stretli sme sa s tým, že zber a aktualizácia všetkých potrebných údajov z najväčších stránok začala zaberať príliš veľa času. Napríklad zber údajov z reklamného systému AdRiver, pomocou ktorého sledujeme štatistiky pre väčšinu umiestnení, trvá približne 12 hodín.
Aby sme tento problém vyriešili, začali sme využívať všetky druhy reportov na sťahovanie dát zo stránok, snažíme sa spoločne so stránkami vyvíjať ich API tak, aby rýchlosť jeho fungovania vyhovovala našim potrebám a čo najviac paralelizovať sťahovanie dát.
Ďalší problém sa týka spracovania stiahnutých dát. Teraz, keď prídu nové štatistiky umiestnení, spustí sa viacstupňový proces prepočítavania metrík, ktorý zahŕňa načítanie nespracovaných údajov, výpočet súhrnných metrík pre každú stránku, vzájomné porovnanie údajov z rôznych zdrojov a výpočet súhrnných metrík pre kampaň. To spôsobuje veľké zaťaženie webovej aplikácie, ktorá vykonáva všetky výpočty. Počas procesu prepočtu aplikácia niekoľkokrát spotrebovala všetku pamäť na serveri, približne 10-15 GB, čo malo najškodlivejší vplyv na prácu používateľov so systémom.
Zistené problémy a ambiciózne plány ďalšieho vývoja produktu nás viedli k potrebe prehodnotiť aplikačnú architektúru.
Začali sme s konektormi.
Všimli sme si, že všetky konektory fungujú podľa rovnakého modelu, a tak sme vytvorili pipeline framework, v ktorom na vytvorenie konektora stačilo naprogramovať logiku krokov, zvyšok bol univerzálny. Ak konektor vyžaduje vylepšenie, okamžite ho prenesieme do nového rámca súčasne s vylepšením konektora.
Zároveň sme začali nasadzovať konektory pre Docker a Kubernetes.
Prechod na Kubernetes sme plánovali pomerne dlho, experimentovali sme s nastaveniami CI/CD, no začali sme sa sťahovať až vtedy, keď jeden konektor kvôli chybe začal zaberať viac ako 20 GB pamäte na serveri, čím prakticky zabíjali ostatné procesy. . Počas vyšetrovania bol konektor presunutý do klastra Kubernetes, kde nakoniec zostal, aj keď bola chyba opravená.
Pomerne rýchlo sme si uvedomili, že Kubernetes je pohodlný a do šiestich mesiacov sme preniesli 7 konektorov a Connectors Proxy, ktoré spotrebúvajú najviac zdrojov, do produkčného klastra.
Po konektoroch sme sa rozhodli zmeniť architektúru zvyšku aplikácie.
Hlavným problémom bolo, že dáta prichádzajú z konektorov na proxy vo veľkých dávkach a potom sa dostanú do DANBoID a sú odoslané do centrálnej webovej aplikácie na spracovanie. Kvôli veľkému počtu prepočtov metrík dochádza k veľkému zaťaženiu aplikácie.
Ukázalo sa tiež, že je dosť ťažké monitorovať stav jednotlivých úloh zberu údajov a hlásiť chyby vyskytujúce sa v konektoroch do centrálnej webovej aplikácie, aby používatelia videli, čo sa deje a prečo sa údaje nezhromažďujú.
Na vyriešenie týchto problémov sme vyvinuli architektúru 2.0.
Hlavný rozdiel medzi novou verziou architektúry je v tom, že namiesto webového API používame na výmenu správ medzi službami RabbitMQ a knižnicu MassTransit. Aby sme to dosiahli, museli sme takmer úplne prepísať Connectors Proxy, čím sme z neho urobili Connectors Hub. Názov bol zmenený, pretože hlavná úloha služby už nespočíva v preposielaní požiadaviek na konektory a späť, ale v správe zberu metrík z konektorov.
Z centrálnej webovej aplikácie sme oddelili informácie o umiestneniach a štatistiky zo stránok do samostatných služieb, čo umožnilo zbaviť sa zbytočných prepočtov a ukladať len už vypočítané a agregované štatistiky na úrovni umiestnenia. Tiež sme prepísali a optimalizovali logiku výpočtu základných štatistík na základe nespracovaných údajov.
Zároveň migrujeme všetky služby a aplikácie na Docker a Kubernetes, aby bolo riešenie jednoduchšie škálovateľné a pohodlnejšie na správu.
Kde sme teraz
Produkt pre overenie koncepcie architektúry 2.0 D1.Digitálne pripravené a fungujúce v testovacom prostredí s obmedzenou sadou konektorov. Zostáva len prepísať ďalších 20 konektorov na novú platformu, otestovať, či sú údaje správne načítané a všetky metriky sú vypočítané správne, a uviesť celý návrh do výroby.
V skutočnosti sa tento proces bude diať postupne a budeme musieť opustiť spätnú kompatibilitu so starými API, aby všetko fungovalo.
Naše bezprostredné plány zahŕňajú vývoj nových konektorov, integráciu s novými systémami a pridanie ďalších metrík k súboru údajov stiahnutých z pripojených stránok a reklamných systémov.
Plánujeme tiež preniesť všetky aplikácie vrátane centrálnej webovej aplikácie na Docker a Kubernetes. V kombinácii s novou architektúrou to výrazne zjednoduší nasadenie, monitorovanie a kontrolu spotrebovaných zdrojov.
Ďalším nápadom je experimentovať s výberom databázy na ukladanie štatistík, ktorá je momentálne uložená v MongoDB. Do SQL databáz sme už preniesli niekoľko nových konektorov, ale tam je rozdiel takmer nebadateľný a pri agregovaných štatistikách za deň, ktoré je možné požadovať na ľubovoľné obdobie, môže byť zisk dosť vážny.
Vo všeobecnosti sú plány veľkolepé, poďme ďalej :)
Autori článku R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Michail Kotsik ()
Zdroj: hab.com