Как проверить, что события доходят до AppMetrica

Запишите платформу, версию и номер сборки, приложение в AppMetrica, точное имя события и время действия с часовым поясом. Для нашего примера добавьте ID тестового заказа. Так аналитик и разработчик будут искать одну запись, а не похожие события разных пользователей.

Уточните условие отправки: событие должно приходить после открытия экрана или после подтверждения оплаты сервером? Если заявка только одобрена, а событие описывает оплаченную покупку, его отсутствие может быть правильным поведением. Как записать это условие в плане, разобрано в статье об изменении событий.

API-ключ SDK выбирает приложение, куда отправляются данные. OAuth-токен даёт право их читать. Если тестовая сборка пишет в отдельное приложение AppMetrica, отчёт основного приложения не покажет этот заказ даже при исправной отправке.

В отладочной сборке Android включите withLogs() при создании конфигурации AppMetrica. Повторите действие и сопоставьте записи SDK со временем заказа. Не опирайтесь только на строку своего приложения перед вызовом отправки: она подтверждает, что выполнение дошло до этого места, но не результат работы SDK.

SDK накапливает события в буфере. Для одной проверки можно вызвать AppMetrica.sendEventsBuffer() после нужного действия, чтобы инициировать отправку накопленных событий. Это не подтверждение доставки и не замена проверке выгрузки. Частый вызов увеличивает расход трафика и энергии, поэтому добавлять его после каждого события ради этой диагностики не нужно.

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

Настройка логов и работа буфера описаны в документации Android SDK.

В Logs API поле event_datetime относится ко времени действия, а event_receive_datetime — ко времени получения сервером. Параметр date_dimension выбирает, по какому из них ограничивать период. Значение default означает время действия; receive — время получения.

# Подставьте токен и числовой ID приложения.
# Даты ниже иллюстрируют запрос; замените их своим периодом.
curl --get --include --fail-with-body \
  'https://api.appmetrica.yandex.ru/logs/v1/export/events.json' \
  --header 'Authorization: OAuth <токен>' \
  --data-urlencode 'application_id=<ID приложения>' \
  --data-urlencode 'date_since=2026-08-20 09:00:00' \
  --data-urlencode 'date_until=2026-08-20 12:00:00' \
  --data-urlencode 'date_dimension=default' \
  --data-urlencode 'event_name=purchase_completed' \
  --data-urlencode 'fields=event_name,event_datetime,event_receive_datetime,event_json,os_name,app_version_name,app_build_number' \
  --data-urlencode 'skip_unavailable_shards=false'

Параметры события находятся в event_json: это строка с JSON внутри ответа. В ней ищем ID тестового заказа. Поле с номером сборки помогает отличить две сборки с одинаковым названием версии. Если проверяется ошибка в имени, повторите запрос без фильтра event_name.

Список полей и условия отбора приведены в описании выгрузки событий. Согласуйте часовой пояс запроса с журналом проверки; одинаковые числа на часах ещё не означают один момент времени.

Ответ 202 Accepted означает подготовку файла. Повторяйте тот же запрос с паузой до 200 OK; ответ с ошибкой доступа или другим HTTP-статусом не считайте пустой выгрузкой. Тело ответа поможет отличить ошибку запроса от отсутствия данных.

У повторного запроса есть особенность: готовый файл доступен в течение 24 часов. Если событие пришло позже, очередное скачивание того же файла не обязано его показать. Для нового поиска отправьте запрос с заголовком Cache-Control: no-cache один раз, затем опрашивайте тот же URL без этого заголовка, пока файл готовится.

Параметр skip_unavailable_shards=true разрешает выгрузку с пропуском временно недоступной части данных. Для поиска потерянного события оставляем false: частичный ответ не позволит проверить отсутствие записи. Правила подготовки и обновления файла описаны в процедуре запроса Logs API.

В учебном примере покупка произошла в 10:03. Телефон был без сети, сервер получил событие в 11:17, а в доступной выгрузке оно появилось ещё позже. Для простоты все времена здесь приведены к одному часовому поясу. Это иллюстрация порядка событий, а не замер задержек AppMetrica.

Найденный ID заказа подтверждает, что эта запись дошла и доступна в Logs API. После этого проверяйте период и фильтры отчёта, выбранную платформу и параметры события. Один найденный заказ не доказывает полноту данных за сутки.

Выгрузка каждого часа ровно один раз пропускает поздние записи. Это возможно даже при отборе по времени получения: событие уже принято сервером, но ещё не появилось в Logs API. Документация рекомендует загружать с задержкой или повторно запрашивать прошлые периоды.

Для своего загрузчика измерьте, насколько меняется один и тот же период при повторной выгрузке. По этим изменениям выбирайте задержку и глубину повторной загрузки. При замене периода используйте свежий файл; если дописываете строки, заранее определите способ устранения повторов. Сочетание устройства, имени и секунды не гарантирует уникальность: человек может повторить действие в ту же секунду.

В результате диагностики должно быть понятно, что исправлять: условие отправки, подключение SDK, выбор периода, обновление файла или фильтры отчёта. Для каждого варианта есть своя проверка.