# Голиаф: управление платным трафиком

Источник: https://kurzemnek.ru/method/goliath
Автор: Валерий Курземнек
Опубликовано: 2026-10-23
Обновлено: 2026-10-23


<h2 id="task">Задача</h2>

Голиаф — агентская система управления Яндекс Директом. Она разбирает рекламные данные, готовит решения и выполняет разрешённые действия через API — программный интерфейс кабинета. Скрипты считают метрики, модель разбирает результат, отдельный критик проверяет основания решения.

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

<h2 id="prerequisites">Что потребуется</h2>

Перед управлением расходом подготовьте четыре основания:

- **Данные.** Расход, рекламные объекты и события воронки должны связываться с людьми и оплатами. Рядом с источниками нужны время обновления, известные ограничения и определения метрик. Повторная регистрация и новый человек учитываются раздельно.
- **Расчёт.** Значимое число должно воспроизводиться по указанным источникам. Для денежного решения нужна независимая сверка. Если источники расходятся, сначала выясните причину.
- **Правила.** Запишите условия остановки, продолжения и увеличения бюджета, окно оценки и исключения. Пороги рассчитываются по экономике и задержке продаж вашего бизнеса; числа из кейса не становятся готовым регламентом.
- **Полномочия.** Отделите доступ на чтение от права менять кабинет. Укажите допустимые действия, предел расхода и ситуации, которые передаются человеку.

Готовность данных проверяется через [диагностику](/method/diagnosis), право действовать — через [шкалу полномочий](/method/authority). Исправный источник сам по себе не разрешает агенту тратить деньги.

<h2 id="process">Схема процесса</h2>

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

<figure class="g-process" aria-labelledby="g-process-caption">
<figcaption id="g-process-caption">От исходных данных до проверенного результата</figcaption>
<ol class="g-process-track">
<li><strong>Данные → проверка источников</strong><p>Расход и события поступили полностью; определения и расчёт сходятся.</p></li>
<li><strong>Предложение → критик</strong><p>Правило применимо; действие укладывается в бюджет и полномочия.</p></li>
<li><strong>Действие → замер</strong><p>Изменение записано в журнал; прогноз сравнивается с фактом.</p></li>
</ol>
<p class="g-process-stop"><strong>Проверка не пройдена → действие блокируется.</strong> Причина возвращается на доработку.</p>
<p class="g-process-return">Результат → журнал → проверенный урок → следующий запуск.</p>
</figure>

<h2 id="rollout">Этапы внедрения</h2>

1. **Описать одну петлю.** Выберите задачу и готовую основу, которую можно доработать. Зафиксируйте цель, источники, единицу счёта, период и допустимый расход на проверку гипотезы. Результат этапа — понятное описание того, какое решение должна подготовить система.
2. **Подключить чтение и проверить расчёт.** Сопоставьте рекламу, людей и оплаты. Воспроизведите один расчёт и проверьте поведение при неполных данных. До этого этапа вывод о слабом объявлении может оказаться выводом о сломанном источнике.
3. **Записать правила и запустить предложения.** Агент показывает, что сделал бы и почему. Критик проверяет основания. Человек разбирает расхождения: требуется уточнить правило, исправить расчёт или восстановить данные.
4. **Открыть ограниченное действие.** Разрешите запись через API только для проверенных решений. Сохраните предел доступного расхода и порядок остановки. Отказ критика должен блокировать действие и возвращать задачу на доработку.
5. **Измерить исход и проверить урок.** После назначенного окна сравните прогноз с результатом. Подтверждённую ошибку перенесите в проверку и убедитесь, что на следующем запуске система ведёт себя иначе. Затем можно рассматривать следующую петлю.

<h2 id="example">Учебный разбор: расход есть, заявки пропали</h2>

<div class="g-example">
<p class="g-example-label">Условный пример</p>
<p>В рекламном отчёте есть расход, а новых заявок нет. Агент предлагает остановить объявление по правилу отсутствия результата. Это учебный сценарий для проверки устройства петли; он не описывает отдельный запуск Голиафа.</p>
</div>

Сначала проверьте основание «нет заявок»: совпадают ли период и рекламный объект, поступили ли события, видны ли регистрации в CRM. Отсутствие строки в отчёте ещё не объясняет, что произошло с человеком после клика.

Дальше возможны разные решения:

- **Регистрации есть в CRM, но не дошли до отчёта.** Основание для остановки не подтверждено. Действие блокируется, расхождение передаётся на исправление. После восстановления данных расчёт выполняется заново.
- **Источники проверены, заявок действительно нет.** Можно проверять условие остановки: достаточно ли наблюдений, истекло ли окно, применимо ли правило. Затем критик сверяет решение. Исполнение возможно только в пределах выданных полномочий.
- **Источники не удалось сверить.** Система сообщает, каких данных не хватает. Решение об остановке по отсутствию заявок остаётся заблокированным до проверки.

В журнале сохраните входные данные, причину выбранной ветки и разрешённое действие. В реальном [кейсе Голиафа](/cases/goliath) ошибка на стыке разметки и платформы уже приводила к неверной остановке. Из неё появилось требование сверять источники перед выводом об отсутствии результата.

<h2 id="acceptance">Критерии приёмки</h2>

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

<ul class="g-checklist">
<li><strong>Расчёт воспроизводится.</strong> По указанным источникам можно повторить число в той же аудитории и за тот же период.</li>
<li><strong>Сбой данных обнаруживается.</strong> Устаревший или неполный источник блокирует действие, основанное на этих данных; причина видна человеку.</li>
<li><strong>Отказ критика останавливает запись.</strong> После отказа задача возвращается на доработку.</li>
<li><strong>Полномочия соблюдаются.</strong> Действие за пределами разрешённого бюджета или перечня операций не выполняется самостоятельно.</li>
<li><strong>Решение восстанавливается по журналу.</strong> Сохранены исходные числа, правило, действие и последующий результат.</li>
<li><strong>Обслуживание учтено.</strong> Определено, кто проверяет исключения, поддерживает доступы и проверяет обновления до расширения полномочий.</li>
</ul>

<h2 id="connections">Связи с другими направлениями</h2>

[Соломон](/method/solomon) даёт аналитическое основание для рекламного решения. [Воронка](/method/funnels) связывает привлечение с последующими событиями. Общий [стандарт](/method/standard) сохраняет определения, проверки и журнал при переходе между направлениями. История автономии, результаты и рамка измерения остаются в [кейсе Голиафа](/cases/goliath).

Для своей задачи используйте [открытый шаблон плана](/method/direct-plan), [шесть требований спецификации 1.0](/method/specification) и [учебные проверки](/method/examples). О работе Голиафа также опубликован [разбор на Sostav](https://www.sostav.ru/publication/kazhdyj-rubl-mashinochitaemyj-kak-zerokoder-otdal-upravlenie-reklamoj-ii-agentu-85530.html).

<h2 id="public-boundary">Что открыто в этой главе</h2>

<div class="g-boundary">
<p>Здесь опубликованы подход, порядок внедрения и требования к проверке. Рабочая сборка Голиафа, внутренние инструкции агентов, конфигурации и доступы в документацию не входят. Для своего бизнеса потребуется заново связать источники, рассчитать правила и проверить поведение системы.</p>
</div>