Структура аккаунта под 2026: зачем я режу кампании по стадиям воронки, а не по типам ключей

Структура аккаунта под 2026: зачем я режу кампании по стадиям воронки, а не по типам ключей

В 2026 я всё чаще отказываюсь от «классической» структуры: отдельные кампании под информационные/коммерческие ключи и отдельно — по продуктам. Она выглядит логично для SEO-логики и прошлой эпохи last-click, но плохо переживает три вещи: zero-click-потребление (часть запросов закрывается ответами в выдаче), рост роли Topical Authority (пользователь доверяет теме, а не одному лендингу) и push privacy-first-атрибуции (модель хуже видит “кто кого привёл”, если мы сами ломаем путь пользователя на несвязанные куски).

Моя практика: я строю аккаунт не по словам, а по стадии принятия решения. Это обычно 3 блока:
— Discovery (понимание проблемы/категории)
— Evaluation (сравнение вариантов и критерии выбора)
— Purchase/Activation (сделка, заявка, активация, продление)

Что меняется в настройках
1) В Discovery я не пытаюсь “продать”. Я даю контент-единицы, которые выдерживают AI-ответы и не исчезают при склейке с органикой: кейсы с цифрами, разборы процессов, чек-листы выбора, калькуляторы/тесты, объяснение методологии. Да, это выглядит как контент-маркетинг, но в платном поиске работает как инструмент предварительной квалификации.
2) В Evaluation я собираю сигналы выбора: ретаргет на взаимодействия, динамические сегменты по страницам (какая страница читалась, какое решение изучалось), кампании “покажи вариант решения под критерий”. Здесь важна сквозная логика: если Discovery должен привести к интересу, то Evaluation обязан убирать неопределённость — показать “почему мы” в терминах критериев, которые пользователь уже назвал.
3) В Purchase/Activation я ставлю задачу не “кликнуть”, а довести до события, которое реально монетизируется. Для performance-отдела это иногда больно, потому что ломает привычную KPI-иерархию “лид любой ценой”. Но в эпоху RevOps (ответственность маркетинга+sales+customer success за выручку) это становится нормой: мы оптимизируемся на качество, которое влияет на SQL и удержание.

Почему это помогает именно в поиске
Если кампании разрезаны по типам ключей, то алгоритм часто видит смесь разных намерений как один “портрет”. Он оптимизируется под среднее, а среднее в 2026 — почти всегда хуже. Когда же я режу по стадиям, я получаю более чистые поведенческие траектории:
— Discovery оптимизируется на ранние микрособытия (например, глубокие просмотры, загрузки материалов, прохождение теста)
— Evaluation — на “намерение сравнивать” (например, визит в страницу продукта/пакета + время на странице + возвраты в течение N дней)
— Purchase — на финальное событие (форма с подтверждением, старт процесса, активация)

Один практический факт из моей работы
В одном B2B-проекте (средний цикл сделки ~6–8 недель) мы перестроили поисковый аккаунт с разбиения “инфо/коммерческие” на стадии. Итог: CPL по лидовой цели упал на **18%**, но самое важное — доля SQL выросла на **+22%** при сопоставимом объёме трафика. Рост SQL был не магией креатива, а тем, что Discovery перестал тащить людей, которым “просто интересно”, а Purchase перестал догонять тех, кто ещё не сформировал критерии. То есть мы сократили разрыв между сообщением и готовностью к действию.

Мой вывод (и почему я настаиваю на этом)
В платном поиске будущего “правильная структура” — это та, которая собирает целостную историю пользователя в измеримых шагах. Если вы сейчас всё оптимизируете под один финальный KPI и при этом ведёте людей из холодных запросов напрямую в продажу — вы платите за неопределённость.

Если хотите, можете написать в ответ: у вас сейчас структура по ключам, по продуктам или по аудиториям? Я скажу, где именно у вас, скорее всего, теряется связность пути (обычно это место видно по тому, как ведут себя CPC/CTR и что происходит с качеством лидов на переходе между кампаниями).

— @PaidSearchRoom