Проверка отправки событий

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

В analytics-lab используем знакомый переход Markdown → XML. Его событие называется lesson_next; значение — активация ссылки, а не успешная загрузка следующего документа. Выберите для собственной практики локальный журнал или явно настроенный тестовый приёмник. Все результаты ниже описывают ожидаемое наблюдение, которое следует получить и записать самому.

Пять разных уровней

Сначала существует HTML: у ссылки есть правильный href, а data-next-article-id содержит xml. Затем браузер обрабатывает действие. Функция recordLessonEvent строит объект, адаптер вызывает метод платформы, а сервис позже отражает обработанные данные. Если между уровнями возникла ошибка, исследовать следует именно переход между ними.

Уровень	Что он подтверждает	Чего не подтверждает
HTML	Настройку ссылки и параметров	Выполнение JavaScript
Локальный объект	Вызов и форму события	Получение сервером
Метод платформы	Попытку передачи	Полную доставку
Network	Наблюдаемый запрос и ответ	Смысл строки итогового отчёта
Диагностика сервиса	Обработку в выбранном режиме	Полноту всей аудитории

Такое разделение не усложняет простое нажатие. Оно помогает не менять исправную часть. Например, если локальный объект имеет правильный ID, но ресурс в панели другой, переписывание обработчика ссылки не поможет. Если обработчик не вызван, попытка изменить цель в панели тоже не устранит причину.

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

Локальное свидетельство

Второй урок уже добавил событие браузера pw:analytics. Теперь подготовим полный вспомогательный файл assets/debug-events.js. Он ничего не отправляет провайдеру и не записывает сведения в постоянное хранилище. Его задача — показать полученные объекты в текущем экземпляре страницы.

const records = [];
window.addEventListener("pw:analytics", event => {
  records.push({
    observed_at: new Date().toISOString(),
    event: structuredClone(event.detail)
  });
  console.table(records.map(row => ({
    observed_at: row.observed_at,
    event_name: row.event.event_name,
    article_id: row.event.article_id,
    target_article_id: row.event.target_article_id ?? ""
  })));
});

Подключите этот модуль до article-events.js, если хотите видеть событие открытия. Если слушатель добавлен позже, ранняя запись не появится в его массиве. Это пропуск диагностического инструмента, а не доказательство, что lesson_open не сформировалось. Для открытия после подготовки слушателя нужна новая загрузка страницы, а не ручная подстановка строки в таблицу.

После одной обычной активации ожидается одна новая запись lesson_next с исходным markdown и назначением xml. Значение времени здесь — момент наблюдения локальным модулем. Оно не является временем обработки сервиса или временем открытия назначения. Различие пригодится при исследовании задержек и порядка событий.

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

Повторная инициализация

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

Защита data-analytics-ready из второго урока предотвращает повторную установку на том же корневом элементе. Однако она не проверяет весь сайт. Если другая библиотека отправляет событие самостоятельно, два канала могут продолжить работать. Поэтому ищите все места вызова и все способы подключения, а не ограничивайтесь проверкой одного флага.

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

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

Сеть и платформа

На уровне Network рассматривайте время, адрес назначения и результат запроса. Коды ответа и наличие запроса помогают локализовать проблему, но не объясняют настройку цели. В стандартном bootstrap вызов может попасть в очередь, а доставка — произойти позже или не состояться из-за блокировщика. Поэтому функцию ym или gtag нельзя использовать как единственный индикатор полной установки.

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

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

Рабочая запись проверки

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

Повторите проверку на старом XML-адресе и обычной Markdown-странице. Их внешний вид может быть одинаковым, а модуль или настройка ID — различаться. Общая оболочка помогает избежать этого, но правильность итогового HTML всё равно проверяется отдельно. После изменения шаблона тот же контрольный сценарий позволяет заметить регрессию.

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