Контроль цін конкурентів у Google Sheets: коли простий моніторинг корисніший за складний парсер

Багатьом інтернет-магазинам не потрібен великий price intelligence інструмент на старті. Їм потрібна відповідь на простіші питання: по яких товарах конкурент уже дешевший, де різниця справді впливає на продажі, а де вона не варта реакції. Якщо таких SKU не тисячі, а кілька десятків або кілька сотень, Google Sheets часто дає більше користі, ніж спроба одразу будувати важкий парсер.

Головна помилка в моніторингу цін - починати з питання “як спарсити весь ринок”. Бізнесу зазвичай не потрібен весь ринок. Йому потрібно не пропустити ситуацію, коли ключовий товар у рекламі став дорожчим за конкурентів, маржинальна позиція провалилася в цінову війну або сезонний SKU треба швидко переоцінити.

Тому перша версія price monitoring має бути не про тотальний scraping, а про керований список товарів, зрозумілі пороги і нормальний статус дії.

Які товари варто моніторити

Якщо додати в таблицю весь каталог, команда швидко отримає шум. Частина товарів продається рідко, частина не має прямого конкурента, частина не впливає на прибуток навіть при невеликому відхиленні ціни.

Практичніше почати з короткого списку:

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

Для першої версії достатньо 30-80 товарів. Це вже дає операційний контроль, але ще не перетворює таблицю на другий каталог. Якщо магазин не може пояснити, навіщо моніторити конкретний SKU, цей SKU краще не додавати в перший список.

Структура таблиці

Базова вкладка може називатися Price_Monitor. Один рядок - один товар і один конкурентний URL або один зовнішній price source.

Мінімальний набір колонок:

Окремо корисно мати вкладку Rules. Там зберігаються пороги: для яких SKU різниця 2% уже важлива, а для яких навіть 7% не критичні. Без правил таблиця швидко стане місцем для суб'єктивних рішень.

Як рахувати delta

Базова формула проста:

deltapercent = (ownprice - competitorprice) / ownprice

Якщо результат додатний, конкурент дешевший. Якщо від'ємний, ваша ціна нижча. Але сам відсоток ще нічого не вирішує. Різниця в 3% може бути критичною для товару з тонкою конкуренцією у рекламі, але неважливою для товару з сильним брендом, швидкою доставкою або комплектною послугою.

Тому delta треба читати разом з двома речами:

• priority - наскільки важливий товар для продажів;
• margin_status - чи є простір для цінової реакції.

Наприклад, якщо конкурент дешевший на 5%, але ваш товар має кращу комплектацію або швидшу доставку, це може бути watch, а не автоматична зміна ціни. Якщо конкурент дешевший на 3%, а товар стоїть у Google Ads і дає основний оборот категорії, це вже може бути review.

Технічні варіанти

Є кілька рівнів реалізації, і не всі вони потребують парсера.

Ручний checkpoint. Менеджер раз або два рази на тиждень відкриває конкурентні URL, оновлює competitor_price і ставить дату перевірки. Це звучить просто, але для 30 важливих SKU часто працює краще, ніж недописаний парсер, який ламається на кожній зміні верстки.

Напівавтоматична перевірка. Apps Script бере список URL, робить обережний UrlFetchApp.fetch, намагається знайти ціну по простому патерну або структурованих даних і записує результат. Це можна використовувати тільки там, де сайт це дозволяє і відповідь стабільна. Офіційна документація Apps Script по UrlFetchApp корисна для розуміння базових запитів, але вона не робить будь-який сайт безпечним або дозволеним джерелом для збору даних.

API або фід. Якщо конкурент, маркетплейс, постачальник або партнер дає API, CSV, XML або merchant feed, це краще за scraping. Дані стабільніші, менше юридичних і технічних ризиків, легше контролювати частоту оновлення.

Платний сервіс. Якщо магазин має великий каталог, багато конкурентів, кілька країн і щоденне repricing-рішення, окремий сервіс може бути дешевшим за підтримку власної системи. Google Merchant Center теж має price competitiveness можливості для eligible accounts. У Merchant API є звіт pricecompetitivenessproductview, а в BigQuery export є таблиця PriceCompetitiveness, які дають benchmark-дані для товарів, де така інформація доступна.

Базова логіка alert

Перша версія скрипта не повинна ходити по всьому інтернету. Її задача - взяти вже внесені ціни, порахувати різницю і поставити зрозумілий action status.

function updatePriceActions() {
  const sheet = SpreadsheetApp.getActive().getSheetByName('Price_Monitor');
  const values = sheet.getDataRange().getValues();
  const headers = values.shift();
  const rows = values.map(row => toObject_(headers, row));

  const output = rows.map(row => {
    const own = Number(row.own_price);
    const competitor = Number(row.competitor_price);
    const priority = String(row.priority || '').toLowerCase();
    const margin = String(row.margin_status || '').toLowerCase();

    if (!own || !competitor) {
      return ['', 'no price data'];
    }

    const delta = (own - competitor) / own;
    const deltaPercent = Math.round(delta * 1000) / 10;
    let action = 'ignore';

    if (delta >= 0.08 && priority === 'high') {
      action = margin === 'thin' ? 'review margin' : 'change_price';
    } else if (delta >= 0.04 && priority !== 'low') {
      action = 'review';
    } else if (delta >= 0.02) {
      action = 'watch';
    }

    return [deltaPercent + '%', action];
  });

  if (output.length) {
    sheet.getRange(2, 6, output.length, 2).setValues(output);
  }
}

function toObject_(headers, row) {
  return headers.reduce((acc, header, index) => {
    acc[String(header).trim()] = row[index];
    return acc;
  }, {});
}

Цей код свідомо не збирає ціни з чужих сайтів. Він показує логіку рішення: не кожне відхилення стає алертом, і не кожен алерт означає “знижуємо ціну”. Якщо маржа тонка, action має вести до перегляду правила, а не до автоматичної знижки.

Decision flow замість цінової паніки

Правильний price monitor має закінчуватися не списком червоних рядків, а чергою рішень.

Робоча логіка може бути такою:

1. Товар потрапляє в monitoring list тільки якщо він важливий для продажів.
2. Ціна перевіряється вручну, через API або легку автоматизацію.
3. Скрипт рахує delta.
4. Правило дивиться на priority і margin.
5. У action потрапляє тільки корисне рішення.

Це захищає команду від хаосу. Якщо конкурент тимчасово знизив ціну на товар, який ви майже не продаєте, немає сенсу будити менеджера. Якщо різниця невелика, але SKU критичний для рекламної кампанії, сигнал потрібен швидко.

Як не перейти межу зі scraping

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

Краще тримати прості правила:

• перевіряти тільки важливі URL;
• не робити часті запити без потреби;
• поважати robots.txt, terms і технічні обмеження сайту;
• не збирати персональні або зайві дані;
• віддавати перевагу API, фідам і офіційним джерелам;
• залишати ручний checkpoint там, де автоматизація ненадійна.

Google у своїй документації по robots.txt пояснює, що цей файл задає правила для crawler-доступу до частин сайту. Для комерційного моніторингу цього недостатньо як юридичної консультації, але достатньо як технічного нагадування: чужий сайт не є безкоштовною базою даних для необмежених запитів.

Коли Sheets достатньо, а коли ні

Google Sheets достатньо, якщо:

• моніторите десятки або кілька сотень SKU;
• рішення приймає людина, а не автоматичний repricing engine;
• ціни оновлюються кілька разів на тиждень, а не щохвилини;
• головна задача - не пропустити відхилення по важливих товарах;
• дані можна брати з ручних checkpoints, фідів або простих джерел.

Окремий API-сервіс або платформа потрібні, якщо:

• каталог великий і конкуренти змінюють ціни часто;
• потрібна історія цін по багатьох ринках;
• є автоматичний repricing;
• дані потрібні для закупівель, реклами, BI і фінансів одночасно;
• потрібно SLA, логування, retry, proxy-management і нормальна підтримка джерел.

Важливо не плутати MVP з майбутньою архітектурою. Таблиця не повинна назавжди замінити price intelligence платформу. Але вона допомагає зрозуміти, які саме рішення бізнес хоче приймати по цінах. Без цього складніший інструмент просто автоматизує нечіткий процес.

Rocket-підхід

У практичному e-commerce monitoring найцінніші три речі.

Перше - короткий список SKU. Не “все, що є в каталозі”, а товари, де ціна реально впливає на гроші.

Друге - пороги різниці. Для одного товару 2% уже важливо, для іншого 10% не змінює поведінку покупця. Пороги мають бути налаштовані під категорію, маржу і джерело трафіку.

Третє - action queue. Таблиця має казати, що робити: ігнорувати, спостерігати, переглянути маржу, змінити ціну або перевірити джерело вручну.

Добрий price monitor починається не з парсера. Він починається зі списку товарів, по яких бізнес готовий діяти. Якщо цей список правильний, навіть проста Google Sheets система дає ранній сигнал. Якщо список хаотичний, жоден складний scraping pipeline не зробить рішення розумнішим.