Событийная и мобильная аналитика

Все темы Product Analyst

Что такое clickstream и как из него строят путь пользователя?

Clickstream это последовательность событий с типом, user_id или анонимным ID, timestamp и свойствами страницы, экрана или действия. Сначала удаляют технические дубли и ботов, приводят время и идентификаторы, затем упорядочивают события. Сессии выделяют по правилу таймаута или бизнес-событиям, понимая, что это аналитическая конструкция. Из последовательностей строят воронки и пути, явно задавая допустимый порядок и окно. Late events, несколько устройств и смена анонимного ID на авторизованный требуют отдельных правил склейки.

Как измерять клиентский опыт в мобильном приложении?

Систему строят вокруг ключевых сценариев: доля успешного завершения, время и число шагов, ошибки и abandonment. Поведенческие сигналы дополняют retention и прямой обратной связью, например CSAT или отзывами, понимая bias ответивших. Техническая часть включает crash-free users, ANR и скорость. Все метрики смотрят по ОС, версии приложения, устройству и типу пользователя. Изменение показателей после релиза не доказывает причинность, поэтому крупные изменения проверяют экспериментом или поэтапным rollout с контролем.

Какие технические метрики мобильного приложения влияют на продукт?

Основные SLI: crash-free users и sessions, ANR, cold и warm startup time, response time ключевых экранов, network errors, память и влияние на батарею. Среднее скрывает хвосты, поэтому для времени нужны p50, p95 и p99. Метрики режут по версии приложения, ОС, модели устройства и релизной когорте. Затем связывают техническую деградацию с abandonment, конверсией и retention. Один crash rate без знаменателя и версии не помогает найти проблемный релиз или оценить продуктовый ущерб.

Зачем передавать event_id в событиях push-кампании?

event_id однозначно идентифицирует конкретное событие и позволяет сделать прием идемпотентным: повторная доставка не увеличит sent, delivered или open. По нему можно связать этапы одной доставки и расследовать пропуски. campaign_id идентифицирует кампанию и повторяется у многих событий, поэтому для дедупликации недостаточен. ID генерируют стабильно на стороне источника, сохраняют при retry и задают срок хранения ключей дедупликации. Для пользователя и устройства нужны отдельные поля, их нельзя выводить из event_id.