Попросите подрядчика показать для одного просмотра товара три вещи: отправленный идентификатор, строки каталога, с которыми он совпадает, и ожидаемый вариант товара. Такой приёмочный лист помогает найти ситуацию, когда событие есть, но его ID ведёт к другой позиции или только к общей группе вариантов.
Ниже — проверка связки для розничного каталога Google Merchant Center и динамического ремаркетинга Google Ads. Общая настройка аудиторий и исключений разобрана в ответе о ремаркетинге Google Ads; здесь принимаем именно передачу товарных идентификаторов.
Сначала определите формат события
В справке Google Ads о параметрах динамического ремаркетинга розничный пример передаёт товар через items[].id. Для id указано совпадение с одним из атрибутов фида Merchant Center: id, item_group_id или display_ads_id. Параметр google_business_vertical со значением retail отмечен как рекомендуемый.
При этом руководство Google Ads API содержит пример с параметрами GA4: items[].item_id, который соответствует Product ID Merchant Center. А руководство Google tag использует в розничном примере id.
Поэтому совет «переименуйте все item_id в id» не годится как универсальное исправление. Сначала зафиксируйте, какой тег или шаблон отправляет данные, куда он их направляет и какое поле предусмотрено именно этим способом внедрения. Название события view_item само по себе этого не объясняет. Если задействовано преобразование параметров, сохраните значения до него и после.
Согласуйте, что именно должен обозначать ID
Для одной контрольной карточки запишите договорённость:
| Поле рабочего листа | Пример договорённости |
|---|---|
| Действие посетителя | Просмотр зелёного варианта кроссовок |
| Проверяемый отправитель | Розничный event snippet Google Ads |
Поле в объекте items | id |
| Колонка каталога для сверки | id |
| Ожидаемая позиция каталога | SKU-GREEN |
| Требуемая точность | Один выбранный вариант |
Колонка сверки — часть вашего рабочего листа, а не настройка внутреннего алгоритма Google. Она делает проверяемой договорённость команды: какое пространство идентификаторов используется и какую позицию обозначает значение.
Особенно полезно отделить вариант от группы. В учебном каталоге ниже зелёный и синий варианты имеют разные id, но общий item_group_id. Совпадение по группе допустимо в описанном Google розничном формате; оно не доказывает, что передан идентификатор конкретного зелёного варианта. Если задаче достаточно модели целиком, это следует явно записать в критериях приёмки.
id,item_group_id,display_ads_id,color
SKU-GREEN,MODEL-1,AD-GREEN,green
SKU-BLUE,MODEL-1,AD-BLUE,blue
00123,MODEL-2,AD-00123,black
Учебная схема локальной сверки. Она показывает найденные строки каталога, а не прогноз того, какой товар Google выберет для объявления.
Проверьте семь контрольных случаев
Для примера мы выполнили локальную сверку трёх строк каталога с семью событиями. В каждой строке таблицы заранее заданы поле события, колонка каталога и ожидаемый вариант; идентификаторы сравниваются точно. Это учебные данные, без отправки событий в Google и без обращения к рекламному аккаунту.
| Случай | Поле и значение события | Колонка сверки | Ожидаемая позиция | Результат |
|---|---|---|---|---|
| A | id: "SKU-GREEN" | id | SKU-GREEN | Один нужный вариант |
| B | Только item_id: "SKU-GREEN", хотя в договорённости задано id | id | SKU-GREEN | Ожидаемого поля нет |
| C | id: "MODEL-1" | item_group_id | SKU-GREEN | Найдены два варианта группы |
| D | id: 123 как число | id | 00123 | Проверить преобразование типа |
| E | id: "SKU-UNKNOWN" | id | SKU-GREEN | Совпадений нет |
| F | item_id: "SKU-GREEN" при договорённости с полем item_id | id | SKU-GREEN | Один нужный вариант |
| G | id: "AD-BLUE" | display_ads_id | SKU-GREEN | Найден другой вариант: SKU-BLUE |
Случаи B и F отличаются договорённостью о формате. Результат B означает, что локальная проверка не нашла ожидаемое поле; это не утверждение, что item_id вообще непригоден для ремаркетинга.
В случае D действует наше правило сохранения ID строкой. Оно защищает непрозрачные идентификаторы вроде 00123 от потери нулей. Это внутреннее правило примера, а не требование Google использовать только строки: в розничном примере Google встречается числовой id.
В случае G формальное совпадение есть, но бизнес-проверка не пройдена. Если сверять только существование значения в каталоге, синий товар ошибочно получит отметку «всё верно» при просмотре зелёного.
Чтобы повторить логику в таблице, сначала проверьте наличие согласованного поля и сохранность значения, затем отберите все строки по согласованной колонке. Отдельно запишите число совпадений и их id; единственную найденную позицию сравните с ожидаемым вариантом. Не подставляйте автоматически другое поле, если нужного нет: такая подстановка скрывает расхождение внедрения с договорённостью.
Что запросить у подрядчика для приёмки
Проверьте несколько реальных действий на тестовом устройстве: открытие карточки, смену варианта и добавление в корзину. Для каждого сохраните время, URL, выбранный вариант, версию тега или шаблона, получателя события, фактически отправленные параметры и актуальную выгрузку каталога. Удалите из передаваемых примеров данные пользователя и заказа, если они не нужны для проверки товара.
Сначала возьмите контрольный товар, по которому ожидается совпадение. Затем проверьте пару вариантов с общей группой и позицию с чувствительным к преобразованию ID. Разбирайте расхождение по цепочке: выбранная карточка → данные страницы → параметры отправителя → найденные строки каталога. Это помогает передать исправление ответственному за конкретный участок, сохранив исходные значения для повторной проверки.
Если договорённость требует точного варианта, отметка о приёмке должна содержать его id. Результаты «совпадений нет», «другая позиция» и «только группа» требуют разных решений; общий статус «событие сработало» их не заменяет.
Где заканчивается эта проверка
Локальное совпадение подтверждает связь двух сохранённых наборов данных. Оно не подтверждает доставку параметров в нужный аккаунт, обработку каталога, право на персонализацию, готовность аудитории или фактический показ объявления. Эти проверки выполняются отдельно в используемом внедрении и диагностике сервиса.
Метод сверки можно выполнить локально без покупки сервисов. Доступность Merchant Center и рекламных функций для конкретного бизнеса, страны продаж и аккаунта нужно проверять отдельно; наличие документации не подтверждает возможность запуска из Беларуси.
Следующий шаг — приложить рабочий лист с ожидаемыми позициями к проверке динамического ремаркетинга. Структуру самого файла можно предварительно проверить в анализаторе фида; эта проверка файла не подтверждает передачу ID из событий.
Источники
Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.
Что думаете?
Загружаем комментарии…