Зміст статті 13
Performance Max цілком може оптимізуватися під помилково обрану, продубльовану або малоцінну конверсію, бо його ставки йдуть за тими цілями, які ви налаштували в акаунті чи в кампанії. Це кампанія на основі цілей, яка оптимізується під задані цілі конверсій за допомогою Smart Bidding (довідка Google), а Smart Bidding приймає рішення в аукціоні, спираючись на конверсійні дані та контекстні сигнали (довідка Google). Це ризик, а не автоматичний наслідок. Але поки семантика подій і коректність відстеження не перевірені, зміна ставок, бюджетів чи креативів може відволікти від помилки в самих вхідних даних.
Що на практиці означає брудний конверсійний сигнал
Проблемний сигнал не завжди виглядає як зламаний тег. Це може бути подія, яка технічно фіксується правильно, але означає не те, що ви маєте на увазі, або означає надто мало.
Типові різновиди, які варто впізнавати:
- подія наміру, а не результату: додавання в кошик, перегляд номера телефону, початок оформлення. Сама собою вона корисна для спостереження, проблема виникає тоді, коли вона бере участь у ставках нарівні з покупкою;
- одна покупка, порахована двічі через паралельні джерела (наприклад, тег Google Ads і імпорт з аналітики), через що частина замовлень має більшу вагу за інші;
- подія без цінності або з однаковою умовною цінністю для всіх товарів, тоді як реальна маржинальність відрізняється;
- конверсії, які згодом скасовуються чи повертаються, але залишаються в даних, на яких навчається система;
- дія, яку користувач може повторити багато разів за сеанс: клік по телефону, відкриття месенджера, повторне надсилання форми.
Google рекомендує використовувати точні конверсійні дані та будувати кампанії з чіткою метою (довідка Google). У межах нашого аудиту точність означає не лише спрацювання тега, а й те, що саме ви рахуєте і скільки разів.
Як PMax читає вашу конфігурацію цілей
Google AI у Performance Max використовує цілі рекламодавця, креативні асети, сигнали аудиторії і за бажанням фіди даних (довідка Google). Бізнес має сам вирішити, чи відповідає конверсійна дія потрібному результату. Якщо конфігурація включає дію до ставок, система використовує її для оптимізації.
Основні, другорядні дії і виняток зі спеціальною ціллю
Конверсійні дії групуються в цілі конверсій. Основні дії показуються в стовпці «Конверсії» і використовуються для призначення ставок, коли для ставок використовується їхня стандартна ціль. Другорядні дії призначені лише для спостереження і відображаються в «Усіх конверсіях» (довідка Google).
Важливий виняток: другорядна дія, включена до спеціальної цілі, використовується і для звітності, і для призначення ставок (довідка Google). Тобто позначка «другорядна» не забороняє використання дії у ставках через спеціальну ціль. Спеціальна ціль, зібрана колись під тестову кампанію, може повернути подію наміру в ставки.
Цілі за замовчуванням акаунта проти цілей конкретної кампанії
Основні дії всередині цілей за замовчуванням акаунта використовуються для ставок у всіх кампаніях, крім тих, що мають власні цілі на рівні кампанії. Цілі, не застосовані до кампанії, не з'являються в стовпці «Конверсії», але залишаються доступними в «Усіх конверсіях» (довідка Google).
Перевірте два сценарії. У першому нова основна дія входить у ціль за замовчуванням, тому кампанії без власних налаштувань враховують її у ставках. У другому PMax має цілі на рівні кампанії, тож зміни набору цілей за замовчуванням акаунта не змінюють її конфігурацію. Перед інтерпретацією цифр треба знати, який режим застосовано до конкретної кампанії.
Аудит від бізнес-події до тега і звіту
Послідовність нижче це метод аудиту, а не вимога Google. Офіційні джерела підтверджують лише ті твердження, біля яких стоїть посилання.
- Випишіть бізнес-події, які реально мають значення для прибутку: оплачене замовлення, підтверджене замовлення телефоном, кваліфікована заявка. Окремо випишіть проміжні події, які ви хочете бачити, але не хочете оптимізувати.
- Відкрийте Цілі > Конверсії > Зведення і перегляньте стовпець «Статус» для кожної дії (довідка Google). Дії з невизначеним або проблемним статусом розберіть до того, як робити висновки про кампанію.
- Для кожної дії зафіксуйте три атрибути: основна чи другорядна, до якої цілі належить, чи входить ця ціль у ставки. Така карта дає змогу помітити неочевидне використання дій через спеціальні цілі (довідка Google).
- Перевірте рівень застосування: PMax працює на цілях за замовчуванням акаунта чи на власних цілях кампанії (довідка Google).
- Перевірте технічну реалізацію: зробіть тестову конверсію через Tag Assistant, подивіться на впровадження тега, факт спрацювання і статус самої конверсійної дії (довідка Google).
- Знайдіть паралельні джерела однієї події. Гіпотетичний приклад: покупка приходить і з глобального тега на сторінці подяки, і з імпорту з аналітики, обидві дії активні й обидві основні.
- Звірте дані з бекендом магазину, але спершу врахуйте різницю в моделях атрибуції і принципах звітності, перш ніж називати розбіжність збоєм відстеження (довідка Google).
- Перевірте цінність: чи передається вона динамічно, чи однакова для всіх товарів, чи відповідає валюті та податковій логіці магазину.
Результат цього проходу зручно звести в реєстр конверсій. Для кожної дії запишіть технічну назву, зрозумілий опис бізнес-події, джерело даних, власника налаштування, роль у ставках і спосіб перевірки. Окремим полем позначте, що станеться після скасування або повернення замовлення. Це редакційний шаблон Uplify, а не функція Google Ads. Він потрібен, щоб розробник, аналітик і PPC-спеціаліст говорили про одну подію однаково. Якщо назву дії неможливо пояснити без доступу до старого чату чи пам'яті попереднього підрядника, конфігурація ще не готова до керованих змін.
Компактна діагностика
| Що ви бачите | Що перевірити першим | Де дивитися |
|---|---|---|
| Багато конверсій, мало замовлень у бекенді | Чи не потрапила подія наміру в ставки через спеціальну ціль | Налаштування цілей і тип дії (джерело) |
| Кампанія не реагує на зміни цілей акаунта | Чи задані цілі на рівні кампанії | Налаштування цілей кампанії (джерело) |
| Конверсії є в «Усіх конверсіях», але не в «Конверсіях» | Чи застосована ціль до цієї кампанії | Стовпці звіту (джерело) |
| Дія має неочікуваний статус | Впровадження і спрацювання тега, тестова конверсія | Цілі > Конверсії > Зведення (джерело) |
| Цифри Ads і бекенду не сходяться | Різниця в атрибуції та звітності до висновку про поломку | Порівняння методик (джерело) |
Дублі та випадкові події
Дублювання може бути вибірковим: спрацьовувати на частині трафіку, на певному способі оплати або після повернення користувача на сторінку подяки з історії браузера. Через це загальна кількість конверсій не показує, які саме сегменти отримали зайву вагу. Вплив на кампанію не слід оголошувати без перевірки джерел і розподілу дублів.
Під час перевірки порахуйте дії, які фізично можуть повторюватися в межах одного візиту, і перегляньте всі джерела, що записують одну й ту саму подію. Якщо ви імпортуєте офлайн-дані або дані з аналітики паралельно з тегом, вирішіть, яке джерело є основним для ставок, а яке лишається для спостереження. Google Ads дає для цього поділ на основні й другорядні дії (довідка Google).
Цінність, повернення і скасування
Для товарного бізнесу оптимізація по цінності має сенс лише тоді, коли цінність відображає щось реальне. Smart Bidding здатний оптимізувати саме під цінність конверсій (довідка Google), але зміст цієї цінності визначаєте ви.
Перевірка цінності не закінчується в момент первинної фіксації. Замовлення можуть скасувати, товар повернути, а суму змінити після узгодження з клієнтом. Дані мають відображати й цей етап життєвого циклу замовлення. Для таких випадків існують коригування конверсій: вони дозволяють відкликати конверсію, яка більше не має рахуватися (скасоване замовлення чи повернення), і перевизначити змінену цінність (довідка Google). Для зіставлення коригування з початковою конверсією мають значення ідентифікатори замовлення або транзакції (довідка Google), тому наскрізний ідентифікатор варто закладати ще на етапі впровадження, а не добудовувати згодом.
Виключення даних чи коригування конверсій
Ці інструменти працюють із різними типами проблем.
Виключення даних допомагають зменшити вплив проблем із відстеженням конверсій на Smart Bidding. Вони впливають на дані, які використовує призначення ставок, але не прибирають конверсії зі звітності (довідка Google). Це інструмент для збоїв і перебоїв у зборі даних, а не для регулярного прибирання, і він не обіцяє стабільної результативності (довідка Google).
Коригування конверсій навпаки працюють з окремими подіями, які були зафіксовані коректно, але потім змінили свій статус або суму (довідка Google). Скасування і повернення це їхня територія.
Робоче розмежування для аудиту таке: коли проблема стосується самого збору даних у певний період, перевірте придатність виключення даних. Коли вже зафіксована конверсія пізніше змінила статус або цінність, перевірте придатність коригування.
Що змінювати першим і як перевіряти
Порядок нижче відображає підхід редакції до пріоритезації, а не офіційну рекомендацію.
- Спочатку виправте семантику: приберіть із ставок події, які не є бізнес-результатом, у тому числі через ревізію спеціальних цілей (довідка Google).
- Визначте, які окремі conversion actions рахують одну бізнес-подію та беруть участь у ставках. Якщо застосовується multi-source beta, перевірте зіставлення джерел усередині тієї самої дії та transaction_id. Не вимикайте коректне додаткове джерело лише тому, що їх декілька.
- Потім приведіть до ладу цінність і налагодьте передачу ідентифікаторів замовлень для майбутніх коригувань (довідка Google).
- Після цього узгодьте рівень цілей: акаунт чи кампанія, свідомо, а не за замовчуванням (довідка Google).
- Після цих перевірок повертайтеся до стратегій ставок, бюджетів, груп асетів і сигналів аудиторії.
Перевірка після змін має бути такою ж прозаїчною, як і аудит: тестова конверсія через Tag Assistant, контроль статусу дії в зведенні конверсій (довідка Google), звірка з бекендом з поправкою на атрибуцію. Змінюйте по одному блоку за раз, інакше ви не зрозумієте, що саме вплинуло на поведінку кампанії.
Чеклист перед зміною ставок і асетів
- Кожна конверсійна дія має власника і зрозумілий бізнес-сенс, записаний словами.
- Для кожної дії відомо, чи бере вона участь у ставках, з урахуванням спеціальних цілей (джерело).
- Відомо, чи використовує кампанія цілі акаунта, чи власні (джерело).
- Статуси дій перевірені в Цілі > Конверсії > Зведення (джерело).
- Тестова конверсія проходить і фіксується коректно (джерело).
- Визначте, які окремі conversion actions рахують одну бізнес-подію та беруть участь у ставках. Якщо застосовується multi-source beta, перевірте зіставлення джерел усередині тієї самої дії та transaction_id. Не вимикайте коректне додаткове джерело лише тому, що їх декілька.
- Цінність передається динамічно і відповідає реальній економіці замовлення.
- Ідентифікатор замовлення передається, тому коригування можливі (джерело).
- Для періодів із технічними збоями розглянуто виключення даних, а не ручне прибирання звітів (джерело).
- Зафіксовано дату і зміст кожної зміни, щоб інтерпретувати подальшу динаміку.
Performance Max використовує налаштовані цілі разом з іншими доступними сигналами (довідка Google). Тому аудит конверсій є частиною оптимізації. Повторіть його після додавання нової події, джерела даних чи інтеграції, а також коли звітність перестає узгоджуватися з фактичними замовленнями.
Пов’язані матеріали UPLIFY
Два джерела — не завжди подвійна конверсія
Розрізняйте дві окремі conversion actions, що рахують одну покупку, та multi-source conversions усередині однієї дії. У поточній beta-функції Google додаткове джерело з бекенду чи CRM доповнює той самий запис. Зіставлення за transaction_id працює в межах однієї дії, а не між різними conversion actions. Функція доступна не всім акаунтам і стосується підтримуваних website actions через Google tag або GTM, а не імпортованих GA4 чи URL-based actions. Перевіряйте суму, валюту та згоду користувача; не передавайте клієнтські дані без погодженого процесу. Google Ads Help ↗
Не плутайте затримку звіту з поломкою
Google описує затримку відображення конверсій у звітах, яка залежить від джерела й моделі атрибуції. Звіт Ads також може відносити конверсію до дати рекламної взаємодії, а не покупки. Порівнюйте однакові періоди, часові пояси, вікна й моделі; перевірте колонки за часом конверсії. Дробове число конверсій може бути наслідком розподілу атрибуції, а не помилкою. Якщо реальних замовлень немає, справний тег не вирішує питання попиту, оффера, checkout чи якості трафіку. Google Ads Help ↗
Питання про конверсії PMax
Чому Performance Max не дає конверсій?
Спершу з’ясуйте, чи немає самих замовлень або лише даних про них у Google Ads. Перевірте статус дії, тестову подію, цілі саме цієї кампанії та затримку звіту. Якщо замовлень немає і вимірювання працює, наступна перевірка стосується попиту, пропозиції, посадкової сторінки й checkout. Не підмінюйте діагностику універсальним правилом про мінімальну кількість конверсій або бездумним збільшенням бюджету.
Чим основні конверсії відрізняються від другорядних?
Основна дія бере участь у ставках, коли кампанія використовує відповідну ціль. Другорядна зазвичай потрібна для спостереження в «Усіх конверсіях», але є виняток: дія всередині custom goal також може використовуватися для ставок. Тому перевіряйте і позначку, і склад цілі, і налаштування конкретної кампанії. Не змінюйте роль усіх дій масово лише за їхніми назвами без узгодження потрібного бізнес-результату.
Чому конверсії Google Ads і GA4 відрізняються?
Різниця сама по собі не доводить злам або дубль. Спочатку зіставте бізнес-подію, джерело, часовий пояс, період, вікно конверсії та модель атрибуції. Врахуйте дату рекламної взаємодії проти дати події й затримку обробки. Потім перевірте контрольне замовлення та окремі conversion actions. Результат звіряйте з бекендом на однаковій базі: зафіксована цінність конверсій не дорівнює підтвердженому прибутку магазину після повернень.
Чи прибирає transaction_id усі дублі?
Ні. Ідентифікатор допомагає зіставляти події в підтримуваній конфігурації, але не об’єднує автоматично дві різні conversion actions. Окремо перевірте повторне спрацювання тега, паралельний імпорт і вибір дій для ставок. Multi-source conversions у beta — інший сценарій: джерела доповнюють одну дію, і дедуплікація працює в її межах. Збережіть доступність функції, правила зіставлення та результати контрольного тесту в журналі перевірки.
Чим data exclusions відрізняються від conversion adjustments?
Data exclusions призначені для впливу перебоїв відстеження на Smart Bidding: вони не видаляють дані зі звітів. Conversion adjustments змінюють статус або цінність окремої раніше зафіксованої конверсії, наприклад після повернення. Перевірте підтримку вашого джерела, ідентифікатори й строки перед застосуванням. Не використовуйте виключення як регулярне очищення звітності та не очікуйте, що один із цих інструментів гарантує відновлення продажів або стабільність ставок.
Потрібна перевірка Google Ads?
Подивіться склад аудиту та приклад звіту: проблеми, докази, пріоритети й наступні дії. Запуск змін у кампаніях погоджується окремо; гайд не замінює перевірку вашого акаунта.