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

«Вводите ключевое слово — на выходе получаете рекламный ролик». Именно так сегодня продают почти все AI-инструменты для креативов. И именно на этом обещании проще всего обмануть самого себя.

Стоит попробовать запустить такой процесс в реальной работе — и за словом «автоматически» сразу обнаруживается длинный список нерешенных вопросов. Что делать, если ключевой запрос слишком нишевый, в органической выдаче ничего нет, а в коммерческой библиотеке тоже пусто? Остановить процесс с сообщением «недостаточно данных» или отправить пустой бриф в генерацию и получить ролик, который никто не валидировал? А если на середине пути один из каналов недоступен для вашего аккаунта и данные не возвращаются? Это «результатов нет» или «запрос вообще не выполнялся»? Реагировать на эти ситуации нужно противоположным образом, но большинство решений в один клик показывают в обоих случаях один и тот же бесконечный лоадер.

Рабочий креативный конвейер ценен не кнопкой «Сгенерировать» в финале. Его главная задача — честно показывать состояние каждого этапа. Только так процесс можно использовать в production и быстро понять, где именно он сломался, если на выходе ничего не появилось.

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

Пять этапов, из которых собирается рабочий конвейер

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

1. Поиск спроса. Берем поисковый запрос рынка, ищем органический контент и проверяем, есть ли у темы реальный интерес со стороны пользователей. На выходе получаем сигнал по органическому контенту.

2. Коммерческая валидация. Здесь нужны два коммерческих сигнала. Первый — потенциал ключевого слова: поисковый объем, конкуренция, данные со стороны рекламных расходов. Второй — Top Ads из creative center, которые показывают хорошие результаты. За оба типа сигналов уже платили деньгами, и оба прошли рыночную проверку — это принципиально отличает их от органического контента.

3. Подбор авторов. Ищем в библиотеке инфлюенсеров авторов, которые подходят под тему и целевой рынок.

4. Креативный бриф. Собираем квалифицированные данные трех предыдущих этапов в структурированную спецификацию, которую можно сразу передать модели генерации. Здесь фиксируются драматургия, тип хука и целевой рынок.

5. Генерация. Передаем бриф модели генерации видео и получаем вертикальную нативную рекламу в формате 9:16.

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

Каждый из первых трех этапов заслуживает отдельного разбора. О том, как читать retention curve посекундно, как превратить потенциал ключевого слова в одно число рекламного бюджета и как сопоставлять библиотеку инфлюенсеров с библиотекой ассетов, а не выбирать людей по числу подписчиков, уже рассказывают три другие статьи. Здесь разберем вопросы, которые возникают только после объединения этих этапов в единую цепочку.

Шесть статусов этапа: почему одного «failed» недостаточно

Это самый важный раздел статьи.

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

В этой цепочке результат каждого этапа должен попадать в один из шести статусов:

• completed: этап выполнился, вернул квалифицированный результат и передает его дальше.

• empty: этап запускался, канал был доступен, но квалифицированных результатов не нашлось. Искали — ничего не нашли.

• skipped: вы сами отключили этап, установив для него квоту 0, поэтому он вообще не запускался.

• unavailable: этап должен был запуститься, но не смог. Канал недоступен для вашего аккаунта — например, keyword opportunity покрывает только часть языков рынка — либо временно недоступна зависимость.

• blocked: данных с предыдущих этапов недостаточно, поэтому сработал намеренный gate. Сам этап не сломался: просто сверху не пришли нужные входные данные.

• ready: промежуточный статус только для генерации. Preflight пройден, но задачу еще не отправили. Видео можно создать, система ждет вашего подтверждения.

Дело не в том, чтобы придумать шесть названий. Как только empty, skipped, unavailable и blocked сливаются в единый «failed», конвейером невозможно управлять. Во всех четырех случаях результат один — «в этот раз видео не будет», — но от вас требуются совершенно разные действия.

• empty означает проблему с данными. Возможно, на рынке нет объема или запрос выбран слишком узко. Нужно изменить формулировку запроса либо ослабить порог — без правок в коде.

• skipped — это ваше собственное решение. Делать ничего не нужно, но статус обязан отличаться от empty, иначе можно полдня отлаживать этап, который никто даже не включал.

• unavailable указывает на проблему с каналом или конфигурацией. Проверяйте покрытие аккаунта либо повторите попытку, а не перебирайте ключевые слова.

• blocked означает проблему выше по цепочке. Сам слой исправен, но один из предыдущих этапов вернул пустой результат. Ищите этап со статусом empty, а не пытайтесь чинить заблокированный слой.

Один непрозрачный статус «failed» закрывает все четыре пути и заставляет гадать. Поэтому конвейер, который отдает результат, но не показывает статусы, долго не проживет. При каждой проблеме придется воспроизводить весь процесс с нуля, чтобы понять, что именно произошло.

Воронка доказательств: органику и коммерческие сигналы нельзя складывать в общий балл

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

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

Это правило работает даже внутри одного ролика. При оценке органического видео лайки и комментарии — один тип сигнала, а репосты и сохранения — другой. Репосты и сохранения ближе к коммерческому намерению: это действия в духе «стоит оставить» или «стоит переслать». При ранжировании они должны весить больше обычного вовлечения. Объем engagement показывает, что видео интересно смотреть. Репосты и сохранения говорят, что оно, возможно, способно продавать. Даже в пределах одного видео это разные вещи.

(Небольшое отступление: на этапе атрибуции модель особенно склонна принимать корреляцию за причинность, а частотность — за эффективность. Поэтому промпт должен принуждать ее приводить контрпример. Это та же дисциплина промпта, которая заставляет модель не останавливаться на распознанном паттерне в статье о fingerprinting. Там речь о контрдоказательствах при reverse engineering, здесь — о контрпримере в рекламной атрибуции. Механика одна и та же.)

Два значения «ready»: готовность платформы и достаточность данных

Непосредственно перед генерацией есть две проверки, которые очень легко объединить — и категорически нельзя объединять: «может ли платформа создать видео» и «стоит ли создавать именно это видео».

Первая — platform preflight ready: доступен ли сервис генерации, хватает ли квоты, разрешен ли промпт. Это инфраструктурные проверки. Вторая — research evidence ready: есть ли среди собранных данных хотя бы один квалифицированный первичный источник. Это проверка на уровне содержания. Перед отправкой должны пройти обе, а при сбое любой из них статусом будет blocked.

Объединить их очень хочется, ведь обе отвечают на вопрос «можем ли мы генерировать». Но именно это ведет к самому дорогому типу ошибки: платформа исправна, квоты достаточно, промпт разрешен, preflight проходит — и система создает видео на нулевой доказательной базе. Это дороже корректного отказа, потому что внешне выглядит как успех, и на такой ролик можно реально потратить рекламный бюджет. Если gates разделены, этот случай безопасно останавливается на blocked и прямо сообщает: не хватает данных, а не квоты. «Можем создать» никогда не равно «следует создавать»; объединение этих условий в одно — самая распространенная ошибка при проектировании подобных конвейеров.

Бриф использует только квалифицированные данные: тексты конкурентов остаются в исследовании

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

Задача модели — извлечь из квалифицированных данных подтвержденную структуру. Какие хуки повторяются в Top Ads, на какой секунде достигает пика retention curve, какой каркас использует успешный органический контент: «сформулировать проблему, показать результат, призвать к действию». Затем эти структуры собираются в спецификацию для генерации.

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

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

Инструкция «выдели из массива данных действительно подтвержденные структуры, активно исключай утверждения конкурентов и приводи контрпример для каждой “эффективной структуры”» проверяет ровно те же качества: сильное рассуждение и готовность спорить с собственным выводом. Это то же распределение ролей, что и в статье о том, что модель должна и не должна делать в reverse engineering: модель хорошо формирует гипотезы и плохо проверяет факты, поэтому верификация должна опираться на ваши данные и тесты.

Как распределить модели по этапам

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

Отдельно тестировать стоит именно уровень подготовки брифа. Это единственный этап, где смена модели заметно меняет результат. Проверка конкретная, и это единственное место в статье, где нужно провести собственный тест.

1. Возьмите из действительно завершенного запуска конвейера один квалифицированный набор доказательств: хуки Top Ads, ключевые точки retention curve, профили авторов, потенциал ключевого слова и несколько успешных органических материалов.

2. С одним и тем же промптом для брифа — правила такие: использовать только структуру ассетов, явно исключать названия брендов, цены, квоты и заявления об эффективности, приводить по одной контргипотезе для каждой «эффективной структуры» — отдельно подайте набор в claude-opus-5 и gpt-5.6-sol.

3. Смотрите только на два критерия: не протекли ли в промпт генерации конкретные утверждения конкурента — утечка означает провал, — и приводит ли модель контрпример, когда заявляет, что структура работает, или просто принимает частотность за эффективность.

4. Эти два показателя и должны определять выбор. От них напрямую зависит, будет ли сгенерированный ролик «копировать сценарий конкурента» или «использовать проверенную структуру».

Одного прогона достаточно, чтобы увидеть разницу намного яснее, чем в любом бенчмарке. Пакетный слой извлечения полей — Sonnet — почти не требует подбора: подойдет любая стабильно работающая модель. Kimi для длинного контекста выбирается, чтобы вам не пришлось самостоятельно строить chunked retrieval.

Генерация видео: отправить задачу, дождаться финального статуса и не потерять task_id при таймауте

Генерация — это не «вызвали API и получили видео». Создание видео занимает время: вы отправляете задачу, она попадает в очередь, а результат становится известен только после опроса до терминального состояния. У этого этапа три разных сценария завершения, и смешивать их нельзя.

• Вернуться сразу после отправки. Задача встает в очередь, вы получаете task_id и статус processing. Необязательно сидеть и ждать — можно заняться другими делами.

• Дождаться терминального статуса. Опрос продолжается до completed или failed. Именно это и есть результат, ради которого запускалась задача.

• Достигнуть таймаута ожидания. Вы ограничили polling по времени, но результат не успел прийти. Нельзя выбрасывать такую задачу как failed. Правильное действие — сохранить task_id, отметить задачу как «таймаут, не завершена» и позже продолжить ожидание по тому же id, а не отправлять ее повторно. Повторная отправка означает повторные расходы.

Именно третий случай чаще всего реализуют неправильно. Многие решения приравнивают «истек таймаут polling» к «задача завершилась ошибкой» и выбрасывают ролик, который все еще рендерится, просто дольше ожидаемого. Умение отличать «задача завершилась ошибкой» от «я перестал ждать в этот раз» — основа этого этапа. Первое — терминальное состояние. Второе означает лишь, что ожидание было прервано. Задача и ее id никуда не делись: продолжайте работу с ней.

При пустых данных не запускайте генерацию

Если свести все ограничения выше в одно правило, получится самое неочевидное и одновременно самое ценное правило конвейера: когда все источники данных пусты, генерацию отправлять не нужно.

Поиск спроса — empty, коммерческая валидация — empty, подбор авторов — empty. Во всех трех направлениях нет ни одного квалифицированного первичного доказательства. Бриф получает blocked, gate research-ready на preflight генерации не проходит, вся цепочка останавливается на blocked, и не генерируется ни единого кадра.

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

Половина ценности конвейера — в способности генерировать. Вторая половина — в понимании, когда генерация не нужна. Первое — возможности, второе — дисциплина. А условием этой дисциплины служат шесть статусов, о которых говорилось выше. Без различения empty и blocked у вас не будет чистого сигнала «все пусто», на котором можно строить решение «не отправлять задачу».

Один ключ для аналитики и генерации

Проектирование конвейера на этом заканчивается. Остается чисто инженерное препятствие — и именно на нем чаще всего все и застревают.

Нужные для этой цепочки модели относятся к двум типам поставщиков. Текстовые уровни — чтение данных, извлечение полей, подготовка брифа и атрибуция — приходят от нескольких вендоров, а генерация — это отдельный сервис для изображений и видео. Можно подключить для каждого уровня свой SDK, схему авторизации и формат ошибок. Или, как делают большинство, использовать одну модель для всего: переплачивать на пакетных задачах, терять точность в брифе, а затем отдельно подключать видеоплатформу. Чтобы сэкономить усилия на интеграции, качество всего конвейера понижается на ступень.

AIReiter убирает этот слой. Один ключ, один OpenAI-совместимый интерфейс, все четыре текстовых уровня за ним; переключение выполняется сменой поля model в теле запроса. Генерация изображений и видео доступна на том же сайте и с тем же ключом, поэтому после подготовки брифа можно сразу попробовать создать ролик в /chat.

# Write the brief: the reasoning tier
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": "<brief prompt + qualified evidence bundle>"}]
  }'

# Extract fields in bulk: change the model field, leave the rest
#   "model": "claude-sonnet-5"
# Stage attribution:      "model": "gpt-5.6-sol"
# Read long evidence at once: "model": "kimi-k3"

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

Цены хорошо ложатся на структуру затрат этого конвейера. Самый плотный по вызовам этап — пакетное извлечение полей: десятки или сотни ассетов, по одному вызову на каждый, и именно здесь формируется основная часть текстовых расходов. Скидка 30% на Claude попадает прямо в эту задачу: Sonnet обрабатывает пакет, Opus дорабатывает бриф, то есть оба уровня Claude. Атрибуция выполняется на GPT-5.6 за половину цены. Длинные массивы данных обрабатывает Kimi K3 с тем же ключом. Генерация — отдельная статья расходов с оплатой за запуск, но она включается только после прохождения evidence gate, когда видео действительно стоит создавать. Правило «не запускать при полностью пустых данных» само по себе экономит деньги на генерации.

• Получить API key

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

Вывод

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

Управляемость этого участка держится на трех принципах. Каждый этап завершается одним из шести статусов, а не просто «успехом или ошибкой», поэтому empty, skipped, unavailable и blocked всегда указывают на понятное следующее действие. Данные группируются по типам и ранжируются по надежности, а не суммируются, поэтому сильный сигнал не тонет в массе слабых. Наконец, «можем создать» и «следует создавать» разделены на два gate, поэтому полностью пустая доказательная база безопасно останавливает процесс до генерации.

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