Zdá se, že oblast online reklamy by měla být technologicky co nejpokročilejší a automatizovaná. Samozřejmě, protože tam pracují takoví giganti a odborníci ve svém oboru jako Yandex, Mail.Ru, Google a Facebook. Jak se ale ukázalo, dokonalost nemá meze a vždy je co automatizovat.
Komunikační skupina Dentsu Aegis Network Rusko je největším hráčem na trhu digitální reklamy a aktivně investuje do technologií, snaží se optimalizovat a automatizovat své obchodní procesy. Jedním z neřešených problémů online reklamního trhu se stal úkol shromažďovat statistiky reklamních kampaní z různých internetových platforem. Řešení tohoto problému nakonec vyústilo ve vytvoření produktu D1.Digitální (čteno jako DiVan), o jehož vývoji chceme mluvit.
Proč?
1. V době startu projektu nebyl na trhu jediný hotový produkt, který by řešil problém automatizace sběru statistik reklamních kampaní. To znamená, že nikdo kromě nás samotných neuspokojí naše potřeby.
Služby jako Improvado, Roistat, Supermetrics, SegmentStream nabízejí integraci s platformami, sociálními sítěmi a Google Analitycs a také umožňují vytvářet analytické dashboardy pro pohodlnou analýzu a kontrolu reklamních kampaní. Než jsme začali vyvíjet náš produkt, zkoušeli jsme některé z těchto systémů využít ke sběru dat ze stránek, ale bohužel naše problémy nevyřešily.
Hlavním problémem bylo, že testované produkty vycházely z datových zdrojů, zobrazovaly statistiky umístění podle stránek a neposkytovaly možnost agregovat statistiky reklamních kampaní. Tento přístup nám neumožnil vidět statistiky z různých stránek na jednom místě a analyzovat stav kampaně jako celku.
Dalším faktorem bylo, že v počátečních fázích byly produkty zaměřeny na západní trh a nepodporovaly integraci s ruskými weby. A u stránek, se kterými byla integrace implementována, nebyly všechny potřebné metriky vždy staženy dostatečně podrobně a integrace nebyla vždy pohodlná a transparentní, zvláště když bylo nutné získat něco, co není v systémovém rozhraní.
Obecně jsme se rozhodli nepřizpůsobovat se produktům třetích stran, ale začali jsme vyvíjet vlastní...
2. Trh s online reklamou rok od roku roste a v roce 2018 předběhl z hlediska reklamních rozpočtů tradičně největší trh TV reklamy. Existuje tedy měřítko.
3. Na rozdíl od trhu TV reklamy, kde je prodej komerční reklamy monopolizován, na internetu působí mnoho individuálních vlastníků reklamního inventáře různé velikosti s vlastními reklamními účty. Vzhledem k tomu, že reklamní kampaň zpravidla běží na několika stránkách najednou, je pro pochopení stavu reklamní kampaně nutné shromáždit zprávy ze všech stránek a spojit je do jedné velké zprávy, která ukáže celý obrázek. To znamená, že existuje potenciál pro optimalizaci.
4. Zdálo se nám, že vlastníci reklamního inventáře na internetu již mají infrastrukturu pro sběr statistik a jejich zobrazování v reklamních účtech a budou schopni poskytnout API pro tato data. To znamená, že je technicky možné jej realizovat. Řekněme hned, že se ukázalo, že to není tak jednoduché.
Obecně pro nás byly zřejmé všechny předpoklady pro realizaci projektu a běželi jsme projekt uvést v život...
Velký plán
Nejprve jsme si vytvořili vizi ideálního systému:
- Do něj by se měly automaticky načítat reklamní kampaně z podnikového systému 1C s jejich názvy, obdobími, rozpočty a umístěními na různých platformách.
- Pro každé umístění v rámci reklamní kampaně by měly být automaticky staženy všechny možné statistiky ze stránek, kde se umístění uskutečňuje, jako je počet zobrazení, kliknutí, zobrazení atd.
- Některé reklamní kampaně jsou sledovány pomocí monitorování třetích stran pomocí takzvaných reklamních systémů, jako je Adriver, Weborama, DCM atd. V Rusku je také průmyslový internetový měřič - společnost Mediascope. Podle našeho plánu by se do odpovídajících reklamních kampaní měla automaticky načítat i data z nezávislého a průmyslového monitoringu.
- Většina reklamních kampaní na internetu je zaměřena na určité cílové akce (nákup, zavolání, přihlášení na testovací jízdu atd.), které jsou sledovány pomocí Google Analytics, a statistiky, které jsou také důležité pro pochopení stavu kampaně a by měl být načten do našeho nástroje .
První palačinka je hrudkovitá
Vzhledem k našemu závazku k flexibilním principům vývoje softwaru (agilní, všechny věci), jsme se rozhodli nejprve vyvinout MVP a poté iterativně přejít k zamýšlenému cíli.
Rozhodli jsme se vybudovat MVP na základě našeho produktu DANBo (Dentsu Aegis Network Board), což je webová aplikace s obecnými informacemi o reklamních kampaních našich klientů.
Pro MVP byl projekt z hlediska realizace maximálně zjednodušen. Vybrali jsme omezený seznam platforem pro integraci. Jednalo se o hlavní platformy, jako jsou Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB a hlavní reklamní systémy Adriver a Weborama.
Pro přístup ke statistikám na stránkách přes API jsme použili jeden účet. Správce skupiny klientů, který chtěl využít automatické shromažďování statistik o reklamní kampani, musel nejprve delegovat přístup k potřebným reklamním kampaním na stránkách účtu platformy.
Další je uživatel systému DANBo musel do systému Excel nahrát soubor určitého formátu, který obsahoval veškeré informace o umístění (reklamní kampaň, platforma, formát, období umístění, plánované ukazatele, rozpočet atd.) a identifikátory odpovídajících reklamních kampaní na stránky a počítadla v reklamních systémech.
Vypadalo to, upřímně řečeno, děsivě:
Stažená data byla ukládána do databáze a poté z nich samostatné služby sbíraly identifikátory kampaní na stránkách a stahovaly o nich statistiky.
Pro každý web byla napsána samostatná služba Windows, která jednou denně přecházela pod jeden servisní účet v rozhraní API webu a stahovala statistiky pro zadaná ID kampaní. Totéž se stalo s reklamními systémy.
Stažená data byla zobrazena na rozhraní ve formě malého vlastního dashboardu:
Pro nás nečekaně začal fungovat MVP a začal stahovat aktuální statistiky reklamních kampaní na internetu. Implementovali jsme systém na několika klientech, ale při pokusu o škálování jsme narazili na vážné problémy:
- Hlavním problémem byla složitost přípravy dat pro načtení do systému. Také data umístění musela být před načtením převedena do přísně pevného formátu. Do souboru ke stažení bylo nutné zahrnout identifikátory entit z různých stránek. Setkáváme se s tím, že pro technicky nezkušené uživatele je velmi obtížné vysvětlit, kde na webu tyto identifikátory najít a kde v souboru je je třeba zadat. Vzhledem k počtu zaměstnanců v odděleních provozujících kampaně na stránkách a obratu to vyústilo v obrovskou podporu z naší strany, se kterou jsme absolutně nebyli spokojeni.
- Dalším problémem bylo, že ne všechny reklamní platformy měly mechanismy pro delegování přístupu k reklamním kampaním na jiné účty. Ale i kdyby byl k dispozici mechanismus delegování, ne všichni inzerenti byli ochotni udělit přístup ke svým kampaním účtům třetích stran.
- Důležitým faktorem bylo rozhořčení, které mezi uživateli vzbudila skutečnost, že všechny plánované ukazatele a detaily umístění, které již zadávají do našeho účetního systému 1C, musí znovu zadat DANBo.
To nám dalo myšlenku, že primárním zdrojem informací o umístění by měl být náš systém 1C, do kterého se všechna data zadávají přesně a včas (zde jde o to, že faktury jsou generovány na základě dat 1C, takže správné zadávání dat do 1C je prioritou pro každého KPI). Tak vznikl nový koncept systému...
Koncepce
První věc, kterou jsme se rozhodli udělat, bylo oddělit systém sběru statistik o reklamních kampaních na internetu do samostatného produktu - D1.Digitální.
V novém konceptu jsme se rozhodli naložit do D1.Digitální informace o reklamních kampaních a umístěních v nich od společnosti 1C, a poté vytáhnout statistiky z webů a systémů AdServing do těchto umístění. To mělo výrazně zjednodušit život uživatelům (a jako obvykle přidat více práce vývojářům) a snížit objem podpory.
První problém, na který jsme narazili, byl organizačního charakteru a souvisel s tím, že jsme nemohli najít klíč nebo znak, pomocí kterého bychom mohli porovnávat entity z různých systémů s kampaněmi a umístěními od 1C. Faktem je, že proces v naší společnosti je navržen tak, že reklamní kampaně zadávají do různých systémů různí lidé (mediální plánovači, nákup atd.).
Abychom tento problém vyřešili, museli jsme vymyslet unikátní hashovaný klíč DANBoID, který by spojoval entity v různých systémech dohromady a který by bylo možné poměrně snadno a jednoznačně identifikovat ve stažených souborech dat. Tento identifikátor je generován v interním systému 1C pro každé jednotlivé umístění a je přenášen do kampaní, umístění a počítadel na všech stránkách a ve všech systémech AdServing. Implementace praxe vkládání DANBoID do všech umístění nějakou dobu trvala, ale podařilo se nám to :)
Pak jsme zjistili, že ne všechny weby mají API pro automatický sběr statistik a ani ty, které API mají, nevrací všechna potřebná data.
V této fázi jsme se rozhodli výrazně zredukovat seznam platforem pro integraci a zaměřit se na hlavní platformy, které se podílejí na drtivé většině reklamních kampaní. Tento seznam zahrnuje všechny největší hráče na reklamním trhu (Google, Yandex, Mail.ru), sociálních sítích (VK, Facebook, Twitter), hlavních reklamních a analytických systémech (DCM, Adriver, Weborama, Google Analytics) a dalších platformách.
Většina webů, které jsme vybrali, měla rozhraní API, které poskytovalo metriky, které jsme potřebovali. V případech, kdy API neexistovalo nebo neobsahovalo potřebná data, jsme k načítání dat používali reporty zasílané denně na náš kancelářský email (v některých systémech je možné takové reporty nakonfigurovat, v jiných jsme se dohodli na vývoji takových reportů pro nás).
Při analýze dat z různých webů jsme zjistili, že hierarchie entit není v různých systémech stejná. Kromě toho je třeba z různých systémů stahovat informace v různých podrobnostech.
K vyřešení tohoto problému byl vyvinut koncept SubDANBoID. Myšlenka SubDANBoID je celkem jednoduchá, vygenerovaným DANBoID označíme hlavní entitu kampaně na webu a všechny vnořené entity nahrajeme s unikátními identifikátory webu a vytvoříme SubDANBoID podle principu DANBoID + identifikátor první úrovně vnořená entita + identifikátor vnořené entity druhé úrovně +... Tento přístup nám umožnil propojit reklamní kampaně v různých systémech a stáhnout si o nich podrobné statistiky.
Museli jsme také vyřešit problém přístupu ke kampaním na různých platformách. Jak jsme psali výše, mechanismus delegování přístupu ke kampani na samostatný technický účet není vždy použitelný. Proto jsme museli vyvinout infrastrukturu pro automatickou autorizaci přes OAuth pomocí tokenů a mechanismů pro aktualizaci těchto tokenů.
Dále se v článku pokusíme podrobněji popsat architekturu řešení a technické detaily implementace.
Architektura řešení 1.0
Při zahájení implementace nového produktu jsme pochopili, že okamžitě potřebujeme zajistit možnost připojení nových webů, a proto jsme se rozhodli jít cestou architektury mikroservisů.
Při návrhu architektury jsme oddělili konektory na všechny externí systémy - 1C, reklamní platformy a reklamní systémy - do samostatných služeb.
Hlavní myšlenkou je, že všechny konektory k webům mají stejné API a jsou to adaptéry, které přivádějí API webu do rozhraní, které je pro nás vhodné.
Středem našeho produktu je webová aplikace, což je monolit, který je navržen tak, aby jej bylo možné snadno rozložit na služby. Tato aplikace je zodpovědná za zpracování stažených dat, porovnávání statistik z různých systémů a jejich prezentaci uživatelům systému.
Pro komunikaci mezi konektory a webovou aplikací jsme museli vytvořit doplňkovou službu, kterou jsme nazvali Connector Proxy. Provádí funkce Service Discovery a Task Scheduler. Tato služba spouští úlohy sběru dat pro každý konektor každou noc. Psaní vrstvy služeb bylo jednodušší než připojení zprostředkovatele zpráv a pro nás bylo důležité získat výsledek co nejrychleji.
Pro jednoduchost a rychlost vývoje jsme se také rozhodli, že všechny služby budou webová API. To umožnilo rychle sestavit proof-of-concept a ověřit, že celý návrh funguje.
Samostatným, poměrně složitým úkolem bylo nastavení přístupu ke sběru dat z různých účtů, které by, jak jsme se rozhodli, měli provádět uživatelé přes webové rozhraní. Skládá se ze dvou samostatných kroků: nejprve uživatel přidá token pro přístup k účtu přes OAuth a poté nakonfiguruje sběr dat pro klienta z konkrétního účtu. Získání tokenu přes OAuth je nutné, protože jak jsme již psali, ne vždy je možné delegovat přístup k požadovanému účtu na webu.
Abychom vytvořili univerzální mechanismus pro výběr účtu ze stránek, museli jsme do rozhraní API konektorů přidat metodu, která vrací schéma JSON, které je vykresleno do formuláře pomocí upravené komponenty JSONEditor. Uživatelé si tak mohli vybrat účty, ze kterých budou stahovat data.
Abychom vyhověli limitům požadavků, které na webech existují, kombinujeme požadavky na nastavení v rámci jednoho tokenu, ale můžeme paralelně zpracovávat různé tokeny.
Jako úložiště načtených dat pro webovou aplikaci i konektory jsme zvolili MongoDB, což nám umožnilo nedělat si příliš starostí s datovou strukturou v počátečních fázích vývoje, kdy se objektový model aplikace mění každý druhý den.
Brzy jsme zjistili, že ne všechna data dobře sedí v MongoDB a například je pohodlnější ukládat denní statistiky do relační databáze. Proto jsme pro konektory, jejichž datová struktura je vhodnější pro relační databázi, začali jako úložiště používat PostgreSQL nebo MS SQL Server.
Zvolená architektura a technologie nám umožnily poměrně rychle postavit a uvést na trh produkt D1.Digital. Za dva roky vývoje produktu jsme vyvinuli 23 konektorů pro weby, získali neocenitelné zkušenosti s prací s API třetích stran, naučili se vyhýbat nástrahám různých webů, z nichž každý měl své vlastní, přispěli k vývoji API minimálně 3 stránky, automaticky stáhly informace o téměř 15 000 kampaních a pro více než 80 000 umístění, shromáždily mnoho zpětné vazby od uživatelů na fungování produktu a na základě této zpětné vazby se jim podařilo několikrát změnit hlavní proces produktu.
Architektura řešení 2.0
Od zahájení vývoje uplynuly dva roky D1.Digitální. Neustálé zvyšování zátěže systému a vznik stále nových a nových zdrojů dat postupně odhaloval problémy ve stávající architektuře řešení.
První problém souvisí s množstvím dat stahovaných ze stránek. Potýkali jsme se s tím, že sběr a aktualizace všech potřebných dat z největších webů začala zabírat příliš mnoho času. Například sběr dat z reklamního systému AdRiver, pomocí kterého sledujeme statistiky u většiny umístění, trvá zhruba 12 hodin.
Abychom tento problém vyřešili, začali jsme pro stahování dat ze stránek používat nejrůznější reporty, snažíme se společně se stránkami vyvíjet jejich API tak, aby rychlost jeho provozu odpovídala našim potřebám a co nejvíce paralelizovat stahování dat.
Další problém se týká zpracování stažených dat. Nyní, když přicházejí nové statistiky umístění, je spuštěn vícestupňový proces přepočítávání metrik, který zahrnuje načítání nezpracovaných dat, výpočet agregovaných metrik pro každý web, vzájemné porovnání dat z různých zdrojů a výpočet souhrnných metrik pro kampaň. To způsobuje velké zatížení webové aplikace, která provádí všechny výpočty. Během procesu přepočtu aplikace několikrát spotřebovala veškerou paměť na serveru, cca 10-15 GB, což mělo nejškodlivější vliv na práci uživatelů se systémem.
Zjištěné problémy a ambiciózní plány dalšího vývoje produktu nás vedly k nutnosti přehodnotit aplikační architekturu.
Začali jsme s konektory.
Všimli jsme si, že všechny konektory fungují podle stejného modelu, a tak jsme postavili pipeline framework, ve kterém pro vytvoření konektoru stačilo naprogramovat logiku kroků, zbytek byl univerzální. Pokud některý konektor vyžaduje vylepšení, okamžitě jej přeneseme do nového rámce současně s vylepšením konektoru.
Zároveň jsme začali nasazovat konektory pro Docker a Kubernetes.
Přechod na Kubernetes jsme plánovali poměrně dlouho, experimentovali s nastavením CI/CD, ale začali jsme se hýbat, až když jeden konektor kvůli chybě začal zabírat více než 20 GB paměti na serveru, což prakticky zabilo ostatní procesy . Během vyšetřování byl konektor přesunut do clusteru Kubernetes, kde nakonec zůstal, i když byla chyba opravena.
Poměrně rychle jsme si uvědomili, že Kubernetes je pohodlný, a během šesti měsíců jsme do produkčního clusteru přenesli 7 konektorů a Connectors Proxy, které spotřebovávají nejvíce prostředků.
Po konektorech jsme se rozhodli změnit architekturu zbytku aplikace.
Hlavním problémem bylo, že data přicházejí z konektorů na servery proxy ve velkých dávkách a poté se dostanou do DANBoID a jsou odeslána do centrální webové aplikace ke zpracování. Vzhledem k velkému počtu přepočtů metrik dochází k velkému zatížení aplikace.
Ukázalo se také poměrně obtížné sledovat stav jednotlivých úloh sběru dat a hlásit chyby vyskytující se v konektorech do centrální webové aplikace, aby uživatelé viděli, co se děje a proč se data nesbírají.
K vyřešení těchto problémů jsme vyvinuli architekturu 2.0.
Hlavní rozdíl mezi novou verzí architektury je v tom, že místo webového API používáme k výměně zpráv mezi službami RabbitMQ a knihovnu MassTransit. Abychom toho dosáhli, museli jsme téměř úplně přepsat Connectors Proxy, čímž jsme vytvořili Connectors Hub. Název byl změněn, protože hlavní role služby již není v přeposílání požadavků na konektory a zpět, ale ve správě sběru metrik z konektorů.
Z centrální webové aplikace jsme oddělili informace o umístěních a statistiky ze stránek do samostatných služeb, což umožnilo zbavit se zbytečných přepočtů a ukládat pouze již vypočítané a agregované statistiky na úrovni umístění. Také jsme přepsali a optimalizovali logiku pro výpočet základních statistik na základě hrubých dat.
Zároveň migrujeme všechny služby a aplikace na Docker a Kubernetes, aby bylo řešení snadněji škálovatelné a snadněji se spravovalo.
Kde jsme teď
Proof-of-concept architektura 2.0 produkt D1.Digitální připravené a fungující v testovacím prostředí s omezenou sadou konektorů. Zbývá pouze přepsat dalších 20 konektorů na novou platformu, otestovat, zda jsou data načtena správně a všechny metriky jsou správně vypočítány, a celý návrh zavést do výroby.
Ve skutečnosti k tomuto procesu dojde postupně a budeme muset opustit zpětnou kompatibilitu se starými API, aby vše fungovalo.
Naše nejbližší plány zahrnují vývoj nových konektorů, integraci s novými systémy a přidání dalších metrik k souboru dat stažených z připojených webů a reklamních systémů.
Plánujeme také převedení všech aplikací včetně centrální webové aplikace na Docker a Kubernetes. V kombinaci s novou architekturou to výrazně zjednoduší nasazení, sledování a kontrolu spotřebovaných zdrojů.
Dalším nápadem je experimentovat s výběrem databáze pro ukládání statistik, která je aktuálně uložena v MongoDB. Již jsme přenesli několik nových konektorů do SQL databází, ale tam je rozdíl téměř nepozorovatelný a pro agregované statistiky za den, které lze požadovat za libovolnou dobu, může být zisk docela vážný.
Obecně jsou plány velkolepé, pojďme dál :)
Autoři článku R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Michail Kotsik ()
Zdroj: www.habr.com