Детальный разбор: технические проблемы, характерные для AdTech и MarTech

Три года я работал CTO в агентстве digital-маркетинга с оборотом $100M+. Мы запустили несколько AdTech-продуктов с нуля и решали задачи, которые почти не встречаются в других индустриях. Не потому что они академически сложнее, а потому что цена ошибки напрямую измеряется деньгами клиента, и она становится заметной уже через часы, а не через спринты.

В этом выпуске я разберу конкретные технические задачи, с которыми мы столкнулись, и подходы, которые сработали.

1. Сквозная аналитика: когда data pipeline - это и есть продукт

В большинстве SaaS-компаний data pipeline - это вспомогательная инфраструктура для продукта. В MarTech pipeline сам по себе становится продуктом.

Мы построили ETL-систему, которая автоматически забирала данные из рекламных кабинетов (Google Ads, Яндекс Директ, Facebook Ads, myTarget и других), систем веб-аналитики, коллтрекинга и CRM-систем клиентов. Дальше - трансформация, очистка, объединение. На выходе - дашборды, которые показывали полную картину от клика до продажи.

Звучит как стандартный ETL. На практике - каждый источник данных живёт по своим правилам. У рекламных кабинетов разные модели атрибуции, разная гранулярность данных, разные таймзоны. Даже стоимость передаётся по-разному - одни платформы отдают суммы с НДС, другие без, и это нужно учитывать при сведении данных. CRM-система клиента может отдавать данные с задержкой в сутки. Коллтрекинг привязывает звонки к сессиям по своей логике. И всё это нужно свести в единую целостную картину.

Отдельная боль - стабильность. Рекламные платформы меняют API, ломают обратную совместимость, вводят лимиты на запросы к API. Если пайплайн упал ночью и данные за вчера не загрузились, утром менеджер на стороне клиента принимает решения на основе неполных данных. Мы пришли к тому, что мониторинг и reconciliation-джобы (автоматическая сверка загруженных данных с источниками) - это не просто вспомогательная опция, а неотъемлимая часть системы.

2. Управление фидами: специфика застройщиков недвижимости

Когда говорят про управление фидами данных в AdTech, обычно подразумевают товарные фиды для e-commerce. У нас основной кейс был другой - фиды для площадок недвижимости: Яндекс Недвижимость, Авито, ЦИАН.

Недвижимость сложнее товарки по нескольким причинам. Объект - не "товар на складе," а квартира в строящемся доме, у которой меняется статус (свободна, забронирована, продана), цена, планировка, визуализация. У каждой площадки свой формат фида, свои требования к фотографиям, свой набор обязательных полей. ЦИАН хочет одну структуру, Авито - другую, Яндекс Недвижимость - третью.

Плюс бизнес-логика: какие объекты показывать, какие скрывать, как управлять приоритетами в зависимости от стадии продаж. Застройщик не хочет рекламировать квартиры, которые уже проданы, но данные об этом приходят из его CRM с задержкой.

Мы строили систему с адаптерами под каждую площадку и reconciliation-механизмом, который отлавливал расхождения между фидом и актуальным состоянием объектов. По сути - тот же паттерн, что и в сквозной аналитике: абстракция над нестабильными внешними системами, агрессивный мониторинг, минимизация последствий при изменениях.

3. Эконометрика и Marketing Mix Modeling

Классический вопрос для любого маркетингового медиапланирования: "Какой канал реально приносит деньги, а какой просто присваивает себе конверсии?" Стандартная атрибуция из Google Analytics на этот вопрос не отвечает - она показывает, какой канал был последним в цепочке, а не какой реально повлиял на решение о покупке.

Мы реализовали Marketing Mix Modeling на основе ML-модели - по сути, эконометрический анализ влияния каждого рекламного канала на бизнес-результат. Ключевые компоненты:

• AdStock-эффект. Реклама в большинстве случаев не работает мгновенно. Как правило, чем дороже товар - тем длиннее цикл сделки. Человек увидел рекламу сегодня, а купил через неделю. Нужно моделировать затухание рекламного воздействия во времени, и коэффициент затухания у каждого канала свой.

• Предел насыщения. Каждый канал имеет точку, после которой дополнительные инвестиции перестают давать пропорциональный возврат. Вбухивать в канал больше денег после этой точки - сжигать бюджет. Модель позволяла найти оптимальное распределение бюджета между каналами.

• Анализ ROAS. На выходе - не абстрактные "инсайты", а конкретные цифры: сколько каждый рубль инвестиций в конкретном канале приносит выручки, с учётом отложенного эффекта и насыщения.

Технически это было реализовано на Python (NumPy, Pandas, Sklearn, FB Prophet), довольно тяжёлые вычисления на исторических данных клиента. Главная инженерная сложность - не сама модель, а данные. Чтобы MMM работала, нужны чистые, полные и правильно размеченные данные о расходах по каналам и бизнес-результатах за длинный период. Та самая ETL-система из первого раздела.

4. Data-driven атрибуция: Цепи Маркова и Вектор Шепли вместо last click

Параллельно с MMM мы работали над data-driven атрибуцией - задачей о распределении "заслуги" за конверсию между касаниями в пользовательском пути.

Два подхода, которые мы применяли:

• Цепи Маркова. Моделируем путь пользователя как граф переходов между каналами. Для каждого канала рассчитываем removal effect - насколько упадёт общее количество конверсий, если этот канал убрать из цепочки. Каналы с высоким removal effect получают больше "ценности" за конверсию. Этот подход хорошо работает, когда данных достаточно для построения статистически значимого графа переходов.

• Вектор Шепли. Подход из теории игр - каждый канал рассматривается как "игрок в коалиции", и его вклад оценивается по тому, какую дополнительную ценность он привносит в каждую возможную комбинацию каналов. Математически красиво, но вычислительно тяжело - количество коалиций растёт экспоненциально с количеством каналов.

Оба подхода показывали картину, которая сильно отличалась от стандартного last-click из Google Analytics. Часто выяснялось, что каналы верхней части воронки (медийная реклама, OLV), которые по last-click выглядели бесполезными, на самом деле инициировали цепочки, приводящие к конверсиям.

Инженерная сложность здесь - масштаб. У крупных клиентов миллионы сессий, тысячи уникальных путей. Наивная реализация Вектора Шепли упирается в вычислительный потолок, соответсвенно приходится применять аппроксимации. Плюс всё те же проблемы с идентификацией пользователей: чтобы построить пользовательский путь, нужно сначала собрать все касания одного человека в одну цепочку, а это отдельная задача на стыке данных, приватности и технических ограничений браузеров.

5. Кластеризация аудитории и lookalike-таргетинг

Одна из задач, где ML дал реальный, измеримый бизнес-результат - это кластеризация аудитории.

Схема такая: собираем данные от DMP (Data Management Platform) о пользователях, которые взаимодействовали с рекламой клиента. У каждого пользователя - набор характеристик: демография, интересы, поведение на сайте, история покупок. Дальше ML-алгоритмы группируют пользователей в кластеры по схожим признакам.

Самое ценное - не сами кластеры, а выявление доминирующих признаков у конвертирующей аудитории. Условно: "ваши лучшие покупатели - мужчины 30-40, интересуются автомобилями, были на сайте 3+ раза за последний месяц". Это давало конкретные рекомендации для креативной команды - под какие аудитории подстраивать рекламные сообщения и визуалы.

Следующий шаг - экспорт этих сегментов в Facebook Ads и Google Ads для создания lookalike-аудиторий. Платформы берут ваш сегмент и находят похожих пользователей, которых вы ещё не охватили. На практике конверсия по таким аудиториям была заметно выше, чем по стандартному таргетингу.

Техническая сторона: Python для ML-части (кластеризация, feature importance), интеграция с DMP через пиксель для сбора данных, интеграция с рекламными платформами для выгрузки сегментов. Основная инженерная проблема - не алгоритмы (стандартные подходы вроде k-means и random forest работают), а качество данных на входе и автоматизация пайплайна, чтобы сегменты обновлялись регулярно, а не были одноразовым упражнением.

6. A/B-тесты и алгоритмы многоруких бандитов

Стандартное A/B-тестирование предполагает, что можно случайно разделить трафик и независимо измерить результаты. В рекламе это ломается быстро.

У рекламных кампаний есть бюджетные ограничения, пересечение аудиторий и временные эффекты, из-за которых нельзя считать их независимыми. Если вы перекидываете бюджет с кампании A на кампанию B для теста, вы тестируете не только B - вы ещё снижаете конкуренцию в аукционах, где участвовала кампания A, что меняет результаты обеих кампаний.

Мы исследовали и публиковали материалы по использованию алгоритмов многоруких бандитов как альтернативы классическому A/B-тесту в рекламном контексте. "Бандиты" динамически адаптируют распределение бюджета на основе наблюдаемых результатов - вместо того чтобы делить трафик 50/50 и ждать статистической значимости, алгоритм постепенно перераспределяет бюджет в пользу лучше работающего варианта.

Плюсы: меньше потерь на проигрышном варианте, быстрее адаптация. Минусы: медленнее сходимость к статистически достоверному выводу, сложнее интерпретировать результаты, труднее правильно реализовать.

Гео-тестирование оказалось самым надёжным подходом для измерения инкрементального эффекта от рекламных расходов. Берёте схожие географические регионы, запускаете кампанию в одних и не запускаете в других, сравниваете результаты. Не модно, зато даёт цифры, которым можно доверять.

7. Рекомендательные движки для e-commerce

Отдельное направление - рекомендательные системы на основе машинного обучения для e-commerce клиентов агентства. Задача классическая: показать пользователю товары, которые он с наибольшей вероятностью купит, на основе его поведения и поведения похожих пользователей.

Здесь интересна не сама модель (collaborative filtering, content-based подходы - всё стандартное), а контекст применения. В агентстве рекомендательный движок - не внутренний продукт компании, а сервис, который нужно развернуть и интегрировать с инфраструктурой клиента. У каждого клиента свой стек, свои данные, своё понимание того, что считать "товаром" и "конверсией".

Это создаёт потребность в архитектуре, которая достаточно гибка для адаптации под разных клиентов, но при этом не превращается в набор одноразовых кастомных решений. Мы пришли к модульной структуре: общее ядро с подключаемыми адаптерами для данных и конфигурациями модели под конкретного клиента.

Что всё это значит, если вы строите продукт в AdTech/MarTech

Семь разделов выше - это семь разных инженерных задач, и у каждой свои подводные камни. Но общие паттерны прослеживаются:

• Данные — это фундамент всего. Ни MMM, ни кластеризация, ни атрибуция не работают без чистых, полных и своевременных данных. Инвестиции в ETL-инфраструктуру окупаются во всех остальных направлениях.

• Внешние зависимости будут ломаться. Google, Meta, Яндекс меняют API по своему графику. Строить нужно с расчётом на нестабильность - адаптеры, абстракции, мониторинг.

• Доменная экспертиза решает. Человек, который уже прошёл через эконометрическое моделирование на масштабе или строил data-driven атрибуцию, сэкономит месяцы проб и ошибок. В этой вертикали разрыв между "разбираюсь в ML" и "умею применять ML к рекламным данным" - огромный.

---

Меня зовут Антон Голосниченко, я fractional CTO и технический консультант. Больше 3 лет руководил отделом технологий в агентстве диджитал-маркетинга с оборотом $100M+, где мы строили всё описанное выше. Сейчас помогаю AdTech, MarTech, TravelTech и SaaS-стартапам масштабировать инженерные команды и техническую инфраструктуру. Если ваш стартап столкнулся с техническими проблемами роста - буду рад познакомиться и пообщаться. Записаться на бесплатную консультацию: https://golosnichenko.com