Цілі конверсій Google Ads: як правильно налаштувати основні й додаткові дії та цілі на рівні облікового запису
Google Ads може оптимізувати кампанії лише в тому напрямі, який компанія дозволяє своєю архітектурою цілей. Саме тут у малих і середніх компаніях виникають дорогі непорозуміння: натискання на номер телефону враховують нарівні з кваліфікованим замовленням, імпортована з GA4 подія працює паралельно з тегом Google Ads або одна кампанія місяцями використовує інші цілі, ніж решта облікового запису. В інтерфейсі й надалі відображаються конверсії. Проте залишається незрозумілим, чи мають усі вони однакове значення для бізнесу.
Цей посібник пропонує для такої перевірки реєстр цілей конверсій. Він пов’язує кожну дію-конверсію з бізнес-результатом, джерелом даних, роллю в оптимізації, сферою застосування, доказом якості та задокументованим дозволом. Внутрішні статуси реєстру СТОП, СПОСТЕРЕЖЕННЯ, ТЕСТ КАМПАНІЇ та СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ навмисно не є налаштуваннями Google Ads. Вони відображають процес перевірки з боку компанії: дія може бути технічно налаштована в Google Ads як Primary, тобто основна, але все одно отримати в реєстрі статус СТОП, якщо вона зараховує результат двічі або не відображає надійної бізнес-цінності.
Ціль конверсії — не один перемикач
Роль дії, тип цілі та сферу застосування потрібно читати разом
В офіційному огляді цілей конверсій описано багаторівневу архітектуру. На нижньому рівні міститься дія-конверсія: наприклад, покупка, зафіксована тегом Google, імпортована подія GA4 або кваліфікований лід із CRM. За категорією дії об’єднуються у стандартні цілі на кшталт «Покупка», «Контакт» або «Надсилання форми». Для більшості дій-конверсій саме на рівні дії визначають, чи буде вона Primary або Secondary, тобто основною чи додатковою; для окремих типів дій такий вибір обмежений. На рівні цілі або кампанії вирішують, які стандартні цілі буде включено та чи успадковуватиме кампанія типовий набір цілей облікового запису, чи матиме власний.
Ці рівні відповідають на різні запитання. Категорія описує, яку саме дію вимірюють. Primary або Secondary загалом визначає роль дії в оптимізації. Стандарт облікового запису окреслює набір цілей для нових кампаній і кампаній, які його успадковують. Власний вибір кампанії локально замінює цей набір. Custom Goal, тобто спеціальна ціль, є окремим вручну сформованим винятком. Якщо читати всі ці рівні як один перелік «конверсій», можна правильно вибрати окремий параметр і водночас побудувати неправильну архітектуру загалом.
| Рівень | Об’єкт | Ключове запитання | Типове налаштування | Вплив | Доказ у реєстрі |
|---|---|---|---|---|---|
| Бізнес | Реальний результат | Яка дія створює економічну цінність? | Замовлення, кваліфікований лід або покупка | Визначає бізнес-критерій | Підтвердження з CRM, магазину або фінансової системи |
| Дані | Дія-конверсія | Яке джерело фіксує та передає подію? | Тег Google, GA4 або офлайн-імпорт | Створює вимірюваний набір даних | Тестовий випадок і унікальний ID |
| Значення | Категорія цілі | До якої категорії належить дія? | Purchase, Qualified lead або Contact | Упорядковує дії для цілей і звітів | Категорія, що відповідає змісту |
| Оптимізація | Роль дії | Чи має дія регулярно впливати на ставки? | Primary або Secondary | Впливає на стовпці та можливість оптимізації ставок | Дозвіл і перевірка винятків |
| Обліковий запис | Стандартна ціль | Які цілі мають бути типовими? | Use as account goal | Її використовують кампанії, що успадковують стандарт облікового запису | Перелік охоплених кампаній |
| Кампанія | Вибір цілей | Чи успадковує кампанія стандарт? | Account-default або campaign-specific | Визначає фактично застосований набір цілей | Подання кампанії та журнал змін |
Таблицю потрібно перевіряти в обох напрямах. Технічно чистий показник без бізнес-значення не є доброю ціллю. Цінне замовлення без надійної передачі ще не є придатним сигналом. І дія Primary не керує автоматично кожною кампанією: вона має входити до цілі, яку відповідна кампанія справді використовує. Поза таким вибором дія не є явно заданою ціллю оптимізації та не відображається для цієї кампанії у стовпці «Conversions»; водночас Google зазначає, що такі дані Primary можуть допомагати прогнозуванню. Лише узгодженість усіх шести рівнів дає підставу для дозволу.
Бізнес-результат важливіший за налаштування в інтерфейсі
Надіслана форма ще не є кваліфікованим замовленням
Перш ніж змінювати налаштування, компанія описує результат своєю бізнес-мовою. Для ремісничого підприємства це може бути підтверджений виїзд у межах потрібного регіону. Для B2B-постачальника лід може стати кваліфікованим лише після перевірки ролі контакту, потреби й бюджету. В інтернет-магазині покупка не обов’язково є прибутковою, якщо не враховано повернення, знижки або різну маржинальність. Дія-конверсія — це вимірюване наближення до результату, а не автоматичне підтвердження його правдивості.
Навіть доречна категорія не замінює бізнес-визначення. Огляд оновлених категорій конверсій Google розрізняє, зокрема, Purchase, Add to cart, Begin checkout, Qualified lead, Converted lead, Submit lead form, Book appointment, Request quote, Contact, Page view та Other. Категорія полегшує групування й читання звітів, однак сама не надає дії більшої цінності й не перетворює надіслану форму на кваліфікований лід.
Тому для кожної дії реєстр зберігає коротке бізнес-визначення: подію-тригер, допустимі випадки, винятки та систему підтвердження. Наприклад, «Qualified lead» може означати: з людиною можна зв’язатися, її місцезнаходження підходить, потреба реальна, а потрібна послуга належить до пропозиції компанії. Це визначення мають однаково розуміти відділ продажів, маркетинг і агенція. Якщо його немає, дія отримує СТОП. Якщо визначення існує, але звірка з внутрішньою системою ще ненадійна, статус буде СПОСТЕРЕЖЕННЯ. Лише коли технічні й бізнес-вибірки підтверджують той самий результат, можна вирішувати, чи дозволяти дії впливати на ставки.
Primary і Secondary визначають роль дії в оптимізації
Сигнал для ставок потрібно відокремити від спостереження
Згідно з офіційним поясненням Primary і Secondary Conversion Actions, звичайна дія Primary, тобто основна дія, відображається у стовпці «Conversions» і може використовуватися для призначення ставок, якщо кампанія справді застосовує відповідну ціль. Дія Secondary, тобто додаткова, загалом призначена для спостереження, показується в «All conversions» і в межах звичайних стандартних цілей не слугує сигналом для ставок. У цьому твердженні є дві важливі умови: одного статусу Primary недостатньо, а Secondary не означає «неважлива» чи «не вимірюється».
Різницю видно на прикладі. Продавець вимірює покупку, початок оформлення замовлення та перегляд товару. Покупка може бути Primary, бо вона найближча до бізнес-результату. Початок оформлення й перегляд можуть залишатися Secondary, щоб зміни в шляху користувача були помітними, але Smart Bidding не отримував три дії різної глибини як нібито рівнозначні успіхи. У сервісної компанії надіслана форма може спершу залишатися Secondary, тоді як підтверджений згодом кваліфікований лід стає Primary. Якщо надійного офлайн-зворотного зв’язку ще немає, форма може тимчасово слугувати тестовим сигналом; однак така перехідна схема потребує дати, відповідальної особи й умови заміни.
Тому ці терміни не варто сприймати як позначки престижу. Secondary може бути важливою діагностичною метрикою. Primary може бути поганим сигналом, якщо його легко штучно збільшити, він дублюється або має надто широке бізнес-значення. Крім того, діє виняток для Custom Goal із розділу 7: дія, позначена як Secondary, усе одно може використовуватися для ставок у межах застосованої спеціальної цілі. Отже, кожен дозвіл має перевіряти не лише статус дії, а й тип цілі та конкретний вибір кампанії.
Реєстр цілей конверсій робить рішення перевірюваними
Шість полів пов’язують бізнес-цінність, якість даних і масштаб застосування
Реєстр не копіює огляд конверсій. Він доповнює технічну конфігурацію інформацією, якої Google Ads не може знати: економічним значенням, зрілістю даних, відповідальністю з боку бізнесу та підставою для дозволу. У поданні Goals → Conversions → Summary, відповідно до актуальної інструкції з керування цілями конверсій, можна, зокрема, керувати параметром Account Default і Action Optimization як Primary або Secondary, а також створювати Custom Goals. Зміна статусу здатна вплинути на всі кампанії, які використовують відповідну ціль. Саме тому кожній зміні налаштувань має передувати запис у реєстрі.
| Дія-конверсія | Бізнес-результат | Джерело та доказ якості | Роль у Google і сфера застосування | Статус реєстру | Наступна умова дозволу |
|---|---|---|---|---|---|
| Покупка — тег Google | Оплачене замовлення | Тестова покупка, ID транзакції та звірка з магазином | Purchase · Primary · стандартна ціль · без Custom Goal · призначено для Account Default | СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ | Щомісячно перевіряти цінність, скасування й дублікати |
| Покупка — GA4 | Те саме оплачене замовлення | Паралельне вимірювання показує той самий набір замовлень | Purchase · Secondary · стандартна ціль · без Custom Goal · без прямого використання для ставок | СПОСТЕРЕЖЕННЯ | Пояснити розбіжності, не робити обидві дії Primary |
| Форму надіслано | Неперевірене звернення | Тест тегу пройдено, якість у CRM нестабільна | Submit lead form · Secondary · стандартна ціль · без Custom Goal · спостереження | СПОСТЕРЕЖЕННЯ | Отримати надійну частку якісних лідів і фільтрацію спаму |
| Кваліфікований лід | Потенційна угода, перевірена відділом продажів | Статус CRM, ID завантаження та вибіркова перевірка | Qualified lead · Primary · стандартна ціль · без Custom Goal · лише пілотна кампанія | ТЕСТ КАМПАНІЇ | Підтвердити обсяг, затримку й цінність у тестовому вікні |
| Натискання на номер телефону | Намір без підтвердженої розмови | Подія браузера без доказу дзвінка | Contact · Secondary · стандартна ціль · без Custom Goal · не вибрано як ціль | СТОП | Спершу пов’язати з фактичним дзвінком і мінімальною тривалістю |
| Стара сторінка подяки | Немає однозначного результату | Можливі повторне завантаження й подвійний підрахунок | Submit lead form · Primary · входить до застарілої Custom Goal · кілька кампаній | СТОП | Зафіксувати участь у Custom Goal та охоплені кампанії, потім замінити |
Ланцюжок статусів має вигляд СТОП → СПОСТЕРЕЖЕННЯ → ТЕСТ КАМПАНІЇ → СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ, але не кожна дія мусить дійти до останнього етапу. Корисний мікросигнал може назавжди залишитися у статусі СПОСТЕРЕЖЕННЯ. Якісну, але рідкісну офлайн-дію спершу можна дозволити лише для ТЕСТУ КАМПАНІЇ. СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ в цьому внутрішньому реєстрі означає, що дія дозволена як Primary у стандартній цілі, яка може слугувати Account Default. Сам параметр Account Default залишається на рівні цілі й не примушує автоматично кожну наявну кампанію використовувати цю дію.
До реєстру також належить журнал змін: дата, попередній стан, новий стан, охоплені кампанії, особа, яка надала дозвіл, очікуваний вплив і правило повернення. Знімок екрана фіксує інтерфейс, але не рішення. Запис у реєстрі пояснює, чому компанія дозволяє певній дії впливати на оптимізацію та який доказ може змінити це рішення.
Цілі конверсій на рівні облікового запису формують стандарт для кампаній
Стандарт облікового запису означає успадкування, а не відсутність винятків
Account-default Conversion Goals утворюють типовий набір для кампаній, які успадковують це налаштування облікового запису. Офіційний опис цілей конверсій на рівні облікового запису розділяє два рівні: Use as an account goal задається для цілі, а Primary або Secondary — для окремої дії. Коли типовий набір облікового запису змінюється, це впливає на кампанії, які використовують Account-default; кампанія з власними цілями не обов’язково успадкує зміну.
Тому стандарт облікового запису є управлінським рішенням. Він має містити небагато бізнес-результатів, які справді актуальні для більшої частини облікового запису. Якщо покупка, кошик, оформлення замовлення й перегляд сторінки одночасно входять до загального обсягу оптимізації, система може переслідувати кілька етапів одного шляху, хоча економічно значущою є лише покупка. Для лідів логіка така сама: натискання на контакт, форма, зустріч і кваліфікована потенційна угода не можуть вважатися взаємозамінними без логіки цінності та якості.
Перед зміною команда визначає всі кампанії, що успадковують стандарт облікового запису, і всі винятки. Нові кампанії можуть автоматично приймати цей стандарт, а чинні конфігурації з цілями на рівні кампанії залишаються окремими випадками. Відповідно до документації, Account-default Goals не застосовуються до кампаній для застосунків: потрібні дії-конверсії там завжди вибирають на рівні кампанії. Тому в реєстрі записують не лише «на рівні облікового запису: так», а й групи кампаній, які успадковують стандарт, винятки та відповідальну особу, що регулярно перевіряє ці винятки.
Цілі на рівні кампанії потребують обґрунтованого винятку
Виняток — частина архітектури, а не швидка кнопка ремонту
За допомогою campaign-specific goals кампанія може замінити загальний набір вибраними стандартними цілями та, за потреби, Custom Goal. У документації про цілі конверсій на рівні кампанії Google загалом рекомендує спільний набір Account-default, оскільки так подібні кампанії навчаються на узгодженому наборі цілей. Виняток усе ж може бути доречним, якщо кампанія справді працює на інший бізнес-результат, а не просто тому, що її поточні показники незручні.
Обґрунтований приклад — B2B-кампанія, яка має оптимізуватися на кваліфіковані потенційні угоди, тоді як окремий напрям самообслуговування орієнтований на прямі покупки. Менш обґрунтовано додавати простішу мікроціль, щойно падає коефіцієнт конверсії, лише щоб в інтерфейсі знову з’явилося більше «конверсій». Так цільова функція змінюється посеред оцінювання, а приваблива цифра після цього відповідає вже на інше запитання. Різна економічна цінність також не завжди є приводом розділяти цілі. Якщо той самий тип результату має різні значення, коректна стратегія ставок на основі цінності може бути доречнішою.
Custom Goal — головний виняток із простого правила Secondary
У Custom Goal навіть додаткова дія може впливати на ставки
Custom Goal може вручну об’єднати конкретні дії-конверсії з різних стандартних цілей. За чинної архітектури цілей в одній кампанії можна використовувати щонайбільше одну таку спеціальну ціль. Це не нейтральна папка для звітності: коли Custom Goal застосована до кампанії, усі придатні для ставок дії в її складі використовуються для звітів і ставок. Це прямо стосується й дій, для яких Action Optimization встановлено як Secondary. Дії-конверсії Store Sales Direct є винятком: їх не можна використовувати для ставок навіть у межах Custom Goal.
Такий виняток операційно небезпечний, бо поверхова перевірка може створити хибне відчуття безпеки. У деталях дії зазначено «Secondary (observe only)», але та сама дія входить до застосованої Custom Goal і все одно впливає на кампанію. Тому реєстр потребує окремого поля «Входить до Custom Goal» та перехресної перевірки на рівні кампанії. Простого експорту переліку дій Primary недостатньо.
Custom Goals виправдані лише тоді, коли чітко визначена кампанія потребує комбінації, яку неможливо належно відтворити стандартними цілями. Їх не варто використовувати, щоб обходити неясні категорії, складати докупи кілька мікросигналів або штучно компенсувати брак даних легкими діями. Перед дозволом кожну дію у складі оцінюють окремо. Якщо комбінація містить дію зі статусом СТОП, Custom Goal також отримує СТОП. Якщо вона постійно об’єднує різні типи результатів, значення та ціль ставок мають економічно відображати ці відмінності.
Мікро- й макроконверсії виконують різні завдання
Більше сигналів не обов’язково означає кращі сигнали
Макроконверсії безпосередньо пов’язані з бізнес-результатом: покупка, підтверджене замовлення на послугу, кваліфікована потенційна угода або оплачена підписка. Мікроконверсії описують проміжні дії, як-от перегляд товару, глибина прокручування, завантаження PDF, додавання до кошика чи натискання на спосіб зв’язку. Обидва типи можуть бути корисними для діагностики. Проблема виникає, коли саму можливість виміряти подію плутають із її придатністю для оптимізації.
Smart Bidding навчається не на внутрішній оцінці команди, а на переданих цілях і значеннях. Якщо часта взаємодія зі сторінкою стає Primary, вона здатна кількісно затьмарити рідший, але важливіший результат. Тоді система може ефективно знаходити більше простих дій, тоді як кількість замовлень не зростає. Мале або середнє підприємство отримує активність, але не обов’язково виторг чи кваліфікований попит. Саме тому мікродії зазвичай залишають Secondary і використовують для діагностики воронки. Тимчасове використання як Primary потребує чіткого обґрунтування, відмінності в цінності й визначеної умови заміни.
Кілька джерел даних не повинні множити той самий бізнес-випадок
Тег Google, імпорт GA4 та передані офлайн-дані потрібно звіряти на рівні дії
Типовий обліковий запис вимірює ту саму покупку за допомогою тегу Google Ads та імпорту GA4, іноді ще й доповнює їх офлайн-завантаженням. Кілька дій Primary для одного замовлення можуть повідомити Smart Bidding про кілька окремих успіхів. ID транзакції допомагає в межах належно налаштованої дії, але не гарантує дедуплікації між різними діями або джерелами.
Дія-конверсія, створена через інтерфейс Google Analytics, за замовчуванням отримує статус Secondary. Щоб регулярно використовувати її для ставок через стандартну ціль, у Google Ads її переводять у Primary; однак у застосованій Custom Goal вона може впливати на ставки навіть як Secondary. Історичні дані за період до імпорту не завантажуються. Розбіжності між Ads та Analytics не обов’язково свідчать про помилку, адже можуть відрізнятися, зокрема, дата звітування, метод підрахунку, атрибуція та вікно конверсії.
Власник конверсій також має бути визначений однозначно. За відстеження конверсій у кількох облікових записах клієнтський обліковий запис використовує або власні дії-конверсії, або дії, надані керуючим обліковим записом (MCC), а не обидва набори одночасно. Редагувати спільні дії може лише відповідний керуючий обліковий запис. Під час переходу на відстеження конверсій через керуючий обліковий запис (MCC) кампанії, які раніше використовували конкретні дії клієнтського облікового запису, переводяться на типові цілі керуючого облікового запису; якщо обліковий запис згодом повертається до власного відстеження, вибір цілей потрібно перевірити знову. Попередня статистика через це не зникає, однак вибір цілей та історію слід задокументувати до й після кожного переходу.
Для кожного реального результату реєстр називає провідне джерело даних, а іншим призначає роль контролю, резерву або повідомлення про якість. Тестові випадки показують, які дії спрацьовують, із яким значенням, валютою та ID. Невирішене багаторазове зарахування отримує СТОП, а не усереднене число з суперечливих систем. Технічне встановлення залишається окремою робочою ділянкою.
Значення, метод підрахунку та вікно конверсії визначають зміст сигналу
Правильна дія з неправильною економікою все одно є хибною ціллю
Дія, правильна за бізнес-змістом, може стати непридатною через хибні значення. Магазин із кошиками, що сильно різняться, не повинен передавати для всіх однакове фіксоване значення. Значення ліда не можна подавати як точний виторг, якщо воно є лише очікуванням; як модельний показник його потрібно прозоро вивести з імовірності укладання угоди, доходу або маржинального доходу.
Метод підрахунку також має відповідати бізнес-випадку. Для покупок важливе кожне унікальне замовлення. Натомість повторне надсилання форми тією самою людиною за короткий час не обов’язково означає кілька нових можливостей. Вікно конверсії має відповідати реальному циклу ухвалення рішення: надто коротке недооцінює тривалі продажі, а дуже довге може охопити пізніші контакти, які потребують обережнішого тлумачення. Конверсії за показами та конверсії після активного перегляду відео слід аналізувати окремо, якщо вони присутні в конкретному налаштуванні.
Реєстр зберігає джерело значення, частоту оновлення, валюту, метод підрахунку, вікно та затримку даних. Для лідів додають частку повернення даних: яка частка лідів узагалі отримує наступний статус у CRM? Приваблива звітна CPA ненадійна, якщо багато записів ніколи не повертаються зі статусом кваліфікованих або відхилених. Лише відповідні параметри дають підставу для статусу ТЕСТ КАМПАНІЇ чи СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ; реалізація лишається поза межами цієї статті.
У звітності потрібно розділяти конфігурацію та результат
Conversions, Conversion value та All conversions — різні показники
Стовпець «Conversions» показує конверсії з дій Primary у стандартних і спеціальних цілях, на які оптимізується конкретна кампанія. Винятком є дія Secondary у застосованій Custom Goal: вона також використовується для ставок і потрапляє до «Conversions». «Conversion value» показує присвоєне значення цих конверсій, а не автоматично виторг чи прибуток. Стовпець кампанії «Conversion goals» допомагає побачити, які цілі вибрано. Документація про звітування щодо результатів додатково описує «Results» («Результати») на рівні кампанії. Цей стовпець показує дії Primary з усіх стандартних цілей облікового запису: результати з цілей, на які оптимізується кампанія, відображаються звичайно, а інші отримані результати — сірим. Дії Secondary там не з’являються. Custom Goals не показуються як окреме групування, хоча дія Primary з їхнього складу може з’явитися через відповідну стандартну ціль. У кампаніях для застосунків стовпець Results не підтримується. Отже, «Results» і «Conversions» не в кожному налаштуванні є тим самим числом.
Стовпець «All conversions» ширший. Він охоплює звичайні конверсії, дії Secondary, а залежно від ситуації — додаткові типи на кшталт конверсій за показами, певних даних про дзвінки або відвідування магазинів. Це діагностичне подання, а не безпосереднє відображення переліку цілей Smart Bidding. Зростання «All conversions» може виникнути через більшу кількість спостережуваних мікродій, навіть якщо основний бізнес-результат не покращився.
Тому звіти сегментують за дією-конверсією та джерелом. Команда порівнює чотири подання: фактичні цілі кампанії, Conversions за діями, All conversions за діями та результати внутрішньої системи за той самий період. Де можливо, значення також розкладають за діями. Категорії допомагають упорядкувати зміст, але не замінюють економічної перевірки. Різні числа передусім є підставою для розслідування. Їх не можна ані автоматично додавати, ані замінювати тим показником інтерфейсу, який здається найправдоподібнішим.
Зміни цілей потребують протоколу тестування
Одна гіпотеза, одна зміна й одне правило повернення
Коли змінюється дія, її статус або набір цілей, змінюються і оптимізація, і тлумачення звітів. Офіційна інструкція з оновлення цілей конверсій рекомендує перед зміною переглянути охоплені кампанії через «Review campaigns» і зберегти їх у CSV. Якщо дію видалити, вона архівується й може бути відновлена; історичні дані через це не стираються. Однак нова логіка цілей усе одно здатна суттєво змінити поточну оптимізацію ставок.
| Гіпотеза | Базовий рівень | Єдина запланована зміна | Основна метрика | Захисна метрика | Правило повернення |
|---|---|---|---|---|---|
| Кваліфіковані ліди дають кращий сигнал для ставок, ніж надіслані форми | Форми, якість у CRM і витрати до переходу | Використовувати Qualified lead як Primary в одній пілотній кампанії | Витрати на кваліфіковану потенційну угоду | Обсяг лідів, затримка й частка укладених угод | Повернути попередній вибір цілей, якщо припиниться повернення даних із CRM |
| Подвійна дія GA4 потрібна лише для діагностики | Покупки за тегом і GA4 для кожного замовлення | Залишити покупку GA4 Secondary, а покупку тегу — провідним джерелом | Покупки та значення, підтверджені внутрішньою системою | Прогалина у вимірюванні провідного джерела | Тестувати альтернативне джерело лише після підтвердженої відмови |
| Стандарт облікового запису підходить основним кампаніям | Вибір цілей і значення всіх основних кампаній | Застосувати визначений стандарт до тестової групи | Спільний бізнес-результат | Волатильність, бюджет і якість результату | Документовано повернути кампанії-винятки до попередніх налаштувань |
| Мікроціль викривляє ставки | Співвідношення мікро- й макродій та попередня якість | Прибрати мікродію з набору, що впливає на ставки | Макроконверсії або значення | Охоплення й кваліфіковані проміжні кроки | Зупинити зміну, якщо ланцюжок вимірювання класифіковано хибно |
| Custom Goal містить неправильну дію Secondary | Дії, ролі та участь у кампаніях | Очистити або замінити Custom Goal | Потрібний тип результату | Обсяг за кожною дією у складі | Відновити попередню конфігурацію лише за задокументованим аварійним дозволом |
У протоколі тестування зазначають одну гіпотезу й одну свідомо контрольовану зміну. Технічні аварії, звісно, можна виправляти негайно, але їх також протоколюють. Одночасна зміна цілі, бюджету, стратегії ставок, атрибуції та цільової сторінки позбавляє оцінювання однозначності. Так само немає універсальної обіцянки, що результати стабілізуються рівно через сім чи чотирнадцять днів. Тривалість спостереження визначають за затримкою конверсій, обсягом і бізнес-метою, а правило повернення погоджують до початку.
Шлях погодження веде через сім контрольних етапів до стандарту облікового запису
Сім етапів упорядковують перевірку, тест і впровадження
Цей шлях не дозволяє технічно видимій події одразу стати сигналом для ставок у всьому обліковому записі. Кожен етап має перевірюваний результат і відповідальну особу. Якщо команда пропускає етап, попередній статус у реєстрі не змінюється.
- Бізнес-етап: команда називає реальний результат, його економічну цінність і винятки. Без спільного визначення діє СТОП.
- Етап джерела: тег, GA4, CRM або магазин прив’язують до однозначного випадку; ID, значення й валюту перевіряють на тестах. За подвійного підрахунку діє СТОП.
- Етап якості: вибірка підтверджує, що виміряна подія справді відповідає бізнес-визначенню. Якщо зрілості даних вистачає лише для діагностики, статусом буде СПОСТЕРЕЖЕННЯ.
- Етап ролі: вибір Primary або Secondary обґрунтовують на рівні дії; участь у стандартних і Custom Goals перевіряють окремо. Неперевірений виняток Custom Goal веде до СТОП.
- Етап сфери застосування: команда перелічує кампанії, що успадковують стандарт облікового запису, кампанії з власними цілями, керуючий обліковий запис і всі винятки. Лише після цього саме запланована пілотна група отримує зміну.
- Тестовий етап: протокол тестування з розділу 12 діє протягом вікна, що відповідає затримці даних. Основну й захисні метрики звіряють із внутрішньою системою та базовим рівнем; до завершення статус лишається ТЕСТ КАМПАНІЇ.
- Етап стандарту: лише технічно стабільна й економічно обґрунтована дія з визначеним процесом супроводу отримує в реєстрі СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ, тобто дозвіл на роль Primary у стандартній цілі, погодженій на рівні облікового запису. Відповідальна особа, частота контролю й правило повернення залишаються чинними і після впровадження.
Цей шлях не обов’язково проходити лінійно до кінця. Перегляд товару може після етапу якості назавжди залишитися у статусі СПОСТЕРЕЖЕННЯ. Рідкісній офлайн-конверсії може знадобитися кілька тестових циклів. Якщо подальша звірка з внутрішньою системою покаже погіршення, дію зі статусом СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ повертають до ТЕСТУ КАМПАНІЇ або СТОП. Управління означає не раз назавжди сертифікувати налаштування, а регулярно знову доводити його обґрунтованість.
Правила СТОП захищають ставки від хибних сигналів
Коли потрібно відмовити в дозволі або повернути попередній стан
Негайний СТОП потрібен за невирішеного подвійного підрахунку, відсутнього чи мінливого бізнес-визначення, неправильної валюти, статичних вигаданих значень, неоднозначних транзакцій або джерела даних без названої відповідальної особи. Те саме правило діє, якщо Secondary непомітно входить до застосованої Custom Goal, кампанія використовує не ті цілі, що зафіксовані в протоколі тестування, або перехід на рівні всього облікового запису планують без переліку охоплених кампаній.
До попереднього стану повертаються, якщо основне джерело перестає працювати в робочому середовищі, офлайн-дані більше не передаються повністю, різко зростає спам або частка некваліфікованих лідів, значення не збігаються з внутрішньою системою чи якість тестового результату падає нижче погодженої захисної межі. Саме зменшення кількості конверсій ще не є помилкою: після вилучення нецінної мікроцілі число може знизитися, тоді як керування стане змістовно кращим. Вирішальним є бізнес-доказ, визначений заздалегідь.
Enhanced Conversions не змінюють цієї системи управління. У червні 2026 року Google розпочав поетапне об’єднання налаштувань для Web і Leads в одному перемикачі; доступність оновленого інтерфейсу потрібно перевіряти в конкретному обліковому записі. Згідно з актуальною документацією про налаштування Enhanced Conversions, надані користувачем дані можуть опрацьовуватися через теги, Data Manager та API. Це рівень даних і зіставлення. Він не створює автоматично нової цілі, не перетворює дію на Primary і не замінює ані стандарт облікового запису, ані вибір кампанії. Конкретна технічна реалізація належить до наступного спеціалізованого посібника, а не до удаваного «ремонту» реєстру цілей.
СТОП не обов’язково означає «вимкнути кампанію». Він може означати: вилучити дію з набору, що впливає на ставки, полагодити джерело даних, від’єднати Custom Goal, призупинити пілот або повернутися до задокументованого стану. Статус захищає цільову функцію, поки команда з’ясовує причину й відповідальність.
90-денний план веде від інвентаризації до надійного стандарту
Чотири етапи від інвентаризації до стандарту облікового запису
Дев’яносто днів — це робоча рамка, а не гарантія достатнього обсягу даних. Обліковий запис електронної торгівлі зі щоденними покупками може швидше відповісти на окремі запитання; B2B-компанії з довгим циклом продажу потрібно більше часу для оцінки якості й виторгу. Вирішальне значення має послідовність: спершу інвентаризація, потім очищення, далі обмежений тест і лише наприкінці — ширший стандарт.
| Етап | Мета | Основна робота | Потрібний доказ | Рішення |
|---|---|---|---|---|
| Дні 0–14 | Провести інвентаризацію цілей | Зібрати дії, категорії, ролі, джерела, Custom Goals, стандарт облікового запису й винятки кампаній | Повний реєстр та експорт охоплених кампаній | СТОП або СПОСТЕРЕЖЕННЯ для кожної дії |
| Дні 15–30 | Очистити основу вимірювання | Перевірити тестові випадки, ID, значення, валюту, метод підрахунку, вікно та звірку з внутрішньою системою | Немає невирішеного дублювання; бізнес-вибірка пройшла перевірку | Дозвіл на тест або ремонт |
| Дні 31–60 | Перевірити обмежену зміну цілі | Реалізувати одну гіпотезу в чітко названій групі кампаній і записати зміну | Порівняння зрілих основної та захисних метрик із базовим рівнем | ТЕСТ КАМПАНІЇ: продовжити, зупинити чи розширити |
| Дні 61–90 | Закріпити управління | Дозволити придатну дію як стандарт, задокументувати винятки й частоту перевірок | Визначено відповідальну особу; підтверджено моніторинг і правило повернення | СТАНДАРТ ОБЛІКОВОГО ЗАПИСУ або подальший тест |
Технічні засади, зокрема тегування, GA4 і Consent Mode, докладніше розглянуто в посібнику про налаштування відстеження конверсій Google Ads за допомогою GA4 і Consent Mode. Для оцінки економічного впливу дозволеного сигналу далі потрібно вирішити, як компанії вибрати відповідну стратегію ставок Google Ads для кліків, CPA або ROAS. Якщо статус клієнта сам стає частиною цільової функції, необхідна окрема перевірка того, як правильно вимірювати залучення нових клієнтів у Performance Max. Ці поглиблені матеріали не замінюють реєстру; вони позначають суміжні рішення, що мають власну методику.
Поширені запитання про цілі конверсій Google Ads
Вісім відповідей проти хаосу цілей в обліковому записі
Наведені нижче відповіді стосуються актуальної архітектури цілей Google Ads. Вони не замінюють ані технічної перевірки відстеження, ані погодження з боку бізнесу.
Чи використовує Smart Bidding автоматично кожну конверсію Primary?
Ні. Для звичайних стандартних цілей дія має бути Primary, а кампанія повинна справді використовувати відповідну ціль. Дія Primary поза вибраним набором не є явно заданою ціллю оптимізації цієї кампанії та не відображається для неї у «Conversions»; водночас Google може використовувати такі дані для поліпшення прогнозів. Тому роль дії й цілі кампанії завжди перевіряють разом.
Дії Secondary взагалі не враховуються?
Враховуються. Зазвичай вони відображаються у «All conversions» і можуть бути важливими для діагностики, аналізу воронки або контролю якості. У стандартних цілях вони переважно не використовуються для ставок. Вирішальний виняток — застосована Custom Goal: у її складі навіть дія Secondary може впливати на ставки.
Що означає «на рівні облікового запису» для цілей конверсій?
Це означає, що стандартна ціль визначена як Account Default для кампаній, які успадковують таке налаштування. Вона не є незмінним примусом для кожної кампанії. Цілі на рівні кампанії можуть локально замінити стандарт. Account-default Goals не застосовуються до кампаній для застосунків: там дії-конверсії вибирають на рівні кампанії.
Чи мають кошик, оформлення замовлення й покупка всі бути Primary?
Зазвичай ні, якщо єдина причина полягає в тому, що всі три події можна виміряти. Коли справжнім результатом є покупка, попередні кроки можуть лишатися Secondary для діагностики. Проміжна дія, що впливає на ставки, потребує обґрунтованого зв’язку з бізнес-цінністю, відповідних значень і правила заміни або перевірки.
Чи може імпорт GA4 залишатися Primary паралельно з тегом Google Ads?
Технічно може існувати кілька дій, але з погляду бізнесу виникає ризик подвійного підрахунку того самого випадку. Команда визначає провідне джерело й перевіряє ті самі тестові замовлення за дією, ID, значенням і часом. Друге джерело часто залишається Secondary, поки для нього не доведено іншу чітку функцію.
Коли доцільна Custom Goal?
Коли окрема кампанія потребує обґрунтованої, вручну складеної комбінації конкретних дій, яку стандартні цілі не відображають належним чином. Це не папка для всього. Усі придатні для ставок дії в її складі впливають на призначення ставок у кампанії, де застосовано цю ціль, зокрема дії Secondary; дії-конверсії Store Sales Direct залишаються винятком. Тому участь кожної дії потрібно погоджувати окремо.
Чи видаляє вилучення дії-конверсії її історію?
Після вилучення дія архівується та може бути відновлена; попередня статистика не стирається. Проте вилучення здатне змінити звіти й оптимізацію. Тому заздалегідь зберігають перелік охоплених кампаній, базовий рівень і шлях повернення.
Скільки чекати після зміни цілі?
Універсального строку, який гарантує стабільність кожного облікового запису, немає. Вікно залежить від затримки конверсій, обсягу, стратегії ставок і бізнес-циклу. Справжні помилки вимірювання виправляють негайно, а результати оцінюють лише після досягнення погодженої зрілості даних.
Наступний крок: погодити цілі конверсій як план керування
Перелік конверсій має стати погодженим планом керування
Надійна архітектура починається не з перемикання Secondary на Primary. Вона починається з реального результату, однозначного джерела та перевірки з боку бізнесу. Далі команда перевіряє категорію, роль дії, тип цілі й сферу застосування. Семиступеневий шлях показує, чому за дією спостерігають, чому її тестують в одній кампанії або чому дозволяють як стандарт облікового запису.
Реєстр цілей конверсій створює для цього спільну мову між керівництвом, маркетингом, продажами, аналітикою та агенцією. Він також фіксує, які дії свідомо залишають Secondary, які кампанії не успадковують стандарт і яке правило повернення діє в разі помилки. Це не усуває ризик, але робить зміну зрозумілою та зворотною.