Событие принято, но не видно в отчёте

Самое коварное состояние интеграции: транспорт исправен, ответ успешный, а данных нет. Ниже — все причины, по которым это бывает, и точная проверка для каждой. Порядок неслучайный: сверху то, что подтверждается за минуту.

Сначала прочитайте ответ до конца

Прежде чем искать событие в отчётах, убедитесь, что оно действительно принято. 202 приходит и тогда, когда весь батч отклонён по элементам:

{ "accepted": 0, "n": 1, "rejected": [{ "i": 0, "code": "invalid_event" }] }

Если accepted равен нулю или rejected не пуст — событие не принято, и дальше по этой странице идти не нужно: расшифровка кодов отказа лежит в дереве диагностики. Эта страница про случай, когда accepted больше нуля.

Решение проблем

Событие только что отправлено и его ещё нет

Вероятная причина. Нормальная задержка обработки. 202 означает, что событие попало в долговременную очередь приёма, а не что оно уже лежит в хранилище отчётов. Накопленное записывается пакетами, пакет сбрасывается каждые 2 секунды.

Как проверить. Откройте Данные и сбор → События и включите живой поток кнопкой в шапке экрана. Если событие появляется в потоке, но ещё не в таблице истории — вы просто смотрите раньше, чем закончилась запись. Повторите обновление таблицы через 5–10 секунд.

Безопасное исправление. Ничего делать не нужно, кроме ожидания. Не отправляйте событие повторно с новым event_id — так вы получите два события вместо одного.

Если не помогло. Если событие не появилось и через минуту, задержка ни при чём — идите к следующим разделам. Учтите, что живой поток выше 20 сообщений в секунду прореживается на сервере: считать по нему события нельзя, он годится только для проверки «нажал — увидел».

Событие лежит в другом месте шкалы времени

Вероятная причина. Поле time вышло за окно приёма ±48 часов, и приём заменил его временем получения. Отказа при этом не будет: поведение намеренно прощающее. Самые частые источники — сбитые часы на сервере, время в местном поясе без указания смещения и попытка догрузить историю через приём событий.

Как проверить. Найдите событие в Данные и сбор → События без фильтра по дате и откройте его карточку. Сравните event_time и server_time: заметная разница означает, что время подменено. Если событие вообще не находится — причина не в этом.

Безопасное исправление. Отправляйте time в UTC в формате RFC 3339 и синхронизируйте часы на серверах-отправителях. Уже принятые события с подменённым временем переписать нельзя, поэтому исправление действует только на новые.

Если не помогло. Проверьте, не смотрите ли вы отчёт в другом часовом поясе: это отдельная причина, она разобрана ниже.

Событие отклонил реестр

Вероятная причина. Три разных механизма дают три разных кода.

Что произошло	Код отказа элемента
Проект в строгом режиме проверки, событие нарушило схему	schema_violation
В реестре у события указан источник, не совпадающий с типом ключа	credential_event_forbidden
Реестр недоступен и контракт не удалось разрешить	credential_event_forbidden

Вторая строка — самая неочевидная. Поле «Источник» в карточке события реестра не декоративное: событие, зарегистрированное с источником Server, браузерным токеном отправить нельзя, а событие с источником System не примет ни один публичный ключ. Незарегистрированное событие этой проверкой не ограничено — источник у него не указан.

Как проверить. Откройте Данные и сбор → Проверка интеграции, вкладку «Нарушения», и найдите своё имя события за нужное окно. Там же видно, чем именно контракт не сошёлся. Затем откройте это событие в Реестре событий и посмотрите поле «Источник».

Безопасное исправление. Если расходится схема — приведите событие в соответствие с контрактом либо выпустите новую версию схемы. Пока разметка не устоялась, переведите проект в режим «Мониторинг»: нарушения будут записываться, а события продолжат приниматься. Если расходится источник — поменяйте источник в карточке события на тот, которым вы действительно отправляете, или отправляйте с ключа соответствующего типа.

Если не помогло. Событие с кодом schema_violation сохраняется, но без свойств и идентификаторов — специально, чтобы его было видно на экране проверки интеграции. Поэтому «событие есть, а свойств нет» — это тоже признак строгого режима, а не потери данных. Подробности — в реестре событий.

Имя события не проходит проверку

Вероятная причина. Имя не подходит под ^[a-z0-9_.]{1,128}$. Заглавные буквы, кириллица, пробелы, дефисы и двоеточия недопустимы. Такое событие получает отказ invalid_event и не сохраняется вообще.

Как проверить. Посмотрите тело запроса в сетевой панели или в своём журнале и сверьте имя символ за символом. Order_Created, order-created и order created — три недопустимых варианта одного имени.

Безопасное исправление. Приведите имя к нижнему регистру с подчёркиваниями: order_created. Имя события — часть контракта, поэтому меняйте его осознанно: после переименования старые события останутся под старым именем, и отчёты придётся строить по двум именам либо начинать историю заново.

Если не помогло. Если имя выглядит корректным, проверьте невидимые символы: завершающий пробел и неразрывный пробел в имени, скопированном из документа, — частая причина. Полный список ограничений полей — в лимитах.

Отчёт смотрит другой период

Вероятная причина. Границы периода считаются по-разному на разных экранах. Список событий расширяет выбранные даты до границ суток в UTC, а отчёты трактуют даты как календарные дни часового пояса проекта. Для проекта со смещением от UTC это разные окна, и событие у края суток попадает в одно и не попадает в другое.

Как проверить. Посмотрите часовой пояс проекта в Настройках проекта, поле «Часовой пояс». Затем расширьте период в отчёте на день в каждую сторону: если событие появилось — дело в границах.

Безопасное исправление. Сравнивайте числа между экранами только на одинаковых окнах и не по одному дню, а по периоду. Для сверки «пришло ли событие» используйте список событий, для чисел — отчёты.

Если не помогло. Проверьте срок хранения. События старше срока хранения тарифа удаляются: срок составляет от 6 месяцев до 25 месяцев в зависимости от тарифа. Событие за пределами этого срока не найдётся ни на одном экране.

Фильтр отчёта исключает событие

Вероятная причина. Активный сегмент, фильтр по свойству, выбранная группировка или тип устройства отсекают именно ваше событие. Отдельный случай — фильтр по свойству, значение которого было отредактировано на приёме: значения с признаками секрета или персональных данных заменяются на [redacted], и фильтр «свойство равно ожидаемому значению» перестаёт совпадать.

Как проверить. Снимите все фильтры и сегменты и постройте отчёт по одному событию за один день. Затем возвращайте фильтры по одному. Значение свойства проверьте в карточке события в списке событий — там видно, что реально сохранилось.

Безопасное исправление. Уберите или исправьте фильтр. Если значение свойства оказалось [redacted], не пытайтесь обойти редактирование: перенесите признак в отдельное свойство без персональных данных — например, вместо адреса электронной почты передавайте внутренний идентификатор. Что именно редактируется, описано в приватности.

Если не помогло. Проверьте, что вы смотрите отчёт того же проекта. Это следующий раздел.

Событие ушло в другой проект

Вероятная причина. Проект определяется криптографически по ключу и не может быть переопределён ни заголовком, ни параметром. Ключ от другого проекта отправит события в другой проект и вернёт при этом честный 202. Типовые источники — один и тот же ключ в тестовом и рабочем окружении, ключ, скопированный из соседнего проекта, и подстановка ключа из общей переменной окружения.

Как проверить. Возьмите префикс ключа из запроса — символы до второго подчёркивания в значении заголовка авторизации — и найдите его в списке ключей проекта. Если префикса там нет, ключ принадлежит другому проекту.

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

Если не помогло. Проверьте адрес приёма. Разные установки ActionPulse — это разные хранилища данных, и корректный ключ на неправильном хосте даст либо 401, либо события в другой установке.

Исчерпана квота тарифа

Вероятная причина. Приём остановлен биллингом. В этом состоянии успешного ответа уже не будет: запросы получают 429 с кодом quota_exceeded, 429 trial_quota_exceeded либо 402. Симптом «принято, но не видно» здесь выглядит иначе: часть событий за период есть, а с какого-то момента поток обрывается.

Как проверить. Посмотрите код ответа на последних попытках отправки в своём журнале и раздел биллинга в кабинете — там видно потребление за период. Учитывайте, что потребление пересчитывается фоново примерно раз в полчаса, поэтому маркер блокировки может появиться позже фактического превышения.

Безопасное исправление. Повышать частоту повторов бесполезно: у квотных отказов нет заголовка Retry-After, и повтор не поможет. Нужно либо повысить тариф, либо дождаться следующего периода. Различайте коды по полю error.code, а не по коду ответа: rate_limited повторять стоит, quota_exceeded — нет. Разбор всех кодов ответа — в кодах ответа.

Если не помогло. Проверьте, не отправляете ли вы в проект лишнего объёма: автосбор поведения можно сузить в Настройках → Сбор и приватность, а диагностику и записи сессий — выключить. Квоты и лимиты разобраны в лимитах.

Событие отправлено дважды, а видно одно

Вероятная причина. Сработала защита от дублей: повторная отправка события с тем же event_id в пределах окна не создаёт второе событие. Ответ при этом выглядит совершенно так же — accepted: 1, — поэтому по ответу дубль не отличить.

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

Безопасное исправление. Для двух разных фактов используйте разные event_id. Собирайте их детерминированно из бизнес-ключа вместе с версией события — тогда осознанная переотправка возможна, а случайное схлопывание нет. Готовый рецепт — в доставке и повторах.

Если не помогло. Обратная ситуация — событие видно дважды — тоже штатная: защита действует в пределах одного класса источника. Один и тот же event_id, отправленный браузерным токеном и серверным ключом, даёт два независимых события. Выберите одну сторону для каждого факта.

Порядок проверки, если ничего не подошло

1. Ответ на /v1/track: accepted больше нуля, rejected пуст.
2. Событие находится в списке событий без фильтра по дате.
3. event_time и server_time в карточке события совпадают в пределах ожидаемого.
4. Префикс ключа из запроса есть в списке ключей нужного проекта.
5. На экране проверки интеграции за это окно нет нарушений с вашим именем события.
6. Отчёт построен без сегментов и фильтров, период расширен на сутки в каждую сторону.

Если все шесть пунктов сходятся, а события нет, соберите для поддержки: event_id, имя события, время попытки в UTC, префикс ключа и код ответа. Значение ключа не пересылайте ни при каких обстоятельствах.