Det ser ud til, at området for onlineannoncering bør være så teknologisk avanceret og automatiseret som muligt. Selvfølgelig, fordi sådanne giganter og eksperter inden for deres felt som Yandex, Mail.Ru, Google og Facebook arbejder der. Men som det viste sig, er der ingen grænse for perfektion, og der er altid noget at automatisere.
Kommunikationsgruppe Dentsu Aegis Network Rusland er den største spiller på det digitale annoncemarked og investerer aktivt i teknologi og forsøger at optimere og automatisere sine forretningsprocesser. Et af de uløste problemer på onlineannoncemarkedet er blevet opgaven med at indsamle statistik over reklamekampagner fra forskellige internetplatforme. Løsningen på dette problem resulterede i sidste ende i oprettelsen af et produkt D1.Digital (læs som DiVan), hvis udvikling vi vil tale om.
Hvorfor?
1. På tidspunktet for projektets start var der ikke et eneste færdigt produkt på markedet, der løste problemet med at automatisere indsamlingen af statistik om annoncekampagner. Det betyder, at ingen undtagen os selv vil tilfredsstille vores behov.
Tjenester som Improvado, Roistat, Supermetrics, SegmentStream tilbyder integration med platforme, sociale netværk og Google Analitycs, og gør det også muligt at bygge analytiske dashboards til bekvem analyse og kontrol af annoncekampagner. Før vi begyndte at udvikle vores produkt, forsøgte vi at bruge nogle af disse systemer til at indsamle data fra websteder, men de kunne desværre ikke løse vores problemer.
Hovedproblemet var, at de testede produkter var baseret på datakilder, viste placeringsstatistikker efter websted og ikke gav mulighed for at samle statistik om annoncekampagner. Denne tilgang tillod os ikke at se statistikker fra forskellige websteder på ét sted og analysere kampagnens tilstand som helhed.
En anden faktor var, at produkterne i de indledende faser var rettet mod det vestlige marked og ikke understøttede integration med russiske websteder. Og for de websteder, som integrationen blev implementeret med, blev alle de nødvendige målinger ikke altid downloadet med tilstrækkelige detaljer, og integrationen var ikke altid praktisk og gennemsigtig, især når det var nødvendigt at få noget, der ikke er i systemgrænsefladen.
Generelt besluttede vi ikke at tilpasse os tredjepartsprodukter, men begyndte at udvikle vores egne...
2. Onlineannoncemarkedet vokser fra år til år, og i 2018 overhalede det, hvad angår annoncebudgetter, det traditionelt største tv-annoncemarked. Så der er en skala.
3. I modsætning til tv-reklamemarkedet, hvor salget af kommerciel reklame er monopoliseret, er der mange individuelle ejere af reklamebeholdninger af forskellig størrelse, der opererer på internettet med deres egne reklamekonti. Da en annoncekampagne som regel kører på flere websteder på én gang, for at forstå annoncekampagnens tilstand, er det nødvendigt at indsamle rapporter fra alle websteder og kombinere dem til en stor rapport, der viser hele billedet. Det betyder, at der er potentiale for optimering.
4. Det forekom for os, at ejerne af reklamebeholdning på internettet allerede har infrastrukturen til at indsamle statistik og vise dem på reklamekonti, og de vil være i stand til at levere en API til disse data. Det betyder, at det er teknisk muligt at implementere det. Lad os sige med det samme, at det viste sig ikke at være så enkelt.
Generelt var alle forudsætninger for gennemførelsen af projektet åbenlyse for os, og vi løb for at føre projektet ud i livet...
Stor plan
Til at begynde med dannede vi en vision om et ideelt system:
- Annoncekampagner fra 1C-virksomhedssystemet bør automatisk indlæses i det med deres navne, perioder, budgetter og placeringer på forskellige platforme.
- For hver placering i en annoncekampagne skal alle mulige statistikker automatisk downloades fra de websteder, hvor placeringen finder sted, såsom antal visninger, klik, visninger osv.
- Nogle annoncekampagner spores ved hjælp af tredjepartsovervågning af såkaldte adserving-systemer som Adriver, Weborama, DCM osv. Der er også en industriel internetmåler i Rusland - Mediascope-virksomheden. Ifølge vores plan skal data fra uafhængig og industriel overvågning også automatisk indlæses i de tilsvarende reklamekampagner.
- De fleste annoncekampagner på internettet er rettet mod bestemte målhandlinger (køb, ring, tilmeld dig en prøvetur osv.), som spores ved hjælp af Google Analytics, og statistik for hvilke også er vigtige for at forstå kampagnens status og skal indlæses i vores værktøj.
Den første pandekage er klumpet
I betragtning af vores forpligtelse til fleksible principper for softwareudvikling (agile, alle ting), besluttede vi først at udvikle en MVP og derefter bevæge os mod det tilsigtede mål iterativt.
Vi besluttede at bygge MVP baseret på vores produkt DANBo (Dentsu Aegis Network Board), som er en webapplikation med generel information om vores kunders annoncekampagner.
For MVP blev projektet forenklet så meget som muligt med hensyn til implementering. Vi har udvalgt en begrænset liste over platforme til integration. Disse var de vigtigste platforme, såsom Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB og de vigtigste adservingsystemer Adriver og Weborama.
For at få adgang til statistik på websteder via API'et brugte vi en enkelt konto. En kundegruppeleder, der ønskede at bruge automatisk indsamling af statistik på en annoncekampagne, skulle først delegere adgang til de nødvendige annoncekampagner på websteder til platformkontoen.
Dernæst er systembrugeren DANBo skulle uploade en fil af et bestemt format til Excel-systemet, som indeholdt alle oplysninger om placeringen (annoncekampagne, platform, format, placeringsperiode, planlagte indikatorer, budget osv.) og identifikatorer for de tilsvarende annoncekampagner på websteder og tællere i annoncesystemer.
Det så ærligt talt skræmmende ud:
De downloadede data blev gemt i en database, og derefter indsamlede separate tjenester kampagne-id'er på websteder fra dem og downloadede statistik om dem.
For hver side blev der skrevet en separat Windows-tjeneste, som én gang om dagen gik ind under én servicekonto i sidens API og downloadede statistik for specificerede kampagne-id'er. Det samme skete med adserving-systemer.
De downloadede data blev vist på grænsefladen i form af et lille brugerdefineret dashboard:
Uventet for os begyndte MVP at arbejde og begyndte at downloade aktuelle statistikker om reklamekampagner på internettet. Vi implementerede systemet på flere klienter, men da vi forsøgte at skalere, stødte vi på alvorlige problemer:
- Hovedproblemet var kompleksiteten i at forberede data til indlæsning i systemet. Placeringsdataene skulle også konverteres til et strengt fast format før indlæsning. Det var nødvendigt at inkludere enhedsidentifikatorer fra forskellige websteder i downloadfilen. Vi står over for, at det er meget svært for teknisk utrænede brugere at forklare, hvor man kan finde disse identifikatorer på siden, og hvor i filen de skal indtastes. Med tanke på antallet af medarbejdere i afdelingerne, der kører kampagner på sites og omsætningen, resulterede det i en enorm opbakning fra vores side, som vi absolut ikke var tilfredse med.
- Et andet problem var, at ikke alle reklameplatforme havde mekanismer til at uddelegere adgang til reklamekampagner til andre konti. Men selvom en delegationsmekanisme var tilgængelig, var ikke alle annoncører villige til at give adgang til deres kampagner til tredjepartskonti.
- En vigtig faktor var den indignation, der vakte blandt brugerne over, at alle de planlagte indikatorer og placeringsdetaljer, som de allerede indtaster i vores 1C regnskabssystem, skal de genindlæse. DANBo.
Dette gav os ideen om, at den primære kilde til information om placering skulle være vores 1C-system, hvor alle data indtastes præcist og til tiden (pointen her er, at fakturaer genereres baseret på 1C-data, så korrekt indtastning af data i 1C er en prioritet for alle KPI). Sådan opstod et nyt koncept af systemet...
koncept
Det første, vi besluttede at gøre, var at adskille systemet til indsamling af statistik over reklamekampagner på internettet i et separat produkt - D1.Digital.
I det nye koncept besluttede vi at indlæse D1.Digital oplysninger om annoncekampagner og placeringer i dem fra 1C, og derefter trække statistik fra websteder og AdServing-systemer til disse placeringer. Dette skulle forenkle livet betydeligt for brugere (og som sædvanligt tilføje mere arbejde til udviklere) og reducere mængden af support.
Det første problem, vi stødte på, var af organisatorisk karakter og var relateret til, at vi ikke kunne finde en nøgle eller et tegn, hvormed vi kunne sammenligne enheder fra forskellige systemer med kampagner og placeringer fra 1C. Faktum er, at processen i vores virksomhed er designet på en sådan måde, at reklamekampagner bliver lagt ind i forskellige systemer af forskellige personer (medieplanlæggere, indkøb osv.).
For at løse dette problem var vi nødt til at opfinde en unik hashed-nøgle, DANBoID, som ville forbinde entiteter i forskellige systemer sammen, og som ret nemt og entydigt kunne identificeres i downloadede datasæt. Denne identifikator genereres i det interne 1C-system for hver enkelt placering og overføres til kampagner, placeringer og tællere på alle sider og i alle AdServing-systemer. Implementering af praksis med at sætte DANBoID i alle placeringer tog noget tid, men vi formåede at gøre det :)
Så fandt vi ud af, at ikke alle websteder har en API til automatisk at indsamle statistik, og selv dem, der har en API, returnerer den ikke alle de nødvendige data.
På dette tidspunkt besluttede vi at reducere listen over platforme til integration markant og fokusere på de vigtigste platforme, der er involveret i langt de fleste annoncekampagner. Denne liste omfatter alle de største aktører på annoncemarkedet (Google, Yandex, Mail.ru), sociale netværk (VK, Facebook, Twitter), store AdServing- og analysesystemer (DCM, Adriver, Weborama, Google Analytics) og andre platforme.
De fleste af de websteder, vi valgte, havde en API, der leverede de målinger, vi havde brug for. I tilfælde, hvor der ikke var nogen API, eller det ikke indeholdt de nødvendige data, brugte vi rapporter sendt dagligt til vores kontor-e-mail til at indlæse data (i nogle systemer er det muligt at konfigurere sådanne rapporter, i andre aftalte vi udviklingen af sådanne rapporter for os).
Da vi analyserede data fra forskellige websteder, fandt vi ud af, at hierarkiet af enheder ikke er det samme i forskellige systemer. Desuden skal information downloades i forskellige detaljer fra forskellige systemer.
For at løse dette problem blev SubDANBoID konceptet udviklet. Ideen med SubDANBoID er ret enkel, vi markerer hovedenheden af kampagnen på webstedet med det genererede DANBoID, og vi uploader alle indlejrede entiteter med unikke webstedsidentifikatorer og danner SubDANBoID i henhold til DANBoID-princippet + identifikator på første niveau indlejret enhed + identifikator for indlejret enhed på andet niveau +... Denne tilgang tillod os at forbinde reklamekampagner i forskellige systemer og downloade detaljerede statistikker om dem.
Vi skulle også løse problemet med adgang til kampagner på forskellige platforme. Som vi skrev ovenfor, er mekanismen med at uddelegere adgang til en kampagne til en separat teknisk konto ikke altid anvendelig. Derfor var vi nødt til at udvikle en infrastruktur til automatisk godkendelse via OAuth ved hjælp af tokens og mekanismer til opdatering af disse tokens.
Senere i artiklen vil vi forsøge at beskrive mere detaljeret løsningens arkitektur og de tekniske detaljer i implementeringen.
Løsningsarkitektur 1.0
Da vi startede implementeringen af et nyt produkt, forstod vi, at vi straks var nødt til at sørge for muligheden for at forbinde nye websteder, så vi besluttede at følge mikroservicearkitekturens vej.
Ved design af arkitekturen adskilte vi stik til alle eksterne systemer - 1C, reklameplatforme og reklamesystemer - i separate tjenester.
Hovedideen er, at alle forbindelser til websteder har den samme API og er adaptere, der bringer webstedets API til en grænseflade, der er praktisk for os.
I centrum af vores produkt er en webapplikation, som er en monolit, der er designet på en sådan måde, at den let kan skilles ad til tjenester. Denne applikation er ansvarlig for at behandle de downloadede data, samle statistik fra forskellige systemer og præsentere dem for systembrugere.
For at kommunikere mellem connectorerne og webapplikationen var vi nødt til at oprette en ekstra service, som vi kaldte Connector Proxy. Den udfører funktionerne Service Discovery og Task Scheduler. Denne tjeneste kører dataindsamlingsopgaver for hver forbindelse hver nat. At skrive et servicelag var nemmere end at forbinde en beskedmægler, og for os var det vigtigt at få resultatet så hurtigt som muligt.
For enkelhedens skyld og udviklingshastigheden besluttede vi også, at alle tjenester skal være web-API'er. Dette gjorde det muligt hurtigt at sammensætte et proof-of-concept og verificere, at hele designet fungerer.
En separat, ret kompleks opgave var at oprette adgang til at indsamle data fra forskellige konti, som, som vi besluttede, skulle udføres af brugerne via webgrænsefladen. Den består af to separate trin: For det første tilføjer brugeren et token for at få adgang til kontoen via OAuth og konfigurerer derefter indsamlingen af data for klienten fra en specifik konto. Det er nødvendigt at få et token via OAuth, fordi det, som vi allerede har skrevet, ikke altid er muligt at uddelegere adgang til den ønskede konto på siden.
For at skabe en universel mekanisme til at vælge en konto fra websteder, var vi nødt til at tilføje en metode til connectors API, der returnerer JSON Schema, som gengives til en form ved hjælp af en modificeret JSONEditor-komponent. På denne måde var brugerne i stand til at vælge de konti, hvorfra de skulle downloade data.
For at overholde de anmodningsgrænser, der findes på websteder, kombinerer vi anmodninger om indstillinger inden for et token, men vi kan behandle forskellige tokens parallelt.
Vi valgte MongoDB som et lager for indlæste data til både webapplikationen og connectors, hvilket gjorde det muligt for os ikke at bekymre os for meget om datastrukturen i de indledende stadier af udviklingen, når objektmodellen for applikationen ændres hver anden dag.
Vi fandt hurtigt ud af, at ikke alle data passer godt ind i MongoDB, og for eksempel er det mere bekvemt at gemme daglig statistik i en relationsdatabase. Derfor begyndte vi at bruge PostgreSQL eller MS SQL Server som opbevaring for connectorer, hvis datastruktur er mere egnet til en relationel database.
Den valgte arkitektur og teknologier gjorde det muligt for os at bygge og lancere D1.Digital-produktet relativt hurtigt. I løbet af to års produktudvikling udviklede vi 23 connectors til websteder, fik uvurderlig erfaring med at arbejde med tredjeparts API'er, lærte at undgå faldgruberne på forskellige websteder, som hver havde deres egne, bidrog til udviklingen af API'et på mindst 3 websteder, downloadede automatisk information om næsten 15 kampagner og for mere end 000 placeringer, indsamlede en masse feedback fra brugere om produktets drift og formåede at ændre hovedprocessen af produktet flere gange, baseret på denne feedback.
Løsningsarkitektur 2.0
To år er gået siden starten af udviklingen D1.Digital. Den konstante stigning i belastningen på systemet og fremkomsten af flere og flere nye datakilder afslørede gradvist problemer i den eksisterende løsningsarkitektur.
Det første problem er relateret til mængden af data, der downloades fra webstederne. Vi stod over for det faktum, at indsamling og opdatering af alle nødvendige data fra de største websteder begyndte at tage for meget tid. For eksempel tager det omkring 12 timer at indsamle data fra AdRivers annoncesystem, som vi sporer statistik for de fleste placeringer.
For at løse dette problem begyndte vi at bruge alle slags rapporter til at downloade data fra websteder, vi forsøger at udvikle deres API sammen med webstederne, så hastigheden af dens drift opfylder vores behov, og parallelisere dataoverførslen så meget som muligt.
Et andet problem vedrører behandlingen af downloadede data. Nu, når der kommer nye placeringsstatistikker, lanceres en flertrinsproces med genberegning af metrics, som omfatter indlæsning af rådata, beregning af aggregerede metrics for hvert websted, sammenligning af data fra forskellige kilder med hinanden og beregning af opsummerende metrics for kampagnen. Dette medfører en masse belastning på webapplikationen, der udfører alle beregningerne. Flere gange, under genberegningsprocessen, forbrugte applikationen al hukommelsen på serveren, omkring 10-15 GB, hvilket havde den mest skadelige effekt på brugernes arbejde med systemet.
De identificerede problemer og ambitiøse planer for videreudvikling af produktet førte os til behovet for at genoverveje applikationsarkitekturen.
Vi startede med stik.
Vi lagde mærke til, at alle konnektorer fungerer efter samme model, så vi byggede en pipeline-ramme, hvor man for at skabe en konnektor kun skulle programmere logikken i trinene, resten var universel. Hvis noget stik kræver forbedring, så overfører vi det straks til et nyt framework, samtidig med at stikket bliver forbedret.
Samtidig begyndte vi at implementere connectors til Docker og Kubernetes.
Vi planlagde flytningen til Kubernetes i ret lang tid, eksperimenterede med CI/CD-indstillinger, men begyndte først at flytte, da det ene stik på grund af en fejl begyndte at æde mere end 20 GB hukommelse på serveren, hvilket praktisk talt dræbte andre processer . Under undersøgelsen blev stikket flyttet til en Kubernetes-klynge, hvor det i sidste ende forblev, selv efter fejlen var rettet.
Ret hurtigt indså vi, at Kubernetes var praktisk, og inden for seks måneder overførte vi 7 stik og Connectors Proxy, som bruger flest ressourcer, til produktionsklyngen.
Efter konnektorerne besluttede vi at ændre arkitekturen for resten af applikationen.
Hovedproblemet var, at data kommer fra konnektorer til proxyer i store partier, og derefter rammer DANBoID og sendes til den centrale webapplikation til behandling. På grund af det store antal metric-genberegninger er der stor belastning på applikationen.
Det viste sig også at være ret vanskeligt at overvåge status for individuelle dataindsamlingsjob og rapportere fejl, der opstod i forbindelser til en central webapplikation, så brugerne kunne se, hvad der skete, og hvorfor data ikke blev indsamlet.
For at løse disse problemer udviklede vi arkitektur 2.0.
Den største forskel mellem den nye version af arkitekturen er, at vi i stedet for Web API'en bruger RabbitMQ og MassTransit-biblioteket til at udveksle meddelelser mellem tjenester. For at gøre dette var vi nødt til næsten fuldstændigt at omskrive Connectors Proxy, hvilket gjorde det Connectors Hub. Navnet blev ændret, fordi tjenestens hovedrolle ikke længere er at videresende anmodninger til connectors og tilbage, men i at administrere indsamlingen af metrics fra connectors.
Fra den centrale webapplikation har vi adskilt information om placeringer og statistik fra websteder i separate tjenester, hvilket gjorde det muligt at slippe for unødvendige genberegninger og kun gemme allerede beregnede og aggregerede statistikker på placeringsniveau. Vi omskrev og optimerede også logikken til beregning af grundlæggende statistik baseret på rådata.
Samtidig migrerer vi alle tjenester og applikationer til Docker og Kubernetes for at gøre løsningen nemmere at skalere og mere bekvem at administrere.
Hvor er vi nu
Proof-of-concept arkitektur 2.0-produkt D1.Digital klar og arbejder i et testmiljø med et begrænset sæt stik. Det eneste, der er tilbage at gøre, er at omskrive yderligere 20 stik til en ny platform, teste, at dataene er indlæst korrekt, og alle metrics er beregnet korrekt, og rulle hele designet ud i produktion.
Faktisk vil denne proces ske gradvist, og vi bliver nødt til at forlade bagudkompatibilitet med gamle API'er for at holde alt i gang.
Vores umiddelbare planer omfatter udvikling af nye connectors, integration med nye systemer og tilføjelse af yderligere metrikker til datasættet, der downloades fra tilsluttede websteder og annoncesystemer.
Vi planlægger også at overføre alle applikationer, inklusive den centrale webapplikation, til Docker og Kubernetes. Kombineret med den nye arkitektur vil dette markant forenkle implementering, overvågning og kontrol af forbrugte ressourcer.
En anden idé er at eksperimentere med valget af database til lagring af statistik, som i øjeblikket er gemt i MongoDB. Vi har allerede overført flere nye connectorer til SQL-databaser, men dér er forskellen næsten umærkelig, og for aggregerede statistikker om dagen, som kan rekvireres i en vilkårlig periode, kan gevinsten være ret alvorlig.
Generelt er planerne storslåede, lad os komme videre :)
Forfattere af artiklen R&D Dentsu Aegis Network Rusland: Georgy Ostapenko (), Mikhail Kotsik ()
Kilde: www.habr.com