Вопрос проверяет понимание особенностей аналитики и push-уведомлений как долгоживущих и асинхронных систем.
Миграция аналитики и пушей сложна из-за потери данных, различий в форматах событий и особенностей доставки. Аналитика может начать собираться некорректно, а пуши — приходить нестабильно. Также возникают проблемы с идентификацией пользователей и обратной совместимостью. Без поэтапного перехода легко получить «слепые зоны» в данных.
Аналитика и пуши тесно связаны с жизненным циклом приложения и пользователя.
При смене сервиса:
события могут логироваться дважды
часть событий теряется
метрики перестают сходиться
Причина:
разные модели буферизации
отличия в ретраях и отправке
Определение:Идентификатор пользователя — ключ, по которому события и пуши связываются с конкретным человеком.
Проблемы:
разные userId
смена схемы авторизации
потеря связки анонимный → авторизованный
Пуши зависят от:
токена устройства
корректной регистрации
backend-логики
При миграции:
токены нужно переотправлять
старые пуши могут "залипать"
сложно отлаживать доставку
старые версии приложения продолжают слать события
backend должен поддерживать несколько форматов
аналитика временно усложняется
Делать двойную отправку на этапе миграции
Явно версионировать события
Логировать ошибки доставки
Постепенно отключать старый сервис
Миграция аналитики и пушей — это процесс, а не переключатель. Успех зависит от поэтапности и контроля данных.