Часть II · Глава 5

Как устроена рекламная кампания

Статус: reviewed · Пререквизиты: Что такое AdTech и зачем он существует, Участники рекламной экосистемы, Основные рекламные метрики, Экономика и бизнес-модели AdTech

Как устроена рекламная кампания

Суть

Рекламная кампания1 — не один banner и не строка в отчёте. Это control-plane-конфигурация, которая переводит business intent advertiser2 в правила delivery: что система должна улучшать, какие рекламные возможности допустимы, где может появиться реклама, сколько и когда можно потратить, какой content показать, куда привести user и какие signals использовать для измерения.

У большинства platforms есть похожее дерево объектов:

advertiser account
└── campaign
    └── ad group / ad set
        └── ad
            ├── creative
            └── destination

Но это не единая отраслевая schema. Vendors и campaign types по-разному размещают budget3, targeting4, optimization и schedule5. Переносимая mental model строится не вокруг названий экранов, а вокруг двух вопросов: какой объект владеет настройкой и какие дочерние объекты получают её действие.

Зачем кампании нужна иерархия: account как корень управления

Один advertiser одновременно запускает разные продукты, страны, billing scopes и команды. Плоский список ads6 не позволил бы безопасно определить, кто имеет доступ, в какой валюте учитывать spend7, какой time zone управляет расписанием и какие data sources доступны объектам. Поэтому platform начинает с advertiser account8, или ad account, — tenant, внутри которого существуют campaigns и связанные с ними настройки.

Account обычно образует несколько границ сразу:

  • Ownership и access. Он определяет владельца ресурсов, роли и permissions операторов.
  • Billing identity. С ним связаны payer9, billing profile или иная договорная сущность. Точный состав полей зависит от product.
  • Currency и time zone. Эти значения влияют на reporting, budget periods и schedule; в некоторых products после создания их трудно или невозможно изменить.
  • Namespace. Campaign и ad resource IDs уникальны как минимум в контексте platform/account. Identifiers событий (click ID, event ID) принадлежат другим namespaces и этому правилу не подчиняются — см. главы 21–23.
  • Shared configuration. Data sources, conversion actions10, brand assets, URL settings и defaults могут быть доступны нескольким campaigns.

Юридическое лицо advertiser и ad account — не одно и то же. У одной компании могут быть отдельные accounts для регионов, brands, currencies или разных payers. И наоборот, один account может обслуживать несколько инициатив одного юридического лица.

Manager account11 — административный слой, который даёт agency12 или внутренней группе централизованный доступ к нескольким ad accounts. Доступ к отдельному account может быть выдан и без него; в любом случае это administrative access, а не delivery-уровень внутри campaign.

Subscription App Ltd.
├── internal growth team
├── agency manager access ─────────────┐
│                                     │
├── ad account EU (EUR, Europe/Berlin)│
│   ├── campaign: Spring subscriptions│
│   └── campaign: Returning users     │
└── ad account US (USD, America/NY) ◀─┘
    └── campaign: Summer acquisition
Объект Что он представляет Чего из него нельзя заключить
Legal advertiser Компанию или другую юридическую сторону Что у неё ровно один ad account
Ad account Границу product, access и billing Что только одна команда или agency может им управлять
Manager account Делегированный доступ к нескольким accounts Что он участвует в delivery hierarchy каждой campaign

Account-level setting часто наследуется вниз, пока более конкретный объект не задаст override. Но inheritance — product-specific contract: одинаковое имя поля не гарантирует одинаковый порядок приоритетов. При чтении configuration нужно фиксировать не только значение, но и его источник: account default, campaign value или ad-level override.

Для сквозного примера возьмём EU account subscription app. Agency получила access, но владелец и billing identity остаются у advertiser. Account использует EUR и time zone Europe/Berlin; именно эта зона будет исходной для campaign schedule. Цель бизнеса — получить новые оплаченные подписки, однако сама campaign ещё должна превратить эту цель в исполняемые настройки.

Дерево исполнения: campaign, ad group/ad set, ad и creative

Campaign — верхнеуровневый delivery container для одного business intent или согласованного flight — периода размещения с датами начала и конца. Она объединяет настройки, которые должны действовать на несколько дочерних групп и ads: objective13, общие ограничения, channel/type и другие product-specific controls. Campaign — не просто папка для отчёта: её pause, schedule или ограничение может остановить либо изменить delivery всех потомков.

Ad group14 или ad set — промежуточная граница scope для группы ads. Обе сущности отвечают на вопрос «какие ads разделяют правила исполнения?», но не имеют универсально одинаковой schema:

  • в Google-like модели ad group обычно объединяет близкие ads и triggering criteria, например related keywords;
  • в Meta-like модели ad set обычно хранит audience, placements15, optimization, bid16, budget и schedule.

Поэтому фразы «targeting всегда находится в ad group» или «budget всегда задаётся на campaign» неверны без названия platform и campaign type.

В DSP17 и ad server18 те же уровни часто называются insertion order и line item (главы 11 и 16): функции совпадают, названия — нет.

Ad — исполняемая delivery-единица. Она связывает родительскую группу, advertiser identity, creative19, destination20, tracking и status. Creative отвечает за сообщение и assets — text, image, video, audio, CTA (call to action — призыв к действию) и metadata. Creative может быть inline-частью ad или отдельным reusable object. Даже если UI показывает их одной карточкой, логически это разные обязанности:

creative: что увидит user
ad:       где и по каким правилам родителя этот creative исполняется,
          куда ведёт и в каком состоянии находится
Уровень Переносимая функция Google-like пример Meta-like пример
Campaign Общий intent и delivery scope Campaign settings, channel/type и budget link Objective и, при выбранной модели, campaign-level budget
Middle layer Группа ads с общими правилами исполнения Ad group: related ads и keywords/criteria Ad set: audience, placements, optimization, bid, budget/schedule
Ad Delivery unit Ad внутри ad group Ad с родительским adset_id и creative reference
Creative Content и assets Assets/ad content Отдельный creative_id может переиспользоваться

Ниже — учебное дерево, а не payload реального API:

{
  "account_id": "acct_eu_1",
  "campaign": {
    "id": "cmp_subscriptions_42",
    "objective": "APP_PROMOTION",
    "groups": [
      {
        "id": "grp_us_1",
        "label": "US",
        "ads": [
          { "id": "ad_7", "creative_id": "cr_video_a", "status": "active" },
          { "id": "ad_8", "creative_id": "cr_video_b", "status": "active" }
        ]
      },
      {
        "id": "grp_de_1",
        "label": "DE",
        "ads": [
          { "id": "ad_9", "creative_id": "cr_video_a", "status": "active" }
        ]
      }
    ]
  }
}

Метки US и DE здесь — произвольные названия execution scopes внутри одного account: метка сама по себе не задаёт targeting и не означает, что регион обязан совпадать с границей account. Правила построения audiences относятся к следующей главе. cr_video_a используется двумя ads: content общий, но у ads разные родительские объекты, IDs, status и могут вести на разные destinations.

Иерархия также объясняет effective behavior. Если ad_7 настроен как active, но родительская campaign paused, показы не начнутся. Если campaign задаёт общую URL-настройку, ad может унаследовать её или переопределить там, где product это разрешает. Чтение дерева сверху вниз показывает общие constraints; чтение снизу вверх — полный набор настроек, реально действующих на конкретный ad.

От business intent к правилам выбора показа

Дерево сообщает, где живут настройки. Причинная цепочка объясняет, зачем они нужны:

business objective
  → optimization event / performance goal
  → eligible audience и placements
  → bid strategy
  → budget + schedule
  → delivery
  → tracking signals и переход в destination

Для subscription app эта цепочка может выглядеть так:

рост числа paid subscriptions                    # business outcome
  → App promotion или Sales                       # campaign objective
  → install, затем paid subscription              # optimization event
  → geo/device/audience rules и exclusions        # targeting
  → feed, video или in-app inventory              # placements
  → maximize conversions с target/control         # bid strategy

Названия App promotion, Sales и доступные combinations product-specific и меняются со временем. Значение имеет не метка, а переход от желаемого business outcome к наблюдаемому signal и правилам delivery.

Objective и optimization event

Campaign objective — high-level business intent или setup guidance: awareness, traffic, leads, app promotion, sales. Platform может на его основе предложить campaign types, features и defaults. Objective не обязан быть событием, которое optimizer непосредственно предсказывает.

Optimization event21, или performance goal, — наблюдаемый результат, вероятность или value которого delivery system старается увеличить. Это может быть impression22, click23, landing-page view, install, purchase или conversion24 value. Конкретная conversion action задаёт, какое tracking event считается выбранным input для bidding и/или reporting; некоторые products группируют несколько actions в conversion goal и различают primary и secondary events.

Глубокое событие вроде paid subscription ближе к business value, но не автоматически лучше для optimization. Оно может быть редким, задержанным или ненадёжно передаваться из event source. Install возникает раньше и чаще, но является лишь proxy для подписки. Выбор требует достаточного signal volume и корректного measurement25; алгоритмический trade-off рассматривается в главе 7.

Слой configuration Вопрос Subscription-app пример
Business outcome Что должен получить бизнес? Больше новых paid subscriptions
Campaign objective Какой общий intent сообщён platform? App promotion или Sales, в зависимости от product
Optimization event Какой signal влияет на delivery decisions? Сначала install, позже paid_subscription
Tracked events Какие события вообще наблюдаются? Install, trial, purchase, renewal
Bid strategy26 Как policy переводит goal и constraints в bids? Maximize conversions с заданным control
Billing/pricing basis27 За какое qualifying event возникает charge? Например CPM28 или CPC29; basis известна из contract и не обязана совпадать с optimization

Billing basis, как показано в предыдущей главе, задаётся отдельно. Поэтому метка subscription campaign ничего не доказывает о billable event30.

Targeting и placement

Targeting определяет правила eligibility и inputs delivery model: какие opportunities31, users или contexts допустимы либо предпочтительны. На обзорном уровне это могут быть geo, device, context, audience/keyword criteria и exclusions. Источники audience data, identity и privacy рассматриваются в главе 6.

Placement отвечает на другой вопрос: в каком media environment и slot реклама может появиться. Примеры — feed, stories, search results, video pre-roll, in-app banner или rewarded slot. Термин многозначен: на publisher32 side placement — конкретный slot (главы 1 и 10), на buy side у Google-like products — выбранные sites/apps (глава 6), у Meta-like — positions вроде feed/stories; здесь речь о buy-side поле configuration. Placement связан с eligibility creative format, но сами formats, assets и compatibility подробно рассматриваются в главе 8.

Ось Главный вопрос Пример ограничения
Targeting Для каких opportunities/users/contexts возможен показ? Geo DE, mobile devices, keyword category, audience exclusion33
Placement Где именно возможен показ? Feed, search results, in-app rewarded slot

API может хранить placements внутри объекта с названием targeting; это nesting конкретного product, а не доказательство, что audience и placement — одна концепция. Opportunity должна пройти ограничения обеих осей.

Bid strategy

Bid strategy — policy, которая переводит optimization goal и ограничения в auction34 bids. Strategy может стремиться максимизировать conversions, value или другой результат и учитывать target либо cap. Здесь важно разделять четыре сущности:

bid strategy  = правило принятия решений
strategy target/cap = параметр или ограничение policy
actual bid    = решение для конкретной auction opportunity
price/charge  = результат auction и billing contract

Один числовой target CPA35 не является actual bid, а actual bid не определяет billable amount сам по себе. Как вычисляются bids, распределяется budget и работает pacing36, разбирается в главе 7.

Эти три различия — objective ≠ optimization event, placement ≠ audience, strategy ≠ bid amount — позволяют прочитать campaign configuration, не предполагая, что одна метка в UI одновременно описывает business goal, delivery signal и деньги.

Ресурсы и время: budget и schedule

Даже правильно выбранная decision policy действует только внутри resource и time constraints. Budget ограничивает доступный spend на заданной scope и time basis. Он не гарантирует inventory37, conversions, равномерный расход или точный invoice amount.

Распространены две временные семантики:

  • Daily budget задаёт дневную basis. Конкретный product определяет, является ли значение жёстким календарным cap, average daily target или иной формой ограничения.
  • Lifetime, campaign-total или flight budget ограничивает spend за весь период.

Scope также различается. Budget может принадлежать campaign, быть shared между campaigns или задаваться отдельной группе (ad group/ad set). При campaign-level allocation система распределяет общий ресурс между дочерними объектами; при budgets на уровне группы у каждой из них собственный limit.

Настройка Возможная scope Единица измерения Что ограничивает Чего не гарантирует
Daily budget Campaign или группа Currency per day Доступный spend на дневной basis Одинаковый spend каждый час или день во всех products
Lifetime budget Campaign или группа Currency per flight Совокупный spend до end condition Равномерное деление по дням
Shared budget Несколько campaigns Currency на общий pool Общий ресурс группы Фиксированную долю каждому дочернему объекту
Bid target/cap Strategy scope Currency per predicted/result unit Decision policy или bid constraint Total spend и число результатов

В сквозном примере campaign получает учебный lifetime budget €700 на семидневный flight и содержит две группы (в Meta-like setup — два ad sets). Нельзя автоматически записать €100/day: доступные opportunities и allocation могут меняться, а pacing может распределять spend неравномерно. Нельзя также без product configuration заключить, что каждая группа получит €350.

Schedule, или flight, задаёт временную eligibility:

  • start и end;
  • account time zone, в которой интерпретируются даты;
  • при поддержке product — dayparting, то есть допустимые дни недели и часы.
configured status = enabled
start = 2026-09-07 00:00 Europe/Berlin
end   = 2026-09-14 00:00 Europe/Berlin

До start campaign может быть enabled, но иметь effective status pending и не доставлять ads. После end она становится ended/completed, даже если часть €700 не потрачена. Dayparting способен сделать campaign временно ineligible внутри активного flight. Budget, schedule и status работают совместно: разрешение оператора необходимо, но недостаточно для показа.

Куда приходит user и откуда система получает сигналы

Campaign связывает два разных маршрута: user должен попасть в destination, а системы измерения — получить identifiers и events. Эти маршруты могут пересекаться, но не обязаны совпадать.

Landing page, destination или final URL — первая целевая поверхность после interaction: web page, App Store/Google Play listing либо deep link в app. Это часть user experience и product path, а не tracking record.

Tracking settings38 — configuration observability. В неё могут входить:

  • campaign, group и ad IDs;
  • URL parameters, macros, tracking template и final URL suffix;
  • pixel, app SDK, server-to-server integration или MMP39 как event source;
  • выбранные conversion actions;
  • граница конфигурации attribution40, например используемое platform rule/window.

Attribution mechanics, mobile privacy, postbacks и discrepancy analysis здесь не рассматриваются; важно увидеть, где campaign с ними соединяется.

user path:
  ad click → final URL / store listing / deep link

measurement path:
  click ID + campaign/group/ad IDs → platform и/или MMP
  install → trial → paid_subscription events → reporting/optimization

Учебный URL может передать внутренние identifiers:

https://example.com/app?campaign_id=cmp_subscriptions_42&ad_id=ad_7

Имена параметров не являются industry standard. Platform macros могут подставлять фактические IDs в момент click; destination или analytics затем сохраняет их для mapping. Tracking template управляет measurement path, но не является landing page.

Google Ads предоставляет product-specific пример разделения путей: при parallel tracking user направляется к final URL, а click measurement выполняется в фоне. Это implementation Google, а не гарантия для любой platform, browser или MMP link.

Для subscription app ad с creative_id=cr_video_a обещает premium-функции и ведёт нового user в store listing. После install SDK или MMP регистрирует install; backend позднее может передать trial и paid subscription. Чтобы platform использовала subscription для optimization, недостаточно видеть это событие в analytics: нужная conversion action должна быть корректно mapped и выбрана в campaign configuration.

Обещание creative Destination Наблюдаемый event Проверка согласованности
«Попробуйте premium 7 дней» Store listing для новых users Install, затем trial Listing описывает тот же product и offer
«Продолжите настройку подписки» Deep link для installed app Subscription-start screen view Deep link открывает ожидаемый state
«Сравните планы» Web pricing page Landing-page view, purchase URL ведёт на нужную locale/currency version

Landing-page optimization и CRO (conversion rate optimization) — отдельные темы.

MMP также не получает campaign hierarchy магически. Platform, tracking link и MMP должны согласовать mapping IDs и event names. Наличие ad_id без mapping родительских объектов не восстанавливает account/campaign/group relationships автоматически. И наоборот, корректная hierarchy в platform не доказывает, что downstream event source передаёт нужные identifiers.

Lifecycle без ложной линейности

Для первого знакомства lifecycle удобно запомнить как:

draft → learning → active → paused → completed

Но это мнемоника, а не универсальная линейная state machine. Она смешивает состояние configuration, разрешение delivery, schedule и состояние optimizer. Реальный объект лучше описывать вектором состояний.

  • Draft: configuration ещё не опубликована. В некоторых системах draft существует только в UI или client и ещё не является server-side campaign.
  • Learning41: delivery/bidding model собирает данные о результатах после запуска или существенного (material) изменения configuration. Показы и spend в это время уже могут происходить.
  • Active/enabled: оператор разрешил delivery. Фактические показы дополнительно зависят от родительского объекта, review (policy и technical проверка ads на стороне platform), schedule, budget, errors и наличия eligible opportunities.
  • Paused: оператор остановил delivery. Обычно это обратимый переход; resume не создаёт новую campaign.
  • Completed/ended: наступила end condition, чаще всего schedule end. Object, reporting и history обычно сохраняются; это не synonym deleted.
draft → publish → pending/review → eligible delivery
                                  ↘ learning → stable delivery
active/learning ↔ paused
active or paused → end condition → completed/ended
material edit → learning again

Стрелка learning → active вводит в заблуждение: learning может быть под-состоянием active delivery, а не предшествующим запретом показов.

Ось Кто или что её определяет Возможные состояния Пример одного момента
Configured status Operator/API Draft, enabled, paused, removed Campaign enabled
Effective delivery status Platform после всех constraints Pending, eligible, not delivering, ended Ad set eligible
Review/issues Policy и technical checks Pending review, approved, limited, rejected/error Ad approved
Learning status Optimization subsystem Learning, stable, limited data Strategy/ad set learning

В Google-specific представлении campaign может иметь status Eligible, а bidding strategy одновременно — Learning. В Meta-specific представлении active ad set может находиться в learning phase. Метки и точные правила различаются, но переносимый вывод один: одна колонка status не описывает всё operational state.

Изменение campaign и повторный learning

До изменения сквозная группа оптимизируется по installs:

configured: active
schedule:   eligible
review:     approved
optimizer:  stable on install event

Advertiser меняет optimization event на paid_subscription и обновляет creative под subscription offer. Исторические installs и реакции на старый message уже не полностью описывают новую configuration. Platform может вернуть optimizer в learning, продолжая active delivery:

configured: active
schedule:   eligible
review:     approved или pending для нового creative
optimizer:  learning on paid_subscription event

Meta, например, относит изменения targeting, creative, optimization event, состава ads, bid strategy и длительную паузу ad set к возможным significant edits; влияние budget change зависит от правил product и масштаба. Этот список нельзя переносить на Google Ads, DSP или ad network42, а thresholds и duration нельзя считать постоянными. Общая причинная связь лишь такова:

material configuration change
  → прежние данные хуже описывают новые decisions
  → optimizer снова собирает данные

Pause не обязан предшествовать completion: campaign может завершиться по end date прямо из active delivery, а paused campaign — оставаться paused до ручного resume или перейти в ended при наступлении end condition.

Как читать любую campaign

  1. Кто владеет ad account, кто имеет access и какие currency/time zone действуют?
  2. На каком object level находится каждая настройка и кто её наследует?
  3. Какой business objective заявлен и какой optimization event реально выбран?
  4. Какие правила targeting и placements определяют eligibility?
  5. Какая bid strategy выбрана и какие target/cap относятся к ней?
  6. Где заданы budget и schedule, какова их scope и basis?
  7. Какие IDs, URL settings и event sources образуют tracking path?
  8. Куда попадает user после interaction?
  9. Каковы configured, effective, review и learning states прямо сейчас?

С чем это часто путают

  • Account не равен advertiser company. Это граница product, access и billing; manager account даёт доступ, а не добавляет delivery level.
  • Campaign не является только папкой. Настройки и ограничения родителя меняют поведение дочерних объектов.
  • Objective, optimization event, tracked conversion и billing basis не обязаны совпадать. Это разные configuration и contract layers.
  • Enabled не означает delivery прямо сейчас, а learning не означает inactive. Статус родителя, schedule, review, budget, errors и eligibility могут остановить показы; optimizer способен адаптироваться во время active delivery.
  • Pause не означает completed. Pause обратим, хотя у некоторых platforms длительная пауза сама считается significant edit; completion обычно следует end condition.
  • Tracking URL не является landing page. Measurement path и user path решают разные задачи.

Что важно запомнить

  1. Campaign hierarchy — модель scope и inheritance, а не единая межплатформенная schema; у каждой настройки есть источник: account default, campaign value или ad-level override.
  2. Ad account задаёт административную границу; campaign переводит один intent/flight в общие правила delivery; ad group/ad set группирует ads с общими правилами исполнения, а расположение полей зависит от product.
  3. Ad является delivery binding, creative — content; один creative может использоваться несколькими ads.
  4. Objective описывает общий intent, optimization event — наблюдаемый signal для decisions; bid strategy, strategy target, actual bid и billable price — разные объекты.
  5. Targeting ограничивает допустимые opportunities, placement — media environment и slot.
  6. Budget и schedule ограничивают ресурс и время, но не гарантируют равномерный spend или результат.
  7. Destination ведёт user; tracking settings связывают IDs и event sources с measurement/optimization.
  8. Operational lifecycle нужно читать как несколько осей: configured, effective, review и learning status.

Проверьте себя

  1. Campaign имеет objective App promotion, оптимизируется по paid_subscription, отслеживает install, trial и subscription, а billing basis — CPM. Почему эти значения не противоречат друг другу?
  2. Ad настроен как active, но не получает impressions. Какие состояния родителя, schedule, review, budget и eligibility нужно проверить?
  3. Почему изменение optimization event с install на subscription может вернуть optimizer в learning, не меняя configured status active?
  4. Какие settings вы ожидали бы разделить между двумя ads и какие — хранить отдельно, если они используют один creative, но ведут в разные regions и destinations?

Источники и дополнительное чтение

  1. Google Ads Help — Account, campaign, and ad group performance и Google Ads API — Campaigns overview — Google-specific hierarchy и campaign resources; расположение полей зависит от campaign type и API version.
  2. Meta Marketing API — Basic Ad Creation — отдельные campaign, ad set, creative и ad в Meta Graph API; это vendor schema, а не отраслевой standard.
  3. Google Ads Help — About campaign objectives и About conversion goals — distinction между high-level objective, conversion goals/actions и их использованием в bidding.
  4. Meta Business Help Center — About performance goals — product-specific связь objective, performance goal и необходимых signals.
  5. Google Ads Help — About tracking in Google Ads — tracking-template inheritance, final URL settings и parallel tracking как Google-specific implementation.
  6. Google Ads Help — About campaign statuses и Google Ads API — Bidding Strategy Status — separate operational и learning statuses в Google Ads.
  7. Meta Business Help Center — About the learning phase, Significant edits and learning phase и Meta Marketing API — Budgets — Meta-specific learning, significant edits, daily/lifetime budgets и scheduling behavior.

Footnotes

  1. Campaign (рекламная кампания) — организованный набор рекламной активности advertiser с целью, бюджетом, правилами доставки и creatives. До показа её условия сообщаются системам покупки; объекты и события связываются identifiers вроде campaign_id. ↩

  2. Advertiser (рекламодатель) — участник рынка, который финансирует рекламу ради бизнес-результата: установок, покупок подписки, роста узнаваемости. Он покупает не человека, а возможность обратиться к аудитории в определённом контексте; создаёт demand и задаёт цели, бюджет и creative. ↩

  3. Budget (бюджет) — ограничение доступного spend на заданной scope (campaign, ad set, shared pool нескольких campaigns) и time basis. Распространены daily budget (жёсткий календарный cap, average daily target или иная форма — определяет product) и lifetime/flight budget на весь interval. Budget ограничивает расход, но не гарантирует inventory, conversions, равномерный расход или точный invoice amount. ↩

  4. Targeting (таргетинг) — правила кампании о том, кому и где может быть показана реклама: hard controls (eligibility rules — geo, device, context, audience/keyword criteria, exclusions), которые ограничивают множество допустимых opportunities, и signals/hints, которые в algorithmic products лишь направляют delivery, не сужая eligible set. Targeting отвечает на вопрос «для каких opportunities/users/contexts возможен показ», в отличие от placement («где именно») и optimization («какой из допустимых показов выбрать»); даже если API хранит их в одном объекте, это разные оси. ↩

  5. Schedule (flight, расписание кампании) — временная eligibility кампании: start и end, account time zone, в которой интерпретируются даты, и при поддержке product — dayparting (допустимые дни недели и часы). До start кампания может быть enabled, но иметь effective status pending; после end она завершается, даже если часть budget не потрачена. ↩

  6. Ad (объявление) — исполняемая delivery-единица кампании: связывает parent group (ad group или ad set), advertiser identity, creative, destination, tracking и status. Ad — не то же, что creative: один creative может исполняться в нескольких ads с разными parent rules, destinations и состояниями. ↩

  7. Media spend (рекламные расходы) — деньги, которые advertiser выделяет и тратит на покупку рекламы. Проходят через продавцов media и в итоге образуют publisher revenue, уменьшаясь по пути на fees; не синоним publisher revenue и не синоним intermediary fee — это разные суммы одной цепочки. ↩

  8. Ad account (advertiser account, рекламный аккаунт) — tenant на advertising platform, внутри которого существуют campaigns и связанные настройки; образует сразу несколько границ: ownership и access (роли и permissions операторов), billing identity, currency и time zone, namespace идентификаторов и shared configuration (data sources, brand assets, defaults). Юридическая компания advertiser и ad account — не одно и то же: у одной компании может быть несколько accounts под регионы, бренды и валюты, а один account может обслуживать несколько инициатив одной legal entity. ↩

  9. Payee / payer — две стороны одного платёжного обязательства: payer платит за billable event, payee получает оплату. В pricing model распределение риска описывается через них: при CPM payee получает право на charge раньше воронки, а post-impression risk несёт payer; при CPA payee принимает на себя весь риск до конверсии. Одна компания может быть payee в одном договоре и payer в другом. ↩

  10. Conversion action — настроенное на платформе определение события, которое считается conversion для отчётности и optimization: источник (pixel, SDK, S2S, импорт), имя события, правила counting (одна или каждая на interaction), value и окно. Platform может иметь несколько conversion actions на account; какие из них primary (используются для optimization) и какие secondary (только отчётность) — часть конфигурации campaign. ↩

  11. Manager account — административный слой platform, который даёт agency или внутренней группе централизованный delegated доступ к нескольким ad accounts. Это administrative access, а не дополнительный delivery-уровень: manager account не участвует в delivery-иерархии каждой campaign. ↩

  12. Agency — компания-подрядчик, которая планирует и выполняет marketing- и media-работу от имени advertiser: разрабатывает стратегию, готовит creative, выбирает каналы, запускает campaign и ведёт отчётность. Advertiser может держать покупку media in-house, отдать её agency целиком или разделить ответственность. Agency — организация и договорная роль, в отличие от media buyer — операционной функции, которая может работать и внутри advertiser. ↩

  13. Campaign objective (цель кампании) — high-level business intent или setup guidance, сообщённый platform при создании кампании: awareness, traffic, leads, app promotion, sales. Objective предлагает campaign types, features и defaults, но не обязан совпадать с событием, которое optimizer непосредственно предсказывает: optimization event выбирается отдельно. ↩

  14. Ad group / ad set — промежуточный уровень иерархии кампании между campaign и ad, группирующий ads с общими execution rules. Названия и состав полей vendor-specific, универсальной schema нет: в Google-like модели ad group объединяет близкие ads и triggering criteria (например related keywords), в Meta-like модели ad set хранит audience, placements, optimization, bid, budget и schedule. ↩

  15. Placement (рекламное место или selectable media scope) — overloaded product term. На publisher side это заранее заданный ad slot или правило появления рекламы, которое порождает ad opportunities по мере использования продукта. На buy side placement может означать явно выбранную среду показа — site, app, channel, video, section или отдельный slot. Уровень сущности нужно уточнять из product contract. ↩

  16. Bid (ставка) — предложение buyer заплатить определённую цену за конкретную ad opportunity, обычно выраженное как CPM. Bid — это решение до события: он не равен итоговой цене (clearing price) и не равен billable amount; в programmatic bid формируется DSP на каждый bid request отдельно. ↩

  17. DSP (Demand-Side Platform, платформа стороны спроса) — платформа, которая автоматизирует покупку рекламных возможностей для advertiser: агрегирует доступ к нескольким supply-источникам, оценивает каждую opportunity и решает, делать ли ставку и сколько платить. Относится к demand side не потому, что «создаёт demand», а потому, что действует в интересах покупателя. ↩

  18. Ad server (рекламный сервер) — система, которая выбирает, доставляет и регистрирует рекламу по заданным правилам. Бывает publisher-стороны (сопоставляет прямые кампании, сети и programmatic-спрос, управляет delivery) и advertiser-стороны (хранит creative, считает показы и клики); термин обозначает функцию, а не сторону рынка. ↩

  19. Creative (креатив) — рекламный материал, который доставляется и показывается user: баннер, видео, нативный формат, playable. Наряду с правилами targeting является объектом доставки и должен соответствовать формату и правилам среды publisher; в кампании обычно готовят несколько creatives. ↩

  20. Destination (landing page, final URL) — первая целевая поверхность после interaction с рекламой: web page, App Store/Google Play listing или deep link в app. Это часть user path, а не tracking record: tracking template и URL parameters управляют measurement path, но landing page не являются. ↩

  21. Optimization event — наблюдаемое событие, под которое система доставки обучается и оптимизирует показы: install, trial start, paid subscription, purchase. Выбирается advertiser в настройках campaign (у разных platforms — conversion action, conversion goal, performance goal). Не равно campaign objective (бизнес-намерение), не равно billable event (за что платят) и не равно параметру стратегии вроде target CPA. Более глубокое событие даёт меньше сигналов и дольше learning. ↩

  22. Impression (показ) — событие доставки или показа выбранной рекламы, зарегистрированное системой по определённому правилу; единица подсчёта, а не факт восприятия человеком. Served, rendered и viewable — разные состояния доставки, поэтому счётчики разных участников одной сделки могут не совпадать. ↩

  23. Click (клик) — qualifying user-initiated interaction с рекламой, зарегистрированная по правилу конкретной системы. Даже одно действие имеет несколько measurement points: initiated, measured (click tracker), received (destination) и resolved (landing page) clicks не обязаны совпадать из-за обрывов соединения, redirect-цепочек и filters. ↩

  24. Conversion (конверсия) — valuable action или outcome, который advertiser определил как значимый (install, trial, первая оплата, renewal, purchase) и который система засчитала по measurement и attribution rules. Conversions нельзя складывать без явного counting rule: один click может привести к нескольким conversions. Observed conversion — зарегистрированное событие; attributed conversion — событие, которому attribution rule назначил credit; ни то ни другое не доказывает causality. ↩

  25. Measurement (измерение) — функция регистрации и агрегации рекламных событий (impressions, clicks, outcomes) для отчётности и оптимизации. Measurement-провайдеры дают независимую точку наблюдения; у разных участников разные timestamps и правила подсчёта, поэтому отчёты не обязаны совпадать идеально. В mobile выделенная категория — MMP. ↩

  26. Bid strategy (стратегия ставок) — policy, которая переводит optimization goal и ограничения (target или cap) в auction bids. Strategy, её target/cap, actual bid на конкретную opportunity и billable price — четыре разные сущности: один числовой target CPA не является actual bid, а actual bid не определяет billable amount сам по себе. ↩

  27. Pricing basis — договорное правило расчёта цены: объект, за который buyer платит, — impression, click, action, install, lead, доля proceeds, период доступа к software или иной согласованный результат. Название метрики в интерфейсе (CPM, CPC, CPA) не задаёт basis само по себе: одно и то же имя может быть договорной ценой, bid или фактическим средним после событий, поэтому денежное обязательство создаёт только названная в договоре basis. ↩

  28. CPM (Cost per Mille) — стоимость тысячи counted impressions для buyer: CPM = advertiser cost or spend / counted impressions × 1,000. Термин неоднозначен без контракта: может означать pricing basis, rate, bid или observed average CPM post-fact; observed CPM отвечает на вопрос «сколько buyer потратил на тысячу counted impressions». ↩

  29. CPC (Cost per Click) — cost или spend на qualifying clicks по disclosed rule: CPC = cost / qualifying clicks. Bid/target CPC не равен фактическому average CPC: первый — ставка или цель оптимизации, второй — post-fact среднее. ↩

  30. Billable event — qualifying-событие, определённое договором, после которого payee вправе начислить billable amount — сумму по pricing basis после counts, rates, validation и договорных adjustments; она ещё не обязательно выставлена в invoice, признана revenue или оплачена. Событие задаётся contract policy, а не протоколом автоматически: auction win, win notice и billing notice — разные точки, и win не гарантирует delivery или charge. ↩

  31. Ad opportunity (рекламная возможность) — конкретная возможность выбрать и показать рекламу, возникшая, когда user дошёл до placement. Короткоживущее событие: в цифровой среде оно может исчезнуть быстрее, чем человек успеет принять решение, поэтому обрабатывается системами за миллисекунды, а в programmatic выставляется на торги как отдельная единица. ↩

  32. Publisher (издатель) — владелец или управляющий media-средой, где возникают рекламные возможности: сайт, мобильное приложение, видеосервис, игра. Монетизирует среду рекламой, создаёт supply и решает, какие placement, форматы и покупателей допускать, балансируя revenue с пользовательским опытом. ↩

  33. Audience exclusion / suppression — отрицательное targeting rule, предназначенное не допустить entities с named membership или status; фактическая полнота exclusion ограничена identity match, freshness, propagation latency и semantics конкретной platform. ↩

  34. Auction (аукцион) — механизм выбора победителя среди нескольких bids на одну ad opportunity и определения цены (clearing price) по правилам аукциона — first-price, second-price и их варианты. Auction win — событие выбора победителя; оно не равно показу и не делает impression billable само по себе. ↩

  35. CPA (Cost per Action) — cost на advertiser-defined qualifying actions: CPA = cost / qualifying actions. Action определяется контрактом кампании — trial, order, lead или subscription, не обязательно новый customer, поэтому CPA нельзя читать без имени action и сравнивать между кампаниями напрямую. ↩

  36. Pacing (темп расхода) — политика распределения spend во времени внутри budget-ограничений: тратить ли равномерно, ускоряться на дешёвых или качественных opportunities или придерживать бюджет. Pacing распределяет ресурс, но не обещает равномерный расход: доступные opportunities и allocation меняются. ↩

  37. Advertising inventory (рекламный инвентарь) — множество доступных или прогнозируемых возможностей показать рекламу, ограниченное средой, местом, форматом, временем, правилами publisher и допустимым контекстом аудитории. Inventory — не список пользователей и не склад заранее произведённых показов: opportunity возникает и исчезает в момент использования продукта. ↩

  38. Tracking settings (настройки отслеживания) — configuration observability кампании: передаваемые identifiers (campaign/group/ad IDs), URL parameters, macros, tracking template и final URL suffix, event sources (pixel, app SDK, server-to-server integration, MMP), выбранные conversion actions и attribution configuration boundary. Tracking settings управляют measurement path и не заменяют destination; имена URL-параметров не являются industry standard. ↩

  39. MMP (Mobile Measurement Partner, мобильный измерительный партнёр) — специализированная категория measurement-провайдеров для mobile: измеряет установки и in-app события, проводит attribution и предоставляет независимые данные сторонам сделки. Не синоним любой системы measurement. ↩

  40. Attribution (атрибуция) — правила, по которым доступные рекламные touchpoints (impression, click) сопоставляются с outcomes (установка, регистрация, покупка) и получают credit за конверсию. Attribution отвечает на вопрос «какому источнику по выбранным правилам приписано действие», а не «была ли реклама истинной причиной»: credit не доказывает causality. Провайдеры attribution — отдельная поперечная категория; в mobile — MMP. ↩

  41. Learning phase (learning status, фаза обучения) — состояние optimizer, в котором delivery/bidding model собирает evidence после запуска или material configuration change: прежние данные хуже описывают новые решения. Learning — одна из осей operational state наряду с configured, effective и review status, а не противоположность active: показы и spend идут, а vendor-specific significant edits (targeting, creative, optimization event, состав ads, bid strategy) могут вернуть optimizer в learning без изменения configured status. ↩

  42. Ad network (рекламная сеть) — посредник, который агрегирует рекламные возможности (inventory) от многих publisher и продаёт их advertiser как единый упакованный продукт: сеть берёт на себя подбор supply, ценообразование и показ, а покупатель получает одно управляемое предложение вместо десятка отдельных договоров. Цены внутри сети обычно непрозрачны для покупателя. Исторически многие ad network добавили аукционные механики и перестроились в ad exchange, поэтому под одним брендом часто совмещаются обе функции. ↩