Структура рекламного проекта
В предыдущем уроке мы согласовали обещание объявления и посадочную страницу. Теперь требуется организовать рекламный проект так, чтобы эти связи не потерялись при появлении нескольких групп запросов и материалов. Структура нужна не ради красивых папок, а ради управления: кто меняет предложение, где действует ограничение и к какому документу относится результат.
Продолжим учебную «Линию». В кампании продвигается AUDIT-ONE на /audit/. У нас нет настоящего рекламного аккаунта, выбранной страны или утверждённой валюты. Структура ниже является нейтральной моделью проекта, которую позже можно сопоставить с конкретной платформой. Никакие кампании, группы и настройки в кабинетах не создаются.
Выделяем уровни решения
На уровне проекта фиксируются предложение и его версия. На уровне кампании — задача привлечения, канал и будущие ограничения расходов. На уровне группы — связанное намерение человека и набор сообщений. На уровне объявления — конкретная формулировка или визуальный материал. На уровне посадочной страницы — обещанный результат и действие.
Это редакционная модель, а не утверждение, что все системы устроены одинаково. Google Ads, Директ и другие площадки имеют собственные типы кампаний, правила наследования и доступные поля. При будущем переносе нужно читать актуальную документацию конкретного формата. Сейчас мы определяем смысл объектов, чтобы не зависеть от одного интерфейса.
Для проекта используем LINE-AUDIT. Поисковая кампания получит идентификатор SEARCH-AUDIT, а экспериментальная контекстная группа будет обсуждаться отдельно. Поиск и визуальные размещения не объединяем только ради общего отчёта: у них разные ситуации показа. При этом предмет услуги остаётся одним, и изменение паспорта AUDIT-ONE должно быть видно всем связанным материалам.
Делим группы по задаче человека
Первая группа AUDIT-INTENT относится к человеку, который прямо ищет аудит лендинга. Вторая MESSAGE-PROBLEM относится к задаче понять, почему посетители не замечают предложение и действие. Эти группы могут вести на одну страницу, но тексты объясняют разные входные вопросы. Мы не назначаем им действительных ставок и не заявляем измеренный спрос.
Неудачная структура создаёт отдельную группу для каждой перестановки слов. Тогда много объектов описывает один смысл, а изменение объявления требует десятков правок. Другой крайний случай объединяет аудит, разработку, обучение и рекламу в одну группу. Тогда становится трудно сохранить точное предложение. Полезная граница находится между самостоятельными задачами, а не между случайными вариантами написания.
{
"project_id": "LINE-AUDIT",
"offer_id": "AUDIT-ONE",
"campaigns": [{
"id": "SEARCH-AUDIT",
"status": "draft",
"groups": ["AUDIT-INTENT", "MESSAGE-PROBLEM"],
"landing": "/audit/"
}],
"account_created": false
}Устанавливаем устойчивые названия
Человеческое имя удобно для чтения, а идентификатор нужен для связи документов. Если группу переименуют из «Проверка лендинга» в «Аудит страницы», служебный ID AUDIT-INTENT должен сохраниться. Иначе будущий отчёт может принять прежнюю и новую группу за разные объекты и потерять историю изменения.
В структуре также запишем версию предложения и материала. Например, COPY-A-01 относится к базовому тексту, а LANDING-A-01 — к согласованному первому экрану. Эти названия не являются идентификаторами настоящей платформы. При будущем переносе потребуется отдельное сопоставление editorial_id и platform_id; неизвестный platform_id остаётся пустым.
| Объект | Учебный ID | Ответственность |
|---|---|---|
| Проект | LINE-AUDIT | Общий предмет и ограничения |
| Предложение | AUDIT-ONE | Объём услуги и результат |
| Кампания | SEARCH-AUDIT | Поисковая задача и будущий бюджет |
| Группа | AUDIT-INTENT | Прямой интерес к аудиту |
| Материал | COPY-A-01 | Согласованная формулировка |
Разбираем наследование ограничений
Представим, что на уровне всего проекта записано «внедрение не включено». Это ограничение должно сохраняться в каждом сообщении и посадочной странице. Если одна группа начинает обещать готовые исправления, она не становится новой услугой автоматически. Сначала нужно согласовать другой предмет предложения, затем создать соответствующий маршрут.
С рекламными исключениями ситуация сложнее: конкретные системы поддерживают разные уровни и правила. Поэтому наш документ хранит semantic_scope, например «исключение запросов разработки магазина для кампании аудита». Он не имитирует готовую строку импорта. В следующих уроках отдельно рассмотрим платформенные различия, прежде чем переводить смысл в операторы.
Google в руководстве по созданию поисковой кампании описывает кампании и группы объявлений как объекты выбранного формата. Мы используем эту справку для будущего сопоставления, но не воспроизводим текущие кнопки интерфейса. Сохранённая нейтральная структура не означает, что система поддержит любое наше редакционное поле.
Отделяем структуру от доступа
В настоящем проекте участники имеют разные полномочия. Автор текста может подготовить COPY-A-01, но это не означает право расходовать бюджет или менять платёжные условия. В учебных исходниках нет пользователей кабинета и секретных ключей. Мы сохраняем только смысловые ответственности, чтобы будущая организация доступа исходила из реальных задач. Любой platform_id здесь неизвестен, а не придуман для полноты таблицы.
При передаче комплекта другой команде также нужно объяснить, какие поля являются редакционными. Название группы AUDIT-INTENT не подтверждает, что такой объект уже создан в системе. Статус draft означает подготовку, а execution:not_run — отсутствие исполнения. Если убрать эти признаки, получатель может принять план за выгрузку работающей кампании. Устойчивая структура нужна не только для поиска файлов, но и для честного описания стадии проекта.
Проверяем изменения без потери смысла
Пусть редактор хочет добавить группу «Аудит интернет-магазина». Нужно сначала выяснить, рекламируется одна посадочная страница магазина или весь каталог. Первый случай может соответствовать AUDIT-ONE, второй расширяет услугу. Новое название без уточнения предмета создаёт скрытую проблему, которую потом ошибочно называют плохой настройкой рекламы.
Другой пример — отдельная группа для английского объявления. Язык текста не определяет допустимость рынка и способ исполнения. Если фактические условия не согласованы, такой объект остаётся кандидатом. Мы не создаём фиктивную международную кампанию на основании перевода. В структуре должны быть явно видны неизвестные страна, валюта и доступность платформы.
Наконец, проверим архив материалов. В нём должны сохраняться версии и связи, а не только последние изображения. Старый COPY-A-01 нужен для понимания будущего сравнения. Удаление всех прежних файлов делает отчёт необъяснимым: числа останутся, а сообщения, которые видел человек, восстановить не получится.
Ожидаемый результат — project-structure.json с устойчивыми ID, одним предложением и двумя смысловыми группами. Аккаунт не создан, реальные настройки неизвестны. Следующий урок наполнит поисковую кампанию моделью запросов и покажет, чем пользовательская фраза отличается от условия рекламного показа.