Зміст статті 12
Структуру Google Ads будують від економіки каталогу, цілей і якості даних, якими живляться кампанії. Маржа, наявність, сезонність та роль товару визначають потрібний рівень контролю; тип кампанії лише реалізує його. Тому два магазини з однаковим набором Search, Shopping і Performance Max можуть потребувати зовсім різної архітектури. Копіювати чужу схему без перевірки власних товарних даних і конверсій — слабка відправна точка.
Три типи кампаній — три механізми контролю
Search, Standard Shopping і Performance Max відрізняються насамперед сигналами, на яких працюють.
Search дає найпряміший контроль над пошуковим наміром: рекламодавець задає ключові слова, типи відповідності й тексти оголошень. Standard Shopping використовує дані Merchant Center, а товари організовуються в product groups. Performance Max — goal-based кампанія, яка працює з інвентарем Google та оптимізується на задані conversion goals за допомогою фіду, активів і сигналів рекламодавця.
| Кампанія | Основна одиниця керування | Що контролює рекламодавець | Коли корисна |
|---|---|---|---|
| Search | ключові слова й оголошення | намір, відповідність, текст, посадкову сторінку | коли важливий явний контроль над запитом і повідомленням |
| Standard Shopping | товар або product group | склад груп, ставки та виключення | коли потрібен детальний товарний контроль |
| Performance Max | conversion goal і групи активів/товарів | цілі, фід, активи, сигнали, виключення | коли потрібна автоматизація на кількох каналах Google |
Таблиця не встановлює універсальних ролей. У конкретному акаунті частина задач може перетинатися, а доцільність кожного типу залежить від каталогу, трекінгу й бізнес-цілей. Окреме порівняння механік є в матеріалі Performance Max чи Standard Shopping.
Як Performance Max взаємодіє із Search
Google описує PMax як доповнення до keyword-based Search. Якщо запит користувача ідентичний активному exact-match keyword у Search, Search зазвичай має пріоритет. Водночас Google прямо зазначає винятки: наприклад, Search-кампанія може бути обмежена бюджетом або мати суворіший таргетинг. Тому наявність exact-match keyword не дає абсолютної гарантії, що PMax ніколи не покаже оголошення за цим запитом.
Для керування перетином є різні інструменти:
- campaign-level
brandexclusions допомагають обмежити показ PMax за вибраними брендовими запитами; - campaign-level negative keywords у PMax відсікають конкретні нерелевантні або небажані запити в Search і Shopping inventory;
- account-level negative keywords діють ширше — на відповідний Search і Shopping inventory в акаунті, включно з PMax.
Ці механізми мають різний радіус дії. Перед додаванням виключення варто перевірити, чи воно вирішує справжній конфлікт, а не просто прибирає трафік, який здається незручним для звітності.
Сегментація Shopping і PMax за даними фіду
Shopping і retail-PMax можуть організовувати товари за атрибутами Merchant Center: category, product_type, brand, condition, item id і custom_label_0–4. У Standard Shopping product groups дозволяють окремо керувати ставками для підгруп. У PMax listing groups визначають, які частини каталогу входять до групи активів.
Category і product_type відображають таксономію каталогу. Brand та condition корисні, якщо ці характеристики справді змінюють економіку або стратегію показу. Item id дозволяє виділити конкретний SKU. Custom labels — п’ять необов’язкових внутрішніх полів: їх значення не бачить покупець, зате рекламодавець може використовувати їх для фільтрації, звітності та bidding.
| Ознака | Як позначити | Що контролювати | Питання для перевірки |
|---|---|---|---|
| категорія або тип товару | category / product_type | склад product або listing groups | чи не змішані товари з різною роллю в одному сегменті |
| бренд і стан | brand / condition | окремі групи, ставки або виключення | чи впливає ознака на цінність продажу |
| конкретний SKU | item id | індивідуальне включення або виключення | чи має товар достатнє бізнес-значення для окремого контролю |
| маржа, сезон, пріоритет | custom_label_0–4 | фільтри, звітність, bidding | хто оновлює мітку і наскільки вона актуальна |
Маржа й роль товару — методика, а не вимога Google
Google не вимагає групувати товари за маржею, оборотністю чи роллю у воронці. Це редакційна й управлінська модель, яку команда може накласти на стандартні атрибути через custom labels. Вона корисна тоді, коли товарна таксономія не відображає бізнес-економіку: два товари однієї категорії можуть мати різну маржу, доступність або стратегічну цінність.
Модель «Standard Shopping для контрольованого тесту, PMax для масштабування» теж є лише одним зі сценаріїв. Вона може допомогти, коли команді потрібен проміжний рівень ручного контролю. Для невеликого каталогу або стабільної групи товарів додаткова кампанія, навпаки, здатна створити зайву фрагментацію. Орієнтуйтеся на задачу сегмента; назва типу кампанії тут вторинна.
Передумови для осмисленої автоматизації
До перебудови акаунта перевірте три шари.
Product data. Назва, ціна, availability, GTIN, категорія та інші атрибути мають відповідати товарній сторінці й реальному стану каталогу. Сегментація не виправить помилки в даних, на яких вона побудована. Для перевірки самого джерела даних використовуйте гайд із налаштування Google Merchant Center.
Conversion tracking. Purchase і його value повинні передаватися коректно. Якщо primary goal змішує покупку з add_to_cart або іншою проміжною подією, Smart Bidding отримує неоднозначний сигнал.
Conversion goals. Кампанія має оптимізуватися на дію, яку бізнес справді вважає результатом. Secondary actions можна зберігати для спостереження, не прирівнюючи їх до продажу.
Без цього автоматизація може технічно працювати без помилок і водночас розподіляти бюджет за слабким сигналом.
Покрокова побудова структури
- Опишіть економіку каталогу. Зафіксуйте маржу, доступність, сезонність і роль товарних груп. Якщо частина даних недоступна, позначте це як обмеження — не підміняйте її здогадкою.
- Перевірте вимірювання. Зіставте purchase і revenue в рекламній системі з даними магазину. Відокремте primary conversion від допоміжних дій.
- Перенесіть потрібні ознаки у фід. Використовуйте стандартні атрибути та custom_label_0–4. Для кожної мітки визначте власника й правило оновлення.
- Призначте роль кожному сегменту. Вирішіть, де потрібен keyword-control Search, де корисна гранулярність Standard Shopping, а де виправдана автоматизація PMax.
- Зафіксуйте межі. Перевірте
brandexclusions, negative keywords, product/listing groups та URL exclusions. Не додавайте виключення без пояснення, який конфлікт воно усуває. - Розподіліть бюджет за пріоритетом. Враховуйте бізнес-цінність сегмента, місткість попиту й достовірність сигналу. Рівний бюджет для нерівних груп рідко є нейтральним рішенням.
- Встановіть цикл перегляду. Каталог і попит змінюються. Регулярно перевіряйте search terms, товарні групи, goals, якість фіду та актуальність custom labels.
Контроль search terms і мінус-слів
Search terms report у Search показує фактичні запити, за якими відбулися покази. У PMax Google також розвиває звітність за search terms та insights, але спосіб доступу й повнота даних можуть відрізнятися залежно від інтерфейсу й типу звіту. Тому рішення про виключення краще приймати за доступними фактичними запитами. Ставка на те, що алгоритм розбереться сам, звіту не замінює.
Мінус-слова доцільно розділити за рівнем:
- account-level — для запитів, небажаних у всьому відповідному інвентарі акаунта;
- campaign-level — для меж конкретної PMax або іншої кампанії;
brandexclusions — для контролю вибраних брендів у PMax.
Після змін перевіряйте не лише зменшення небажаних показів, а й можливу втрату корисного охоплення.
Бюджет і bidding без магічних порогів
Немає універсальної кількості конверсій, днів або бюджету, після якої автоматизована кампанія гарантовано стає ефективною. Потрібний обсяг сигналу залежить від категорії, середнього чека, сезонності й тривалості шляху до покупки. Для первинного сценарного розрахунку можна використати калькулятор бюджету Performance Max, не сприймаючи його результат як прогноз.
Практичніше оцінювати якість рішення за ознаками:
- чи вистачає бюджету для участі в релевантних аукціонах;
- чи стабільно передаються purchase і value;
- чи не змінилася доступність або ціна ключових товарів;
- чи відповідає bidding goal реальній економіці сегмента;
- чи не обмежують кампанію надто жорсткі targets або виключення.
ROAS або CPA в інтерфейсі не дорівнює прибутковості без урахування маржі, повернень, логістики й інших витрат. Рекламний target узгоджуйте з власною фінансовою моделлю; чужі значення переносяться погано.
Діагностика структурної проблеми
Структуру варто переглянути, якщо:
- PMax регулярно обслуговує брендові запити, які команда хотіла контролювати через Search;
- рекламні конверсії зростають, а підтверджені покупки магазину — ні;
- в одній товарній групі змішані позиції з різною економікою й доступністю;
- важливий сегмент не отримує достатнього охоплення через спільний бюджет або невдалу групу;
- custom labels більше не відповідають поточному каталогу;
- кампанії мають різні назви, але фактично працюють з однаковими товарами й цілями без чіткої ролі.
Кожен симптом потребує перевірки даних, налаштувань і аукціонної ситуації. Один і той самий результат може мати кілька причин, тому висновок не варто робити за однією метрикою. Якщо потрібна незалежна перевірка всього акаунта, дивіться склад аудиту Google Ads і його публічний зразок.
Підхід UPLIFY
UPLIFY — performance-marketing агенція для e-commerce. Як робочу методику команда рекомендує починати з аудиту каталогу та вимірювання, а вже потім призначати ролі Search, Shopping і PMax. Такий порядок не гарантує фінансовий результат, проте робить припущення видимими: команда може пояснити, чому сегмент існує, який сигнал використовує і за якою ознакою його переглядатимуть.
FAQ
Що робити, якщо один товар одночасно входить у Standard Shopping і PMax?
Спочатку перевірте, чи перетин був запланований і чи дозволяє він відповісти на конкретне питання. Якщо ні, розділіть інвентар через item id, custom label або listing/product groups. Не порівнюйте кампанії як чистий тест, доки вони можуть брати участь в аукціонах за ті самі товари: розподіл показів між типами кампаній не є нейтральним.
Як сегментувати за маржею, якщо собівартість оновлюється вручну?
Використовуйте custom label з явно вказаною датою або правилом оновлення у внутрішньому реєстрі. Груба, але контрольована класифікація може бути кориснішою за точне число, якому команда вже не довіряє. Якщо маржа змінюється швидше, ніж оновлюється мітка, не використовуйте її як єдину основу для автоматичного рішення.
Чи потрібна складна структура монобрендовому магазину з невеликим каталогом?
Зазвичай природних меж для поділу там менше. Почніть із мінімальної структури, у якій кожна кампанія має окрему роль, а даних вистачає для оцінки. Дрібні групи без відмінностей у цілях, економіці або повідомленні лише ускладнюють аналіз. Search може окремо контролювати запити, де важливий текст оголошення, а товарний інвентар залишатися консолідованим.
Що змінювати першим, якщо add_to_cart і purchase записані як primary conversions?
Спершу виправте модель вимірювання: залиште purchase основною дією для продажів, а проміжні події використовуйте як secondary, якщо вони потрібні для аналізу. Лише після стабілізації даних оцінюйте bidding і структуру. Інакше зміна кампаній не покаже, чи проблема була в архітектурі, чи в тому, що алгоритм оптимізувався на іншу подію.
Чи потрібна окрема кампанія для товарів, яких немає в наявності?
Зазвичай ні: коректний availability у Merchant Center має не допускати показ недоступного товару. Якщо позиція продовжує з’являтися, перевірте частоту оновлення фіду, відповідність сторінки товару й статус у Merchant Center. Окрема кампанія не виправить затримку або розбіжність даних; спочатку усуньте джерело невірного статусу.