Сквозная аналитика — это попытка проследить путь денег от рекламного клика до оплаты. Звучит как стандартная задача, но на практике данные живут в пяти разных кабинетах, каждый из которых отвечает только на часть вопроса. Рекламный кабинет знает расход, веб-аналитика — визиты, биллинг — оплаты, и ни один из них не знает про остальные.
Автор кейса, опубликованного на Habr, собрал минимальный рабочий вариант за две недели. Ядро — три источника: Яндекс.Директ (расход и клики), Яндекс.Метрика (трафик как опережающий сигнал, не абсолютные цифры) и собственный биллинг с UTM-привязкой оплат. Поверх — Python с pandas в роли ETL, Google Sheets как витрина и BI-дашборд. Оркестратор — cron. Никаких Kafka, Airflow или облачного хранилища данных: на старте они только замедляют.
| Источник | Что даёт | Ограничение |
|---|---|---|
| Яндекс.Директ | Расход, клики, показы, CTR, CPC по кампаниям | Конверсии — внутренние цели кабинета, не реальные оплаты |
| Яндекс.Метрика | Источники трафика, динамика визитов | Погрешность, нет данных о деньгах, только опережающий сигнал |
| Биллинг (своя БД) | Оплаты с UTM-привязкой, выручка | Не знает, из какой рекламы пришёл пользователь |
Самое спорное решение в архитектуре — Google Sheets вместо базы данных. Каждый Python-модуль собирает один лист: build_channel_spend.py пишет расходы по каналам, build_leads.py — лиды. Лист работает как материализованное представление: все джойны делаются в pandas в памяти, в таблицу попадает уже готовый результат. Плюсы очевидны: сервис-аккаунт, библиотека gspread, и через десять минут данные уже пишутся. Маркетолог видит их без SQL. Минусы тоже реальны: API отдаёт ошибки 429 и 503 на пиках, числа читаются строками, дат нет как типа — каждый загрузчик приводит типы сам. Когда Sheets перестал тянуть на этапе BI с прямым коннектором, схему перенесли в Postgres — но к тому моменту она уже была отлажена, и перенос оказался механическим.
Claude Code ускорил написание кода примерно в пять раз, но архитектуру атрибуции LLM не заменяет.
Ключевой паттерн против дублей при инкрементальном сборе — идемпотентный upsert по стабильному ключу. Автор споткнулся здесь: в качестве ключа для рекламного объявления взял слаг плюс заголовок плюс дату. Часть креативов совпадала по заголовку и минуте создания — upsert схлопывал разные объявления в одно. Лечение простое: ключ должен быть идентификатором из самой системы, а не «вроде бы уникальной» комбинацией полей.
Claude Code дал, по оценке автора, ускорение примерно в пять раз на рутинных задачах: разведка незнакомых API, написание ETL, парсинг, тесты, бойлерплейт. Но там, где нужно принимать продуктовые решения, LLM скорее мешает: его скорость генерации кода опережает скорость осмысления задачи. Атрибуцию, определение сущности «лид» и логику резолвинга namespace разработчик строил сам.
Namespace-ад — отдельная история. «Продукт» в системе живёт в трёх несводимых пространствах: слаг лендинга в URL, utm_campaign в ссылке объявления и идентификатор в биллинге. Маркетолог пишет UTM-метки как привык, лендинг живёт своей жизнью, биллинг — третьей. Решение — приоритетный резолвер: сначала официальная карта utm → продукт, потом слаг посадочной, потом фаззи-матч по имени кампании. Третий шаг критичен: в одном рекламном источнике до 70% кампаний оказались лид-формами без ссылки на сайт — у них нет ни UTM, ни landing-slug, только название. Дополнительная деталь: универсальная нормализация строк убивала символы ++ и #, и C++ склеивался с C# — реальный баг на 200 с лишним объявлениях.
Дедупликация лидов — ещё одно продуктовое решение, которое нельзя делегировать инструменту. Один человек мог оставить заявку, заказать обратный звонок и записаться на вебинар — это один лид или три? Договорились считать по формуле «человек × продукт = один лид» с приоритетной категорией. Без дедупа воронки завышены кратно. Технически это обычный groupby, но определение сущности — решение команды, а не алгоритма.
В итоге MVP, который «собирается за две недели», на практике превратился в несколько месяцев работы — именно из-за атрибуции, namespace-резолвинга и честного определения метрик. Кейс честно разделяет две части: что просто и быстро, и где начинается настоящая сложность аналитической системы.
