Как проверить согласие на аналитику в Shopify за пределами cookie баннера

Меня заинтересовало обсуждение на Shopify Community о довольно простом на первый взгляд противоречии. Посетитель ещё ничего не выбрал в cookie-баннере, а в браузере уже видна активность инструментов аналитики. Возникает естественный вопрос: магазин действительно ждёт решения человека или только показывает ему соответствующий интерфейс?

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

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

Как сохранение корзины стало частью истории отслеживания

В феврале 1997 года RFC 2109 описывал механизм сохранения состояния между HTTP-запросами. Среди примеров прямо упоминалась корзина покупок. Сам по себе запрос страницы не объяснял серверу, как он связан с предыдущими действиями; cookie помогали сохранять эту связь. Документ сегодня имеет историческое значение и не служит инструкцией для современной реализации.

Мне кажется полезным помнить исходную задачу. Сохранить выбранные товары и узнавать человека при посещении разных сайтов — разные цели, даже если в обоих случаях используется cookie. Поэтому вопрос «есть ли cookie» слишком грубый. Я хочу знать, для чего хранится информация, кто её получает и какое решение посетителя должно управлять этим процессом.

Следующим этапом стало развитие правил доступа к информации на устройстве. Поправки 2009 года к европейской ePrivacy Directive закрепили требование согласия с предусмотренными исключениями; историю этого изменения разбирает European Data Protection Supervisor. Позже, с 25 мая 2018 года, начал применяться GDPR. Это связанные, но разные правовые уровни: доступ к информации на устройстве и обработка персональных данных нельзя свести к одной настройке баннера.

Параллельно менялись браузеры. В июне 2017 года WebKit представил Intelligent Tracking Prevention для ограничения межсайтового отслеживания через cookie и другие данные сайтов. Для меня здесь существенен управленческий вывод: согласие посетителя и техническая возможность измерить его действия стали независимыми условиями. Полученное согласие само по себе не отменяет ограничения браузера и не гарантирует полноту отчёта.

В сентябре 2020 года Google представил Consent Mode, позволяющий менять поведение тегов в зависимости от выбора человека. В ноябре 2023 года механизм дополнили параметрами ad_user_data и ad_personalization. Разрешение на рекламное хранилище, передачу пользовательских данных для рекламы и персонализацию рекламы стало нужно передавать раздельно.

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

Что я принимаю в аргументах участников форума

В обсуждении Shopify Community dropfeed предложил сопоставить выбор посетителя, разрешения Shopify и сетевые запросы. В описанном наблюдении незаполненный выбор сочетался с разрешённой обработкой; после отказа разрешения менялись. JohnQQ обратил внимание, что загрузка ресурса ещё не доказывает отслеживание. Это сообщения участников, а не проведённый мной аудит магазина.

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

Я бы продолжил разговор вопросом о последовательности. Что произошло до выбора, что изменилось после отказа и что сохранилось при следующем открытии страницы? Именно такое сравнение позволяет проверить гипотезу. Снимок консоли в произвольный момент оставляет слишком много альтернативных объяснений.

Почему пустой выбор и разрешённая обработка могут сосуществовать

Shopify различает сохранённое решение посетителя и вычисленное разрешение на обработку. В Customer Privacy API методы Allowed учитывают настройки магазина, определённое местоположение и согласие. Для регионов, настроенных как требующие согласия, необязательные цели по умолчанию запрещены до его получения; для остальных стандартное поведение отличается.

Поэтому пустое значение currentVisitorConsent() и true у analyticsProcessingAllowed() сами по себе ещё не устанавливают ошибку. Я проверил бы определённый регион и настройки магазина. Полученное true описывает работу конфигурации, а не юридическое заключение о том, что именно этому бизнесу разрешено делать.

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

Для app pixels Shopify проверяет заявленные разрешения перед загрузкой. У custom pixels требования задаются отдельно. Я бы проверял соответствие этих настроек реальному назначению интеграции. Снятие требования согласия ради того, чтобы тест наконец показал событие, меняет поведение системы; это не исправление причины, по которой разрешение до неё не дошло.

Когда запрос после отказа требует объяснения

У Google есть базовый и расширенный варианты Consent Mode. В базовом варианте Google-теги блокируются до согласия. В расширенном они могут загружаться при denied и передавать измерения без cookie. Поэтому наличие запроса после отказа нужно сопоставлять с выбранным режимом и составом передаваемой информации.

Я не стал бы автоматически объявлять такую отправку нарушением или подтверждением корректности. Возможность, описанная поставщиком технологии, ещё не отвечает на вопрос о допустимости конкретной обработки. Для магазина необходимо заранее определить требования по рынкам и целям, а затем проверить реализацию этих требований. Если согласован полный запрет отправки определённому получателю до согласия, наличие соответствующих запросов расходится с этим условием независимо от отсутствия cookie.

Представим условный случай. Баннер записал отказ, но старый тег в теме продолжает отправлять обычное событие покупки. Рядом работает актуальная интеграция, которая учитывает выбор. Проверка только новой интеграции даст успокаивающий результат, хотя второй маршрут останется. Я бы устанавливал источник каждого события и убирал подтверждённый лишний маршрут после проверки оставшегося.

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

Как я бы организовал проверку и исправление

Начал бы с перечня получателей и способов подключения: приложение, custom pixel, код темы, контейнер тегов, серверная интеграция. Для каждого зафиксировал бы цель, необходимые разрешения, ответственного и ожидаемые события. Затем согласовал бы поведение по рынкам с тем, кто отвечает за требования к обработке данных. Разработчику нужна определённая задача, а не предложение сделать «как обычно».

После этого я проверил бы пять сценариев в чистом тестовом профиле браузера: первый визит без выбора, отказ, согласие только на аналитику, полное согласие и последующий отзыв. Для каждого нужны повторное открытие страницы и переход от товара к корзине и оформлению заказа. Существующий профиль с сохранённым согласием не заменяет проверку первого визита. Отдельно я бы повторил ключевые сценарии в Safari и Chrome, на телефоне и компьютере.

В протоколе я хочу видеть URL, время, определённый регион, версию баннера и интеграции, состояние разрешений и действия пользователя. В браузере сопоставляются записи в хранилищах, запросы, их инициаторы и параметры. Для Google Tag Assistant помогает проверить исходное состояние и его изменение. Запись сети следует начинать до загрузки страницы; журнал после нажатия кнопки не расскажет, что успело уйти раньше.

Решение зависит от найденного разрыва. Если сторонний баннер не передаёт выбор в Shopify, исправляется интеграция с Customer Privacy API — эта зависимость отражена в инструкции по проверке пикселей. Если Google получает обновление слишком поздно, нужно исправить порядок инициализации: его руководство требует установить исходное состояние до команд измерения. Если отправляет старый код темы, его работу проверяют отдельно от нового пикселя.

Я не рекомендую универсальную вставку кода для всех этих случаев. Она может продублировать действующую интеграцию или исправить только один из маршрутов. Мне нужен воспроизводимый дефект и минимальное изменение, устраняющее именно его. Такой результат я ожидаю от диагностики Shopify-магазина: понятная причина, границы проверки и план подтверждения исправления.

Серверную отправку также включаю в обследование. В серверной архитектуре Google Tag Manager сигналы согласия передаются дальше вместе с запросом и влияют на работу тегов. По чистому журналу браузера нельзя заключить, что приложение не отправляет данные с сервера. Нужны настройки и журналы соответствующего маршрута; перенос обработки на сервер сам по себе не устраняет необходимость учитывать выбор человека.

Какой результат имеет смысл принять владельцу магазина

Я бы принимал работу по воспроизводимым сценариям. До выбора и после отказа система выполняет согласованные ограничения. После частичного согласия включаются только соответствующие цели. Отзыв меняет последующую обработку и сохраняется при навигации. В разрешённых сценариях нужные события доходят корректно, а корзина и оформление заказа продолжают работать. Для каждого пункта должны быть наблюдения и перечисленные ограничения проверки.

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

С рекламными отчётами нужна та же аккуратность. Shopify связывает часть расхождений по посетителям и сессиям с согласием. Поэтому снижение числа наблюдаемых сессий после исправления ещё не доказывает падение спроса. Я сопоставлял бы заказы, период, рынки, рекламные изменения и долю доступных наблюдений. Это соответствует подходу к аналитике бизнеса в IceStoreLab: прежде чем делать вывод по показателю, понять источник и ограничения данных.

Из этого обсуждения я выношу вполне конкретное требование к работе. Владелец должен понимать, какие данные собираются при каждом выборе посетителя и на каком основании команда считает настройку правильной. История развития технологии объясняет, почему ответ больше не помещается в наличие баннера. А хорошая диагностика превращает этот сложный вопрос в проверяемые действия, распределённую ответственность и результат, который можно поддерживать после следующего обновления магазина.