Svo virðist sem svið auglýsinga á netinu eigi að vera eins tæknivædd og sjálfvirk og mögulegt er. Auðvitað vegna þess að þar starfa risar og sérfræðingar á sínu sviði eins og Yandex, Mail.Ru, Google og Facebook. En eins og það kom í ljós eru engin takmörk fyrir fullkomnun og það er alltaf eitthvað til að gera sjálfvirkan.
Samskiptahópur Dentsu Aegis Network Rússland er stærsti aðilinn á stafrænum auglýsingamarkaði og er virkur að fjárfesta í tækni, reyna að hagræða og gera sjálfvirkan viðskiptaferla sína. Eitt af óleystu vandamálum auglýsingamarkaðarins á netinu hefur orðið það verkefni að safna tölfræði um auglýsingaherferðir frá mismunandi netkerfum. Lausnin á þessu vandamáli leiddi að lokum til framleiðslu vöru D1.Stafræn (lesið sem DiVan), þróunina sem við viljum tala um.
Hvers vegna?
1. Þegar verkefnið hófst var ekki ein ein tilbúin vara á markaðnum sem leysti þann vanda að gera sjálfvirka söfnun tölfræði um auglýsingaherferðir. Þetta þýðir að enginn nema við sjálf mun fullnægja þörfum okkar.
Þjónusta eins og Improvado, Roistat, Supermetrics, SegmentStream bjóða upp á samþættingu við palla, samfélagsnet og Google Analycs og gera það einnig mögulegt að byggja upp greiningarmælaborð fyrir þægilega greiningu og stjórn á auglýsingaherferðum. Áður en við byrjuðum að þróa vöruna okkar reyndum við að nota sum þessara kerfa til að safna gögnum frá vefsvæðum, en því miður gátu þau ekki leyst vandamál okkar.
Helsta vandamálið var að vörurnar sem voru prófaðar reiddu sig á gagnaheimildir, sýndu staðsetningartölfræði eftir síðu og gáfu ekki möguleika á að safna saman tölfræði um auglýsingaherferðir. Þessi nálgun leyfði okkur ekki að sjá tölfræði frá mismunandi síðum á einum stað og greina stöðu herferðarinnar í heild sinni.
Annar þáttur var að á fyrstu stigum voru vörurnar miðaðar að vestrænum markaði og studdu ekki samþættingu við rússneskar síður. Og fyrir þær síður sem samþætting var innleidd með voru allar nauðsynlegar mælingar ekki alltaf sóttar með nægjanlegum smáatriðum og samþættingin var ekki alltaf þægileg og gagnsæ, sérstaklega þegar það var nauðsynlegt að fá eitthvað sem er ekki í kerfisviðmótinu.
Almennt ákváðum við að laga okkur ekki að vörum frá þriðja aðila heldur byrjuðum við að þróa okkar eigin...
2. Auglýsingamarkaðurinn á netinu er að stækka ár frá ári og árið 2018, miðað við auglýsingafjárveitingar, fór hann fram úr hefðbundnum stærsta sjónvarpsauglýsingamarkaði. Svo það er mælikvarði.
3. Ólíkt sjónvarpsauglýsingamarkaði, þar sem sala á auglýsingum er einokuð, þá eru margir einstakir eigendur auglýsingabirgða af ýmsum stærðum starfandi á Netinu með eigin auglýsingareikninga. Þar sem auglýsingaherferð keyrir að jafnaði á nokkrum síðum í einu, til að átta sig á stöðu auglýsingaherferðarinnar, er nauðsynlegt að safna skýrslum af öllum síðum og sameina þær í eina stóra skýrslu sem sýnir heildarmyndina. Þetta þýðir að það er möguleiki á hagræðingu.
4. Okkur virtist sem eigendur auglýsingabirgða á Netinu hafa nú þegar innviði til að safna tölfræði og birta þær á auglýsingareikningum og þeir munu geta útvegað API fyrir þessi gögn. Þetta þýðir að það er tæknilega mögulegt að framkvæma það. Segjum strax að þetta reyndist ekki vera svo einfalt.
Almennt séð voru allar forsendur fyrir framkvæmd verkefnisins augljósar fyrir okkur og hlupum við til að koma verkefninu í framkvæmd...
Stórkostlegt plan
Til að byrja með mynduðum við sýn um hugsjón kerfi:
- Auglýsingaherferðir frá 1C fyrirtækjakerfinu ættu að vera sjálfkrafa hlaðnar inn í það með nöfnum, tímabilum, fjárhagsáætlunum og staðsetningum á ýmsum kerfum.
- Fyrir hverja staðsetningu innan auglýsingaherferðar ætti að hlaða niður öllum mögulegum tölfræði sjálfkrafa frá þeim síðum þar sem staðsetningin á sér stað, svo sem fjölda birtinga, smella, skoðana o.s.frv.
- Sumar auglýsingaherferðir eru raktar með eftirliti þriðja aðila með svokölluðum auglýsingakerfum eins og Adriver, Weborama, DCM o.fl. Það er líka iðnaðar internetmælir í Rússlandi - Mediascope fyrirtækið. Samkvæmt áætlun okkar ætti einnig að hlaða gögnum frá óháðu og iðnaðareftirliti sjálfkrafa inn í samsvarandi auglýsingaherferðir.
- Flestar auglýsingaherferðir á netinu miða að ákveðnum markaðgerðum (kaupum, hringingu, skráningu í reynsluakstur o.s.frv.), sem fylgst er með með Google Analytics og tölfræði sem er einnig mikilvæg til að skilja stöðu herferðarinnar og ætti að vera hlaðið inn í tólið okkar.
Fyrsta pönnukaka er klumpur
Í ljósi skuldbindingar okkar við sveigjanlegar meginreglur hugbúnaðarþróunar (lipur, allt), ákváðum við fyrst að þróa MVP og stefna síðan í átt að tilætluðu markmiði ítrekað.
Við ákváðum að byggja MVP út frá vörunni okkar DANBo (Dentsu Aegis Network Board), sem er vefforrit með almennum upplýsingum um auglýsingaherferðir viðskiptavina okkar.
Fyrir MVP var verkefnið einfaldað eins og hægt var hvað varðar framkvæmd. Við höfum valið takmarkaðan lista yfir vettvanga fyrir samþættingu. Þetta voru helstu pallarnir, eins og Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB og helstu auglýsingakerfin Adriver og Weborama.
Til að fá aðgang að tölfræði um vefsvæði í gegnum API notuðum við einn reikning. Stjórnandi viðskiptavinahóps sem vildi nota sjálfvirka söfnun tölfræði í auglýsingaherferð þurfti fyrst að fela aðgangi að nauðsynlegum auglýsingaherferðum á vefsvæðum yfir á vettvangsreikninginn.
Næstur er kerfisnotandinn DANBo þurfti að hlaða inn skrá af ákveðnu sniði inn í Excel kerfið sem innihélt allar upplýsingar um staðsetninguna (auglýsingaherferð, vettvang, snið, staðsetningartímabil, fyrirhugaða vísbendingar, fjárhagsáætlun o.s.frv.) og auðkenni samsvarandi auglýsingaherferða á síður og teljara í auglýsingakerfum.
Það leit satt að segja skelfilegt út:
Gögnin sem hlaðið var niður voru vistuð í gagnagrunn og síðan safnaði aðskilin þjónusta herferðaauðkenni á vefsvæði frá þeim og sótti tölfræði um þau.
Fyrir hverja síðu var skrifuð sérstök Windows þjónusta, sem einu sinni á dag fór undir einn þjónustureikning í API síðunnar og hlaðið niður tölfræði fyrir tilgreind herferðauðkenni. Það sama gerðist með auglýsingakerfi.
Gögnin sem hlaðið var niður voru sýnd á viðmótinu í formi lítillar sérsniðins mælaborðs:
Óvænt fyrir okkur byrjaði MVP að vinna og byrjaði að hlaða niður núverandi tölfræði um auglýsingaherferðir á Netinu. Við innleiddum kerfið á nokkra viðskiptavini, en þegar reynt var að stækka, lentum við í alvarlegum vandamálum:
- Helsta vandamálið var hversu flókið það var að undirbúa gögn fyrir hleðslu inn í kerfið. Einnig þurfti að breyta staðsetningargögnum í stranglega fast snið fyrir hleðslu. Nauðsynlegt var að hafa einingarauðkenni frá mismunandi síðum í niðurhalsskránni. Við stöndum frammi fyrir þeirri staðreynd að það er mjög erfitt fyrir tæknilega óþjálfaða notendur að útskýra hvar á að finna þessi auðkenni á síðunni og hvar í skránni þarf að slá inn þau. Miðað við fjölda starfsmanna í deildum sem standa fyrir herferðum á lóðum og veltuna, leiddi þetta af sér gífurlegan stuðning okkar megin sem við vorum hreint ekki ánægð með.
- Annað vandamál var að ekki allir auglýsingavettvangar höfðu kerfi til að framselja aðgang að auglýsingaherferðum til annarra reikninga. En jafnvel þótt úthlutunarkerfi væri tiltækt voru ekki allir auglýsendur tilbúnir til að veita reikningum þriðja aðila aðgang að herferðum sínum.
- Mikilvægur þáttur var reiði sem vakti meðal notenda vegna þess að allar fyrirhugaðar vísbendingar og staðsetningarupplýsingar sem þeir þegar setja inn í 1C bókhaldskerfið okkar, verða að fara aftur inn í DANBo.
Þetta gaf okkur þá hugmynd að aðaluppspretta upplýsinga um staðsetningu ætti að vera 1C kerfið okkar, þar sem öll gögn eru færð inn nákvæmlega og á réttum tíma (málið hér er að reikningar eru búnir til byggðir á 1C gögnum, svo rétt innsláttur gagna í 1C er forgangsverkefni allra KPI). Þannig varð til nýtt hugtak um kerfið...
Hugtak
Það fyrsta sem við ákváðum að gera var að aðskilja kerfið til að safna tölfræði um auglýsingaherferðir á netinu í sérstaka vöru - D1.Stafræn.
Í nýju hugmyndinni ákváðum við að hlaða inn D1.Stafræn upplýsingar um auglýsingaherferðir og staðsetningar innan þeirra frá 1C, og draga síðan upp tölfræði frá síðum og AdServing kerfum til þessara staðsetningar. Þetta átti að einfalda verulega lífið fyrir notendur (og, eins og venjulega, bæta meiri vinnu við þróunaraðila) og draga úr stuðningi.
Fyrsta vandamálið sem við lentum í var skipulagslegs eðlis og tengdist því að við gátum ekki fundið lykil eða merki sem við gætum borið saman einingar úr mismunandi kerfum með herferðum og staðsetningum frá 1C. Staðreyndin er sú að ferlið í fyrirtækinu okkar er hannað á þann hátt að auglýsingaherferðir eru settar inn í mismunandi kerfi af mismunandi fólki (fjölmiðlaskipuleggjendur, kaup o.s.frv.).
Til að leysa þetta vandamál þurftum við að finna upp einstakan hashed lykil, DANBoID, sem myndi tengja einingar í mismunandi kerfum saman og sem hægt var að bera kennsl á nokkuð auðveldlega og einstaklega í niðurhaluðum gagnasöfnum. Þetta auðkenni er myndað í innra 1C kerfinu fyrir hverja einstaka staðsetningu og er flutt yfir á herferðir, staðsetningar og teljara á öllum síðum og í öllum AdServing kerfum. Það tók nokkurn tíma að innleiða þá æfingu að setja DANBoID í allar staðsetningar, en okkur tókst það :)
Síðan komumst við að því að ekki eru allar síður með API til að safna tölfræði sjálfkrafa, og jafnvel þær sem eru með API, það skilar ekki öllum nauðsynlegum gögnum.
Á þessu stigi ákváðum við að draga verulega úr listanum yfir samþættingarvettvang og einbeita okkur að helstu kerfum sem taka þátt í langflestum auglýsingaherferðum. Þessi listi inniheldur alla stærstu aðilana á auglýsingamarkaði (Google, Yandex, Mail.ru), samfélagsnetum (VK, Facebook, Twitter), helstu AdServing og greiningarkerfi (DCM, Adriver, Weborama, Google Analytics) og öðrum kerfum.
Meirihluti vefsvæða sem við völdum voru með API sem gaf þær mælikvarða sem við þurftum. Í þeim tilfellum þar sem ekkert API var til eða það innihélt ekki nauðsynleg gögn notuðum við skýrslur sem voru sendar daglega á skrifstofu tölvupóstsins okkar til að hlaða gögnum (í sumum kerfum er hægt að stilla slíkar skýrslur, í öðrum samþykktum við þróun slíkar skýrslur fyrir okkur).
Við greiningu gagna frá mismunandi síðum komumst við að því að stigveldi eininga er ekki það sama í mismunandi kerfum. Þar að auki þarf að hlaða niður upplýsingum í mismunandi smáatriðum frá mismunandi kerfum.
Til að leysa þetta vandamál var SubDANBoID hugtakið þróað. Hugmyndin um SubDANBoID er frekar einföld, við merkjum aðaleiningu herferðarinnar á síðunni með mynduðu DANBoID, og við hleðum upp öllum hreiðri einingar með einstökum síðuauðkennum og myndum SubDANBoID samkvæmt DANBoID meginreglunni + auðkenni á fyrsta stigi hreiður eining + auðkenni annars stigs hreiður eining +... Þessi aðferð gerði okkur kleift að tengja saman auglýsingaherferðir í mismunandi kerfum og hlaða niður ítarlegri tölfræði um þær.
Við þurftum líka að leysa vandamálið varðandi aðgang að herferðum á mismunandi kerfum. Eins og við skrifuðum hér að ofan á aðferðin við að úthluta aðgangi að herferð á sérstakan tæknireikning ekki alltaf við. Þess vegna þurftum við að þróa innviði fyrir sjálfvirka heimild í gegnum OAuth með því að nota tákn og kerfi til að uppfæra þessi tákn.
Síðar í greininni munum við reyna að lýsa nánar arkitektúr lausnarinnar og tæknilegum smáatriðum útfærslunnar.
Lausnararkitektúr 1.0
Þegar við hófum innleiðingu á nýrri vöru skildum við að við þyrftum strax að sjá fyrir möguleika á að tengja nýjar síður, svo við ákváðum að feta slóð örþjónustuarkitektúrs.
Við hönnun arkitektúrsins aðskildum við tengi við öll ytri kerfi - 1C, auglýsingapallur og auglýsingakerfi - í aðskilda þjónustu.
Meginhugmyndin er sú að öll tengi við vefsvæði eru með sama API og eru millistykki sem koma API vefsvæðisins í viðmót sem hentar okkur.
Í miðju vörunnar okkar er vefforrit, sem er einlitur sem er hannaður á þann hátt að auðvelt er að taka hann í sundur í þjónustu. Þetta forrit er ábyrgt fyrir því að vinna niður gögnin, safna saman tölfræði úr mismunandi kerfum og kynna þær fyrir kerfisnotendum.
Til að hafa samskipti milli tengjanna og vefforritsins þurftum við að búa til viðbótarþjónustu sem við kölluðum Connector Proxy. Það sinnir aðgerðum Service Discovery og Task Scheduler. Þessi þjónusta keyrir gagnasöfnunarverkefni fyrir hvert tengi á hverju kvöldi. Að skrifa þjónustulag var auðveldara en að tengja skilaboðamiðlara og fyrir okkur var mikilvægt að fá niðurstöðuna eins fljótt og auðið var.
Fyrir einfaldleika og hraða þróunar ákváðum við einnig að öll þjónusta verði vef-API. Þetta gerði það mögulegt að setja saman proof-of-concept á fljótlegan hátt og sannreyna að öll hönnunin virki.
Sérstakt, frekar flókið verkefni var að setja upp aðgang til að safna gögnum frá mismunandi reikningum, sem, eins og við ákváðum, ættu notendur að framkvæma í gegnum vefviðmótið. Það samanstendur af tveimur aðskildum skrefum: í fyrsta lagi bætir notandinn við tákni til að fá aðgang að reikningnum í gegnum OAuth og stillir síðan gagnasöfnun fyrir viðskiptavininn frá tilteknum reikningi. Að fá auðkenni í gegnum OAuth er nauðsynlegt vegna þess að eins og við höfum þegar skrifað er ekki alltaf hægt að úthluta aðgangi að viðkomandi reikningi á síðunni.
Til að búa til alhliða kerfi til að velja reikning af síðum, þurftum við að bæta aðferð við tengiforritaskilin sem skilar JSON Schema, sem er gert á form með breyttum JSONEditor íhlut. Þannig gátu notendur valið reikningana sem þeir hlaða niður gögnum af.
Til að fara að beiðnitakmörkunum sem eru til staðar á vefsvæðum sameinum við beiðnir um stillingar innan eins tákns, en við getum afgreitt mismunandi tákn samhliða.
Við völdum MongoDB sem geymslu fyrir hlaðin gögn fyrir bæði vefforritið og tengi, sem gerði okkur kleift að hafa ekki of miklar áhyggjur af gagnaskipulaginu á fyrstu stigum þróunar, þegar hlutlíkan forritsins breytist annan hvern dag.
Við komumst fljótlega að því að ekki passa öll gögn vel í MongoDB og til dæmis er þægilegra að geyma daglega tölfræði í venslagagnagrunni. Þess vegna byrjuðum við að nota PostgreSQL eða MS SQL Server sem geymslu fyrir tengi sem henta betur fyrir tengigagnagrunn.
Valin arkitektúr og tækni gerði okkur kleift að smíða og setja D1.Digital vöruna á markað tiltölulega hratt. Á tveggja ára vöruþróun þróuðum við 23 tengi við síður, öðluðumst ómetanlega reynslu af því að vinna með API frá þriðja aðila, lærðum að forðast gildrur mismunandi vefsvæða, sem hver áttu sína, stuðlað að þróun API upp á að minnsta kosti 3 síður, sóttu sjálfkrafa upplýsingar um tæplega 15 herferðir og fyrir meira en 000 staðsetningar, safnaði miklum viðbrögðum frá notendum um rekstur vörunnar og tókst að breyta aðalferli vörunnar nokkrum sinnum, byggt á þessari endurgjöf.
Lausnararkitektúr 2.0
Tvö ár eru liðin frá upphafi þróunar D1.Stafræn. Stöðugt aukið álag á kerfið og tilkoma fleiri og fleiri nýrra gagnagjafa leiddi smám saman í ljós vandamál í núverandi lausnararkitektúr.
Fyrsta vandamálið er tengt magni gagna sem hlaðið er niður af síðunum. Við stóðum frammi fyrir þeirri staðreynd að söfnun og uppfærsla allra nauðsynlegra gagna frá stærstu síðunum fór að taka of langan tíma. Til dæmis tekur um 12 klukkustundir að safna gögnum úr AdRiver auglýsingakerfinu, sem við fylgjumst með tölfræði fyrir flestar staðsetningar.
Til að leysa þetta vandamál byrjuðum við að nota alls kyns skýrslur til að hlaða niður gögnum af síðum, við erum að reyna að þróa API þeirra ásamt vefsvæðum þannig að hraðinn á rekstri þess uppfylli þarfir okkar og samhliða niðurhali gagna eins mikið og mögulegt er.
Annað vandamál tengist vinnslu niðurhalaðra gagna. Nú, þegar ný staðsetningartölfræði berast, er sett í gang fjölþrepa ferli til að endurreikna mælikvarða, sem felur í sér að hlaða hráum gögnum, reikna samansöfnuð mæligildi fyrir hverja síðu, bera saman gögn frá mismunandi aðilum sín á milli og reikna samantektartölur fyrir herferðina. Þetta veldur miklu álagi á vefforritið sem gerir alla útreikninga. Nokkrum sinnum, í endurútreikningsferlinu, neytti forritið allt minni á þjóninum, um 10-15 GB, sem hafði mest skaðleg áhrif á vinnu notenda við kerfið.
Tilgreind vandamál og metnaðarfullar áætlanir um frekari þróun vörunnar leiddu til þess að við þurftum að endurskoða umsóknararkitektúrinn.
Við byrjuðum á tengjum.
Við tókum eftir því að öll tengin virka eftir sama líkani, þannig að við smíðuðum leiðsluramma þar sem til að búa til tengi þurfti aðeins að forrita rökfræði skrefanna, restin var alhliða. Ef einhver tengi þarfnast endurbóta þá flytjum við það strax yfir í nýja ramma á sama tíma og verið er að bæta tengið.
Á sama tíma byrjuðum við að dreifa tengjum til Docker og Kubernetes.
Við ætluðum að flytja til Kubernetes í nokkuð langan tíma, gerðum tilraunir með CI/CD stillingar, en byrjuðum að hreyfa okkur aðeins þegar eitt tengi, vegna villu, byrjaði að éta upp meira en 20 GB af minni á þjóninum, nánast drepa aðra ferla . Meðan á rannsókninni stóð var tengið flutt í Kubernetes þyrping, þar sem það var að lokum áfram, jafnvel eftir að villan var lagfærð.
Nokkuð fljótt áttuðum við okkur á því að Kubernetes var þægilegt og innan sex mánaða fluttum við 7 tengi og Connectors Proxy, sem eyða mestu fjármagni, yfir í framleiðsluklasann.
Í kjölfar tengjanna ákváðum við að breyta arkitektúr restarinnar af forritinu.
Helsta vandamálið var að gögn koma frá tengjum til umboða í stórum lotum, og smella síðan á DANBoID og eru send í miðlæga vefforritið til vinnslu. Vegna mikils fjölda endurútreikninga mæligilda er mikið álag á forritið.
Einnig reyndist nokkuð erfitt að fylgjast með stöðu einstakra gagnasöfnunarstarfa og tilkynna um villur sem komu upp í tengjum við miðlægt vefforrit svo notendur gætu séð hvað var að gerast og hvers vegna ekki var verið að safna gögnum.
Til að leysa þessi vandamál þróuðum við arkitektúr 2.0.
Helsti munurinn á nýju útgáfunni af arkitektúrnum er að í stað vef API notum við RabbitMQ og MassTransit bókasafnið til að skiptast á skilaboðum á milli þjónustu. Til að gera þetta þurftum við að umskrifa Connectors Proxy næstum alveg og gera það Connectors Hub. Nafninu var breytt vegna þess að meginhlutverk þjónustunnar er ekki lengur í að framsenda beiðnir til tengjum og til baka, heldur að halda utan um söfnun mæligilda frá tengjum.
Frá miðlæga vefforritinu aðskildum við upplýsingar um staðsetningar og tölfræði frá síðum í sérstakar þjónustur, sem gerði það mögulegt að losna við óþarfa endurútreikninga og geyma aðeins þegar reiknaða og uppsafnaða tölfræði á staðsetningarstigi. Við endurskrifuðum líka og fínstilltum rökfræðina til að reikna út grunntölfræði byggða á hráum gögnum.
Á sama tíma erum við að flytja alla þjónustu og forrit til Docker og Kubernetes til að gera lausnina auðveldari í stærðargráðu og þægilegri í umsjón.
Hvar erum við núna
Proof-of-concept arkitektúr 2.0 vara D1.Stafræn tilbúið og unnið í prófunarumhverfi með takmörkuðu setti af tengjum. Allt sem er eftir að gera er að endurskrifa önnur 20 tengi á nýjan vettvang, prófa að gögnin séu rétt hlaðin og allar mælingar séu rétt reiknaðar og rúlla út alla hönnunina í framleiðslu.
Reyndar mun þetta ferli gerast smám saman og við verðum að skilja eftir afturábak eindrægni við gömul API til að halda öllu í gangi.
Strax áætlanir okkar fela í sér þróun á nýjum tengjum, samþættingu við ný kerfi og að bæta við viðbótarmælingum við safn gagna sem hlaðið er niður af tengdum síðum og auglýsingakerfum.
Við ætlum líka að flytja öll forrit, þar á meðal miðlæga vefforritið, til Docker og Kubernetes. Ásamt nýjum arkitektúr mun þetta einfalda verulega dreifingu, eftirlit og eftirlit með neyttum auðlindum.
Önnur hugmynd er að gera tilraunir með val á gagnagrunni til að geyma tölfræði, sem er nú geymdur í MongoDB. Við höfum þegar flutt nokkur ný tengi yfir í SQL gagnagrunna, en þar er munurinn nánast ómerkjanlegur og fyrir uppsafnaða tölfræði eftir degi, sem hægt er að biðja um í tiltekinn tíma, getur ávinningurinn verið nokkuð alvarlegur.
Almennt séð eru áformin stórkostleg, við skulum halda áfram :)
Höfundar greinarinnar R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Mikhail Kotsik ()
Heimild: www.habr.com