Перейти до контенту

Fix: Сітлінки, callout-и та structured snippets прикріплені лише на рівні ad group

знахідка google ads оновлено 2026.05.27 8 хв читання

Аудит виявив, що asset extensions — сітлінки, callout-и, structured snippets, call-и, promotions, lead forms — прикріплені до окремих ad group, але не підняті на рівень campaign або вище. Для акаунтів, які вже закрили базові пороги по кількості асетів, це polish-можливість, яка розширює auction eligibility і знижує накладні витрати на підтримку. Це не блокер і не там, де живе найбільший lift у перформансі.

Чому це важливо

Asset extensions — це слоти, які перетворюють однорядковий текстовий ad на багаторядковий блок у результатах пошуку: сітлінки, callout-и, structured snippets, call-кнопки, промо, lead-форми. Google описує їх як компоненти, що збагачують ad додатковою інформацією про бізнес і подаються динамічно, коли аукціон передбачає покращення перформансу [1]. Прикріплення безкоштовне, а оплачується лише стандартний клік за взаємодію.

Рівень, на якому ти прикріпив асет, визначає, на яких campaign і ad group він eligible до показу — а інколи й те, чи заблокує він показ асетів вищого рівня. Документація Google описує модель гілки: якщо ти створив асет на рівнях account, campaign і ad group у межах однієї ієрархічної гілки, аукціон може брати їх з будь-якого з цих рівнів. Для сітлінків Google прямо зазначає, що асети, визначені на всіх трьох рівнях у межах гілки, eligible до показу разом, і Google підбирає найкращу комбінацію в auction time [2].

Інші типи асетів підкоряються жорсткішому правилу. Structured snippets, створені на рівні ad group, блокують показ snippets з рівнів campaign і account для цієї ad group — Google Help прямо говорить: "If you created these ad assets at a more granular level, they will prevent higher level structured snippet assets from serving" [3]. Call assets поводяться так само — Google зазначає, що "the most specific will be used", коли call assets існують на кількох рівнях [4].

Цей мікс має операційне значення. Акаунт, який прикріплює кожен асет на рівні ad group, успадковує три недоліки:

  1. Заглушення вищого покриття. Для structured snippets і call assets ad-group-рівень повністю блокує campaign- і account-fallback [3][4]. Якщо випадково видалити ad-group-запис — ad group буде показуватися взагалі без snippet.
  2. Фрагментація підтримки. Сітлінк до сторінки pricing, який живе у п'ятдесяти ad group, вимагає п'ятдесяти редагувань при зміні URL. Той самий сітлінк на campaign- або account-рівні — це одне редагування.
  3. Повільніше навчання асетів. Google оцінює асети як Learning, Low, Good або Best на основі serving data. Розщеплення impressions між багатьма ad-group-копіями того ж асету означає, що кожна копія накопичує свою частку impressions повільніше — а це може подовжити час, який алгоритм проводить у Learning.

Для акаунтів, що вже на мінімумах по заголовках і кількості асетів, консолідація більшості асетів на campaign- або account-рівні — це next-tier optimization, яка компаундує всі три недоліки. Marginal lift живе у ширшій auction eligibility і нижчій opportunity cost з підтримки — не у драматичному стрибку CTR. Це diminishing-returns territory, і саме тому finding оцінений як LOW.

Як перевірити проблему

  1. Відкрий Google Ads. Перейди в Ads & assetsAssets.
  2. Клікни на таб типу асету, який хочеш проаудитувати (Sitelinks, Callouts, Structured snippets, Calls, Promotions, Lead forms).
  3. Додай колонку Level через column picker, якщо її не видно. Колонка Level показує, на якому рівні (Account, Campaign або Ad group) асоційовано кожен асет.
  4. Відфільтруй або відсортуй за Level. Якщо переважна більшість рядків — Ad group, правило відпрацювало коректно.
  5. Перехресно перевір на рівні campaign: відкрий Campaigns → обери будь-яку campaign → Assets. Якщо асети campaign успадковані лише з ad-group-записів, без campaign- або account-fallback — це підтверджує патерн фрагментації.
  6. Для structured snippets і call assets окремо зверни увагу на ad group, які мають власний запис — ці ad group блокують вищий fallback навіть тоді, коли вищий асет існує [3][4].

Час на перевірку: 10 хвилин для невеликого акаунту, 30 хвилин для акаунту з десятками campaign.

Як виправити

  1. Визнач, які асети evergreen. Пройдися по поточному ad-group-набору. Помітьте кожен як "застосовується до більшості campaign/ad group в акаунті" (evergreen) або "специфічний для ad group" (інший лендинг, інша мова, обмежена за обсягом пропозиція).
  2. Підніми evergreen-асети на account- або campaign-рівень. Використовуй Ads & assetsAssets+ → обери тип асета → на кроці "Add to" обери Account або конкретний Campaign замість ad group. Перестворі evergreen-записи на новому рівні.
  3. Прибери надлишкові ad-group-копії. Для сітлінків видалення дубліката опціональне — модель гілки дозволяє дублікатам співіснувати [2]. Для structured snippets і call assets видалення ad-group-копії — єдиний спосіб дозволити вищому запису обслуговуватися на цій ad group [3][4].
  4. Зберігай ad-group-рівень лише там, де це виправдано. Реальні винятки: ad group, що веде на нестандартний лендинг (наприклад, локалізований варіант); ad group, що працює в мові, відмінній від решти campaign; ad group, що рекламує timed offer, який не діє на всю campaign.
  5. Постав account-level fallback. Навіть якщо кожна campaign має свій campaign-level набір, account-level callout-и і сітлінки покривають будь-яку майбутню campaign, запущену без власних асетів. Це найдешевша страховка у asset-стеку.
  6. Задокументуй політику. Запиши decision rule ("evergreen → account або campaign; ad group лише тоді, коли лендинг або мова відрізняються") у changelog акаунту, щоб майбутні оптимізатори не дрейфували назад до ad-group-рівня за замовчуванням.

Час на фікс: 30-90 хвилин на аудит і консолідацію, залежно від розміру акаунту.

Як переконатися що виправлення спрацювало

  • У Ads & assetsAssets колонка Level показує, що evergreen-асети тепер на рівні Account або Campaign.
  • Жодна ad group не має дублікат structured-snippet або call-asset запису, який заглушує вищий fallback (хіба що це заглушення свідоме).
  • Asset report показує, що impressions накопичуються на нових записах вищого рівня (перевір через 7 днів serving data).
  • Рейтинги асетів (Learning / Low / Good / Best) на консолідованих записах рухаються з Learning до Good або Best у міру концентрації impressions.
  • Campaign-level Asset reports показують покриття по сітлінках, callout-ах і snippets — жодна campaign не обслуговується тепер з нульовою кількістю асетів у певній категорії.
  • Немає вимірюваного падіння CTR чи конверсій у 14-денному вікні після консолідації.

Verification window: 14 днів після консолідації. Асети auction-eligible, а не гарантовані, тож serving frequency наростає протягом першого тижня, поки алгоритм Google вчиться кожній новій комбінації.

campaign_level_assets_usage — polish-tier finding, що зазвичай співпадає з rsa_long_headlines_filled, fix-callout-extensions (під-заповнені callout) і fix-structured-snippets (під-заповнені snippet headers). Це не передумова жодного більшого фікса — акаунти можуть ігнорувати цей finding нескінченно, не ламаючи атрибуцію, бідинг чи навчання. Бери в роботу після того, як закриті findings вищої severity (broad-match negatives hygiene, tROAS value tracking, attribution model consistency).

Фікс механічний: перестворити evergreen-асети на вищому рівні, потім прибрати надлишкові ad-group-копії там, де suppression — активний ризик (structured snippets і call assets). Diminishing-returns territory — корисно, але не той важіль, що рухає головні KPI акаунту.

Пов'язані правила + концепти

Джерела

  1. Google Ads Help — About assets. https://support.google.com/google-ads/answer/7332837 (accessed 2026-05-27)
  2. Google Ads Help — About sitelink assets. https://support.google.com/google-ads/answer/2375416 (accessed 2026-05-27)
  3. Google Ads Help — About structured snippet assets. https://support.google.com/google-ads/answer/6280012 (accessed 2026-05-27)
  4. Google Ads Help — About call assets. https://support.google.com/google-ads/answer/2453991 (accessed 2026-05-27)
// чи було корисно?
// анонімно · не зберігаємо персональні дані