Безопасная миграция аналитики: почему важно начинать с уровня сбора событий
Открытый инструмент SensorFlow предлагает инженерным командам безопасный путь миграции продуктовой аналитики, фокусируясь на уровне приёма событий, а не на визуализации данных.
Замена системы аналитики редко бывает решением на уровне выбора нового дашборда. Самый рискованный этап — миграция границы сбора событий.
Проблема миграции аналитики: не только про графики
Компании, которые годами собирают данные о поведении пользователей через SDK от Amplitude, Mixpanel или отечественных аналитических платформ, со временем приходят к мысли о миграции. Причины могут быть разные: рост стоимости, желание контролировать данные, необходимость в гибкости. Однако замена аналитической системы — это не просто подключение нового сервиса и создание новых дашбордов.
Настоящая сложность заключается на уровне, который пользователи и даже некоторые менеджеры не видят — на уровне «границы сбора событий». Веб-приложения, Android- и iOS-клиенты, бэкенд-сервисы отправляют события по разным протоколам, с разными соглашениями об именовании и с годами накопившимися нюансами идентификации. Переписать все интеграции «на лету» — путь к потере данных и сломанной аналитике.
Что такое SensorFlow и как он работает
На эту проблему обращает внимание open-source проект SensorFlow. Его создатели предлагают не замену «из коробки» с новым красивым интерфейсом, а инструмент для контролируемого, пошагового перехода. Ключевая идея — сохранить существующие клиентские SDK (в том числе совместимые с Sensors Data), но направить поток событий в инфраструктуру, полностью контролируемую компанией.
Архитектура выглядит так:
- Сбор: Существующие SDK приложений и серверов отправляют события.
- Обработка: Лёгкий сервис на языке Go принимает и обрабатывает эти события.
- Хранение: Данные записываются в высокопроизводительную аналитическую базу данных ClickHouse.
- Визуализация: Для построения дашбордов используется Apache Superset — популярный open-source инструмент.
Такой подход позволяет инженерным командам инспектировать сырые записи, определять метрики через SQL-запросы и строить отчёты напрямую к своей базе. Главное преимущество — данные становятся частью общей инфраструктуры команды: с проверяемыми изменениями схем, прозрачными запросами и гибкими правами доступа.
Практические аспекты и ограничения
Авторы проекта подчёркивают, что SensorFlow — это не готовая замена для всех возможностей коммерческих аналитических платформ. В проекте отсутствует запись сессий, инструменты для A/B-тестирования, управления фича-флагами и сложные низкокодовые конструкторы. Это осознанное ограничение круга задач.
SensorFlow рассчитан на инженерные команды, которые:
- Уже имеют многоплатформенную инструментовку (SDK на всех клиентских платформах и бэкенде).
- Стремятся к полному контролю над данными (data ownership).
- Готовы взять на себя эксплуатацию хранилища ClickHouse.
Самостоятельный хостинг — это не способ уйти от операционных расходов. Для тестирования подойдёт Docker Compose, но для production-среды потребуется настройка HTTPS, уникальных учётных данных, мониторинга, резервного копирования и планирования ёмкости. Это добавляет нагрузку на DevOps-инженеров, но даёт полный контроль.
Итог: постепенность вместо революции
SensorFlow предлагает рациональный, хотя и нишевый, подход к проблеме миграции аналитики. Вместо того чтобы требовать немедленного переписывания всего стека сбора данных во всех приложениях, он позволяет начать с замены «внутренностей» — серверной части хранения и обработки. Такой постепенный переход снижает риски потери исторических данных и позволяет командам адаптироваться на ходу.
Для компаний, которые уперлись в стоимость или гибкость своих текущих аналитических решений и при этом обладают сильной инженерной командой, подобный open-source стек может стать осмысленным шагом к автономии. Главное — честно оценить свои ресурсы на эксплуатацию и понимать, что это не «волшебная таблетка», а новый слой ответственности.