Как связаны баннер и запуск счетчиков
Баннер может закрываться по кнопке, пока счетчик уже отправляет сведения о посетителе. Бывает и обратная ситуация: после согласия аналитика не запускается или подключается дважды. Проверяем связь между выбором человека и загрузкой инструментов на конкретном сайте.
По документации Яндекс Метрики, сервис использует идентификаторы браузеров в cookie и localStorage. Перечень инструментов и режимов работы нужно установить фактически, прежде чем описывать их в политике или менять настройки.
Сначала устанавливаем источники подключения
Счетчик может быть добавлен в настройки сайта, код темы, отдельный плагин или контейнер тегов. Виджет способен подгружать дополнительные инструменты самостоятельно. Поэтому начинаем с поиска всех действующих источников, которые относятся к согласованной задаче. Изменение одного фрагмента кода не будет достаточным, если такой же сервис продолжит запускаться другим способом.
Сопоставляем найденные подключения с целями владельца: какие отчеты используются, какие события отслеживаются и какие инструменты больше не нужны. Это помогает обсуждать необходимые изменения предметно. Автоматически удалять все внешние сервисы или отключать аналитику целиком без согласования не предлагаем.
При первичной проверке полезны перечень счетчиков, сведения о менеджере тегов и название существующего баннера. Если инструменты устанавливали разные подрядчики, уточняем, кто может менять каждую настройку. Отсутствие доступа к одному контейнеру отмечаем как ограничение: внешне правильное окно еще не показывает, какие команды выполняются через недоступную часть подключения.
Назначение хранения тоже разбираем отдельно. Например, сохранение корзины и сбор статистики посещений выполняют разные задачи. Для технического решения устанавливаем, какой инструмент создает конкретную запись в браузере и какой сценарий будет нарушен при его отключении.
Что входит в работу
- Поиск счетчиков, рекламных пикселей, контейнеров тегов и виджетов в согласованных страницах.
- Проверка существующего баннера, сохраненного выбора и повторного открытия сайта.
- Сверка описания аналитики и cookie с подключенными сервисами.
- Настройка запуска выбранных инструментов после согласия, если этот сценарий принят для сайта.
- Проверка отказа от необязательной аналитики и возможности изменить решение.
Сначала определяем назначение инструментов и основание обработки. Не переносим одинаковое правило на технические cookie корзины, аналитику и рекламные системы без разбора. Условия обработки оцениваем по статье 6 закона.
Что проверяем в каждом состоянии выбора
Первую проверку проводим в чистой сессии, где отсутствует ранее сохраненное решение посетителя. Фиксируем, какие запросы отправились при загрузке страницы, какие записи появились в хранилище и какие инструменты действительно начали работать. Один снимок открытого баннера без этих наблюдений не позволяет сделать вывод о порядке загрузки аналитики.
Затем проверяем доступные действия отдельно. Для согласованного запуска после разрешения смотрим, загружается ли выбранный счетчик и не повторяется ли его инициализация. Для отказа проверяем, что необязательные инструменты не запускаются в обход принятой настройки. Если предусмотрены категории, сопоставляем каждый переключатель с относящимися к нему сервисами.
После обновления страницы выбор должен обрабатываться по согласованному правилу. Дополнительно проверяем переход на другой шаблон сайта: главная, карточка услуги и страница заказа могут подключать разные наборы кода. Если виджет появляется только при отдельном действии, воспроизводим и этот путь в пределах задачи.
Изменение решения рассматриваем самостоятельным сценарием. Посетитель должен понимать, где открыть настройки повторно. Проверяем, как меняется состояние инструментов после нового выбора и какие ограничения остаются у уже загруженного внешнего кода. Возможность прекратить последующие обращения и вопрос ранее переданной информации не объединяем в одно обещание.
Результаты удобно записывать по схеме: действие посетителя, наблюдаемое состояние, отправленные запросы, обнаруженное расхождение. В такой записи можно повторить проверку после исправления, даже если внешний вид баннера за это время изменился.
Как проверяем результат
Открываем сайт в чистой сессии браузера и смотрим сетевые обращения, cookie и хранилище до выбора. Затем повторяем проверку после согласия, отказа, обновления страницы и изменения решения. Это показывает поведение проверенных инструментов в каждом сценарии.
Отдельно проверяем источники повторного подключения. Например, один счетчик может одновременно находиться в настройках CMS, плагине и контейнере тегов. Если управлять только одним экземпляром, выбор посетителя не будет управлять остальными.
После настройки проверяем видимые элементы на телефоне: баннер не должен перекрывать отправку формы, ссылки на документы должны открываться, а действия посетителя давать ожидаемый результат. Доступность кнопок оцениваем вместе с их фактической работой.
Как согласуем техническое решение
Если существующий баннер умеет управлять нужными инструментами, сначала оцениваем возможность его настройки. Новое окно не требуется только ради другого оформления. Когда текущий механизм лишь показывает сообщение, определяем, какие изменения нужны для связи между выбором посетителя и загрузкой согласованных сервисов.
Учитываем порядок выполнения кода. Например, баннер может появляться после того, как плагин уже подключил счетчик. В этом случае изменение текста кнопок не исправляет очередность. Предлагаем корректировку конкретного источника подключения и проверяем ее после публикации. Техническое действие выбираем по устройству сайта, не обещая одинаковый способ для всех платформ.
Согласуем и видимую часть: понятность действий, доступ к описанию обработки, повторное открытие настроек и поведение на телефоне. Панель не должна мешать посетителю пользоваться согласованными функциями сайта. При этом удобство окна проверяется вместе с работой инструментов, поскольку визуальное закрытие панели само по себе не подтверждает выполнение выбранного действия.
Если в задачу входит проверка целей, уточняем смысл каждого события. Клик по кнопке, открытие формы и подтвержденный прием заявки отражают разные этапы. Проверяем, что выбранный счетчик получает событие в предусмотренном сценарии и не получает лишний повтор при обновлении страницы. Подтверждение доставки уведомления или учет оплаты требуют собственных данных; событие аналитики само по себе их не доказывает.
Что вы получите
В согласованном объеме настроим баннер, связь с аналитикой и тексты о выбранных инструментах. Передадим перечень изменений и результаты проверки сценариев. Если обнаружится внешний сервис, которым нельзя управлять из текущего сайта, опишем ограничение и предложим вариант решения.
Изменение порядка запуска счетчиков влияет на состав доступной аналитики. Перед изменениями обсудим, какие события зависят от выбора посетителя. Сохранение прежнего числа визитов и целей при новом порядке загрузки не обещаем.
Если настройку выполняет ваш разработчик
Для передачи задачи другому исполнителю полезен перечень конкретных подключений и ожидаемого поведения. В нем указывают, какой источник нужно изменить и каким действием посетителя проверяется результат. Список названий счетчиков без этой связи оставляет возможность исправить только часть проблемы. После передачи изменений на сайт повторяют согласованные проверки опубликованной версии. Если часть кода осталась у другого подрядчика, ее статус сохраняется отдельным пунктом до получения подтверждения.
Условный пример и материалы для приемки
Предположим, на сайте есть баннер, который управляет счетчиком в коде темы. Позже подрядчик добавил тот же счетчик через менеджер тегов. Посетитель отказывается от аналитики, но второй источник продолжает отправлять запросы. Внешне баннер выглядит исправным, поэтому проблема обнаруживается при просмотре фактической загрузки.
Для такой ситуации сначала подтверждаем оба подключения, затем согласуем единое управление их запуском. Повторно проверяем чистую сессию, отказ, согласие и переход между страницами. Если доступ к менеджеру тегов отсутствует, этот участок нельзя считать исправленным до изменения и проверки его конфигурации.
В согласованном результате фиксируем перечень затронутых инструментов, источники их подключения и состояния, которые удалось проверить. Отдельно отмечаем внешние ограничения и действия владельца. Это учебный пример последовательности, без утверждения о наличии такого нарушения на вашем сайте или выполненной работе у клиента.
После добавления рекламного пикселя, новой формы или чата прежние результаты не следует автоматически переносить на изменившийся сайт. Сохраненный перечень настроек помогает определить, какой сценарий проверить повторно и с кем согласовать изменение. Постоянное наблюдение за всеми будущими подключениями обсуждается отдельно.
Что нужно для начала
Понадобятся адрес сайта, доступ для согласованных изменений и сведения о подключенных инструментах. Доступ к настройкам Метрики запрашиваем, если они входят в задачу. Стоимость и срок определяем после проверки платформы и числа интеграций.
Установка одного баннера не подтверждает соответствие всего сайта 152-ФЗ. Формы, документы, получатели заявок и действия оператора требуют собственной проверки. После добавления новых тегов или виджетов согласованные сценарии стоит проверить повторно.
