Разработчик Жандос показывает HTTP 200 и предлагает закрыть задачу по аналитике. Маркетолог открывает отчёт, а покупки там нет. Оба описывают то, что действительно видят, просто смотрят на разные участки маршрута. Ваша работа - соединить их наблюдения и найти первый переход, который ничем не подтверждён.
Для каждого случая запишите, что известно, что вы проверяете дальше и по какому признаку работа будет закончена. Это письменная самопроверка, цифры в примерах условные. Для практической части берите тестовую среду или разрешённые записи без персональных данных.
Случай: запрос принят, отправки дальше нет
Браузер отправил запрос на server-side endpoint, сервер ответил HTTP 200. В предварительном просмотре контейнера видны входящий запрос и объект события. А исходящего запроса к нужной аналитической платформе нет.
Коллега предлагает подождать, пока обновится отчёт. Какой участок нужно исследовать, прежде чем ждать? И какие наблюдения понадобятся после исправления, чтобы отличить отправленный запрос от покупки, которую платформа правильно учла?
Разбор: у каждого этапа своё свидетельство
HTTP 200 - это ответ вашего endpoint. По условию запрос до него дошёл и объект события появился. Значит, первый неподтверждённый переход лежит между работой серверного тега и отправкой получателю.
Предварительный просмотр sGTM показывает входящий запрос, Client, события, теги, исходящие запросы и ответы, так что маршрут можно пройти шаг за шагом. Но шаг, который прошёл, не подтверждает следующие.
У каждого этапа своё подтверждение
Endpoint
Входящий запрос принят, HTTP 200
Объект события появился
Серверный тег
Проверить статус, условия и ошибки
Client и обязательные поля тоже требуют проверки
Получатель
Исходящего запроса нет
HTTP 200 входа не подтверждает отправку платформе
Точную причину из одного HTTP 200 определить нельзя. После исправления повторяют тот же сценарий.
Посмотрите статус нужного тега, условия его запуска и сообщения об ошибках. Если тег не сработал, ищите условие, которое не выполнилось. Если он завершился ошибкой, читайте её текст и параметры. Потом выясните, получил ли тег обязательные поля и тот ли Client собрал данные. По одному HTTP 200 точную причину не найти.
После исправления повторите тот же сценарий. В запросе к получателю сверьте адрес назначения, тип события, идентификатор, сумму и валюту. Ответ получателя читайте вместе с его диагностикой: запрос доставлен, но как платформа его обработала и попал ли он в нужный отчёт, из этого ответа ещё не ясно.
В итоге проверка проходит весь путь: реальная операция, событие, отправка, приём и учёт. Если на тестовых значениях всё сходится, а в рабочем потоке расхождение осталось, его разбирают следующей задачей. Один удачный тест не описывает все события за месяц.
Случай: поле скрыли от одного тега
В объекте события есть internal_note, внутренняя заметка, которую внешним получателям передавать не нужно. Жандос создал transformation для одного тега и объявил, что заметка удалена из всей инфраструктуры.
Как вы проверите, на что правило действует на самом деле? Чем опасен список разрешённых полей, который пропускает лишнее, и чем - список, который отрезает нужное? Какие места останутся за пределами преобразования выбранного тега?
Разбор: фильтр проверяют у каждого получателя
Преобразования sGTM меняют параметры объекта события. По умолчанию правило действует на все теги; в блоке Affected tags его сужают до типов тегов или отдельных тегов. Поэтому сначала смотрят условия правила и список затронутых тегов, а потом фактические данные каждого исходящего запроса.
Если правило охватывает один тег, второй может по-прежнему получать internal_note. И даже правильный фильтр перед отправкой не уберёт поле задним числом из входящего браузерного запроса, прокси или журнала: у них свои настройки и свои места хранения. Поэтому вывод формулируют только для того маршрута, который проверили.
В режиме Allow parameters остаются только разрешённые параметры. Слишком широкий список может пропустить ненужную заметку. Слишком узкий отрежет поле, без которого тег не работает, и вместо одного риска вы получите потерю данных. Список составляют под задачу получателя и проверяют на тех событиях, которые он принимает.
На тестовом событии из разбора полей серверного тега Exclude parameters и Allow parameters дают одинаковый запрос; на рабочем событии с другими полями результат расходится. Поэтому работу принимают по исходящему запросу, скриншота настройки для этого мало.
Когда отправка идёт через ваш сервер, решения о составе данных, доступах и допустимых направлениях передачи остаются за командой. В этом задании достаточно подтвердить техническую границу фильтра. Юридическую оценку и соответствие всем правилам получателя такая проверка не заменяет.
Случай: 130 отправок на 100 заказов
У другого магазина в согласованном реестре 100 оплаченных заказов, а в журнале за тот же период 130 попыток отправить событие покупки. Каждый заказ стоит 10 000 ₸. Для расчёта все заказы оплачены, отмен и возвратов нет, и одна покупка должна учитываться один раз.
Команда видит в журнале суммы на 1 300 000 ₸. Один сотрудник называет это ростом продаж, другой предлагает удалить строки с одинаковой суммой. Почему не годится ни то, ни другое? Составьте ключ сверки и перечислите статусы, которые нужно получить.
Разбор: повтор доставки и пропуск могут существовать вместе
На старте известны 100 операций в бизнесе и 130 попыток передачи. Разница в 30 - это ещё не число дублей: часть покупок могла вообще не уйти, а по другим могло пройти несколько повторов. Тип события и границы периода тоже должны совпадать.
Свяжите реестр с журналом по устойчивому идентификатору операции и типу события. Свой идентификатор у каждой попытки помогает отличить повторные отправки. Для каждого заказа нужны время, число попыток, их результат и подтверждение, что получатель событие обработал. Записи, которые не связались с реестром, разбирают отдельно и к заказам по сумме не подклеивают.
Допустим, сверка показала следующее:
| Результат сверки | Количество |
|---|---|
| Уникальных заказов, представленных в журнале | 96 |
| Дополнительных попыток по этим же заказам | 34 |
| Оплаченных заказов без попытки отправки | 4 |
| Всего попыток в журнале | 130 |
Всё сходится: 96 + 34 = 130 попыток, а 96 + 4 = 100 заказов. Выручка магазина по условию 100 × 10 000 = 1 000 000 ₸. Сумма по всем попыткам завышает её на 300 000 ₸. Если оставить только уникальные заказы из журнала, выйдет 96 × 10 000 = 960 000 ₸, на 40 000 ₸ меньше реестра.
Лишние попытки и пропуски здесь живут одновременно. А если удалить строки с одинаковой суммой, останется одно значение 10 000 ₸, хотя у магазина 100 разных заказов. Операцию связывает устойчивый ключ, одинаковая цена для этого не годится.
Что из этого платформа уже учла, по сверке не понять. Повторы она могла обработать по своим правилам, отклонить или записать ещё раз. Дедупликация работает, когда тип и идентификатор одного события совпадают так, как требует получатель. Для пропусков сначала находят причину и безопасный способ дослать событие, сохранив исходный идентификатор операции.
Задание: оформите результат диагностики
Возьмите один тестовый маршрут своего проекта. Запишите операцию и её ключ, ожидаемые поля, отправителя, получателя и свидетельство на каждом переходе. Приложите разрешённый фрагмент журнала или опишите, что вы наблюдали. Назначьте владельца первого неподтверждённого участка и запишите, по какому повторному тесту работу примут.
По хорошей записи другой специалист сможет повторить вашу проверку. «Есть HTTP 200» без указания, кто ответил и на какой запрос, ему ничего не даст. «Дубли убрали» требует ключа, числа уникальных операций и сверки с реестром. Даже если суммы после исправления сошлись, остаётся подтвердить поля и то, что ни одна операция не пропала: одинаковые итоги могут скрывать разные ошибки.