Het lijkt erop dat het gebied van online adverteren technologisch zo geavanceerd en geautomatiseerd mogelijk moet zijn. Natuurlijk, omdat daar reuzen en experts in hun vakgebied als Yandex, Mail.Ru, Google en Facebook werken. Maar het bleek dat er geen grenzen zijn aan perfectie en dat er altijd wel iets te automatiseren is.
Communicatie groep Dentsu Aegis Netwerk Rusland is de grootste speler op de digitale advertentiemarkt en investeert actief in technologie, in een poging haar bedrijfsprocessen te optimaliseren en te automatiseren. Een van de onopgeloste problemen van de online advertentiemarkt is de taak geworden om statistieken te verzamelen over advertentiecampagnes van verschillende internetplatforms. De oplossing voor dit probleem resulteerde uiteindelijk in de creatie van een product D1.Digitaal (lees als DiVan), waarvan we de ontwikkeling willen bespreken.
Waarom?
1. Toen het project van start ging, was er geen enkel kant-en-klaar product op de markt dat het probleem van het automatiseren van het verzamelen van statistieken over reclamecampagnes oploste. Dit betekent dat niemand behalve wijzelf onze behoeften zal bevredigen.
Diensten zoals Improvado, Roistat, Supermetrics en SegmentStream bieden integratie met platforms, sociale netwerken en Google Analitycs, en maken het ook mogelijk om analytische dashboards te bouwen voor gemakkelijke analyse en controle van advertentiecampagnes. Voordat we begonnen met de ontwikkeling van ons product, probeerden we een aantal van deze systemen te gebruiken om gegevens van sites te verzamelen, maar helaas konden ze onze problemen niet oplossen.
Het grootste probleem was dat de geteste producten afhankelijk waren van gegevensbronnen, waarbij plaatsingsstatistieken per site werden weergegeven, en niet de mogelijkheid boden om statistieken over advertentiecampagnes samen te voegen. Door deze aanpak konden we de statistieken van verschillende sites niet op één plek bekijken en de status van de campagne als geheel analyseren.
Een andere factor was dat de producten in de beginfase op de westerse markt waren gericht en de integratie met Russische sites niet ondersteunden. En voor de sites waarmee de integratie werd geïmplementeerd, werden niet altijd alle benodigde statistieken met voldoende details gedownload, en was de integratie niet altijd handig en transparant, vooral als het nodig was om iets te krijgen dat niet in de systeeminterface staat.
Over het algemeen hebben we besloten om ons niet aan te passen aan producten van derden, maar zijn we begonnen met het ontwikkelen van onze eigen...
2. De online advertentiemarkt groeit van jaar tot jaar en heeft in 2018, in termen van advertentiebudgetten, de traditioneel grootste tv-advertentiemarkt ingehaald. Er is dus sprake van een schaal.
3. In tegenstelling tot de tv-reclamemarkt, waar de verkoop van commerciële reclame wordt gemonopoliseerd, zijn er veel individuele eigenaren van reclame-inventaris van verschillende omvang die op internet actief zijn met hun eigen reclame-accounts. Omdat een advertentiecampagne in de regel op meerdere sites tegelijk wordt uitgevoerd, is het, om de status van de advertentiecampagne te begrijpen, noodzakelijk om rapporten van alle sites te verzamelen en deze te combineren tot één groot rapport dat het hele plaatje laat zien. Dit betekent dat er mogelijkheden zijn voor optimalisatie.
4. Het leek ons dat de eigenaren van advertentie-inventaris op internet al over de infrastructuur beschikken om statistieken te verzamelen en deze weer te geven in advertentieaccounts, en dat ze voor deze gegevens een API zullen kunnen leveren. Dit betekent dat het technisch mogelijk is om het te implementeren. Laten we meteen zeggen dat het niet zo eenvoudig bleek te zijn.
Over het algemeen waren alle vereisten voor de implementatie van het project voor ons duidelijk, en we renden om het project tot leven te brengen...
Groots plan
Om te beginnen vormden we een visie op een ideaal systeem:
- Advertentiecampagnes uit het 1C-bedrijfssysteem moeten er automatisch in worden geladen met hun namen, periodes, budgetten en plaatsingen op verschillende platforms.
- Voor elke plaatsing binnen een advertentiecampagne moeten alle mogelijke statistieken automatisch worden gedownload van de sites waar de plaatsing plaatsvindt, zoals het aantal vertoningen, klikken, weergaven, enz.
- Sommige advertentiecampagnes worden gevolgd met behulp van monitoring door derden door zogenaamde advertentiesystemen zoals Adriver, Weborama, DCM, enz. Er is ook een industriële internetmeter in Rusland - het bedrijf Mediascope. Volgens ons plan moeten gegevens van onafhankelijke en industriële monitoring ook automatisch in de bijbehorende reclamecampagnes worden geladen.
- De meeste advertentiecampagnes op internet zijn gericht op bepaalde doelgerichte acties (aankoop, bellen, aanmelden voor een proefrit etc.), die worden bijgehouden met behulp van Google Analytics, en waarvan statistieken ook van belang zijn om de status van de campagne te begrijpen en moet in onze tool worden geladen.
De eerste pannenkoek is klonterig
Gezien onze toewijding aan flexibele principes van softwareontwikkeling (agile, alles), hebben we besloten om eerst een MVP te ontwikkelen en vervolgens iteratief naar het beoogde doel toe te werken.
We besloten om MVP te bouwen op basis van ons product DANBo (Dentsu Aegis netwerkbestuur), een webapplicatie met algemene informatie over de advertentiecampagnes van onze klanten.
Voor MVP werd het project qua uitvoering zoveel mogelijk vereenvoudigd. We hebben een beperkte lijst met platforms voor integratie geselecteerd. Dit waren de belangrijkste platforms, zoals Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, en de belangrijkste advertentiesystemen Adriver en Weborama.
Om via de API toegang te krijgen tot statistieken over sites, gebruikten we één account. Een klantgroepmanager die automatische verzameling van statistieken over een advertentiecampagne wilde gebruiken, moest eerst de toegang tot de benodigde advertentiecampagnes op sites delegeren aan het platformaccount.
De volgende is de systeemgebruiker DANBo moest een bestand van een bepaald formaat uploaden naar het Excel-systeem, dat alle informatie bevatte over de plaatsing (reclamecampagne, platform, formaat, plaatsingsperiode, geplande indicatoren, budget, enz.) en identificatiegegevens van de overeenkomstige reclamecampagnes op de sites en tellers in advertentiesystemen.
Het zag er eerlijk gezegd angstaanjagend uit:
De gedownloade gegevens werden opgeslagen in een database en vervolgens verzamelden afzonderlijke diensten campagne-ID's op sites van hen en downloadden er statistieken over.
Voor elke site werd een aparte Windows-service geschreven, die één keer per dag onder één serviceaccount in de API van de site ging en statistieken voor specifieke campagne-ID's downloadde. Hetzelfde gebeurde met adserving-systemen.
De gedownloade gegevens werden op de interface weergegeven in de vorm van een klein aangepast dashboard:
Onverwacht voor ons begon MVP te werken en begon actuele statistieken over advertentiecampagnes op internet te downloaden. We hebben het systeem bij verschillende klanten geïmplementeerd, maar toen we probeerden op te schalen, kwamen we ernstige problemen tegen:
- Het grootste probleem was de complexiteit van het voorbereiden van gegevens om in het systeem te laden. Bovendien moesten de plaatsingsgegevens vóór het laden worden omgezet naar een strikt vast formaat. Het was noodzakelijk om entiteits-ID's van verschillende sites in het downloadbestand op te nemen. We worden geconfronteerd met het feit dat het voor technisch ongetrainde gebruikers erg moeilijk is om uit te leggen waar ze deze identificatiegegevens op de site kunnen vinden en waar ze in het bestand moeten worden ingevoerd. Gezien het aantal medewerkers op de afdelingen die campagnes voeren op sites en de omzet heeft dit aan onze kant een enorm draagvlak opgeleverd waar wij absoluut niet blij mee waren.
- Een ander probleem was dat niet alle advertentieplatforms over mechanismen beschikten om de toegang tot advertentiecampagnes naar andere accounts te delegeren. Maar zelfs als er een delegatiemechanisme beschikbaar zou zijn, waren niet alle adverteerders bereid toegang tot hun campagnes te verlenen aan accounts van derden.
- Een belangrijke factor was de verontwaardiging die bij gebruikers werd gewekt door het feit dat ze alle geplande indicatoren en plaatsingsdetails die ze al in ons 1C-boekhoudsysteem invoeren, opnieuw moeten invoeren DANBo.
Dit bracht ons op het idee dat de primaire informatiebron over plaatsing ons 1C-systeem zou moeten zijn, waarin alle gegevens nauwkeurig en op tijd worden ingevoerd (het punt hier is dat facturen worden gegenereerd op basis van 1C-gegevens, dus correcte invoer van gegevens in 1C is een prioriteit voor elke KPI). Zo ontstond een nieuw concept van het systeem...
Concept
Het eerste dat we besloten te doen, was het systeem voor het verzamelen van statistieken over advertentiecampagnes op internet in een afzonderlijk product op te splitsen: D1.Digitaal.
In het nieuwe concept hebben we besloten om in te laden D1.Digitaal informatie over advertentiecampagnes en plaatsingen daarin uit 1C, en haal vervolgens statistieken op van sites en AdServing-systemen voor deze plaatsingen. Dit moest het leven van gebruikers aanzienlijk vereenvoudigen (en, zoals gewoonlijk, meer werk voor ontwikkelaars toevoegen) en de hoeveelheid ondersteuning verminderen.
Het eerste probleem dat we tegenkwamen was van organisatorische aard en hield verband met het feit dat we geen sleutel of teken konden vinden waarmee we entiteiten uit verschillende systemen konden vergelijken met campagnes en plaatsingen uit 1C. Feit is dat het proces in ons bedrijf zo is ingericht dat reclamecampagnes door verschillende mensen (mediaplanners, inkoop, etc.) in verschillende systemen worden ingevoerd.
Om dit probleem op te lossen moesten we een unieke gehashte sleutel uitvinden, DANBoID, die entiteiten in verschillende systemen met elkaar zou verbinden, en die vrij eenvoudig en uniek geïdentificeerd kon worden in gedownloade datasets. Deze identificatie wordt voor elke individuele plaatsing gegenereerd in het interne 1C-systeem en overgedragen naar campagnes, plaatsingen en tellers op alle sites en in alle AdServing-systemen. Het implementeren van de praktijk om DANBoID in alle plaatsingen te plaatsen kostte wat tijd, maar het is ons gelukt :)
Toen kwamen we erachter dat niet alle sites een API hebben voor het automatisch verzamelen van statistieken, en zelfs sites die wel een API hebben, retourneren niet alle benodigde gegevens.
In dit stadium hebben we besloten de lijst met platforms voor integratie aanzienlijk in te korten en ons te concentreren op de belangrijkste platforms die betrokken zijn bij de overgrote meerderheid van advertentiecampagnes. Deze lijst bevat alle grootste spelers op de advertentiemarkt (Google, Yandex, Mail.ru), sociale netwerken (VK, Facebook, Twitter), grote AdServing- en analysesystemen (DCM, Adriver, Weborama, Google Analytics) en andere platforms.
Het merendeel van de door ons geselecteerde sites beschikte over een API die de statistieken leverde die we nodig hadden. In gevallen waarin er geen API was of deze niet de benodigde gegevens bevatte, gebruikten we rapporten die dagelijks naar onze kantoor-e-mail werden verzonden om gegevens te laden (in sommige systemen is het mogelijk om dergelijke rapporten te configureren, in andere hebben we overeenstemming bereikt over de ontwikkeling van dergelijke rapporten voor ons).
Bij het analyseren van gegevens van verschillende sites kwamen we erachter dat de hiërarchie van entiteiten niet hetzelfde is in verschillende systemen. Bovendien moet informatie in verschillende details uit verschillende systemen worden gedownload.
Om dit probleem op te lossen is het SubDANBoID-concept ontwikkeld. Het idee van SubDANBoID is vrij eenvoudig: we markeren de hoofdentiteit van de campagne op de site met de gegenereerde DANBoID, en we uploaden alle geneste entiteiten met unieke site-ID's en vormen SubDANBoID volgens het DANBoID-principe + ID van het eerste niveau geneste entiteit + identificatie van de geneste entiteit op het tweede niveau +... Dankzij deze aanpak konden we advertentiecampagnes in verschillende systemen met elkaar verbinden en er gedetailleerde statistieken over downloaden.
We moesten ook het probleem van de toegang tot campagnes op verschillende platforms oplossen. Zoals we hierboven schreven, is het mechanisme van het delegeren van toegang tot een campagne naar een afzonderlijk technisch account niet altijd van toepassing. Daarom moesten we een infrastructuur ontwikkelen voor automatische autorisatie via OAuth met behulp van tokens en mechanismen voor het updaten van deze tokens.
Verderop in het artikel zullen we proberen de architectuur van de oplossing en de technische details van de implementatie gedetailleerder te beschrijven.
Oplossingsarchitectuur 1.0
Toen we begonnen met de implementatie van een nieuw product, begrepen we dat we onmiddellijk moesten voorzien in de mogelijkheid om nieuwe sites met elkaar te verbinden, dus besloten we het pad van de microservice-architectuur te volgen.
Bij het ontwerpen van de architectuur hebben we connectoren naar alle externe systemen (1C, advertentieplatforms en advertentiesystemen) gescheiden in afzonderlijke services.
Het belangrijkste idee is dat alle connectoren naar sites dezelfde API hebben en adapters zijn die de site-API naar een interface brengen die voor ons handig is.
De kern van ons product is een webapplicatie, een monoliet die zo is ontworpen dat deze eenvoudig kan worden gedemonteerd tot services. Deze applicatie is verantwoordelijk voor het verwerken van de gedownloade gegevens, het verzamelen van statistieken van verschillende systemen en het presenteren ervan aan systeemgebruikers.
Om te communiceren tussen de connectoren en de webapplicatie moesten we een extra dienst creëren, die we Connector Proxy noemden. Het voert de functies van Service Discovery en Task Scheduler uit. Deze service voert elke nacht gegevensverzamelingstaken uit voor elke connector. Het schrijven van een servicelaag was eenvoudiger dan het aansluiten van een berichtenmakelaar, en voor ons was het belangrijk om zo snel mogelijk resultaat te krijgen.
Voor de eenvoud en snelheid van de ontwikkeling hebben we ook besloten dat alle services web-API's zullen zijn. Hierdoor was het mogelijk om snel een proof-of-concept samen te stellen en te verifiëren dat het gehele ontwerp werkt.
Een aparte, nogal complexe taak was het opzetten van toegang om gegevens van verschillende accounts te verzamelen, wat, zoals we besloten, door gebruikers via de webinterface zou moeten worden uitgevoerd. Het bestaat uit twee afzonderlijke stappen: eerst voegt de gebruiker een token toe om toegang te krijgen tot het account via OAuth, en configureert vervolgens de verzameling van gegevens voor de klant vanuit een specifiek account. Het verkrijgen van een token via OAuth is noodzakelijk omdat het, zoals we al schreven, niet altijd mogelijk is om de toegang tot het gewenste account op de site te delegeren.
Om een universeel mechanisme te creëren voor het selecteren van een account op sites, moesten we een methode toevoegen aan de connectors-API die JSON Schema retourneert, dat in een formulier wordt weergegeven met behulp van een aangepaste JSONEditor-component. Op deze manier konden gebruikers de accounts selecteren waarvan ze gegevens wilden downloaden.
Om te voldoen aan de verzoeklimieten die op sites bestaan, combineren we verzoeken voor instellingen binnen één token, maar we kunnen verschillende tokens parallel verwerken.
We kozen voor MongoDB als opslag voor geladen gegevens voor zowel de webapplicatie als de connectoren, waardoor we ons in de beginfase van de ontwikkeling, wanneer het objectmodel van de applicatie om de dag verandert, ons niet al te veel zorgen hoefden te maken over de datastructuur.
We kwamen er al snel achter dat niet alle data goed in MongoDB passen en het bijvoorbeeld handiger is om dagelijkse statistieken op te slaan in een relationele database. Daarom zijn we voor connectoren waarvan de datastructuur meer geschikt is voor een relationele database, PostgreSQL of MS SQL Server als opslag gaan gebruiken.
Dankzij de gekozen architectuur en technologieën konden we het D1.Digital-product relatief snel bouwen en lanceren. Gedurende twee jaar productontwikkeling hebben we 23 connectoren voor sites ontwikkeld, waardevolle ervaring opgedaan met het werken met API's van derden, geleerd de valkuilen te vermijden van verschillende sites, die elk hun eigen sites hadden, en hebben bijgedragen aan de ontwikkeling van de API van ten minste 3 sites, downloadden automatisch informatie over bijna 15 campagnes en voor meer dan 000 plaatsingen, verzamelden veel feedback van gebruikers over de werking van het product en slaagden erin om op basis van deze feedback het hoofdproces van het product verschillende keren te wijzigen.
Oplossingsarchitectuur 2.0
Er zijn twee jaar verstreken sinds het begin van de ontwikkeling D1.Digitaal. De constante toename van de belasting van het systeem en de opkomst van steeds meer nieuwe gegevensbronnen brachten geleidelijk problemen in de bestaande oplossingsarchitectuur aan het licht.
Het eerste probleem houdt verband met de hoeveelheid gegevens die van de sites wordt gedownload. We werden geconfronteerd met het feit dat het verzamelen en bijwerken van alle benodigde gegevens van de grootste sites te veel tijd begon te kosten. Het verzamelen van gegevens uit het AdRiver-advertentiesysteem, waarmee we statistieken voor de meeste plaatsingen bijhouden, duurt bijvoorbeeld ongeveer 12 uur.
Om dit probleem op te lossen, zijn we allerlei rapporten gaan gebruiken om gegevens van sites te downloaden. We proberen hun API samen met de sites te ontwikkelen, zodat de snelheid van de werking ervan aan onze behoeften voldoet, en de gegevensdownload zoveel mogelijk parallel te laten verlopen.
Een ander probleem heeft betrekking op de verwerking van gedownloade gegevens. Wanneer er nu nieuwe plaatsingsstatistieken binnenkomen, wordt een meerfasig proces voor het herberekenen van statistieken gelanceerd, waaronder het laden van onbewerkte gegevens, het berekenen van geaggregeerde statistieken voor elke site, het vergelijken van gegevens uit verschillende bronnen met elkaar en het berekenen van samenvattende statistieken voor de campagne. Dit zorgt voor veel belasting van de webapplicatie die alle berekeningen doet. Tijdens het herberekeningsproces heeft de applicatie verschillende keren al het geheugen op de server in beslag genomen, ongeveer 10-15 GB, wat het meest nadelige effect had op het werk van gebruikers met het systeem.
De geïdentificeerde problemen en ambitieuze plannen voor de verdere ontwikkeling van het product brachten ons tot de noodzaak om de applicatiearchitectuur te heroverwegen.
We zijn begonnen met connectoren.
We merkten dat alle connectoren volgens hetzelfde model werken, dus hebben we een pijplijnframework gebouwd waarin je om een connector te maken alleen de logica van de stappen hoefde te programmeren, de rest was universeel. Als een connector verbetering behoeft, dan zetten we deze onmiddellijk over naar een nieuw raamwerk terwijl de connector wordt verbeterd.
Tegelijkertijd zijn we begonnen met het implementeren van connectoren voor Docker en Kubernetes.
We hadden de overstap naar Kubernetes al geruime tijd gepland, geëxperimenteerd met CI/CD-instellingen, maar begonnen pas te verhuizen toen een connector, als gevolg van een fout, meer dan 20 GB geheugen op de server begon op te eten, waardoor andere processen praktisch werden gedood . Tijdens het onderzoek werd de connector verplaatst naar een Kubernetes-cluster, waar deze uiteindelijk bleef staan, zelfs nadat de fout was verholpen.
Al snel beseften we dat Kubernetes handig was, en binnen zes maanden hebben we zeven connectoren en Connectors Proxy, die de meeste bronnen verbruiken, overgezet naar het productiecluster.
Na de connectoren hebben we besloten de architectuur van de rest van de applicatie te veranderen.
Het grootste probleem was dat gegevens in grote batches van connectoren naar proxy's komen, vervolgens op de DANBoID terechtkomen en ter verwerking naar de centrale webapplicatie worden gestuurd. Door het grote aantal metrische herberekeningen is er sprake van een grote belasting van de applicatie.
Het bleek ook behoorlijk moeilijk om de status van individuele gegevensverzamelingstaken te monitoren en fouten te rapporteren die zich binnen connectoren met een centrale webapplicatie voordeden, zodat gebruikers konden zien wat er gebeurde en waarom er geen gegevens werden verzameld.
Om deze problemen op te lossen hebben we architectuur 2.0 ontwikkeld.
Het belangrijkste verschil tussen de nieuwe versie van de architectuur is dat we in plaats van de Web API RabbitMQ en de MassTransit-bibliotheek gebruiken om berichten tussen services uit te wisselen. Om dit te doen, moesten we Connectors Proxy bijna volledig herschrijven, waardoor het Connectors Hub werd. De naam is gewijzigd omdat de belangrijkste rol van de service niet langer bestaat uit het doorsturen van verzoeken naar connectors en terug, maar uit het beheren van de verzameling metrische gegevens van connectors.
Vanuit de centrale webapplicatie hebben we informatie over plaatsingen en statistieken van sites gescheiden in afzonderlijke services, waardoor het mogelijk werd om onnodige herberekeningen achterwege te laten en alleen reeds berekende en geaggregeerde statistieken op plaatsingsniveau op te slaan. Ook hebben we de logica voor het berekenen van basisstatistieken op basis van ruwe data herschreven en geoptimaliseerd.
Tegelijkertijd migreren we alle diensten en applicaties naar Docker en Kubernetes om de oplossing eenvoudiger schaalbaar en gemakkelijker te beheren te maken.
Waar zijn we nu
Proof-of-concept architectuur 2.0-product D1.Digitaal klaar en werkend in een testomgeving met een beperkte set connectoren. Het enige dat u nog hoeft te doen, is nog eens twintig connectoren naar een nieuw platform herschrijven, testen of de gegevens correct zijn geladen en alle statistieken correct zijn berekend, en het volledige ontwerp in productie nemen.
In feite zal dit proces geleidelijk gebeuren en zullen we achterwaartse compatibiliteit met oude API's moeten verlaten om alles werkend te houden.
Onze onmiddellijke plannen omvatten de ontwikkeling van nieuwe connectoren, integratie met nieuwe systemen en het toevoegen van extra statistieken aan de reeks gegevens die worden gedownload van verbonden sites en advertentiesystemen.
Ook zijn we van plan om alle applicaties, inclusief de centrale webapplicatie, over te zetten naar Docker en Kubernetes. Gecombineerd met de nieuwe architectuur zal dit de inzet, monitoring en controle van de verbruikte bronnen aanzienlijk vereenvoudigen.
Een ander idee is om te experimenteren met de keuze van de database voor het opslaan van statistieken, die momenteel is opgeslagen in MongoDB. We hebben al verschillende nieuwe connectoren naar SQL-databases overgezet, maar daar is het verschil vrijwel onmerkbaar, en voor geaggregeerde statistieken per dag, die voor een willekeurige periode kunnen worden opgevraagd, kan de winst behoorlijk groot zijn.
Over het algemeen zijn de plannen grandioos, laten we verder gaan :)
Auteurs van het artikel R&D Dentsu Aegis Network Rusland: Georgy Ostapenko (), Michail Kotsik ()
Bron: www.habr.com