Как събирахме данни за рекламни кампании от онлайн сайтове (трънливият път до продукта)

Изглежда, че сферата на онлайн рекламата трябва да бъде възможно най-технологично напреднала и автоматизирана. Разбира се, защото там работят такива гиганти и експерти в своята област като Yandex, Mail.Ru, Google и Facebook. Но, както се оказа, няма граници за съвършенство и винаги има какво да се автоматизира.

източник

Комуникационна група Dentsu Aegis Network Русия е най-големият играч на пазара на дигитална реклама и инвестира активно в технологии, опитвайки се да оптимизира и автоматизира своите бизнес процеси. Един от нерешените проблеми на пазара на онлайн реклама е задачата за събиране на статистика за рекламни кампании от различни интернет платформи. Решението на този проблем в крайна сметка доведе до създаването на продукт D1.Цифров (чете се като DiVan), за чието развитие искаме да говорим.

Защо?

1. Към момента на стартиране на проекта на пазара нямаше нито един готов продукт, който да решава проблема с автоматизирането на събирането на статистика за рекламни кампании. Това означава, че никой освен нас самите няма да задоволи нуждите ни.

Услуги като Improvado, Roistat, Supermetrics, SegmentStream предлагат интеграция с платформи, социални мрежи и Google Analitycs, а също така дават възможност за изграждане на аналитични табла за удобен анализ и контрол на рекламни кампании. Преди да започнем да разработваме нашия продукт, се опитахме да използваме някои от тези системи за събиране на данни от сайтове, но, за съжаление, те не можаха да решат нашите проблеми.

Основният проблем беше, че тестваните продукти бяха базирани на източници на данни, показващи статистика за разположението по сайт, и не предоставяха възможност за обобщаване на статистика за рекламни кампании. Този подход не ни позволи да видим статистики от различни сайтове на едно място и да анализираме състоянието на кампанията като цяло.

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

2. Пазарът на онлайн реклама се разраства от година на година, като през 2018 г. по рекламни бюджети изпревари традиционно най-големия пазар за телевизионна реклама. Така че има мащаб.

3. За разлика от пазара на телевизионна реклама, където продажбата на търговска реклама е монополизирана, има много индивидуални собственици на рекламен инвентар с различни размери, опериращи в Интернет със собствени рекламни акаунти. Тъй като рекламната кампания по правило се провежда на няколко сайта наведнъж, за да се разбере състоянието на рекламната кампания, е необходимо да се съберат отчети от всички сайтове и да се комбинират в един голям отчет, който ще покаже цялата картина. Това означава, че има потенциал за оптимизация.

4. Струваше ни се, че собствениците на рекламен инвентар в Интернет вече разполагат с инфраструктурата за събиране на статистика и показването им в рекламни акаунти и ще могат да предоставят API за тези данни. Това означава, че е технически възможно да се реализира. Да кажем веднага, че се оказа, че не е толкова просто.

Като цяло всички предпоставки за изпълнението на проекта бяха очевидни за нас и се затичахме да оживим проекта...

Грандиозен план

Като начало създадохме визия за идеална система:

• Рекламните кампании от корпоративната система 1C трябва автоматично да се зареждат в нея с техните имена, периоди, бюджети и разположения на различни платформи.
• За всяко разположение в рамките на рекламна кампания трябва автоматично да се изтеглят всички възможни статистики от сайтовете, където се извършва разположението, като брой импресии, кликове, гледания и др.
• Някои рекламни кампании се проследяват с помощта на мониторинг от трети страни от така наречените рекламни системи като Adriver, Weborama, DCM и др. В Русия има и промишлен интернет измервател - компанията Mediascope. Според нашия план данните от независим и индустриален мониторинг също трябва да се зареждат автоматично в съответните рекламни кампании.
• Повечето рекламни кампании в интернет са насочени към определени целеви действия (покупка, обаждане, записване за тест драйв и т.н.), които се проследяват с помощта на Google Analytics и статистиките за които също са важни за разбирането на статуса на кампанията и трябва да се зареди в нашия инструмент.

Първата палачинка е буйна

Като се има предвид нашия ангажимент към гъвкави принципи на разработка на софтуер (гъвкав, всички неща), решихме първо да разработим MVP и след това да се придвижим към планираната цел итеративно.
Решихме да изградим MVP въз основа на нашия продукт DANBo (Dentsu Aegis Network Board), което е уеб приложение с обща информация за рекламните кампании на нашите клиенти.

За MVP проектът беше максимално опростен по отношение на изпълнението. Избрали сме ограничен списък от платформи за интеграция. Това бяха основните платформи, като Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB и основните рекламни системи Adriver и Weborama.

За достъп до статистически данни за сайтове чрез API използвахме един акаунт. Мениджър на клиентска група, който искаше да използва автоматично събиране на статистика за рекламна кампания, трябваше първо да делегира достъп до необходимите рекламни кампании на сайтове към акаунта на платформата.

Следващият е системният потребител ДАНБо трябваше да качи файл в определен формат в системата Excel, който съдържаше цялата информация за разположението (рекламна кампания, платформа, формат, период на разположение, планирани показатели, бюджет и др.) и идентификатори на съответните рекламни кампании на сайтове и гишета в рекламни системи.

Изглеждаше, честно казано, ужасяващо:

Изтеглените данни се записват в база данни, след което отделни услуги събират от тях идентификатори на кампании в сайтове и изтеглят статистики за тях.

За всеки сайт беше написана отделна услуга за Windows, която веднъж на ден преминаваше под един акаунт за услуга в API на сайта и изтегляше статистика за определени идентификатори на кампании. Същото се случи и със системите за рекламиране.

Изтеглените данни се показват в интерфейса под формата на малко персонализирано табло:

Неочаквано за нас MVP заработи и започна да изтегля текущи статистики за рекламни кампании в интернет. Внедрихме системата на няколко клиента, но при опит за мащабиране срещнахме сериозни проблеми:

• Основният проблем беше сложността на подготовката на данните за зареждане в системата. Освен това данните за разположението трябваше да бъдат преобразувани в строго фиксиран формат преди зареждане. Беше необходимо да се включат идентификатори на обекти от различни сайтове във файла за изтегляне. Изправени сме пред факта, че е много трудно за технически необучени потребители да обяснят къде да намерят тези идентификатори на сайта и къде във файла трябва да бъдат въведени. Имайки предвид броя на служителите в отделите, които провеждат кампании в сайтове и оборота, това доведе до огромна подкрепа от наша страна, от която абсолютно не бяхме доволни.
• Друг проблем беше, че не всички рекламни платформи имаха механизми за делегиране на достъп до рекламни кампании на други акаунти. Но дори и да е наличен механизъм за делегиране, не всички рекламодатели са склонни да предоставят достъп до своите кампании на акаунти на трети страни.
• Важен фактор беше възмущението, което предизвика сред потребителите от факта, че всички планирани показатели и подробности за разположението, които вече въвеждат в нашата счетоводна система 1C, те трябва да въвеждат отново ДАНБо.

Това ни даде идеята, че основният източник на информация за разположението трябва да бъде нашата 1C система, в която всички данни се въвеждат точно и навреме (въпросът тук е, че фактурите се генерират въз основа на 1C данни, така че правилното въвеждане на данни в 1C е приоритет за всеки KPI). Така се появи нова концепция на системата...

Понятие

Първото нещо, което решихме да направим, беше да отделим системата за събиране на статистика за рекламни кампании в интернет в отделен продукт - D1.Цифров.

В новата концепция решихме да заредим D1.Цифров информация за рекламни кампании и разположения в тях от 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. Тази услуга изпълнява задачи за събиране на данни за всеки конектор всяка вечер. Написването на сервизен слой беше по-лесно от свързването на брокер на съобщения и за нас беше важно да получим резултата възможно най-бързо.

За опростяване и бързина на разработка, ние също решихме, че всички услуги ще бъдат уеб API. Това направи възможно бързото сглобяване на доказателство за концепцията и проверката дали целият дизайн работи.

Отделна, доста сложна задача беше настройката на достъпа за събиране на данни от различни акаунти, която, както решихме, трябва да се извършва от потребителите чрез уеб интерфейса. Състои се от две отделни стъпки: първо, потребителят добавя токен за достъп до акаунта чрез OAuth и след това конфигурира събирането на данни за клиента от конкретен акаунт. Получаването на токен чрез OAuth е необходимо, тъй като, както вече писахме, не винаги е възможно да се делегира достъп до желания акаунт в сайта.

За да създадем универсален механизъм за избор на акаунт от сайтове, трябваше да добавим метод към API на конекторите, който връща JSON схема, която се изобразява във формуляр с помощта на модифициран компонент JSONEditor. По този начин потребителите можеха да избират акаунтите, от които да изтеглят данни.

За да спазим ограниченията на заявките, които съществуват на сайтовете, ние комбинираме заявки за настройки в рамките на един токен, но можем да обработваме различни токени паралелно.

Избрахме MongoDB като хранилище за заредени данни както за уеб приложението, така и за конекторите, което ни позволи да не се тревожим твърде много за структурата на данните в началните етапи на разработка, когато обектният модел на приложението се променя през ден.

Скоро разбрахме, че не всички данни се вписват добре в MongoDB и, например, е по-удобно да се съхраняват ежедневни статистики в релационна база данни. Следователно, за конектори, чиято структура от данни е по-подходяща за релационна база данни, започнахме да използваме PostgreSQL или MS SQL Server като хранилище.

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

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

Изминаха две години от началото на разработката D1.Цифров. Постоянното увеличаване на натоварването на системата и появата на все повече и повече нови източници на данни постепенно разкриват проблеми в съществуващата архитектура на решението.

Първият проблем е свързан с количеството данни, изтеглени от сайтовете. Бяхме изправени пред факта, че събирането и актуализирането на всички необходими данни от най-големите сайтове започна да отнема твърде много време. Например, събирането на данни от рекламната система AdRiver, с която проследяваме статистики за повечето разположения, отнема около 12 часа.

За да разрешим този проблем, започнахме да използваме всякакви отчети за изтегляне на данни от сайтове, опитваме се да разработим техния API заедно със сайтовете, така че скоростта на работата му да отговаря на нашите нужди и да паралелизираме изтеглянето на данни колкото е възможно повече.

Друг проблем е свързан с обработката на изтеглените данни. Сега, когато пристигнат нови статистически данни за разположението, се стартира многоетапен процес на преизчисляване на показатели, който включва зареждане на необработени данни, изчисляване на обобщени показатели за всеки сайт, сравняване на данни от различни източници един с друг и изчисляване на обобщени показатели за кампанията. Това причинява голямо натоварване на уеб приложението, което прави всички изчисления. Няколко пъти, по време на процеса на преизчисляване, приложението изразходваше цялата памет на сървъра, около 10-15 GB, което имаше най-лош ефект върху работата на потребителите със системата.

Идентифицираните проблеми и амбициозните планове за по-нататъшно развитие на продукта ни доведоха до необходимостта от преразглеждане на архитектурата на приложението.

Започнахме с конектори.
Забелязахме, че всички конектори работят по един и същ модел, така че изградихме конвейерна рамка, в която за да създадете конектор, трябваше само да програмирате логиката на стъпките, останалото беше универсално. Ако някой конектор изисква подобрение, тогава ние незабавно го прехвърляме в нова рамка в същото време, когато конекторът се подобрява.

В същото време започнахме да внедряваме конектори към Docker и Kubernetes.
Планирахме преминаването към 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 продукт D1.Цифров готов и работещ в тестова среда с ограничен набор от конектори. Всичко, което остава да направите, е да пренапишете още 20 конектора към нова платформа, да тествате дали данните са заредени правилно и всички показатели са изчислени правилно и да внедрите целия дизайн в производство.

Всъщност този процес ще се случи постепенно и ще трябва да оставим обратната съвместимост със старите API, за да продължим да работим.

Нашите непосредствени планове включват разработването на нови конектори, интегриране с нови системи и добавяне на допълнителни показатели към набора от данни, изтеглени от свързани сайтове и системи за рекламиране.

Също така планираме да прехвърлим всички приложения, включително централното уеб приложение, към Docker и Kubernetes. В комбинация с новата архитектура това значително ще опрости внедряването, наблюдението и контрола на изразходваните ресурси.

Друга идея е да експериментирате с избора на база данни за съхранение на статистика, която в момента се съхранява в MongoDB. Вече прехвърлихме няколко нови конектора към SQL бази данни, но там разликата е почти незабележима, а за обобщени статистики по дни, които могат да бъдат поискани за произволен период, печалбата може да бъде доста сериозна.

Като цяло плановете са грандиозни, нека продължим :)

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

Източник: www.habr.com