От набора ключевых слов к бюджету: как свести объём поиска, CPC и конкуренцию к одной цифре

Таблица из keyword tool сама по себе не отвечает на главный вопрос запуска: сколько денег отдать этому набору ключевых слов в текущем месяце. В ней есть объём поиска, CPC и уровень конкуренции для каждого запроса. Но бюджет нельзя получить простым взглядом на эти три колонки. Ниже разберём, как превратить их в рабочую бюджетную модель — и где модель действительно экономит время, а где лишь добавляет ошибок.

Сначала обозначим границы: все данные здесь взяты из публичных библиотек рекламы и creative center соответствующих платформ, через собственный аккаунт. Никаких подписей, обходов ограничений или закрытых источников. Речь только о том, как превратить доступные всем публичные данные в решение по бюджету.

Почему каждая из трёх метрик может обмануть

Обычно таблицу ключевых слов воспринимают как набор трёх неизменных чисел. На деле ни одна из этих колонок не даёт фиксированного значения.

Объём поиска зависит от выбранного окна. Один и тот же запрос может отличаться в разы при окне 7, 30 или 180 дней; рядом обычно есть и изменения месяц к месяцу, и год к году. Запрос с низким объёмом, который удвоился год к году, означает совсем не то же самое, что высокочастотный запрос, потерявший половину объёма за год. Если скопировать только колонку объёма, разницы между ними не видно.

CPC — это диапазон, а не конкретная точка. Планировщик показывает нижнюю и верхнюю границы. Взять на глаз медиану — значит стереть неопределённость, о которой платформа прямо предупреждает. Верхняя граница нужна для консервативного бюджета, нижняя — для оптимистичной оценки отдачи. Выбирая одно число, вы делаете вид, будто знаете то, чего на самом деле не знаете.

Конкуренция — относительный уровень, а не абсолютная сложность. Метка «низкая / средняя / высокая» назначается относительно всего пула ключевых слов платформы на момент применения фильтра. Она говорит лишь: «среди этих запросов конкуренция скорее высокая», а не «выиграть здесь объективно настолько-то сложно». Смените рынок или категорию — и уровень изменится. Сравнивать этот показатель как абсолютную шкалу между разными пулами ключей — самая незаметная из трёх ловушек.

Считать нужно по набору запросов, а не по словам

Когда становится ясно, что все три метрики условны, возникает следующий вопрос: почему нельзя посчитать для каждого слова «объём x CPC» и затем всё сложить?

Потому что объёмы близких по смыслу запросов не суммируются. «Купить X» и «цена X» с высокой вероятностью ищут одни и те же люди в рамках одной покупки. Если сложить их напрямую, одного пользователя посчитают дважды — и бюджет вырастет из ниоткуда.

Поэтому у зрелого планировщика, помимо представления по отдельным словам, есть агрегированное представление по набору ключей: вы отправляете группу запросов одним набором и получаете диапазон общего объёма поиска и диапазон оценки бюджета. Платформа сама убирает пересечения между словами, вместо того чтобы суммировать показатели построчно. Именно так она и рассчитывает бюджет для набора. Три колонки по каждому слову нужны для сортировки и группировки, но не для сложения.

Тема продукта — не всегда поисковый запрос

Это самая ценная ловушка в статье — и та, в которую попадают чаще всего: язык, которым вы называете продукт, нередко не совпадает с тем, что рынок вводит в поисковую строку.

Тематическое слово бизнеса — это внутренний язык компании: название продукта, функции или позиционирования на слайде. Поисковое слово — язык пользователя: более разговорный, привязанный к проблеме. Вы занимаетесь «AI video generation», и вашей темой будет «AI video generation». Но реальные пользователи могут искать «how to turn a photo into a video» или «text to video free». Для объёма поиска, CPC и конкуренции эти группы слов находятся в совершенно разных корзинах.

Такое несовпадение особенно губительно при выходе на другие рынки — когда тематическое слово просто переводят, хотя в целевой стране так не говорят, — и в новых категориях. Вы можете придумать новый термин, а рынок будет описывать новую потребность старыми словами. Решение здесь простое: тематическое слово служит только отправной точкой, а в бюджетную таблицу должны попадать запросы, выросшие из реального языка рынка. В зрелом процессе «тематические слова для креатива» и «поисковые слова рынка» — это два разных поля. Первое определяет, о чём говорит креатив; второе — куда уходит бюджет. Смешаете их — и купите пачку слов, которые никто не ищет, потому что они существуют только в вашем внутреннем языке.

Расширение семантики моделью: дайте ей сиды, контекст и потребуйте интент

Первое место, где модель действительно способна сэкономить время, — расширение нескольких сидов в таблицу, покрывающую реальные запросы рынка. Но только если ставить ей правильную задачу. На просьбу «расширь связанные ключевые слова» вы получите бесформенную кучу синонимов. В правильном промпте есть бизнес-контекст, а для каждого слова модель обязана вернуть три вещи:

Я запускаю поисковую рекламу для <одно предложение с описанием продукта> в
<целевой рынок/страна>.
Сиды: <от 3 до 10 уже известных вам слов>

Расширь список ключевых слов и выведи каждое строго в структуре ниже, без пояснительного текста:

1. Ключевое слово
2. Этап интента (awareness / comparison / decision / brand)
   awareness: пользователь описывает проблему и ещё не знает решения
   comparison: пользователь сравнивает несколько решений
   decision: пользователь готов купить, ищет канал/цену/альтернативу
   brand: пользователь ищет конкретный бренд
3. Почему слово смежно с сидом (другая формулировка той же потребности?
   следующий шаг воронки? смежная потребность в том же сценарии?)

Второй пункт превращает слово в элемент бюджетной модели. Без этапа интента расширенный ключ остаётся просто строкой. Третий нужен для проверки: в нём обычно разваливаются слова, которые модель придумала, но которые на деле не относятся к вашему бизнесу. Эти две колонки заставляют модель выдавать проверяемую структуру, а не просто правдоподобные ассоциации.

Проверка обратной связью: гипотезы модели должны пройти реальный объём поиска

Это контрольная точка всей цепочки. Именно её чаще всего пропускают, а затем запускаются по таблице из галлюцинированных запросов. Расширенные моделью слова — лишь гипотезы, пока вы не вернёте их в инструмент. Модель способна предложить грамматически безупречный запрос с правдоподобной меткой интента, который за месяц ищут ровно ноль человек. У неё нет доступа к живому объёму поиска: она оценивает, похожа ли фраза на настоящий поисковый запрос, но не проверяет, ищет ли её кто-либо в действительности.

Процесс здесь механический: отправьте каждое слово обратно в планировщик, получите реальный объём поиска, CPC и конкуренцию, а затем оставьте только запросы с ненулевым объёмом, чей интент согласуется с фактическими метриками. Согласуется — значит, например, что запрос, который модель отнесла к этапу decision, обычно имеет более высокий реальный CPC и более жёсткую конкуренцию. Если ему назначен decision-intent, но CPC нелепо низкий, а конкуренция находится на минимальном уровне, это не находка, а неверная разметка интента. Отправляйте такой запрос обратно на доработку.

Разделение ролей — «модель выдвигает гипотезу, реальные данные принимают решение» — повторяет ту же схему, что и распознавание моделью алгоритмов в обфусцированном коде с последующей проверкой её галлюцинаций дифференциальным тестированием в реверс-инжиниринге. Модель сильна в генерации кандидатов, но слаба в проверке фактов — нельзя поручать ей и то и другое одновременно. Для ключевых слов «проверкой обратной связью» служит дифференциальный тест, а утверждение volume > 0 куда авторитетнее фразы модели «это хороший запрос».

Бюджет распределяется по этапам интента

После валидации таблица ключевых слов получает рабочую структуру: у каждого запроса есть реальный диапазон объёма поиска, диапазон CPC, уровень конкуренции и метка этапа интента. Только теперь можно рассчитывать бюджет. Распределять его нужно не поровну между словами, а по этапам интента:

• Запросы с decision-intent («X price», «X alternative», «buy X»): они ближе всего к конверсии и наиболее ценны за клик, но имеют небольшой объём, самую высокую конкуренцию и максимальный потолок CPC. Для них нужен высокий приоритет и высокая допустимая цена, но с ограничением: людей, готовых купить прямо сейчас, всегда конечное число.

• Запросы с comparison-intent: находятся посередине и по конверсии, и по объёму; на них перетекает бюджет, который не удаётся эффективно потратить на decision-запросы.

• Запросы с awareness-intent («how to do X», «what is X»): дают максимальный объём и самый низкий CPC, но находятся дальше всего от конверсии. Им выделяется небольшая доля бюджета для охвата; не стоит ожидать от них конверсии на уровне decision-запросов.

Внутри каждой группы сортируйте запросы по «диапазон объёма x целевая доля x диапазон CPC». В итоге набор ключевых слов сводится не к одной взятой с потолка цифре, а к бюджетной структуре по этапам интента — с отдельным диапазоном для каждого этапа.

Какую модель брать на каждом шаге

Задачи модели в этой цепочке слишком различаются по требованиям. Одна модель на весь процесс либо тратит лишние деньги, либо жертвует точностью:

Отдельно стоит выделить первый шаг: именно при расширении семантики и классификации интента смена модели заметно меняет результат. Здесь проверяется, понимает ли модель ваш бизнес и умеет ли признать, что слово на самом деле нерелевантно. Более слабая модель выдаст полностью заполненную таблицу, где каждому запросу присвоен intent decision; один проход проверки обратной связью покажет удручающе низкую точность. Сильная модель с хорошим рассуждением сама отсечёт несмежные слова. Это легко проверить самостоятельно:

1. Возьмите один набор сидов: 5–10 слов, бизнес-контекст которых вам понятен.

2. Передайте одинаковые «сиды + бизнес-контекст» в claude-opus-5 и gpt-5.6-sol. Попросите у каждой модели 50 слов в формате «слово + этап интента + почему смежно».

3. Верните оба списка в планировщик и получите реальные объём поиска, CPC и конкуренцию.

4. Проверьте два показателя: сколько расширенных слов имеют ненулевой реальный объём, то есть не являются придуманными строками; и согласуются ли метки интента с реальными CPC и конкуренцией — запросы с decision-intent должны быть дороже и конкурентнее.

5. Эта точность попадания и станет критерием выбора: она напрямую определяет, сколько галлюцинированных слов придётся отбрасывать дальше по цепочке. Одного раунда достаточно, чтобы увидеть разницу нагляднее любого бенчмарка.

Главная проблема — цена переключения

Четыре модели от трёх вендоров, три SDK, три схемы авторизации, три формата ошибок. Переписывать клиент три раза, чтобы менять модели между расширением семантики, массовой разметкой и атрибуцией, невыгодно. Поэтому большинство остаётся на одной модели для всего процесса, использует для расширения уровень, который плохо понимает интенты, и получает низкую точность после проверки обратной связью, не понимая причины.

AIReiter убирает этот слой: один ключ, один OpenAI-совместимый интерфейс, все четыре уровня за ним, а переключение сводится к изменению поля model в теле запроса.

# Расширение ключевых слов + классификация интента: уровень с сильным рассуждением
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "<промпт на расширение + сиды + бизнес-контекст>"}]
  }'

# Массовая разметка сотен расширенных слов: меняем поле model, остальное оставляем
#   "model": "claude-sonnet-5"
# Атрибуция отклонений после проверки обратной связью:
#   "model": "gpt-5.6-sol"

Если вы уже используете OpenAI SDK, укажите для base_url значение https://aireiter.com/api/v1 и больше ничего не меняйте. Для Anthropic SDK используйте POST /api/v1/messages с тем же ключом.

По цене модели Claude идут со скидкой 30% от листовой стоимости, а GPT — за половину цены. Основные расходы в этом процессе создаёт не расширение: для одного набора ключей достаточно нескольких вызовов модели уровня reasoning. Реальный объём съедает массовая разметка — сотни или тысячи кандидатных слов на один проход планирования нужно разметить по интенту и дедуплицировать. Здесь нужны дешёвая высокопараллельная обработка, и Claude со скидкой 30% хорошо попадает в самый плотный участок вызовов.

• Получить API-ключ

• Попробовать без регистрации: сначала вручную расширьте один набор ключей, сравните точность обратной проверки слов от двух уровней моделей и только затем решайте, стоит ли подключать это в процесс.

Итог

Инструмент ключевых слов выдаёт три условные метрики: объём поиска зависит от окна, CPC является диапазоном, а конкуренция — относительным уровнем. Для запуска же нужна бюджетная структура, разбитая по этапам интента. Её основа такова: дедуплицируйте на уровне набора, а не суммируйте отдельные слова; начинайте с поискового языка рынка, а не с тематических слов бизнеса; поручайте модели расширение и разметку интента, но проверяйте каждый запрос по реальному объёму поиска; распределяйте бюджет по этапам интента, а не поровну между словами. Модель ускоряет расширение семантики и разметку интентов, но не должна принимать решение по бюджету.

После расчёта эта бюджетная цифра становится входом для этапа коммерческой валидации в пайплайне от ключевого слова до готового рекламного креатива: к подбору креаторов и генерации ассетов стоит переходить только для наборов ключей, чей бюджет проходит установленный порог. Параллельная линия решения — анализ посекундной кривой удержания рекламы: первая определяет, на какие слова вы ставите деньги, вторая — на какие креативы.