Согласие не выдано или не сохраняется

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

Модель, из которой следуют все симптомы

Три факта объясняют почти каждую жалобу на согласие.

1. Решение живёт только в памяти страницы. ActionPulse не пишет согласие ни в cookie, ни в localStorage, ни на сервер. При каждой полной загрузке страницы состояние начинается заново с того, что указано в разметке.
2. Значение по умолчанию — «собирать». Состояние pending включается только явно. Любое неизвестное значение атрибута, наоборот, трактуется как ожидание — это единственное место, где поведение по умолчанию строже.
3. До согласия трекер полностью пассивен. Он не создаёт идентификаторов, не пишет в хранилище браузера, не запрашивает конфигурацию сбора и не отправляет ни одного запроса. Поэтому «нет запросов» — ожидаемая картина, а не поломка.

Как значение data-consent превращается в состояние:

Значение в разметке	Состояние	Сбор до вызова CMP
атрибута нет	granted	идёт
data-consent="" (пустое)	granted	идёт
data-consent="required"	pending	нет
data-consent="pending"	pending	нет
data-consent="granted"	granted	идёт
data-consent="denied"	denied	нет
любое другое, в том числе true, yes, Required	pending	нет

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

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

Сбор не начинается вообще: ни одного запроса

Вероятная причина. Состояние осталось pending: либо ваш CMP не вызывает pp.setConsent('granted'), либо вызывает его в категории, которая на этом сайте не срабатывает, либо значение data-consent не то, что вы предполагали (см. таблицу выше).

Как проверить. В консоли страницы:

typeof window.pp;  // 'object' — трекер загрузился
pp.getConsent();   // 'pending' — сбор не начат

Дополнительно: в хранилище браузера нет ни одного ключа с именем pp_anon_id, pp_user_id, pp_session, pp_buffer_v2, а во вкладке «Сеть» нет ни запроса /v1/cfg, ни запроса /v1/track. Всё это вместе — картина корректного ожидания решения.

Безопасное исправление. Вызовите решение из колбэка CMP и убедитесь, что колбэк действительно выполняется:

function onAnalyticsConsentGranted() {
  if (window.pp) pp.setConsent('granted');
}

Ничего удалять и переустанавливать не нужно: вызов включает сбор в тот же момент.

Если не помогло. Если pp.getConsent() возвращает granted, а запросов по-прежнему нет — дело не в согласии. Проверьте, что токен подставился в разметку и что не заданы одновременно data-token и data-key с разными значениями: в этом случае трекер молча не инициализируется. Инструменты — в диагностике отправки.

Сбор начинается и сразу прекращается

Вероятная причина. После granted приходит второй вызов с denied или revoked. Типовой источник — CMP, который сообщает решения по категориям: одна категория разрешена, а вторая, куда попал ваш тег, запрещена, и её колбэк срабатывает позже. Второй вариант — сбор не прекратился, а сузился: конфигурация сбора недоступна, и трекер выключил всё необязательное, оставив только просмотры страниц.

Как проверить. Сравните два наблюдения. Первое — состояние после того, как баннер отработал:

pp.getConsent();  // 'denied' или 'revoked' — было явное запрещающее решение

Второе — хранилище браузера. Запрещающее решение стирает pp_anon_id, pp_user_id, pp_session, pp_buffer_v2 и ключи записи сессий в sessionStorage. Пустое хранилище при загруженном трекере — надёжный признак именно отзыва, а не сбоя сети.

Если же getConsent() возвращает granted, посмотрите в сетевой панели ответ на /v1/cfg: код 200 или 304 — норма, любой другой ответ выключает автосбор, записи сессий и диагностику, а просмотры страниц продолжают идти.

Безопасное исправление. Привяжите вызов setConsent к той категории согласия, в которой у вас действительно находится аналитика, и уберите дублирующий запрещающий вызов. Никаких данных при этом не теряется: уже принятые события остаются в проекте.

Если не помогло. Проверьте, не включён ли учёт заголовка Do Not Track. При подключении из бандла есть параметр respectDoNotTrack: с ним трекер отключается целиком, при этом getConsent() может по-прежнему возвращать granted — состояние согласия и признак отключения независимы. В режиме подключения скриптом такого параметра нет.

Сбор работает до перезагрузки страницы и перестаёт после

Вероятная причина. Это ожидаемое поведение, а не дефект. Решение хранится в памяти страницы. Полная загрузка — новая страница, новое состояние, и оно берётся из data-consent. Ваш CMP помнит согласие в своём хранилище и поэтому не показывает баннер повторно — а трекер об этом ничего не знает.

Как проверить. Дайте согласие, убедитесь, что запросы на /v1/track идут, затем обновите страницу и, не нажимая ничего в баннере, вызовите:

pp.getConsent();  // 'pending' — решение не перенеслось

Если баннер при этом не показан, диагноз подтверждён: CMP считает решение данным, но не сообщает его трекеру.

Безопасное исправление. Передавайте решение на каждой загрузке страницы — из того же места, где CMP восстанавливает своё сохранённое решение, а не только из обработчика клика по баннеру:

// Вызывается и при клике по баннеру, и при инициализации CMP на новой странице
function applyAnalyticsConsent(decision) {
  if (!window.pp) return;
  pp.setConsent(decision === 'granted' ? 'granted' : 'denied');
}

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

Если не помогло. В одностраничном приложении переход между экранами не перезагружает страницу, поэтому симптом виден только при полном обновлении и при переходе на другой домен или поддомен. Если сбор пропадает и при навигации внутри приложения, ищите причину не в согласии, а в повторной инициализации клиента.

Отзыв согласия не срабатывает

Вероятная причина. Одно из двух. Либо в setConsent передано значение вне набора — принимаются ровно granted, denied и revoked, всё остальное молча игнорируется, и состояние остаётся прежним. Либо отзыв сработал, но не сохранился: на следующей загрузке страницы разметка снова говорит «собирать», потому что data-consent отсутствует или равен granted.

Как проверить. Сразу после вызова отзыва:

pp.setConsent('revoked');
pp.getConsent();  // должно быть 'revoked'

Если вернулось прежнее значение — значение аргумента не принято, проверьте написание. Если вернулось revoked, обновите страницу и проверьте снова: если после обновления состояние стало granted, отзыв не переживает перезагрузку.

Безопасное исправление. Поставьте в теге data-consent="required" и вызывайте pp.setConsent('denied') на каждой загрузке, пока посетитель не изменил решение. Тогда отзыв действует и после перезагрузки, а не только до неё.

Если не помогло. Проверьте, что вы вызываете метод того же экземпляра, которым инициализировали сбор. В режиме скрипта это глобальный объект pp; при подключении из бандла глобального объекта нет, и вызов pp.setConsent в консоли не имеет отношения к вашему клиенту.

Баннер выдаёт согласие позже, чем загружается страница

Вероятная причина. Колбэк CMP выполняется раньше, чем на странице появился объект pp, и вызов падает с ошибкой. Дальше по колбэку ничего не выполняется — в том числе вызовы других счётчиков.

Как проверить. В консоли ищите ошибку вида «pp is not defined» или «Cannot read properties of undefined». Порядок тегов виден в разметке: тег CMP и тег трекера могут загружаться асинхронно и в любом порядке.

Безопасное исправление. Всегда проверяйте наличие объекта перед вызовом и повторяйте попытку, когда трекер появился:

let pendingDecision;

function applyAnalyticsConsent(decision) {
  pendingDecision = decision;
  if (window.pp) pp.setConsent(decision);
}

window.addEventListener('load', () => {
  if (window.pp && pendingDecision) pp.setConsent(pendingDecision);
});

Обратный порядок безопасен: если тег трекера уже в разметке, а решение пришло до его инициализации, трекер запомнит решение и применит его при инициализации — терять вызов из-за «слишком рано» не нужно.

Если не помогло. Позднее согласие означает, что часть картины теряется, и это не лечится настройками:

• вызовы pp.track() до согласия не буферизуются — они отбрасываются и задним числом не отправляются;
• просмотр страницы фиксируется в момент выдачи согласия, с текущим адресом. Если одностраничное приложение к этому моменту уже сменило адрес, первый экран в отчёт не попадёт.

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

Что проверить перед обращением в поддержку

1. pp.getConsent() на проблемной странице — и сразу после загрузки, и после того, как баннер отработал.
2. Значение атрибута data-consent в разметке, как её отдаёт сервер, а не как она написана в шаблоне.
3. Есть ли в сетевой панели запрос /v1/cfg и с каким кодом он ответил.
4. Есть ли в хранилище браузера ключи pp_anon_id и pp_session после согласия.
5. Обновляется ли картина после перезагрузки страницы — это отделяет «не выдано» от «не сохраняется».

Полное описание состояний, поведения до решения и связи с баннером — в руководстве по согласию.