Google Sheets + Merchant Center: як автоматично знаходити помилки у фіді до того, як вони вдарять по продажах

Помилки у товарному фіді рідко виглядають драматично в момент, коли вони з'являються. У таблиці просто зник image_link, у частини SKU не оновилася ціна, кілька товарів отримали порожній brand, а availability у фіді роз'їхався зі сторінкою товару.

Для команди це може виглядати як дрібна технічна деталь, але для Merchant Center така дрібниця швидко стає бізнес-проблемою: товар перестає показуватися, реклама втрачає охоплення, а продажі просідають без очевидного пояснення.

Нормальний підхід тут не в тому, щоб чекати, поки Merchant Center сам покаже червону картку. Сильніший процес виглядає інакше: товарний фід проходить власний QA-шар ще до того, як проблема вдарить по модерації, показах або обороту.

Google Sheets зручно використовувати як контрольну таблицю, Apps Script може регулярно перевіряти критичні поля, а окремий статус по SKU допомагає швидко зрозуміти, де справді аварія, а де просто warning для планового виправлення.

Для базової технічної частини варто тримати поруч офіційну специфікацію товарних даних Merchant Center, документацію по UrlFetchApp і installable triggers.

Вони закривають три головні питання: які атрибути очікує Google, як скриптом перевіряти URL та як запускати перевірку за розкладом.

Чому фід треба контролювати до Merchant Center

Merchant Center добре показує проблеми, але це вже downstream-рівень. Якщо магазин має сотні або тисячі SKU, частина помилок може накопичуватися непомітно: сьогодні не підтягнулося кілька зображень, завтра зламався формат ціни в одній категорії, післязавтра фід віддав застарілу наявність.

Коли команда бачить це тільки в інтерфейсі Merchant Center, вона вже реагує на наслідки.

У e-commerce дорожче за все коштують не самі помилки, а час між появою помилки і реакцією. Особливо якщо йдеться про товари з основним оборотом, сезонні позиції або SKU, які зараз підтримуються рекламним бюджетом. Для таких товарів потрібен не просто список помилок, а ранній сигнал: цей товар може втратити покази, перевір зараз.

Саме тому Google Sheets корисний як проміжний QA-шар. Таблиця не замінює Merchant Center, але дає команді власну логіку контролю: які поля критичні, які SKU пріоритетні, які помилки треба виправити сьогодні, а які можна поставити в планову чергу.

Які помилки у фіді варто ловити першими

Не всі помилки однаково небезпечні. Якщо ставити alert на кожне дрібне відхилення, система швидко перетвориться на шум. Починати краще з полів, без яких товар або не проходить якісний показ, або різко втрачає шанс на продаж.

Базовий набір для QA-таблиці:

Ключова ідея проста: critical означає ризик втрати показів, модерації або продажів. Warning означає, що фід стає слабшим, але не обов'язково ламається прямо зараз.

Наприклад, битий image_link для товару з активною рекламою має бути critical. А відсутній gtin для частини каталогу може бути warning, якщо товар все ще проходить покази, але якість даних гірша.

Як зібрати QA-шар у Google Sheets

Для старту не потрібна складна система. Достатньо окремої вкладки Feed_QA, куди скрипт або імпорт фіда складає нормалізовані товарні дані. Краще не змішувати сирий фід і результати перевірки в одній каші.

Практичніша структура така:

Поле priority тут не декоративне. Якщо у вас 8000 товарів, не всі вони однаково важливі для нічної перевірки.

Окремо варто позначити:

• SKU, які дають основний оборот;
• товари в активних кампаніях;
• сезонні позиції;
• товари з високою маржинальністю;
• категорії, де помилки фіда вже виникали раніше.

Так QA-система не просто рахує помилки, а допомагає команді правильно розставити чергу виправлень.

Базова логіка перевірки через Apps Script

Нижче спрощений приклад. Він не замінює повну інтеграцію з Merchant Center, але показує робочий принцип: взяти рядки з таблиці, перевірити image_link, базово провалідувати ціну і записати статус назад у Google Sheets.

function checkFeedQa() {
  const sheet = SpreadsheetApp.getActive().getSheetByName('Feed_QA');
  const rows = sheet.getDataRange().getValues();
  const headers = rows[0];

  const idx = {
    image: headers.indexOf('image_link'),
    price: headers.indexOf('price'),
    priority: headers.indexOf('priority'),
    status: headers.indexOf('status_check'),
    notes: headers.indexOf('notes'),
    checked: headers.indexOf('last_checked'),
  };

  const now = new Date();

  for (let r = 1; r < rows.length; r++) {
    const row = rows[r];
    const problems = [];
    let severity = 'ok';

    const imageUrl = String(row[idx.image] || '').trim();

    if (!imageUrl) {
      problems.push('missing image_link');
      severity = 'critical';
    } else {
      try {
        const response = UrlFetchApp.fetch(imageUrl, {
          method: 'get',
          muteHttpExceptions: true,
          followRedirects: true,
        });

        const code = response.getResponseCode();

        if (code < 200 || code >= 300) {
          problems.push(`image response ${code}`);
          severity = 'critical';
        }
      } catch (error) {
        problems.push('image fetch failed');
        severity = 'critical';
      }
    }

    const price = String(row[idx.price] || '').trim();

    if (!/^\d+([.,]\d{1,2})?\s?[A-Z]{3}$/.test(price)) {
      problems.push('price format issue');

      if (severity !== 'critical') {
        severity = 'warning';
      }
    }

    if (row[idx.priority] === 'revenue_sku' && severity === 'warning') {
      severity = 'critical';
      problems.push('priority SKU');
    }

    sheet.getRange(r + 1, idx.status + 1).setValue(severity);
    sheet.getRange(r + 1, idx.notes + 1).setValue(problems.join('; '));
    sheet.getRange(r + 1, idx.checked + 1).setValue(now);
  }
}

Далі цей скрипт можна запускати вручну або поставити на нічний time-driven trigger. Для великих каталогів краще не перевіряти все одним проходом: розбивайте SKU на батчі, окремо обробляйте пріоритетні товари й не забувайте про ліміти Apps Script.

Як має виглядати перевірочний пайплайн

Практична схема зазвичай така:

Product feed -> Google Sheets -> Apps Script QA -> Feed_QA status -> команда / alert

На першому етапі ви отримуєте або імпортуєте товарний фід. На другому приводите дані до стабільних колонок. На третьому запускаєте перевірки: обов'язкові атрибути, image URL, ціну, availability, дублікати. На четвертому отримуєте статус і нотатки по кожному SKU. На п'ятому команда бачить не просто “десь є помилка”, а конкретну чергу роботи.

Для alert-логіки не треба надсилати все підряд.

Краще формувати повідомлення тільки для:

• critical по revenue SKU;
• масового зламу в категорії;
• різкого росту кількості помилок після оновлення фіда;
• товарів, які залишаються в critical довше заданого часу.

Так система не дратує команду, а реально допомагає ловити проблеми раніше.

Як не перетворити QA на генератор шуму

Головна помилка в автоматизації фіда, це надто грубі правила. Наприклад, “немає GTIN, значить critical” може бути неправильним для частини каталогу. А “будь-який редирект у link, значить аварія” може давати зайві спрацювання, якщо сайт стабільно нормалізує URL.

Краще починати з простого rule set і поступово уточнювати його:

• порожній id, link, image_link або price майже завжди critical;
• image_link з 404, 403 або timeout для активного товару, critical;
• некоректна валюта або нульова ціна, critical;
• відсутній brand або gtin, warning, якщо товар не блокується;
• розбіжність availability між сайтом і фідом, critical для revenue SKU;
• дубль id, critical, бо він ламає стабільність товарних даних.

Окремо варто зберігати історію. Якщо сьогодні у вас 17 warning-помилок, це може бути нормально. Якщо вчора було 17, а сьогодні стало 900, це вже інцидент, навіть якщо кожна окрема помилка не виглядає страшною.

Rocket-підхід для e-commerce-команди

Найкорисніший формат для магазину, це не просто технічна перевірка всього фіда, а робочий dashboard з пріоритетами.

У ньому має бути видно:

• скільки SKU зараз у critical;
• скільки з них revenue SKU;
• які категорії зачеплені;
• коли помилка з'явилася вперше;
• чи був SKU уже переданий у роботу;
• чи повторюється проблема після чергового оновлення фіда.

Тоді QA фіда стає частиною операційного процесу, а не разовим скриптом. PPC-спеціаліст бачить, що може вплинути на кампанії. E-commerce manager бачить, які товари ризикують зникнути з видачі. Технічна команда отримує конкретні поля й конкретні URL, а не загальне “щось не так з фідом”.

Фід має бути керованим процесом, а не чорним ящиком

Merchant Center залишається фінальним джерелом правди для модерації й показів, але чекати тільки на нього, це слабка операційна позиція. Якщо магазин залежить від товарного фіда, команда має бачити критичні помилки раніше: ще на рівні Google Sheets, регулярних Apps Script перевірок і простого пріоритетного dashboard.

Почати можна з малого: перевіряти image_link, price, availability і обов'язкові поля для SKU, які дають найбільший оборот. Потім додати нічний тригер, історію статусів і alert для critical-помилок.

У результаті фід перестає бути чорним ящиком і стає керованим процесом, який захищає рекламний бюджет і продажі від технічних дрібниць.