Ошибка CAPI 2804003: как обойти лимит 7 дней в Facebook

event_id Если вам нужно отправить в Facebook конверсии, которые произошли больше недели назад, серверный API вернет ошибку. Facebook жестко ограничивает время доставки событий. Ниже я покажу, как решить эту проблему с помощью алгоритма сдвига времени и при этом не сломать аналитику.

Для быстрого старта и проверки ваших токенов доступа вы можете использовать бесплатный инструмент.

Что такое Conversions API и зачем его использовать?

Традиционный браузерный пиксель Facebook теряет данные. Блокировщики рекламы, приватные режимы и ограничения iOS (ITP) мешают коду JavaScript на посадочной странице зафиксировать факт покупки.

Conversions API решает эту проблему за счет передачи событий напрямую: трекер Keitaro фиксирует конверсию и отправляет её на серверы Meta через POST-запрос. В этом случае браузер клиента никак не участвует в передаче, а значит, данные не могут быть заблокированы. Использование гибридной схемы (браузер + сервер) позволяет собирать максимум данных для оптимизации кампаний. При этом обязательна правильная настройка идентификаторов, о чем подробно рассказано в статье event_id и дедупликация.

Почему Facebook отклоняет события старше 7 дней?

Алгоритмы таргетинга Meta работают в реальном времени. Рекламная система постоянно обучается на основе поведения пользователей. Если вы начнете загружать данные о покупках месячной давности, алгоритм попытается связать их с текущими показами, что приведет к ложному обучению.

Для предотвращения этого в Conversions API встроено жесткое ограничение: параметр event_time должен находиться в диапазоне последних 7 дней от момента получения сервером Facebook. Все, что выходит за рамки этого окна, отбрасывается. Это ограничение особенно мешает при запуске свежих рекламных кабинетов, когда байеры пытаются использовать накопленную базу лидов. О стратегиях обучения новых пикселей читайте в статье прогрев пикселя.

Что означает ошибка 2804003 в Events Manager?

Когда трекер пытается отправить старую конверсию, Meta API возвращает JSON с ошибкой авторизации или обработки данных. В логах интеграции это выглядит следующим образом:

{
  "error": {
    "message": "Invalid parameter",
    "type": "OAuthException",
    "code": 100,
    "error_subcode": 2804003,
    "is_transient": false,
    "error_user_title": "Event Occurred Too Long Ago",
    "error_user_msg": "The event_time parameter specifies a time that is more than 7 days in the past. To ensure accurate attribution, events must be reported near the time they occurred."
  }
}

Эта ошибка означает, что событие удалено без обработки. Обучить пиксель такими лидами стандартным способом не удастся.

В чем опасность неправильной корректировки времени?

Первое решение, которое приходит в голову - заменить event_time в запросе на текущее время (timestamp отправки). Однако это ломает логику дедупликации.

Если пользователь совершил покупку на сайте, браузерный пиксель отправил событие Purchase с оригинальным временем. Если сервер CAPI отправит то же событие со сдвинутым временем, Facebook не сможет сопоставить их по времени и засчитает покупку дважды. Ваша статистика в рекламном кабинете поплывет, а пиксель начнет оптимизироваться под дубли.

Как устроен алгоритм Time Clamping для обхода лимита?

Чтобы обойти лимит 7 дней и сохранить дедупликацию, необходимо разделить физическое время отправки события и его логический уникальный идентификатор.

Алгоритм Time Clamping (зажатие времени) работает по следующему принципу:

1. Определение возраста: Most проверяет разницу между текущим временем и временем конверсии.
2. Зажатие event_time: Если лид старше 6 дней, Most принудительно устанавливает event_time = now - 6 дней (например, ровно 144 часа назад). Это значение укладывается в разрешенные 7 дней.
3. Сохранение уникального event_id: В качестве event_id передается строка, собранная из sub_id и исходного времени конверсии в UTC:
   Copy

   event_id = {sub_id}_Purchase_{исходное_время_в_UTC}

   Поскольку исходное время в идентификаторе не меняется, Facebook распознает дубль, даже если событие пришло со сдвинутым event_time.

Три слоя защиты от дублирования лидов

Most предотвращает отправку дубликатов на трех этапах обработки данных:

Это гарантирует, что даже при сбоях сети или перезапусках импорта лиды не задвоятся.

Пошаговый план: как исправить передачу времени в Keitaro

Если вы настраиваете интеграцию Keitaro с Facebook самостоятельно, следуйте этому алгоритму:

1. Сверьте системное время: Перейдите в настройки сервера Keitaro и убедитесь, что системное время установлено в UTC. Смешение временных зон - главная причина ошибок 2804004 (события в будущем).
2. Получите токен доступа: Подробную инструкцию по генерации токена можно найти в руководстве Facebook Pixel ID и Access Token.
3. Настройте маппинг статусов: В интеграции Keitaro сопоставьте внутренние статусы трекера (например, sale) со стандартными событиями Meta (Purchase).
4. Проверьте передачу fbclid: Убедитесь, что пиксель на лендинге захватывает параметр клика fbclid и передает его в трекер. Это критично для матчинга событий CAPI.

Как проверить дедупликацию событий через Test Events?

Для тестирования CAPI выполните следующие действия:

1. Откройте Events Manager Facebook, выберите ваш пиксель и перейдите во вкладку Test Events (Тестирование событий).
2. Скопируйте тестовый код (параметр test_event_code).
3. Отправьте тестовое событие CAPI с этим кодом через интерфейс трекера или Pixel Activator.
4. В Events Manager вы должны увидеть событие со значком сервера. Если вы также настроить отправку из браузера, Facebook свяжет их и покажет статус Deduplicated.

Автоматизация прогрева пикселя с помощью Most

Ручной контроль отправки исторических конверсий требует постоянных расчетов таймстемпов. Most убирает рутину.

Сервис работает в фоновом режиме: подключается к API Keitaro, забирает свежие конверсии, проверяет их возраст, при необходимости применяет Time Clamping и передает в Facebook CAPI. Вы один раз настраиваете маппинг событий, а дальше система работает самостоятельно по расписанию, обеспечивая стабильное EMQ и защиту от банов.

Источники