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

Се чини дека полето на онлајн рекламирањето треба да биде што е можно потехнолошки напредно и автоматизирано. Се разбира, затоа што таму работат такви гиганти и експерти во својата област како Yandex, Mail.Ru, Google и Facebook. Но, како што се испостави, нема ограничување до совршенството и секогаш има нешто да се автоматизира.

Извор

Група за комуникации Мрежа Dentsu Aegis Русија е најголемиот играч на пазарот за дигитално рекламирање и активно инвестира во технологијата, обидувајќи се да ги оптимизира и автоматизира своите деловни процеси. Еден од нерешените проблеми на пазарот на онлајн рекламирање е задачата да се собираат статистики за рекламните кампањи од различни интернет платформи. Решението на овој проблем на крајот резултираше со создавање на производ Д1.Дигитален (читај како DiVan), за чиј развој сакаме да зборуваме.

Зошто?

1. Во моментот на почетокот на проектот, на пазарот немаше ниту еден готов производ што го реши проблемот со автоматизирање на собирањето статистика за рекламните кампањи. Тоа значи дека никој освен нас самите нема да ги задоволи нашите потреби.

Услугите како Improvado, Roistat, Supermetrics, SegmentStream нудат интеграција со платформи, социјални мрежи и Google Anaalitycs, а исто така овозможуваат изградба на аналитички контролни табли за удобна анализа и контрола на рекламните кампањи. Пред да започнеме да го развиваме нашиот производ, се обидовме да користиме некои од овие системи за собирање податоци од сајтови, но, за жал, тие не можеа да ги решат нашите проблеми.

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

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

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

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

4. Ни се чинеше дека сопствениците на рекламниот инвентар на Интернет веќе имаат инфраструктура за собирање статистика и нивно прикажување во рекламните сметки и ќе можат да обезбедат API за овие податоци. Тоа значи дека технички е можно да се имплементира. Веднаш да кажеме дека се покажа дека не е толку едноставно.

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

Голем план

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

• Рекламните кампањи од корпоративниот систем 1C треба автоматски да се вчитаат во него со нивните имиња, периоди, буџети и пласмани на различни платформи.
• За секое пласирање во рамките на рекламната кампања, сите можни статистички податоци треба автоматски да се преземат од сајтовите каде што се одвива поставувањето, како што се бројот на импресии, кликови, прегледи итн.
• Некои рекламни кампањи се следат со користење на мониторинг од трета страна од таканаречените системи за рекламирање како што се Adriver, Weborama, DCM итн. Во Русија има и индустриски интернет метар - компанијата Mediascope. Според нашиот план, податоците од независен и индустриски мониторинг исто така треба автоматски да се вчитаат во соодветните рекламни кампањи.
• Повеќето рекламни кампањи на Интернет се насочени кон одредени целни дејства (купување, повик, регистрирање на тест возење итн.), кои се следат со помош на Google Analytics и статистика за кои се исто така важни за разбирање на статусот на кампањата и треба да се вчита во нашата алатка.

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

Имајќи ја предвид нашата посветеност на флексибилните принципи за развој на софтвер (агилен, сите нешта), решивме прво да развиеме MVP, а потоа да се движиме кон зацртаната цел итеративно.
Решивме да изградиме MVP врз основа на нашиот производ DANBo (Мрежен одбор на Dentsu Aegis), која е веб-апликација со општи информации за рекламните кампањи на нашите клиенти.

За МВП, проектот беше максимално поедноставен во смисла на реализација. Избравме ограничен список на платформи за интеграција. Тоа беа главните платформи, како што се Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB и главните системи за рекламирање Adriver и Weborama.

За да пристапиме до статистиката на сајтовите преку API, користевме една сметка. Менаџерот на група на клиенти кој сакаше да користи автоматско собирање на статистика за рекламна кампања мораше прво да делегира пристап до потребните рекламни кампањи на сајтовите на сметката на платформата.

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

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

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

За секоја локација, беше напишана посебна услуга за Windows, која еднаш дневно влегуваше под една сметка на услугата во API на страницата и ја преземаше статистиката за наведените ИД на кампањи. Истото се случи и со системите за рекламирање.

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

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

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

Ова ни даде идеја дека примарен извор на информации за пласманот треба да биде нашиот систем 1C, во кој сите податоци се внесуваат точно и навреме (поентата овде е дека фактурите се генерираат врз основа на податоците од 1C, така што правилно внесување на податоците во 1C е приоритет за сите KPI). Вака се појави нов концепт на системот...

Концепт

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

Во новиот концепт, решивме да се вчитаме во Д1.Дигитален информации за рекламни кампањи и пласмани во нив од 1C, а потоа извлечете статистика од сајтови и системите за адвертајзинг на овие места. Ова требаше значително да го поедностави животот на корисниците (и, како и обично, да додаде повеќе работа на програмерите) и да ја намали количината на поддршка.

Првиот проблем на кој наидовме беше од организациски карактер и беше поврзан со тоа што не можевме да најдеме клуч или знак со кој би можеле да споредиме ентитети од различни системи со кампањи и пласмани од 1C. Факт е дека процесот во нашата компанија е дизајниран на таков начин што рекламните кампањи се внесуваат во различни системи од различни луѓе (медиумски планери, купување итн.).

За да го решиме овој проблем, моравме да измислиме уникатен хаширан клуч, DANBoID, кој ќе ги поврзе ентитетите во различни системи заедно, и кој може прилично лесно и уникатно да се идентификува во преземените збирки на податоци. Овој идентификатор се генерира во внатрешниот систем 1C за секое поединечно поставување и се пренесува на кампањи, пласмани и бројачи на сите страници и во сите системи за сервирање реклами. Спроведувањето на практиката за ставање на DANBoID на сите пласмани траеше извесно време, но успеавме да го направиме тоа :)

Потоа дознавме дека не сите сајтови имаат API за автоматско собирање статистика, а дури и оние што имаат API, тој не ги враќа сите потребни податоци.

Во оваа фаза, решивме значително да ја намалиме листата на платформи за интеграција и да се фокусираме на главните платформи кои се вклучени во огромното мнозинство на рекламни кампањи. Оваа листа ги вклучува сите најголеми играчи на пазарот за рекламирање (Google, Yandex, Mail.ru), социјалните мрежи (VK, Facebook, Twitter), главните системи за адвертајзинг и аналитика (DCM, Adriver, Weborama, Google Analytics) и други платформи.

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

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

За да се реши овој проблем, беше развиен концептот SubDANBoID. Идејата за SubDANBoID е прилично едноставна, го означуваме главниот ентитет на кампањата на страницата со генерираниот DANBoID и ги поставуваме сите вгнездени ентитети со единствени идентификатори на сајтот и формираме SubDANBoID според принципот DANBoID + идентификатор од првото ниво вгнезден ентитет + идентификатор на вгнезден ентитет од второ ниво +... Овој пристап ни овозможи да поврземе рекламни кампањи во различни системи и да преземаме детални статистички податоци за нив.

Моравме да го решиме и проблемот со пристап до кампањи на различни платформи. Како што напишавме погоре, механизмот за делегирање на пристап до кампања на посебна техничка сметка не е секогаш применлив. Затоа, моравме да развиеме инфраструктура за автоматско овластување преку OAuth користејќи токени и механизми за ажурирање на овие токени.

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

Архитектура на решенија 1.0

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

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

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

За да комуницираме помеѓу конекторите и веб апликацијата, моравме да создадеме дополнителна услуга, која ја нарековме Connector Proxy. Ги извршува функциите на Service Discovery и Task Scheduler. Оваа услуга извршува задачи за собирање податоци за секој конектор секоја вечер. Пишувањето слој на услуги беше полесно отколку поврзувањето на брокер за пораки, а за нас беше важно да го добиеме резултатот што е можно побрзо.

Заради едноставност и брзина на развој, решивме и сите услуги да бидат Web API. Ова овозможи брзо да се состави доказ за концепт и да се потврди дека целиот дизајн функционира.

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

За да создадеме универзален механизам за избор на сметка од сајтови, моравме да додадеме метод на API на конекторите што ја враќа шемата JSON, која се прикажува во форма со помош на изменета компонента JSONEditor. На овој начин, корисниците можеа да ги изберат сметките од кои ќе преземаат податоци.

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

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

Наскоро дознавме дека не сите податоци се вклопуваат добро во MongoDB и, на пример, попогодно е да се складираат дневните статистики во релациска база на податоци. Затоа, за конектори чија структура на податоци е посоодветна за релациона база на податоци, почнавме да користиме PostgreSQL или MS SQL Server како складирање.

Избраната архитектура и технологии ни овозможија релативно брзо да го изградиме и лансираме производот D1.Digital. Во текот на две години развој на производи, развивме 23 конектори за сајтови, стекнавме непроценливо искуство работејќи со API-и од трети страни, научивме да ги избегнуваме замките на различни локации, кои секоја од нив имаше свои, придонесе за развој на API од најмалку 3 сајтови, автоматски преземени информации за речиси 15 кампањи и за повеќе од 000 места, собраа многу повратни информации од корисниците за работата на производот и успеаја да го променат главниот процес на производот неколку пати, врз основа на овие повратни информации.

Архитектура на решенија 2.0

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

Првиот проблем е поврзан со количината на податоци преземени од сајтовите. Се соочивме со фактот дека собирањето и ажурирањето на сите потребни податоци од најголемите сајтови почна да одзема премногу време. На пример, собирањето податоци од системот за рекламирање AdRiver, со кој следиме статистика за повеќето места, трае околу 12 часа.

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

Друг проблем се однесува на обработката на преземените податоци. Сега, кога пристигнуваат нови статистики за поставување, се започнува повеќефазен процес на повторно пресметување на метрика, кој вклучува вчитување необработени податоци, пресметување збирни метрики за секоја локација, споредување на податоци од различни извори едни со други и пресметување резиме метрика за кампањата. Ова предизвикува големо оптоварување на веб апликацијата која ги прави сите пресметки. Неколку пати, за време на процесот на повторна пресметка, апликацијата ја потроши целата меморија на серверот, околу 10-15 GB, што имаше најштетно влијание врз работата на корисниците со системот.

Утврдените проблеми и амбициозните планови за понатамошен развој на производот не доведоа до потреба од преиспитување на архитектурата на апликациите.

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

Во исто време, почнавме да распоредуваме конектори за Docker и Kubernetes.
Го планиравме преселувањето во Кубернетес доста долго, експериментиравме со поставките за CI/CD, но почнавме да се движиме само кога еден конектор, поради грешка, почна да јаде повеќе од 20 GB меморија на серверот, практично убивајќи ги другите процеси . За време на истрагата, конекторот беше преместен во кластерот Kubernetes, каде што на крајот остана, дури и откако грешката беше поправена.

Доста брзо сфативме дека Kubernetes е погоден и во рок од шест месеци префрливме 7 конектори и Connectors Proxy, кои трошат најмногу ресурси, во производниот кластер.

Следејќи ги конекторите, решивме да ја промениме архитектурата на остатокот од апликацијата.
Главниот проблем беше што податоците доаѓаат од конектори до прокси во големи серии, а потоа го погодуваат DANBoID и се испраќаат до централната веб-апликација за обработка. Поради големиот број на повторни пресметки на метрика, има големо оптоварување на апликацијата.

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

За да ги решиме овие проблеми, развивме архитектура 2.0.

Главната разлика помеѓу новата верзија на архитектурата е во тоа што наместо Web API, користиме RabbitMQ и библиотеката MassTransit за размена на пораки помеѓу услугите. За да го направите ова, моравме речиси целосно да го преработиме Connectors Proxy, правејќи го Connectors Hub. Името беше променето затоа што главната улога на услугата повеќе не е во препраќање барања до конекторите и назад, туку во управувањето со собирањето на метрика од конекторите.

Од централната веб-апликација, ги одвоивме информациите за пласманите и статистиките од страниците во посебни услуги, што овозможи да се ослободиме од непотребните повторни пресметки и да се складираат само веќе пресметаните и собрани статистики на ниво на поставеност. Исто така, ја преработивме и оптимизиравме логиката за пресметување на основната статистика врз основа на необработени податоци.

Во исто време, ги мигрираме сите услуги и апликации на Docker и Kubernetes за да го направиме решението полесно да се размери и поудобно за управување.

Каде сме сега

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

Всушност, овој процес ќе се случи постепено и ќе мора да ја оставиме наназад компатибилноста со старите API за да продолжиме сè да работи.

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

Исто така, планираме да ги пренесеме сите апликации, вклучително и централната веб-апликација, на Docker и Kubernetes. Во комбинација со новата архитектура, ова значително ќе го поедностави распоредувањето, следењето и контролата на потрошените ресурси.

Друга идеја е да се експериментира со изборот на база на податоци за складирање на статистика, која моментално е зачувана во MongoDB. Веќе префрливме неколку нови конектори во SQL базите на податоци, но таму разликата е речиси незабележлива, а за збирната статистика по ден, која може да се бара за произволен период, добивката може да биде доста сериозна.

Во принцип, плановите се грандиозни, да продолжиме понатаму :)

Автори на статијата R&D Dentsu Aegis Network Русија: Георги Остапенко (шмиигаа), Михаил Коцик (hitexx)

Извор: www.habr.com