In-app-события теряются не в одном месте: чек-лист поиска loss по всей цепочке

In-app-события теряются не в одном месте: чек-лист поиска loss по всей цепочке

Микроконверсия проходит несколько этапов: действие пользователя, фиксация SDK, локальная очередь, отправка, приём сервером, маппинг и передача в отчёт. «Loss» на финальном экране не доказывает, что событие не произошло: оно могло задержаться, получить другой timestamp или не пройти фильтр.

Проверяйте цепочку по порядку:
— событие действительно вызывается после нужного действия;
— имя, параметры и тип значения совпадают с настройкой;
— SDK не теряет данные при сворачивании приложения или слабой сети;
— событие не блокируется согласием, ограничениями устройства или фоновым режимом;
— сервер принимает его без ошибки и повторной отправки.

Отдельно разделяйте три случая: событие не создано, создано, но не доставлено, доставлено, но не отображено. Для этого сравнивайте локальные логи, серверные ответы и отчёты платформы на одном срезе времени. Не смешивайте уникальные события с количеством отправок: ретраи создают дубли, а дедупликация может выглядеть как loss.

Начинайте диагностику с одной микроконверсии и минимального тестового сценария. Зафиксируйте идентификатор пользователя, время, payload и статус ответа, затем повторите путь на стабильной сети и при её отключении. Так проще найти первый этап, на котором расходятся числа.

Ищите не «пропавшие» события, а первый разрыв в цепочке: только после этого решайте, нужен ли фикс в коде, настройках или интерпретации отчёта.