После релиза Android app_version='5.2' DAU по событию app_open упал на 30%. При этом по той же версии объём screen_view и purchase_succeeded почти не изменился. Какое объяснение наиболее вероятно и что делать?
AПользователи перестали открывать приложение, но продолжают пользоваться покупками и экранами.
BСкорее всего сломалось
instrumentation именно события app_open в версии 5.2 (пропуск/переименование); нужно сверить event taxonomy, проверить отправку и добавить санити-чеки по версии.CЭто точно сезонность: после каждого релиза так бывает, ничего не проверяем.
DНужно срочно менять продукт, потому что любая просадка
DAU всегда означает отток.Правильный ответ. Если падает один
event, а соседние события стабильны, это часто баг logging, а не реальное изменение поведения.Разбор
События screen_view и purchase_succeeded подразумевают, что приложение всё же открывают и используют. Значит, вероятнее всего, конкретно app_open перестал отправляться или изменилось имя/условие отправки в app_version='5.2'. Правильный шаг — проверить event taxonomy и сравнить код instrumentation до/после релиза, а также добавить invariants, например отношение screen_view к app_open в разрезе версий. Это позволяет быстро отличить продуктовый эффект от поломки данных.
Проверь себя · 1/3разбор после ответа
Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для
event taxonomy и последующей аналитики?Ещё вопросы по теме «Инструментация и качество данных»
- Вы проектируете `event taxonomy` для регистрации. Какой вариант `instrumentation` лучше всего подходит, чтобы считать конверсию в успешную регистрацию и понимать, через какой способ вошли?
- Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для `event taxonomy` и последующей аналитики?
- Вы настраиваете мониторинг `data quality` для платёжного флоу. Какой набор `invariants` наиболее практичен и устойчив к сезонности?
- После обновления SDK вы видите, что сумма по `purchase_succeeded` выросла почти в 2 раза, но платежный провайдер этого не подтверждает. Что наиболее вероятно и какое действие по `data quality` самое уместное?
- В мобильном приложении события могут копиться офлайн и отправляться позже. Какие поля времени лучше заложить в `logging`, чтобы корректно строить `user journey` и контролировать задержки?
- Все вопросы по «Инструментация и качество данных» →