Delivery Hero отказалась от Google Analytics в пользу собственной платформы и, по словам Engineering Manager Алины Красавиной, получила систему, которая выдерживает в 10 раз большую нагрузку и собирает 97% трекинговых данных. Для команд, которые спорят, строить ли свой собственный трекинг пользователей или терпеть ограничения внешнего сервиса, это не теоретический кейс, а довольно приземлённый разбор с цифрами про качество данных, стоимость и архитектуру.
О проекте Красавина рассказала на InfoQ Dev Summit Munich, сообщает InfoQ. Речь идёт о Delivery Hero, где центральный офис в Германии строит общие сервисы для локальных брендов доставки по всему миру. Внутренний трекинговый сервис там стал одним из таких общих инструментов: он собирает события из мобильных и веб-приложений, отправляет их через API во внутреннюю инфраструктуру, а дальше раздаёт данные либо в real-time-консьюмеры через Pub/Sub, либо в BigQuery для всех остальных сценариев аналитики.
Причин уйти с Google Analytics у компании было сразу несколько. Первая вполне бытовая: Universal Analytics всё равно нужно было заменять, а значит миграции не избежать. В Delivery Hero решили, что если уж тратить ресурсы на переезд, то не на GA4, а на собственную платформу. Вторая причина уже менее бытовая и куда более болезненная для продуктовых команд: Google Analytics не закрывал real-time use cases. В компании есть биллинг, завязанный на рекламные данные, а обновление метрик один-два раза в день для такого сценария бесполезно. Третья причина связана с ограничениями по типам событий. По словам Красавиной, в какой-то момент команда упёрлась в лимит на число событий, которые можно определить в Google Analytics, тогда как во внутренней системе число event types ничем не ограничено.
Отдельным блоком шли GDPR и контроль над данными. Поскольку Google остаётся сторонним провайдером, часть информации компания не могла хранить вне собственной инфраструктуры по юридическим причинам. Для крупного международного бизнеса это уже не пункт в чеклисте комплаенса, а прямое ограничение на архитектуру. Наконец, был и вопрос денег. Изначально задача ставилась скромно: новый сервис не должен обходиться дороже Google Analytics. Но после запуска команда, по её словам, не просто удержалась в этих рамках, а смогла дополнительно оптимизировать затраты. Один из заявленных результатов после rollout: снижение стоимости на 25% при удвоении нагрузки относительно объёма, который раньше обслуживал Google Analytics.
Любопытнее всего в этой истории не сам факт миграции, а то, насколько простой оказалась первая версия системы. На старте собственный трекинг пользователей состоял из API и двух processors, которые читали сообщения из Pub/Sub: основной и резервный на случай fallback-сценариев. Всё. Без россыпи сервисов, без фестиваля из десятков компонентов, без попытки заранее решить все проблемы будущего мира. Красавина прямо называет эту архитектуру очень простой, но именно она дала масштабируемость и, по её словам, не создала команде никаких проблем. Уже после rollout вокруг этого минимального ядра начали появляться дополнительные сервисы: валидация данных, jobs для курирования, новые SDK и прочая обвязка для производителей и потребителей данных. Иначе говоря, сначала команда построила маленькую работающую трубу, а потом аккуратно наращивала мясо вокруг неё, а не наоборот.
Качество данных команда мерила не абстрактным “у нас вроде всё хорошо”, а своим показателем order match rate. Логика простая и очень здравая: если пользователь действительно оплатил заказ, бэкенд сервиса доставки знает об этом со 100-процентной точностью. Значит, заказы можно использовать как source of truth и сравнивать их с тем, что доехало до трекинговой системы. Такой подход особенно полезен в сезоны пикового спроса вроде праздников, когда объём событий растёт сам по себе, и без контрольной метрики легко перепутать поведение пользователей с проблемами в аналитике. По словам Красавиной, у Google Analytics order match rate был на уровне 85%, а после rollout новой платформы показатель вырос на 6 процентных пунктов. Для данных, от которых зависят биллинг и рекламные расчёты, это уже не косметическая правка, а вполне ощутимые деньги, хотя конкретные суммы компания не раскрывала.
Ещё одна сильная деталь кейса в том, что рост качества данных не был магией на стороне хранилища. Команда шла с двух сторон: дорабатывала SDK, чтобы события не терялись на клиенте, и строила надёжную серверную инфраструктуру, чтобы не ронять данные уже после приёма. На графиках, которые Красавина показывала для четырёх брендов в течение года после rollout, линии Google Analytics и нового сервиса сначала сходятся, а затем внутренняя система начинает собирать больше данных. Из этого можно вынести довольно прикладной вывод для разработчиков: проблемы трекинга редко живут в одном месте. Если воронка дырявая, чинить придётся и клиентские библиотеки, и транспорт, и обработку, и контроль качества. Один “переезд на другую платформу” сам по себе ничего не гарантирует.
Для российского рынка, где команды тоже всё чаще хотят держать критичные данные ближе к себе, этот кейс интересен сразу в трёх плоскостях. Во-первых, он показывает, что собственный трекинг пользователей имеет смысл не только из-за суверенности данных, но и из-за продуктовых ограничений внешнего инструмента. Во-вторых, он неплохо отрезвляет архитектурные амбиции: MVP из API и пары processors иногда полезнее, чем “идеальная” event-платформа на двадцать сервисов. В-третьих, метрики успеха тут выбраны по делу: не число микросервисов, не размер кластера и не красота схемы, а match rate, cost per message, отсутствие инцидентов с потерей данных и способность переваривать нагрузку. По словам Красавиной, во время тестирования и rollout система прошла без инцидентов data loss, а это в трекинге дорогого стоит, особенно когда данные завязаны на выручку.
Главный вопрос после таких историй обычно один и тот же: где проходит граница, после которой своя аналитическая платформа становится выгоднее готового сервиса. Кейс Delivery Hero намекает, что ответ зависит не от моды на in-house решения, а от набора конкретных требований: real-time, юридические ограничения, объём событий, требования к качеству и цена ошибки в данных. Когда всё это сходится в одной точке, build instead of buy перестаёт быть инженерным тщеславием и превращается в вполне рациональный выбор.
The post Delivery Hero заменила Google Analytics своим трекингом appeared first on iTech News.