В Shopify указана одна цена, а в карточке Merchant Center видна другая: повторная синхронизация не объясняет расхождение.
Быстрый способ: не считайте правильным ни последнее значение в Shopify, ни последнюю загрузку. Найдите источник конкретной записи, проверьте сопоставление поля и применимые правила, затем подтвердите обработанный результат в карточке товара.
Эта инструкция для специалистов по Shopify, которым нужно объяснить расхождение полей магазина и Merchant Center.
Она также пригодится менеджерам каталогов и рекламы, если товарные сведения поступают из нескольких источников.
Руководителям, отвечающим за совместную работу, здесь предложен формат записи, который можно передать коллеге и повторно проверить.
SECTION 01Почему нельзя определить итоговое значение по времени изменения
Короткий ответ: порядок поступления данных сам по себе не доказывает, какое значение Merchant Center обработал для конкретного атрибута. Сначала выясните, откуда взялась запись товара, какие поля сопоставлены и какие правила к ней применимы.
Google описывает несколько способов передачи сведений о товарах: среди них подключение платформы, файлы, таблицы и API. Это разные пути поступления данных, поэтому похожая карточка в Shopify и Merchant Center ещё не подтверждает, что вы сравниваете один и тот же источник или один и тот же товар. Перечень способов передачи приведён в справке Google о добавлении товарных данных.
У расхождения есть несколько частых причин:
- Другая запись или вариант. В Shopify вы открыли товар, а в Merchant Center — запись конкретного варианта либо другой элемент каталога.
- Несовпадающие поля. Значение из поля Shopify может передаваться не в тот атрибут Merchant Center, который вы сравниваете.
- Дополнительный источник. Данные поступают не только из подключённого магазина; в каталоге может быть другой источник со своей ролью.
- Правило изменяет данные. Условие или действие правила может преобразовать входное значение для целевого атрибута.
- Смешение разных статусов. Черновик правила, результат теста, применённое правило и статус одобрения товара — не одно и то же.
Отсюда важное ограничение: нет универсального ответа вроде «Shopify всегда главный» или «последний файл побеждает». Приоритет конкретного значения зависит от фактической записи и настроек аккаунта. Если в деталях источника или истории обработки нет достаточных сведений, зафиксируйте неопределённость и сверьтесь с актуальной справкой, а не выдавайте предположение за правило платформы.
SECTION 02Какие проверяемые признаки помогут найти причину
Вместо общего сравнения «Shopify против Merchant Center» разбирайте расхождение по признакам. Такой подход позволяет отделить ошибку источника от неверного сопоставления и от состояния самого товара.
| Вариант проверки | Что сопоставить | Какой вывод допустим |
|---|---|---|
| Источник товара | Идентификатор записи, источник данных и его сведения в Merchant Center | Можно установить путь, по которому поступила проверяемая запись; нельзя выводить победителя только по времени загрузки |
| Сопоставление полей | Поле Shopify, поле источника и целевой атрибут Merchant Center | Можно определить, действительно ли сравниваются эквивалентные свойства |
| Правило атрибута | Источник, целевой атрибут, условие, действие и состояние правила | Можно проверить, распространяется ли преобразование на эту запись |
| Идентичность товара | Идентификатор, вариант и группировка вариантов | Можно отделить расхождение в одном товаре от сравнения разных вариантов |
| Результат обработки | Тест правила и фактическое значение в карточке товара | Можно зафиксировать тестовый и наблюдаемый результат, не приравнивая их к одобрению или показу |
Чтобы понять, что именно показывают данные, откройте в Merchant Center сведения о конкретном товаре и запишите доступные там атрибуты и сведения об источнике. В инструкции Google по просмотру товарных данных описано, как проверять данные товара в интерфейсе. Не заменяйте эту проверку поиском товара в публичной витрине: отсутствие показа само по себе не объясняет, какое значение было обработано.
Для спорного атрибута ведите три отдельных значения:
- Вход: значение в Shopify или другом источнике до обработки.
- Сопоставление: поле источника и соответствующий целевой атрибут.
- Результат: значение, показанное в деталях товара после обработки.
Например, если расходится цена, сначала убедитесь, что сравниваете одну валюту, один вариант и одно поле цены. Затем запишите входное значение, поле источника и атрибут Merchant Center. Только после этого проверяйте правило. Для наличия товара применяйте ту же схему, но не предполагайте, что поле с похожим названием автоматически соответствует нужному атрибуту.
Важно: требования к конкретному атрибуту и допустимое представление данных сверяйте с официальной спецификацией товарных данных Google. Совпадение названий полей в двух системах не доказывает совпадение их назначения.
SECTION 03Как проверить товарный источник и идентификатор
Сначала выберите одну конкретную запись, у которой есть воспроизводимое расхождение. Не сравнивайте весь каталог сразу: массовое сопоставление затрудняет поиск причины и повышает риск принять разные варианты за один товар.
Первый этап: зафиксируйте товар в обеих системах
- В Shopify откройте товар, затем выберите именно тот вариант, значение которого расходится.
- Запишите идентификатор, название варианта и исходное значение нужного поля.
- В Merchant Center откройте соответствующую запись и сохраните её идентификатор, атрибут, показанное значение и доступные сведения об источнике.
- Сопоставьте записи по идентификатору, а не только по названию товара: названия могут совпадать у разных вариантов.
- Если не удаётся установить, что записи соответствуют друг другу, остановите разбор правил и сначала выясните, какой именно товар или вариант вы открыли.
Если в Merchant Center доступны сведения о нескольких источниках или товарных предложениях, записывайте их отдельно. Не сводите разные каналы загрузки в одну строку «Shopify». В официальном описании создания источников данных Merchant Center можно проверить актуальные термины и варианты управления источниками.
Второй этап: подтвердите, что это одно и то же поле
Составьте для спорного атрибута цепочку:
поле Shopify → поле в источнике данных → атрибут Merchant Center → значение в карточке товара.
Если цепочка обрывается, например поле Shopify передаётся в другой атрибут, это не подтверждённый конфликт значений. Это может быть ошибка сопоставления или неверно выбранный объект сравнения.
Проверяйте атрибуты по одному. Для заголовка зафиксируйте текст, пришедший из источника, и итоговый заголовок. Для цены — само значение, валюту и выбранный вариант. Для наличия — исходное поле и атрибут, который вы видите в Merchant Center. Такая точность нужна не для того, чтобы угадать внутреннюю логику обработки, а чтобы отделить входные данные от результата.
У вариантов товаров может быть общий идентификатор группы, но он не заменяет проверку конкретного предложения. Сверьте, какой идентификатор относится к товарной группе, а какой — к записи варианта. Требования Google к идентификаторам вариантов изложены в справке о группировке вариантов товаров. Если варианты различаются ценой, размером или другим атрибутом, сравнение без уточнения варианта даст ненадёжный вывод.
SECTION 04Когда правило атрибута действительно применимо
Правило атрибута может преобразовать данные, но его существование в интерфейсе ещё не означает, что оно меняет конкретный товар. Проверяйте область действия и состояние, а не только название правила. Описание настроек пользовательских правил атрибутов Google поможет сверить доступные понятия и способы преобразования.
Для каждого правила, способного затронуть спорный атрибут, проверьте:
- выбранный целевой атрибут;
- источник данных, к которому относится правило;
- условия, которым должна соответствовать запись;
- действие, замену или преобразование значения;
- наличие других правил для того же атрибута;
- статус: правило ещё редактируется, проверяется или применено.
Не считайте последовательность правил очевидной только потому, что интерфейс показывает их рядом. Если на один атрибут влияют несколько условий, выясните установленный порядок применения в интерфейсе и актуальной документации. Не выводите порядок из названий или времени создания.
Для проверки конфигурации используйте предусмотренный Google тест правил. В инструкции по тестированию правил атрибутов описан тестовый процесс. Сохраните входное значение, условия, ожидаемое преобразование и результат теста до применения изменений. После применения заново откройте карточку товара и сравните фактическое значение с сохранённым результатом теста.
Не путайте статусы: успешный тест говорит о результате тестирования правила для проверяемых данных. Он не подтверждает, что товар одобрен, соответствует всем требованиям или будет виден покупателям.
SECTION 05Порядок действий при расхождении
Двигайтесь от идентификации записи к проверке обработки; не редактируйте сразу все источники или правила.
Шаг первый: сохраните исходное состояние
Запишите идентификатор товара и варианта, спорный атрибут, исходное значение, отображаемое значение, сведения об источнике и текущее состояние правила. Если команда уже меняла настройки, уточните, кто и что изменял. Без исходного состояния вы не сможете понять, какое изменение повлияло на результат.
Шаг второй: установите путь поступления данных
Определите, переданы ли сведения через подключённую платформу, файл, таблицу, API или другой активный источник. Для карточки товара запишите источник, который виден в Merchant Center. Не предполагайте, что запись поступила только из Shopify, пока сведения аккаунта этого не подтверждают.
Шаг третий: проверьте соответствие идентификаторов и полей
Сопоставьте один товар и один вариант в обеих системах. Убедитесь, что сравниваете нужный атрибут, а не похожее поле с другим назначением. Если атрибут или вариант определить нельзя, не меняйте правило наугад — сначала уточните сопоставление.
Шаг четвёртый: перечислите применимые правила
Для целевого атрибута проверьте источник, условия и действие каждого подходящего правила. Отметьте, что применено, а что находится в черновом или тестовом состоянии. Если интерфейс не позволяет подтвердить порядок обработки или область действия, зафиксируйте это как вопрос для официальной поддержки.
Шаг пятый: протестируйте изменение до применения
Сначала запишите тестируемое условие и ожидаемый результат. Запустите официальный тест для конкретного случая, если он доступен, и сохраните результат вместе с исходным значением. Не применяйте правило только потому, что тест на другом товаре выглядит корректно: он не подтверждает, что условия совпадают у проверяемой записи.
Шаг шестой: проверьте обработанную карточку
После применения изменения откройте тот же товар в Merchant Center. Сверьте идентификатор, источник и фактическое значение атрибута. Отдельно отметьте статус товара; не используйте статус одобрения или видимость как замену проверке значения.
Шаг седьмой: определите, кому передать проблему
Если источник неверный, расследуйте настройки передачи. Если неверно сопоставлено поле, исправляйте маппинг. Если значение обработано ожидаемо, но товар имеет проблему с требованиями или состоянием, переходите к проверке статуса. Если причина не подтверждается доступными деталями, приложите записи и тестовые данные к обращению в официальную поддержку, вместо повторных несвязанных изменений.
SECTION 06Как передать вывод команде без потери контекста
Используйте одну запись на один товар и один спорный атрибут. В ней должны быть:
- идентификатор товара и варианта;
- название целевого атрибута;
- источник данных и путь передачи;
- исходное значение в Shopify или другом источнике;
- сопоставленное поле и значение в Merchant Center;
- условие, действие и статус относящегося к полю правила;
- дата изменения и имя ответственного;
- результат теста и фактическое значение после применения;
- текущий статус товара и следующий владелец задачи.
Разделяйте выводы на три категории. Проблема источника означает, что данные поступили не оттуда, откуда ожидала команда, или сведения об источнике не подтверждены. Проблема сопоставления означает, что сравнивались разные поля или варианты. Проблема состояния товара означает, что значение уже проверено, но остаётся отдельный вопрос по требованиям, обработке или показу.
Такой формат особенно полезен, если проверку выполняют разные сотрудники: следующий специалист видит, что уже подтверждено, а что остаётся гипотезой. Если для проверки и передачи результатов вам нужна общая удалённая macOS-среда, посмотрите вариант удалённого Mac в США. Она может помочь команде работать в согласованной среде и сохранять материалы проверки, но не меняет настройки источников Merchant Center и не решает вопросы одобрения товара.
SECTION 07Частые вопросы
Shopify обновил товар, но Merchant Center показывает другое значение — с чего начать?
Сопоставьте идентификатор товара и вариант, затем запишите источник, поле и значение в обеих системах. После этого проверьте, не направлено ли поле в другой атрибут и действует ли для него правило. Повторная загрузка без этих проверок не устанавливает причину: она может добавить ещё одно изменение, но не доказывает, какая запись или настройка повлияла на результат.
Что проверять первым, если сведения приходят из нескольких источников?
Откройте детали конкретного товара и зафиксируйте доступную информацию об источнике. Сверьте источник с идентификатором записи и выясните, относится ли дополнительный канал к тому же товару или варианту. Только затем переходите к сопоставлению атрибутов и правилам. Не назначайте источник главным по тому, что его файл или синхронизация обновились позже.
Как правила атрибутов могут повлиять на поле товара?
Они могут преобразовать сведения для выбранного атрибута, если совпадают область действия, источник и условия. Проверьте целевой атрибут и каждое действие, способное изменить его значение; затем выясните, применено ли правило или оно только проверяется. Если действуют несколько правил, не угадывайте порядок. Используйте тест и сверьте его с фактическими данными карточки.
Как узнать, какое значение Merchant Center использует после обработки?
Зафиксируйте результат теста правила, примените подтверждённое изменение и откройте ту же запись товара в Merchant Center. Сравните идентификатор, источник и значение целевого атрибута. Затем отдельно проверьте состояние товара: обработанное значение, одобрение и видимость — разные результаты, и один из них не гарантирует другой.
Если команда сверяет товары с личных устройств и пересылает снимки экрана и таблицы между сотрудниками, типичные недостатки такого процесса — разрозненные версии записей, зависимость доступа от конкретного сотрудника и отсутствие единой среды для повторной проверки. Удалённый Mac может упростить совместную работу, когда участникам нужна общая macOS-среда, но он не исправит маппинг, не изменит приоритет источников и не гарантирует одобрение или показ товара. Если такой сценарий подходит вашей команде, сравните условия аренды MACNOX с собственными устройствами и другими вариантами: аренда уместна для временной проверки и передачи доступа, а при постоянной длительной работе или необходимости физических интерфейсов может быть рациональнее собственный Mac.