Како смо прикупљали податке о рекламним кампањама са онлајн сајтова (трновит пут до производа)

Чини се да област онлајн оглашавања треба да буде што је могуће више технолошки напреднија и аутоматизована. Наравно, јер тамо раде такви гиганти и стручњаци у својој области као што су Иандек, Маил.Ру, Гоогле и Фацебоок. Али, како се испоставило, не постоји граница савршенству и увек постоји нешто за аутоматизацију.

Извор

Група за комуникације Дентсу Аегис Нетворк Руссиа је највећи играч на тржишту дигиталног оглашавања и активно улаже у технологију, покушавајући да оптимизује и аутоматизује своје пословне процесе. Један од нерешених проблема тржишта онлајн оглашавања постао је задатак прикупљања статистичких података о рекламним кампањама са различитих интернет платформи. Решење овог проблема је на крају резултирало стварањем производа Д1.Дигитал (читај као ДиВан), о чијем развоју желимо да причамо.

Зашто?

1. У време почетка пројекта на тржишту није постојао ниједан готов производ који је решио проблем аутоматизације прикупљања статистике о рекламним кампањама. То значи да нико осим нас самих неће задовољити наше потребе.

Услуге као што су Импровадо, Роистат, Суперметрицс, СегментСтреам нуде интеграцију са платформама, друштвеним мрежама и Гоогле Аналитицс, а такође омогућавају прављење аналитичких контролних табли за практичну анализу и контролу рекламних кампања. Пре него што смо почели да развијамо наш производ, покушали смо да користимо неке од ових система за прикупљање података са сајтова, али, нажалост, нису могли да реше наше проблеме.

Главни проблем је био у томе што су се тестирани производи ослањали на изворе података, приказујући статистику пласмана по сајтовима, и нису пружали могућност агрегирања статистике о рекламним кампањама. Овакав приступ нам није омогућио да на једном месту видимо статистику са различитих сајтова и анализирамо стање кампање у целини.

Други фактор је био то што су у почетним фазама производи били усмерени на западно тржиште и нису подржавали интеграцију са руским сајтовима. А за оне сајтове са којима је имплементирана интеграција, све потребне метрике нису увек биле преузете довољно детаљно, а интеграција није увек била згодна и транспарентна, посебно када је било потребно набавити нешто што није у интерфејсу система.
Генерално, одлучили смо да се не прилагођавамо производима трећих страна, већ смо почели да развијамо сопствене...

2. Тржиште оглашавања на мрежи расте из године у годину и у 2018. години је по буџетима за оглашавање претекло традиционално највеће тржиште ТВ оглашавања. Дакле, постоји скала.

3. За разлику од тржишта ТВ оглашавања, где је продаја комерцијалног оглашавања монополизована, постоји велики број појединачних власника рекламног инвентара различитих величина који послују на Интернету са сопственим рекламним налозима. Пошто се рекламна кампања, по правилу, одвија на више сајтова одједном, да би се разумело стање рекламне кампање, потребно је сакупити извештаје са свих сајтова и комбиновати их у један велики извештај који ће показати целу слику. То значи да постоји потенцијал за оптимизацију.

4. Чинило нам се да власници рекламног инвентара на Интернету већ имају инфраструктуру за прикупљање статистике и њихово приказивање у рекламним налозима и да ће моћи да обезбеде АПИ за ове податке. То значи да је то технички могуће спровести. Рецимо одмах да се показало да није тако једноставно.

Генерално, сви предуслови за реализацију пројекта су нам били очигледни и ми смо трчали да пројекат оживимо...

Велики план

За почетак смо формирали визију идеалног система:

• У њега треба аутоматски учитавати рекламне кампање из корпоративног система 1Ц са њиховим називима, периодима, буџетима и пласманима на различитим платформама.
• За свако пласман у оквиру рекламне кампање, сву могућу статистику треба аутоматски преузети са сајтова на којима се пласман одвија, као што је број приказа, кликова, прегледа итд.
• Неке рекламне кампање се прате коришћењем надгледања треће стране од стране такозваних система за оглашавање као што су Адривер, Веборама, ДЦМ, итд. У Русији постоји и индустријски интернет мерач - компанија Медиасцопе. Према нашем плану, подаци из независног и индустријског мониторинга такође би требало да се аутоматски учитавају у одговарајуће рекламне кампање.
• Већина рекламних кампања на Интернету је усмерена на одређене циљне радње (куповина, позив, пријава за пробну вожњу, итд.), које се прате помоћу Гоогле аналитике, а статистика за које је такође важна за разумевање статуса кампање и треба учитати у наш алат.

Прва палачинка је груписана

Имајући у виду нашу посвећеност флексибилним принципима развоја софтвера (агилан, све), одлучили смо да прво развијемо МВП, а затим да се итеративно крећемо ка намераваном циљу.
Одлучили смо да направимо МВП на основу нашег производа ДАНБо (Дентсу Аегис Нетворк Боард), што је веб апликација са општим информацијама о рекламним кампањама наших клијената.

За МВП пројекат је максимално поједностављен у смислу имплементације. Одабрали смо ограничену листу платформи за интеграцију. То су биле главне платформе, као што су Иандек.Дирецт, Иандек.Дисплаи, РБ.Маил, МиТаргет, Адвордс, ДБМ, ВК, ФБ и главни системи за оглашавање Адривер и Веборама.

Да бисмо приступили статистици сајтова преко АПИ-ја, користили смо један налог. Менаџер групе клијената који је желео да користи аутоматско прикупљање статистике о рекламној кампањи морао је прво да делегира приступ неопходним рекламним кампањама на сајтовима на налог платформе.

Следећи је корисник система ДАНБо морали да у Екцел систем учитају фајл одређеног формата који је садржао све информације о пласману (рекламна кампања, платформа, формат, период пласмана, планирани показатељи, буџет итд.) и идентификатори одговарајућих рекламних кампања на сајтова и шалтера у системима за оглашавање.

Искрено, изгледало је застрашујуће:

Преузети подаци су сачувани у бази података, а затим су одвојени сервиси са њих прикупљали идентификаторе кампања на сајтовима и преузимали статистику о њима.

За сваки сајт је написан посебан Виндовс сервис, који је једном дневно пролазио под једним налогом услуге у АПИ-ју сајта и преузимао статистику за одређене ИД-ове кампања. Иста ствар се десила и са системима за оглашавање.

Преузети подаци су приказани на интерфејсу у облику мале прилагођене контролне табле:

Неочекивано за нас, МВП је почео са радом и почео да преузима актуелну статистику о рекламним кампањама на Интернету. Систем смо имплементирали на неколико клијената, али приликом покушаја скалирања наишли смо на озбиљне проблеме:

• Главни проблем је била сложеност припреме података за учитавање у систем. Такође, подаци о пласману су морали да се конвертују у строго фиксни формат пре учитавања. Било је неопходно укључити идентификаторе ентитета са различитих сајтова у датотеку за преузимање. Суочени смо са чињеницом да је технички необученим корисницима веома тешко да објасне где да пронађу ове идентификаторе на сајту и где у фајлу их треба унети. С обзиром на број запослених у одељењима која воде кампање на сајтовима и промет, то је резултирало огромном подршком на нашој страни, чиме апсолутно нисмо били задовољни.
• Други проблем је био што нису све платформе за оглашавање имале механизме за делегирање приступа рекламним кампањама на друге налоге. Али чак и да је механизам делегирања био доступан, нису сви оглашивачи били вољни да дају приступ својим кампањама налозима трећих страна.
• Важан фактор је било огорчење које је изазвало кориснике чињеницом да све планиране индикаторе и детаље пласмана које већ уносе у наш 1Ц рачуноводствени систем морају поново да унесу у ДАНБо.

То нам је дало идеју да примарни извор информација о пласману треба да буде наш 1Ц систем, у који се сви подаци уносе тачно и на време (овде се ради о томе да се фактуре генеришу на основу података 1Ц, тако да исправан унос података у 1Ц је приоритет за све КПИ). Тако је настао нови концепт система...

Цонцепт

Прво што смо одлучили да урадимо је да одвојимо систем за прикупљање статистике о рекламним кампањама на Интернету у посебан производ - Д1.Дигитал.

У новом концепту, одлучили смо да учитамо Д1.Дигитал информације о рекламним кампањама и пласманима у њима из 1Ц, а затим извући статистику са сајтова и система АдСервинг до ових одредишта за пласман. Ово је требало да значајно поједностави живот корисницима (и, као и обично, дода више посла програмерима) и смањи количину подршке.

Први проблем на који смо наишли био је организационе природе и односио се на чињеницу да нисмо могли да пронађемо кључ или знак по коме бисмо могли да упоредимо ентитете из различитих система са кампањама и пласманима из 1Ц. Чињеница је да је процес у нашој компанији тако осмишљен да рекламне кампање уносе различити људи у различите системе (медијски планери, куповина итд.).

Да бисмо решили овај проблем, морали смо да измислимо јединствени хеширани кључ, ДАНБоИД, који би повезао ентитете у различитим системима заједно, и који би се могао прилично лако и јединствено идентификовати у преузетим скуповима података. Овај идентификатор се генерише у интерном 1Ц систему за свако појединачно одредиште за пласман и преноси се на кампање, одредишта за пласман и бројаче на свим сајтовима иу свим системима за приказивање огласа. Имплементација праксе стављања ДАНБоИД-а на све пласмане је потрајала, али смо успели :)

Тада смо сазнали да немају сви сајтови АПИ за аутоматско прикупљање статистике, а чак и они који имају АПИ не враћају све потребне податке.

У овој фази смо одлучили да значајно смањимо листу платформи за интеграцију и фокусирамо се на главне платформе које су укључене у огромну већину рекламних кампања. Ова листа укључује све највеће играче на тржишту оглашавања (Гоогле, Иандек, Маил.ру), друштвеним мрежама (ВК, Фацебоок, Твиттер), главним АдСервинг и аналитичким системима (ДЦМ, Адривер, Веборама, Гоогле Аналитицс) и другим платформама.

Већина сајтова које смо одабрали имали су АПИ који је пружао метрику која нам је потребна. У случајевима када није постојао АПИ или није садржао потребне податке, користили смо извештаје који су нам свакодневно слали на канцеларијски мејл за учитавање података (у неким системима је могуће конфигурисати такве извештаје, у другима смо се договорили о изради такви извештаји за нас).

Анализирајући податке са различитих сајтова, открили смо да хијерархија ентитета није иста у различитим системима. Штавише, информације се морају преузимати са различитим детаљима из различитих система.

Да би се решио овај проблем, развијен је концепт СубДАНБоИД. Идеја СубДАНБоИД-а је прилично једноставна, на сајту означавамо главни ентитет кампање са генерисаним ДАНБоИД-ом, а све угнежђене ентитете учитавамо са јединственим идентификаторима сајта и формирамо СубДАНБоИД по ДАНБоИД принципу + идентификатор првог нивоа угнежђени ентитет + идентификатор угнежђеног ентитета другог нивоа +... Овај приступ нам је омогућио да повежемо рекламне кампање у различитим системима и преузмемо детаљну статистику о њима.

Такође смо морали да решимо проблем приступа кампањама на различитим платформама. Као што смо горе написали, механизам делегирања приступа кампањи на посебан технички налог није увек применљив. Због тога смо морали да развијемо инфраструктуру за аутоматску ауторизацију преко ОАутх-а користећи токене и механизме за ажурирање ових токена.

Касније у чланку покушаћемо да детаљније опишемо архитектуру решења и техничке детаље имплементације.

Архитектура решења 1.0

Када смо кренули са имплементацијом новог производа, схватили смо да одмах треба да обезбедимо могућност повезивања нових сајтова, па смо одлучили да идемо путем микросервисне архитектуре.

Приликом пројектовања архитектуре, раздвојили смо конекторе за све екстерне системе - 1Ц, рекламне платформе и системе за оглашавање - у посебне сервисе.
Главна идеја је да сви конектори за сајтове имају исти АПИ и да су адаптери који доводе АПИ сајта до интерфејса који нам одговара.

У средишту нашег производа је веб апликација, која је монолит који је дизајниран тако да се лако може раставити на сервисе. Ова апликација је одговорна за обраду преузетих података, сређивање статистике из различитих система и њихово представљање корисницима система.

Да бисмо комуницирали између конектора и веб апликације, морали смо да креирамо додатну услугу, коју смо назвали Цоннецтор Проки. Обавља функције откривања услуга и планера задатака. Ова услуга извршава задатке прикупљања података за сваки конектор сваке ноћи. Писање слоја услуге било је лакше него повезивање посредника порука, а за нас је било важно да добијемо резултат што је брже могуће.

Ради једноставности и брзине развоја, такође смо одлучили да сви сервиси буду Веб АПИ-ји. Ово је омогућило да се брзо састави доказ концепта и да се провери да ли цео дизајн функционише.

Посебан, прилично сложен задатак било је подешавање приступа за прикупљање података са различитих налога, које, како смо одлучили, корисници треба да спроводе преко веб интерфејса. Састоји се од два одвојена корака: прво, корисник додаје токен за приступ налогу преко ОАутх-а, а затим конфигурише прикупљање података за клијента са одређеног налога. Добијање токена преко ОАутх-а је неопходно јер, као што смо већ писали, није увек могуће делегирати приступ жељеном налогу на сајту.

Да бисмо креирали универзални механизам за избор налога са сајтова, морали смо да додамо метод у АПИ конектора који враћа ЈСОН шему, која се приказује у форму помоћу модификоване компоненте ЈСОНЕдитор. На овај начин, корисници су могли да изаберу налоге са којих ће преузимати податке.

Да бисмо били у складу са ограничењима захтева која постоје на сајтовима, комбинујемо захтеве за подешавања унутар једног токена, али можемо паралелно да обрађујемо различите токене.

Одабрали смо МонгоДБ као складиште за учитане податке и за веб апликацију и за конекторе, што нам је омогућило да не бринемо превише о структури података у почетним фазама развоја, када се објектни модел апликације мења сваки други дан.

Убрзо смо открили да се сви подаци не уклапају добро у МонгоДБ и да је, на пример, згодније чувати дневну статистику у релационој бази података. Стога смо за конекторе чија је структура података погоднија за релациону базу података, почели да користимо ПостгреСКЛ или МС СКЛ Сервер као складиште.

Изабрана архитектура и технологије су нам омогућиле да направимо и лансирамо Д1.Дигитал производ релативно брзо. Током две године развоја производа, развили смо 23 конектора за сајтове, стекли непроцењиво искуство у раду са АПИ-јима трећих страна, научили да избегавамо замке различитих сајтова, од којих је сваки имао своје, допринели развоју АПИ-ја од најмање 3 сајтови, аутоматски преузели информације о скоро 15 кампања и за више од 000 пласмана, прикупили су доста повратних информација од корисника о раду производа и успели да промене главни процес производа неколико пута, на основу ових повратних информација.

Архитектура решења 2.0

Прошле су две године од почетка развоја Д1.Дигитал. Стално повећање оптерећења система и појава све више и више нових извора података постепено су откривали проблеме у постојећој архитектури решења.

Први проблем је везан за количину података преузетих са сајтова. Суочили смо се са чињеницом да је прикупљање и ажурирање свих потребних података са највећих сајтова почело да одузима превише времена. На пример, прикупљање података из АдРивер система за оглашавање, помоћу којег пратимо статистику за већину пласмана, траје око 12 сати.

Да бисмо решили овај проблем, почели смо да користимо све врсте извештаја за преузимање података са сајтова, трудимо се да заједно са сајтовима развијемо њихов АПИ како би брзина његовог рада одговарала нашим потребама, и што више паралелизирали преузимање података.

Други проблем се односи на обраду преузетих података. Сада, када стигне нова статистика пласмана, покреће се вишестепени процес поновног израчунавања метрике, који укључује учитавање необрађених података, израчунавање збирних показатеља за сваки сајт, међусобно поређење података из различитих извора и израчунавање збирних метрика за кампању. Ово узрокује велико оптерећење на веб апликацији која врши све прорачуне. Неколико пута, током процеса поновног израчунавања, апликација је потрошила сву меморију на серверу, око 10-15 ГБ, што је најштетније утицало на рад корисника са системом.

Идентификовани проблеми и амбициозни планови за даљи развој производа довели су нас до потребе да преиспитамо архитектуру апликације.

Почели смо са конекторима.
Приметили смо да сви конектори раде по истом моделу, па смо направили оквир за цевовод у коме је за креирање конектора требало само да програмирате логику корака, остало је било универзално. Ако неки конектор захтева побољшање, онда га одмах преносимо у нови оквир у исто време када се конектор побољшава.

У исто време, почели смо да примењујемо конекторе на Доцкер и Кубернетес.
Планирали смо прелазак на Кубернетес доста дуго, експериментисали са ЦИ/ЦД подешавањима, али смо кренули тек када је један конектор, због грешке, почео да једе више од 20 ГБ меморије на серверу, практично убијајући друге процесе . Током истраге, конектор је премештен у Кубернетес кластер, где је на крају остао, чак и након што је грешка исправљена.

Врло брзо смо схватили да је Кубернетес згодан и у року од шест месеци пренели смо 7 конектора и Цоннецторс Проки, који троше највише ресурса, у производни кластер.

Пратећи конекторе, одлучили смо да променимо архитектуру остатка апликације.
Главни проблем је био што подаци долазе од конектора до проксија у великим серијама, а затим погађају ДАНБоИД и шаљу се у централну веб апликацију на обраду. Због великог броја прерачунавања метрика, постоји велико оптерећење апликације.

Такође се показало прилично тешким пратити статус појединачних послова прикупљања података и пријавити грешке које се јављају унутар конектора централној веб апликацији како би корисници могли да виде шта се дешава и зашто се подаци не прикупљају.

Да бисмо решили ове проблеме, развили смо архитектуру 2.0.

Главна разлика између нове верзије архитектуре је у томе што уместо Веб АПИ-ја користимо РаббитМК и библиотеку МассТрансит за размену порука између сервиса. Да бисмо то урадили, морали смо да скоро потпуно препишемо Цоннецторс Проки, чинећи га Цоннецторс Хуб-ом. Назив је промењен јер главна улога сервиса више није у прослеђивању захтева ка конекторима и назад, већ у управљању прикупљањем метрика са конектора.

Из централне веб апликације смо одвојили информације о пласманима и статистику са сајтова у посебне сервисе, што је омогућило да се ослободимо непотребних прерачунавања и чувамо само већ израчунату и агрегирану статистику на нивоу пласмана. Такође смо поново написали и оптимизовали логику за израчунавање основне статистике на основу сирових података.

У исто време, мигрирамо све услуге и апликације на Доцкер и Кубернетес како бисмо решење учинили лакшим за скалирање и практичнијим за управљање.

Где смо сада

Прооф-оф-цонцепт архитектура 2.0 производ Д1.Дигитал спреман и ради у тестном окружењу са ограниченим скупом конектора. Све што је преостало је да препишете још 20 конектора на нову платформу, тестирате да ли су подаци исправно учитани и да су све метрике исправно израчунате и да се цео дизајн уведе у производњу.

У ствари, овај процес ће се одвијати постепено и мораћемо да оставимо компатибилност уназад са старим АПИ-јима да би све функционисало.

Наши непосредни планови укључују развој нових конектора, интеграцију са новим системима и додавање додатних метрика у скуп података преузетих са повезаних сајтова и система за оглашавање.

Такође планирамо да пренесемо све апликације, укључујући централну веб апликацију, на Доцкер и Кубернетес. У комбинацији са новом архитектуром, ово ће значајно поједноставити примену, праћење и контролу утрошених ресурса.

Друга идеја је експериментисање са избором базе података за чување статистике, која се тренутно чува у МонгоДБ. Већ смо пренели неколико нових конектора у СКЛ базе података, али ту је разлика готово неприметна, а за збирну статистику по дану, која се може захтевати за произвољан период, добитак може бити прилично озбиљан.

Генерално, планови су грандиозни, идемо даље :)

Аутори чланка Р&Д Дентсу Аегис Нетворк Руссиа: Георгиј Остапенко (схмиигаа), Михаил Коцик (хитекк)

Извор: ввв.хабр.цом