Dit blyk dat die veld van aanlyn-advertensies so tegnologies gevorderd en geoutomatiseerd as moontlik moet wees. Natuurlik, want sulke reuse en kundiges op hul gebied soos Yandex, Mail.Ru, Google en Facebook werk daar. Maar, soos dit geblyk het, is daar geen beperking op perfeksie nie en daar is altyd iets om te outomatiseer.
Kommunikasie groep Dentsu Aegis Netwerk Rusland is die grootste speler in die digitale advertensiemark en belê aktief in tegnologie en probeer om sy besigheidsprosesse te optimaliseer en te outomatiseer. Een van die onopgeloste probleme van die aanlyn-advertensiemark is die taak om statistieke oor advertensieveldtogte vanaf verskillende internetplatforms in te samel. Die oplossing vir hierdie probleem het uiteindelik gelei tot die skepping van 'n produk D1.Digitaal (lees as DiVan), waaroor ons wil praat.
Зачем?
1. Ten tyde van die aanvang van die projek was daar nie 'n enkele klaargemaakte produk op die mark wat die probleem opgelos het om die versameling van statistieke oor advertensieveldtogte te outomatiseer nie. Dit beteken dat niemand behalwe onsself ons behoeftes sal bevredig nie.
Dienste soos Improvado, Roistat, Supermetrics, SegmentStream bied integrasie met platforms, sosiale netwerke en Google Analitycs, en maak dit ook moontlik om analitiese dashboards te bou vir gerieflike ontleding en beheer van advertensieveldtogte. Voordat ons ons produk begin ontwikkel het, het ons probeer om sommige van hierdie stelsels te gebruik om data van werwe af te versamel, maar ongelukkig kon hulle nie ons probleme oplos nie.
Die grootste probleem was dat die getoetste produkte op databronne gebaseer was, wat plasingstatistieke per werf vertoon, en nie die vermoë verskaf het om statistieke oor advertensieveldtogte saam te voeg nie. Hierdie benadering het ons nie toegelaat om statistieke van verskillende werwe op een plek te sien en die stand van die veldtog as geheel te ontleed nie.
Nog 'n faktor was dat die produkte in die aanvanklike stadiums op die Westerse mark gemik was en nie integrasie met Russiese webwerwe ondersteun het nie. En vir daardie werwe waarmee integrasie geïmplementeer is, is al die nodige maatstawwe nie altyd met voldoende detail afgelaai nie, en die integrasie was nie altyd gerieflik en deursigtig nie, veral wanneer dit nodig was om iets te kry wat nie in die stelselkoppelvlak is nie.
Oor die algemeen het ons besluit om nie by derdeparty-produkte aan te pas nie, maar ons eie...
2. Die aanlyn advertensiemark groei van jaar tot jaar, en in 2018, wat advertensiebegrotings betref, het dit die tradisioneel grootste TV-reklamemark verbygesteek. Daar is dus 'n skaal.
3. Anders as die TV-reklamemark, waar die verkoop van kommersiële advertensies gemonopoliseer word, is daar baie individuele eienaars van advertensie-voorraad van verskillende groottes wat op die internet met hul eie advertensierekeninge werk. Aangesien 'n advertensieveldtog, as 'n reël, op verskeie werwe gelyktydig loop, om die stand van die advertensieveldtog te verstaan, is dit nodig om verslae van alle webwerwe in te samel en dit te kombineer in een groot verslag wat die hele prentjie sal wys. Dit beteken daar is potensiaal vir optimalisering.
4. Dit het vir ons gelyk of die eienaars van advertensie-voorraad op die internet reeds die infrastruktuur het om statistieke in te samel en dit in advertensierekeninge te vertoon, en hulle sal 'n API vir hierdie data kan verskaf. Dit beteken dat dit tegnies moontlik is om dit te implementeer. Kom ons sê dadelik dat dit nie so eenvoudig geblyk het nie.
Oor die algemeen was al die voorvereistes vir die implementering van die projek vir ons voor die hand liggend, en ons het gehardloop om die projek tot lewe te bring...
Groot plan
Om mee te begin, het ons 'n visie van 'n ideale stelsel gevorm:
- Advertensieveldtogte van die 1C-korporatiewe stelsel moet outomaties daarin gelaai word met hul name, tydperke, begrotings en plasings op verskeie platforms.
- Vir elke plasing binne 'n advertensieveldtog moet alle moontlike statistieke outomaties afgelaai word vanaf die werwe waar die plasing plaasvind, soos die aantal indrukke, klikke, kyke, ens.
- Sommige advertensieveldtogte word nagespoor met behulp van derdeparty-monitering deur sogenaamde advertensiestelsels soos Adriver, Weborama, DCM, ens. Daar is ook 'n industriële internetmeter in Rusland - die Mediascope-maatskappy. Volgens ons plan moet data van onafhanklike en industriële monitering ook outomaties in die ooreenstemmende advertensieveldtogte gelaai word.
- Die meeste advertensieveldtogte op die internet is gemik op sekere teikenaksies (aankoop, bel, teken aan vir 'n toetsrit, ens.), wat met behulp van Google Analytics nagespoor word, en statistieke waarvoor ook belangrik is om die status van die veldtog te verstaan en moet in ons instrument gelaai word.
Die eerste verdomde ding is klonterig
Gegewe ons verbintenis tot buigsame beginsels van sagteware-ontwikkeling (rats, alles), het ons besluit om eers 'n MVP te ontwikkel en dan herhaaldelik na die beoogde doel te beweeg.
Ons het besluit om MVP te bou op grond van ons produk DANBo (Dentsu Aegis Network Board), wat 'n webtoepassing is met algemene inligting oor ons kliënte se advertensieveldtogte.
Vir MVP is die projek sover moontlik vereenvoudig wat implementering betref. Ons het 'n beperkte lys platforms vir integrasie gekies. Dit was die hoofplatforms, soos Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, en die belangrikste advertensiesisteme Adriver en Weborama.
Om toegang tot statistieke op werwe via die API te verkry, het ons 'n enkele rekening gebruik. 'n Kliëntegroepbestuurder wat outomatiese versameling van statistieke op 'n advertensieveldtog wou gebruik, moes eers toegang tot die nodige advertensieveldtogte op werwe aan die platformrekening delegeer.
Volgende is die stelselgebruiker DANBo moes 'n lêer van 'n sekere formaat in die Excel-stelsel oplaai, wat al die inligting oor die plasing (advertensieveldtog, platform, formaat, plasingstydperk, beplande aanwysers, begroting, ens.) en identifiseerders van die ooreenstemmende advertensieveldtogte op die werwe en tellers in advertensiesisteme.
Dit het, eerlikwaar, skrikwekkend gelyk:
Die afgelaaide data is in 'n databasis gestoor, en dan het aparte dienste veldtog-identifiseerders op werwe van hulle versamel en statistieke daaroor afgelaai.
Vir elke werf is 'n aparte Windows-diens geskryf, wat een keer per dag onder een diensrekening in die werf se API gegaan het en statistieke vir gespesifiseerde veldtog-ID's afgelaai het. Dieselfde ding het gebeur met advertensiesisteme.
Die afgelaaide data is op die koppelvlak vertoon in die vorm van 'n klein pasgemaakte dashboard:
Onverwags vir ons het MVP begin werk en huidige statistieke oor advertensieveldtogte op die internet begin aflaai. Ons het die stelsel op verskeie kliënte geïmplementeer, maar toe ons probeer skaal het, het ons ernstige probleme ondervind:
- Die hoofprobleem was die kompleksiteit van die voorbereiding van data om in die stelsel te laai. Die plasingsdata moes ook na 'n streng vaste formaat omgeskakel word voordat dit gelaai word. Dit was nodig om entiteitidentifiseerders van verskillende werwe in die aflaailêer in te sluit. Ons word gekonfronteer met die feit dat dit baie moeilik is vir tegnies onopgeleide gebruikers om te verduidelik waar om hierdie identifiseerders op die webwerf te vind en waar in die lêer hulle ingevoer moet word. Met inagneming van die aantal werknemers in die departemente wat veldtogte op terreine voer en die omset, het dit 'n groot hoeveelheid ondersteuning aan ons kant tot gevolg gehad, waarmee ons absoluut nie tevrede was nie.
- Nog 'n probleem was dat nie alle advertensieplatforms meganismes gehad het om toegang tot advertensieveldtogte na ander rekeninge te delegeer nie. Maar selfs al was 'n delegeringsmeganisme beskikbaar, was nie alle adverteerders bereid om toegang tot hul veldtogte aan derdeparty-rekeninge te verleen nie.
- 'n Belangrike faktor was die verontwaardiging wat onder gebruikers gewek is deur die feit dat al die beplande aanwysers en plasingsbesonderhede wat hulle reeds in ons 1C-rekeningkundestelsel invoer, hulle weer moet invul. DANBo.
Dit het ons die idee gegee dat die primêre bron van inligting oor plasing ons 1C-stelsel moet wees, waarin alle data akkuraat en betyds ingevoer word (die punt hier is dat fakture op grond van 1C-data gegenereer word, dus korrekte invoer van data in 1C is 'n prioriteit vir almal KPI). Dit is hoe 'n nuwe konsep van die stelsel ontstaan het ...
konsep
Die eerste ding wat ons besluit het om te doen, was om die stelsel vir die insameling van statistieke oor advertensieveldtogte op die internet in 'n aparte produk te skei - D1.Digitaal.
In die nuwe konsep het ons besluit om in te laai D1.Digitaal inligting oor advertensieveldtogte en plasings binne hulle vanaf 1C, en trek dan statistieke van werwe en AdServing-stelsels na hierdie plasings op. Dit was veronderstel om die lewe vir gebruikers aansienlik te vereenvoudig (en, soos gewoonlik, meer werk aan ontwikkelaars by te voeg) en die hoeveelheid ondersteuning te verminder.
Die eerste probleem wat ons teëgekom het was van 'n organisatoriese aard en het verband gehou met die feit dat ons nie 'n sleutel of teken kon vind waarmee ons entiteite van verskillende stelsels met veldtogte en plasings van 1C kon vergelyk nie. Die feit is dat die proses in ons maatskappy so ontwerp is dat advertensieveldtogte deur verskillende mense (mediabeplanners, koop, ens.) in verskillende stelsels ingevoer word.
Om hierdie probleem op te los, moes ons 'n unieke hashed-sleutel, DANBoID, uitvind wat entiteite in verskillende stelsels met mekaar sou verbind, en wat redelik maklik en uniek in afgelaaide datastelle geïdentifiseer kon word. Hierdie identifiseerder word in die interne 1C-stelsel vir elke individuele plasing gegenereer en word oorgedra na veldtogte, plasings en tellers op alle werwe en in alle AdServing-stelsels. Die implementering van die praktyk om DANBoID in alle plasings te plaas het 'n geruime tyd geneem, maar ons het dit reggekry :)
Toe het ons uitgevind dat nie alle werwe 'n API het om statistieke outomaties in te samel nie, en selfs diegene wat wel 'n API het, gee dit nie al die nodige data terug nie.
Op hierdie stadium het ons besluit om die lys platforms vir integrasie aansienlik te verminder en te fokus op die hoofplatforms wat by die oorgrote meerderheid van advertensieveldtogte betrokke is. Hierdie lys sluit al die grootste rolspelers in die advertensiemark (Google, Yandex, Mail.ru), sosiale netwerke (VK, Facebook, Twitter), groot AdServing en analitiese stelsels (DCM, Adriver, Weborama, Google Analytics) en ander platforms in.
Die meerderheid van die werwe wat ons gekies het, het 'n API gehad wat die maatstawwe verskaf het wat ons nodig gehad het. In gevalle waar daar geen API was nie of dit nie die nodige data bevat het nie, het ons verslae gebruik wat daagliks na ons kantoor e-pos gestuur is om data te laai (in sommige stelsels is dit moontlik om sulke verslae op te stel, in ander het ons ooreengekom oor die ontwikkeling van sulke verslae vir ons).
Toe ons data van verskillende werwe ontleed het, het ons uitgevind dat die hiërargie van entiteite nie dieselfde is in verskillende stelsels nie. Boonop moet inligting in verskillende besonderhede vanaf verskillende stelsels afgelaai word.
Om hierdie probleem op te los, is die SubDANBoID-konsep ontwikkel. Die idee van SubDANBoID is redelik eenvoudig, ons merk die hoofentiteit van die veldtog op die webwerf met die gegenereerde DANBoID, en ons laai alle geneste entiteite met unieke webwerf-identifiseerders op en vorm SubDANBoID volgens die DANBoID-beginsel + identifiseerder van die eerste vlak geneste entiteit + identifiseerder van die tweede vlak geneste entiteit +... Hierdie benadering het ons in staat gestel om advertensieveldtogte in verskillende stelsels te verbind en gedetailleerde statistieke daaroor af te laai.
Ons moes ook die probleem van toegang tot veldtogte op verskillende platforms oplos. Soos ons hierbo geskryf het, is die meganisme om toegang tot 'n veldtog na 'n aparte tegniese rekening te delegeer nie altyd van toepassing nie. Daarom moes ons 'n infrastruktuur ontwikkel vir outomatiese magtiging via OAuth met behulp van tekens en meganismes vir die opdatering van hierdie tekens.
Later in die artikel sal ons probeer om die argitektuur van die oplossing en die tegniese besonderhede van die implementering in meer besonderhede te beskryf.
Oplossingsargitektuur 1.0
Toe ons met die implementering van 'n nuwe produk begin het, het ons verstaan dat ons onmiddellik voorsiening moes maak vir die moontlikheid om nuwe werwe te koppel, en daarom het ons besluit om die pad van mikrodiensargitektuur te volg.
Toe ons die argitektuur ontwerp het, het ons verbindings na alle eksterne stelsels - 1C, advertensieplatforms en advertensiestelsels - in aparte dienste geskei.
Die hoofgedagte is dat alle verbindings na werwe dieselfde API het en adapters is wat die webwerf-API na 'n koppelvlak bring wat vir ons gerieflik is.
In die middel van ons produk is 'n webtoepassing, wat 'n monoliet is wat op so 'n manier ontwerp is dat dit maklik in dienste uitmekaar gehaal kan word. Hierdie toepassing is verantwoordelik vir die verwerking van die afgelaaide data, versameling van statistieke van verskillende stelsels en aanbieding daarvan aan stelselgebruikers.
Om tussen die verbindings en die webtoepassing te kommunikeer, moes ons 'n bykomende diens skep, wat ons Connector Proxy genoem het. Dit voer die funksies van Service Discovery en Task Scheduler uit. Hierdie diens voer data-insamelingstake vir elke verbinding elke aand uit. Om 'n dienslaag te skryf was makliker as om 'n boodskapmakelaar te koppel, en vir ons was dit belangrik om die resultaat so vinnig as moontlik te kry.
Vir die eenvoud en spoed van ontwikkeling, het ons ook besluit dat alle dienste Web API's sal wees. Dit het dit moontlik gemaak om vinnig 'n bewys-van-konsep saam te stel en te verifieer dat die hele ontwerp werk.
'n Aparte, taamlik komplekse taak was om toegang op te stel om data van verskillende rekeninge in te samel, wat, soos ons besluit het, deur gebruikers deur die webkoppelvlak uitgevoer moet word. Dit bestaan uit twee afsonderlike stappe: eerstens voeg die gebruiker 'n teken by om toegang tot die rekening via OAuth te verkry, en stel dan die versameling van data vir die kliënt vanaf 'n spesifieke rekening op. Die verkryging van 'n teken via OAuth is nodig omdat, soos ons reeds geskryf het, dit nie altyd moontlik is om toegang tot die verlangde rekening op die webwerf te delegeer nie.
Om 'n universele meganisme te skep om 'n rekening vanaf webwerwe te kies, moes ons 'n metode by die verbindings-API voeg wat JSON-skema terugstuur, wat in 'n vorm weergegee word met behulp van 'n gewysigde JSONEditor-komponent. Op hierdie manier kon gebruikers die rekeninge kies waaruit data afgelaai moet word.
Om te voldoen aan die versoeklimiete wat op werwe bestaan, kombineer ons versoeke vir instellings binne een teken, maar ons kan verskillende tekens parallel verwerk.
Ons het MongoDB gekies as 'n berging vir gelaaide data vir beide die webtoepassing en verbindings, wat ons toegelaat het om nie te veel bekommerd te wees oor die datastruktuur in die aanvanklike stadiums van ontwikkeling, wanneer die objekmodel van die toepassing elke tweede dag verander nie.
Ons het gou uitgevind dat nie alle data goed in MongoDB pas nie en dit is byvoorbeeld geriefliker om daaglikse statistieke in 'n relasionele databasis te stoor. Daarom, vir verbindings wie se datastruktuur meer geskik is vir 'n relasionele databasis, het ons PostgreSQL of MS SQL Server as berging begin gebruik.
Die gekose argitektuur en tegnologieë het ons toegelaat om die D1.Digital-produk relatief vinnig te bou en bekend te stel. Oor twee jaar se produkontwikkeling het ons 23 verbindings na werwe ontwikkel, onskatbare ervaring opgedoen om met derdeparty-API's te werk, geleer om die slaggate van verskillende werwe te vermy, wat elkeen hul eie gehad het, het bygedra tot die ontwikkeling van die API van ten minste 3 webwerwe, outomaties afgelaai inligting oor byna 15 000 veldtogte en vir meer as 80 000 plasings, het baie terugvoer van gebruikers oor die produk se werking ingesamel en daarin geslaag om die hoofproses van die produk verskeie kere te verander, gebaseer op hierdie terugvoer.
Oplossingsargitektuur 2.0
Twee jaar het verloop sedert die begin van ontwikkeling D1.Digitaal. Die konstante toename in las op die stelsel en die opkoms van meer en meer nuwe databronne het geleidelik probleme in die bestaande oplossingsargitektuur aan die lig gebring.
Die eerste probleem hou verband met die hoeveelheid data wat van die webwerwe afgelaai is. Ons het gekonfronteer met die feit dat die insameling en opdatering van al die nodige data vanaf die grootste webwerwe te veel tyd begin neem het. Byvoorbeeld, die insameling van data vanaf die AdRiver-advertensiestelsel, waarmee ons statistieke vir die meeste plasings opspoor, neem ongeveer 12 uur.
Om hierdie probleem op te los, het ons allerhande verslae begin gebruik om data van webwerwe af te laai, ons probeer hul API saam met die webwerwe ontwikkel sodat die spoed van die werking daarvan aan ons behoeftes voldoen, en die data-aflaai soveel as moontlik paralleliseer.
Nog 'n probleem hou verband met die verwerking van afgelaaide data. Nou, wanneer nuwe plasingstatistieke aankom, word 'n multi-stadium proses van herberekening van statistieke van stapel gestuur, wat die laai van rou data, die berekening van saamgevoegde statistieke vir elke werf, die vergelyking van data van verskillende bronne met mekaar, en die berekening van opsommende statistieke vir die veldtog insluit. Dit veroorsaak baie las op die webtoepassing wat al die berekeninge doen. Verskeie kere, tydens die herberekeningsproses, het die toepassing al die geheue op die bediener verbruik, ongeveer 10-15 GB, wat die nadeligste uitwerking op gebruikers se werk met die stelsel gehad het.
Die geïdentifiseerde probleme en ambisieuse planne vir verdere ontwikkeling van die produk het daartoe gelei dat ons die toepassingsargitektuur moes heroorweeg.
Ons het begin met verbindings.
Ons het opgemerk dat alle verbindings volgens dieselfde model werk, so ons het 'n pyplynraamwerk gebou waarin jy net die logika van die stappe hoef te programmeer om 'n koppelaar te skep, die res was universeel. As een of ander koppelstuk verbetering benodig, dra ons dit dadelik oor na 'n nuwe raamwerk op dieselfde tyd as wat die koppelaar verbeter word.
Terselfdertyd het ons verbindings na Docker en Kubernetes begin ontplooi.
Ons het die skuif na Kubernetes vir 'n redelike lang tyd beplan, met CI/CD-instellings geëksperimenteer, maar het eers begin beweeg toe een koppelaar, weens 'n fout, meer as 20 GB geheue op die bediener begin opvreet het, wat ander prosesse feitlik doodgemaak het. . Tydens die ondersoek is die koppelaar na 'n Kubernetes-kluster geskuif, waar dit uiteindelik gebly het, selfs nadat die fout reggestel is.
Ons het redelik vinnig besef dat Kubernetes gerieflik was, en binne ses maande het ons 7 verbindings en Connectors Proxy, wat die meeste hulpbronne verbruik, na die produksiekluster oorgeplaas.
Na aanleiding van die verbindings het ons besluit om die argitektuur van die res van die toepassing te verander.
Die grootste probleem was dat data van koppelaars na gevolmagtigdes in groot groepe kom, en dan die DANBoID tref en na die sentrale webtoepassing gestuur word vir verwerking. As gevolg van die groot aantal metrieke herberekenings, is daar 'n groot las op die toepassing.
Dit was ook nogal moeilik om die status van individuele data-insamelingstake te monitor en foute te rapporteer wat voorkom binne koppelaars na 'n sentrale webtoepassing sodat gebruikers kan sien wat gebeur en hoekom data nie ingesamel word nie.
Om hierdie probleme op te los, het ons argitektuur 2.0 ontwikkel.
Die belangrikste verskil tussen die nuwe weergawe van die argitektuur is dat in plaas van die Web API, ons RabbitMQ en die MassTransit-biblioteek gebruik om boodskappe tussen dienste uit te ruil. Om dit te doen, moes ons Connectors Proxy byna heeltemal herskryf, wat dit Connectors Hub maak. Die naam is verander omdat die hoofrol van die diens nie meer in die aanstuur van versoeke na koppelaars en terug is nie, maar in die bestuur van die versameling van metrieke vanaf koppelaars.
Van die sentrale webtoepassing het ons inligting oor plasings en statistieke van werwe in aparte dienste geskei, wat dit moontlik gemaak het om van onnodige herberekenings ontslae te raak en slegs reeds berekende en saamgestelde statistieke op plasingsvlak te stoor. Ons het ook die logika vir die berekening van basiese statistieke gebaseer op rou data herskryf en geoptimaliseer.
Terselfdertyd migreer ons alle dienste en toepassings na Docker en Kubernetes om die oplossing makliker te skaal en geriefliker om te bestuur.
Waar is ons nou
Bewys-van-konsep argitektuur 2.0 produk D1.Digitaal gereed en werk in 'n toetsomgewing met 'n beperkte stel verbindings. Al wat oorbly om te doen is om nog 20 verbindings na 'n nuwe platform te herskryf, te toets dat die data korrek gelaai is en alle maatstawwe korrek bereken is, en die hele ontwerp in produksie uit te rol.
Trouens, hierdie proses sal geleidelik plaasvind en ons sal terugwaartse versoenbaarheid met ou API's moet verlaat om alles te laat werk.
Ons onmiddellike planne sluit in die ontwikkeling van nuwe verbindings, integrasie met nuwe stelsels en die byvoeging van bykomende maatstawwe by die stel data wat van gekoppelde werwe en advertensiestelsels afgelaai word.
Ons beplan ook om alle toepassings, insluitend die sentrale webtoepassing, na Docker en Kubernetes oor te dra. Gekombineer met die nuwe argitektuur, sal dit die ontplooiing, monitering en beheer van verbruikte hulpbronne aansienlik vereenvoudig.
Nog 'n idee is om te eksperimenteer met die keuse van databasis vir die stoor van statistieke, wat tans in MongoDB gestoor word. Ons het reeds verskeie nuwe verbindings na SQL-databasisse oorgedra, maar daar is die verskil byna onmerkbaar, en vir saamgestelde statistieke per dag, wat vir 'n arbitrêre tydperk aangevra kan word, kan die wins nogal ernstig wees.
Oor die algemeen is die planne grandioos, kom ons gaan aan :)
Skrywers van die artikel R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Bron: will.com