AdTech
Ad-сервер для паблишеров и маркетплейсов: использовать Google Ad Manager, лицензировать готовый или построить свой
Используйте Google Ad Manager, если вы продаёте баннерное или видеоместо на своих сайтах и в приложениях. Выбирайте хостинговый ad-сервер, если нужен API или более простой инструмент, и стройте своё, только если реклама — часть вашего продукта, а хостинговые API не могут применить ваши правила.
Автор: amBrain12 мин чтения
В этой статье
Ad-сервер — это программа, которая решает, какая реклама займёт место на вашем сайте или в приложении, и затем считает результат. Можно использовать Google Ad Manager, платить за хостинговый ad-сервер вроде AdButler или Kevel, запустить открытый, например Revive Adserver, или построить свой. Выбор в основном зависит от того, чьи правила выбирают рекламу и у кого находятся исходные записи о том, что было показано. Кроме того, с 17 февраля 2027 года Google меняет способ подсчёта баннерной рекламы в Ad Manager, поэтому паблишерам, которые им пользуются, стоит заранее проверить договоры, где оплата идёт за показы.
Коротко: используйте Google Ad Manager, если вы продаёте баннерное или видеоместо на своих сайтах и в приложениях и хотите, чтобы рекламный спрос Google конкурировал с вашими прямыми сделками. Хостинговый ad-сервер подходит, когда нужен API или более простой продукт, а самостоятельно размещаемое открытое ПО — только если кто-то у вас будет ставить исправления и поддерживать его. Стройте своё, когда реклама — часть вашего продукта, например спонсируемые размещения в поиске маркетплейса, а проверенные вами хостинговые API не могут применить ваши правила. При любом варианте до первой кампании письменно договоритесь, чей подсчёт определяет счёт.
Что делает ad-сервер?
Каждый раз, когда на странице или в приложении есть рекламное место, она спрашивает ad-сервер, что показать. Ad-сервер отбрасывает объявления, которые не подходят по таргетингу или достигли ограничения частоты, и выбирает одно из оставшихся по приоритету и цене. Затем он записывает показ — одно объявление, засчитанное как доставленное один раз. Эта запись становится отчётом, который паблишер отправляет рекламодателям, и часто основанием для счёта.
Google Ad Manager присваивает каждому типу line item (одному бронированию внутри ad-сервера) номер приоритета, и в его справке сказано: «Чем меньше число, тем выше приоритет.» Sponsorship line item, который продаётся как доля трафика, имеет приоритет 4. Standard, продаваемые как заданное число показов, получают 6, 8 или 10, а House, в которых идут ваши собственные акции, — 16. Все источники в этой статье открыты 9 ноября 2026 года.
Чем ad-сервер отличается от SSP и DSP?
Demand-side платформа (DSP) покупает рекламное место для рекламодателей, а supply-side платформа (SSP) предлагает место паблишера сразу многим покупателям. Ad-сервер стоит ближе всего к паблишеру и в большинстве схем решает последним, чем занять конкретное место, в том числе когда речь о сделках, которые ваши менеджеры заключили с рекламодателями напрямую.
При header bidding страница запрашивает ставки у нескольких SSP и только потом обращается к ad-серверу. Prebid.org, который публикует бесплатное программное обеспечение для header bidding, говорит, что оно «чаще всего используется как библиотека для header bidding», и так описывает эту схему: «Prebid собирает ставки до обращения к ad-серверу, а окончательное решение принимает ad-сервер.» Там же добавлено, что Prebid может работать и как слой принятия решений на странице и сам выбирать победившее объявление. Ad Manager позволяет покупателям из собственных аукционов Google конкурировать с вашими другими бронированиями по CPM, то есть цене за тысячу показов. В его справке сказано, что Ad Exchange или AdSense «покажут рекламу, только если смогут предложить более высокий CPM, чем ваши другие line items в Ad Manager».
Рекламодатели часто запускают собственный второй ad-сервер, чтобы отслеживать, где показывалась их реклама, поэтому одна кампания обычно даёт два набора цифр. Пример — Campaign Manager 360 от Google, который в справке назван «веб-система управления рекламой для рекламодателей и агентств.»
Что делают таргетинг, ограничения частоты и pacing?
- Таргетинг определяет, кто может увидеть объявление. Правила обычно используют страну, устройство и раздел сайта, а также списки аудиторий, которые у вас есть. Маркетплейс может таргетировать по поисковому запросу или категории товара.
- Ограничения частоты (frequency caps) задают, как часто один человек видит объявление. В справке Ad Manager сказано: «Если ограничение по времени задано, а доступного идентификатора нет, line item не может показываться.» Там же сказано, что он «по умолчанию применяет ограничения частоты по отданному коду», то есть в момент, когда рекламный код отправлен, независимо от того, появилось ли объявление.
- В ЕС ограничения частоты зависят и от согласия. В документации Kevel сказано: «В соответствии с GDPR ограничение частоты не включается для зрителей рекламы из Европейского союза, если в запросе не передано согласие на отслеживание.»
- Pacing распределяет бронирование по его датам. Ad Manager «определяет темп доставки line item так, чтобы он достиг своей цели». Его настройка Evenly применяет параметр 5%, поэтому цель в 1 000 показов в день означает 1 050 в первый день.
- Когда ограничение или цель по pacing ведёт себя странно, чтобы понять причину, нужны исходные события, поэтому спросите, что записывается по каждому показу и как долго хранится.
Какие есть четыре способа получить ad-сервер?
- Google Ad Manager. Программу запускает Google, а рекламные места и бронирования вы настраиваете в его интерфейсе.
- Хостинговый ad-сервер. Поставщик, например AdButler, Kevel, Broadstreet или Equativ, запускает программу сам и берёт ежемесячную плату: за рекламные запросы или по договору.
- Открытый ad-сервер. Вы устанавливаете программу вроде Revive Adserver на собственные серверы и сами поддерживаете её работу.
- Собственный ad-сервер. Ваши разработчики или нанятая вами фирма пишут систему, которая принимает решение и считает результат.
Бесплатен ли Google Ad Manager и чем мы жертвуем, используя его?
Бесплатная версия Ad Manager не стоит ничего до месячного лимита, который зависит от страны паблишера, и объединяет прямые сделки и рекламный спрос самого Google в одно решение. На странице биллинга Google указано 90 миллионов показов без видео для паблишеров из США, Канады, Австралии и Новой Зеландии. Для длинного списка стран, куда входят Великобритания, Германия и Индия, лимит составляет 200 миллионов, для остальных — 150 миллионов. У видеоблоков «лимит составляет 800 000 показов в месяц независимо от местоположения.» Вне приложений и видео, если вы используете Google Publisher Tag, «Ad Manager выставляет счёт и за заполненные, и за незаполненные показы», а Google говорит, что если дать Ad Exchange или AdSense участвовать в конкуренции, это может «обеспечить, чтобы показы, монетизированные через Ad Exchange или AdSense, не тарифицировались.»
Сверх этих объёмов Google требует от паблишеров «заключить платный договор». Паблишера, который продолжает превышать лимиты и не добавляет способ оплаты, могут перевести в режим только для чтения, сказано на странице о биллинге. Позже его могут приостановить, «после чего показ вашей рекламы может прекратиться.» Google сообщает, что в разделе Billing аккаунта Ad Manager видны тарифы для вашего региона, поэтому прочитайте их до того, как превысите лимит.
Вы также теряете часть контроля:
- Исходные записи стоят дополнительно и удаляются. Файлы Data Transfer в Ad Manager «содержат неагрегированные данные уровня событий по вашим рекламным кампаниям». Они «предоставляются за дополнительную плату», а «Файлы Data Transfer старше 60 дней удаляются из Ad Manager.» Копируйте их в собственное хранилище по расписанию.
- Google задаёт правила выбора и подсчёта объявлений. Тип и приоритет — «лишь один из факторов выбора рекламы», а остальное решает система Google. Метод подсчёта изменится в феврале 2027 года.
- Уходить с Ad Manager трудоёмко. Ваши бронирования и рекламные места находятся в нём, и их придётся настраивать заново в другом месте, а рекламный код на ваших страницах нужно заменить.
Что меняют антимонопольные дела Google для паблишеров?
Паблишеру, выбирающему ad-сервер, практически важно, получают ли конкурирующие ad-серверы ставки от AdX, рекламной биржи Google, и когда. В пресс-релизе Европейской комиссии от 5 сентября 2025 года объявлен штраф для Google в €2,95 млрд, в котором названо «Предпочтение собственной рекламной бирже AdX в процессе выбора рекламы, который проводит её доминирующий рекламный сервер для паблишеров DFP». Google заявил 14 ноября 2025 года, что не согласен с решением и «подаст апелляцию.» AdExchanger описывает DFP и AdX как объединённые в Google Ad Manager. Министерство юстиции США сообщило 17 апреля 2025 года, что федеральный суд признал, что Google «нарушил антимонопольное законодательство, монополизировав рынки цифровой рекламы в открытом вебе».
PPC Land сообщает, что 2 сентября 2026 года судья в США постановил, что Google «не обязан продавать свою биржу AdX или свой рекламный сервер для паблишеров DFP». AdExchanger сообщил 16 сентября 2026 года, что «AdX также должна передавать ставки в реальном времени конкурирующим рекламным серверам паблишеров на тех же условиях, что и DFP». 2 октября 2026 года стороны подали проект окончательного решения, в котором разногласия оставлены отмеченными. AdExchanger сообщил 5 октября 2026 года, что Министерство юстиции хочет подключить конкурирующие ad-серверы в течение шести месяцев после вступления постановления в силу, а Google — двенадцати, и что после подписи судьи «начнёт отсчёт 60-дневный срок, прежде чем что-либо вступит в силу». В публичной копии судебного реестра, обновлённой 29 октября 2026 года, более поздних документов нет. Digiday сообщает, что Google намерен оспорить решение о признании вины.
Когда лучше подходит хостинговый ad-сервер?
Хостинговый ad-сервер подходит лучше, когда продукт Google избыточен для небольшого отдела продаж или когда разработчики хотят размещать рекламу через API. Для небольших компаний на главной странице Broadstreet написано «Ad Manager для небольших паблишеров», а на странице цен указана стартовая цена $299 в месяц. Попросите показать отчёт, который вы на самом деле отправили бы рекламодателю.
Сравнивайте цены с учётом дополнений. На странице цен AdButler тарифы различаются по числу рекламных запросов, а ряд функций продаётся отдельно. Таргетинг указан как дополнение от $275 в месяц плюс $0,005 CPM, а Log Level Data, «детальные данные о каждом отдельном рекламном запросе», — от $1,100 в месяц плюс $0,01 CPM.
Kevel работает иначе. Её продают как API, то есть способ, которым ваша программа обращается к программе другой компании, поэтому ваши разработчики вызывают её со страниц и из приложений. На главной странице сказано: «Kevel построена на API, поэтому всё полностью гибко и подстраивается под ваш пользовательский опыт.» На той же странице перечислена Kevel Console, которая, по её словам, «позволяет рекламодателям легко планировать, покупать и вести собственные кампании», поэтому уточните, какие экраны входят в продукт, а какие придётся делать вашей команде.
Kevel называет себя «платформа для коммерческих медиа» и содержит разделы для ритейлеров, маркетплейсов, финтех-компаний, туристических брендов и приложений доставки, поэтому новостному или контентному паблишеру стоит спросить, подходит ли она ему. Цен на этой странице нет, поэтому ожидайте разговора с отделом продаж.
Поставщик может также запускать SSP рядом с ad-сервером. На странице Equativ для паблишеров они указаны вместе в продукте для connected TV. Спросите, как их разделяют, и проверьте ответ по собственным данным.
Когда имеет смысл открытый ad-сервер?
Открытый ad-сервер имеет смысл, когда у вас уже есть сотрудники, которые смогут его обслуживать. На главной странице Revive Adserver написано «Скачивать и использовать бесплатно.» В его репозитории на GitHub указана лицензия «лицензия GPL-2.0».
На странице безопасности Revive указаны три бюллетеня за 2026 год, последний от 25 июня 2026 года. Кто-то должен ставить каждое обновление и поддерживать серверы в работе в пики трафика. Если на вашей стороне этим никто заниматься не будет, на сайте Revive есть Hosted-версия «со стоимостью от $10 в месяц». Хостинговые поставщики, перечисленные выше, — другой вариант.
Стоит ли строить собственный ad-сервер?
Да, если рекламное решение — часть вашего продукта, как в маркетплейсе, который показывает спонсируемые размещения в результатах поиска. Там объявление и органический результат ранжируются вместе, поэтому решение должно опираться на ваши собственные данные о релевантности. Оправдать собственную разработку может и любой из таких признаков:
- Ваше рекламное место необычно, например экраны на ваших собственных площадках или слоты внутри процесса бронирования, и проверенные вами продукты не умеют считать его так, как нужно вашим рекламодателям
- Договоры или правила работы с данными требуют хранить информацию о каждом решении внутри ваших собственных систем
- Для рекламы внутри вашего собственного продукта комиссии при ожидаемом через два года объёме обошлись бы дороже, чем команда, которая поддерживает собственную систему, включая дежурства и проверяемые отчёты
У спонсируемых размещений есть и промежуточный путь. В документации Kevel описана схема, которую она называет Auction-as-a-Service, «когда вы определяете, какие товары или размещения могут быть показаны, а Kevel проводит аукцион, управляет темпом показа (pacing), бюджетированием, ограничением частоты и отслеживанием по этому набору.» Статья о ритейл-медиа сетях рассматривает такую схему.
Дальше по теме
Не стоит строить систему, чтобы сэкономить на лицензии для обычной медийной и видеорекламы на сайте. Вам пришлось бы переписывать процесс прямых продаж, распределение показов (pacing), прогнозирование и отчёты, которые оспаривают рекламодатели, и всё равно нужен был бы выход на рекламные биржи. Спор о подсчёте тоже плохая причина, потому что новая система добавляет ещё одно число для сверки. К тому же изменения в браузерах и правилах приватности продолжают появляться и после запуска, и с каждым должен разбираться кто-то из вашей команды.
Почему число показов различается между ad-серверами?
Две компании считают одну и ту же кампанию разными системами и в разные моменты. Ориентиром служат Desktop Display Impression Measurement Guidelines от Interactive Advertising Bureau (IAB) и Media Rating Council (MRC), версия 7.1 от октября 2017 года. В них сказано: «Объявление должно быть загружено и как минимум начать отображаться, чтобы его можно было засчитать как действительный показ.» Подсчёт в момент выдачи страницы «недопустим для подсчёта показов рекламы».
Эти руководства оставляют открытым вопрос, мог ли кто-нибудь увидеть объявление, и в них сказано, что begin-to-render «не требует, чтобы какая-либо часть объявления была видна или отображалась на экране.»
Viewability — это отдельная мера. По Viewable Ad Impression Measurement Guidelines от MRC для десктопа, версия 2.0 от августа 2015 года, медийное объявление считается видимым, когда не менее 50% его пикселей находятся в поле зрения одну непрерывную секунду, или 30% для медийных объявлений от 242 500 пикселей. Видеообъявлению нужно 50% в поле зрения две непрерывные секунды. У MRC есть отдельные руководства для мобильных устройств. Договоритесь, какую из двух мер продаёт ваш договор.
В справке Google по расхождениям в отчётах перечислены типичные причины, и они действуют при любом выборе:
- Правила подсчёта различаются. «У ad-серверов разные методы подсчёта показов и фильтрации недействительных показов.» Недействительные показы появляются из-за ботов и другого трафика, за который не стоит выставлять счёт.
- Креативу, то есть самому файлу объявления, нужно время, чтобы появиться. «Задержка между первым запросом line item и появлением креатива может привести к разным подсчётам.»
- Блокировщики рекламы могут остановить объявление «уже после того, как Ad Manager засчитал показ.»
- Отчёты должны охватывать одни и те же даты и один и тот же часовой пояс, прежде чем вы их сравниваете.
- В небольшой кампании несколько показов могут выглядеть как большой разрыв. «Небольшое числовое расхождение может дать большое процентное расхождение, если line item доставил мало показов в сумме.»
На той же странице сказано, что когда ad-сервер доставляет line items, размещённые третьей стороной, «расхождения по кампании до 20% — обычное дело». Для типа креатива с тегом Campaign Manager 360 там сказано: «Ad Manager согласует подсчёт показов, чтобы снизить расхождения до 2%.» Справка самого Campaign Manager 360 называет тот же диапазон: «Расхождения до 20 процентов считаются нормальными.»
Что изменится, когда Google перейдёт на begin-to-render в феврале 2027 года?
С 17 февраля 2027 года измерение показов медийного инвентаря в Ad Manager и AdSense, по данным справки Google, «перейдёт с методологии count-on-download (COD) на begin-to-render (BTR)». Count-on-download засчитывает показ, когда объявление начинает загружаться. Begin-to-render ждёт, пока креатив загрузится и начнёт отображаться. Нативный инвентарь, приложения и видео уже соответствуют этому, поэтому изменение затрагивает баннеры в вебе, мобильном вебе и connected TV.
Google предупреждает: «вы можете заметить снижение общего числа медийных показов». Тот же трафик тогда даст меньше показов для продажи. Бронированию на заданное число показов потребуется больше вашего трафика, чтобы выполнить цель, и там, где места мало, оно может не добрать. Перед продлением любого договора с оплатой за показы запустите отчёт, который предлагает Google: он сравнивает показы вашего ad-сервера с показами по begin-to-render, начиная с 12 августа 2026 года.
Изменение должно сократить расхождения с покупателями, так как Google говорит, что оно «призвано сократить расхождения с показами, которые считают ваши рекламодатели-партнёры и сторонние поставщики измерений». Если вы используете другой ad-сервер, спросите у его поставщика, по какому методу он считает сегодня.
Чей подсчёт определяет счёт?
Решает договор. IAB опубликовал новые условия для прямых рекламных закупок в мае 2026 года, и в его Direct Buy Addendum версии 1.0 сказано, что стороны «обязаны указать в заказе определяющее измерение». Если в заказе она не названа, «ad-сервер или система измерения, которые показывают рекламу, служат определяющим измерением для целей сверки и выставления счетов», если стороны письменно не договорились об ином.
Более старые Standard Terms and Conditions от 4A's и IAB, версия 3.0 от 2010 года, до сих пор размещены онлайн и охватывают медиазакупки сроком до года. Раздел XIII этого шаблона отдаёт «определяющее измерение» ad-серверу, сертифицированному как соответствующий отраслевым руководствам по измерению. Если соответствуют оба, главным считается сторонний ad-сервер рекламодателя, при условии что он даёт паблишеру «автоматизированный ежедневный интерфейс отчётности». Если не соответствует ни один или это условие выполнить нельзя, главным считается ad-сервер паблишера, если стороны письменно не договорились об ином.
Оба шаблона запускают сверку, если подсчёты расходятся больше чем на 10% за период счёта и определяющим считается меньший из них. Дальше они различаются. По версии 3.0, если сверка не удалась, агентство может рассматривать разницу как недопоставку или заплатить по определяющему подсчёту «плюс повышающая корректировка поставки на 10%.» В дополнении 2026 года фиксированной цифры нет: стороны могут договориться о корректировке, взять другой подсчёт или считать разницу недопоставкой. В вашем договоре может быть написано иначе, поэтому указывайте определяющий подсчёт в каждом заказе и проверьте, что выбранный ad-сервер умеет формировать нужные отчёты.
О чём нам спросить поставщика или фирму, которая будет это строить?
- В какой момент ваша система засчитывает показ, и соответствует ли это рекомендациям IAB и MRC для каждого формата, который мы продаём?
- Проверял ли ваш подсчёт независимый орган, и можем ли мы увидеть актуальный отчёт?
- Можем ли мы выгрузить записи на уровне событий, за какую плату и как долго вы их храните?
- Что делает ограничение частоты, если у человека нет идентификатора или он не дал согласия?
- Как вы фильтруете недействительный трафик и как мы увидим, что было удалено?
- Если вы также запускаете SSP или продаёте рекламный спрос, как вы не даёте этому бизнесу влиять на то, какое объявление побеждает?
- Можете ли вы показать, как это работает на действующем сайте или в приложении уже сейчас?
Где здесь место amBrain?
amBrain публикует этот блог и предлагает такие работы. Его собственными словами: «amBrain строит ad-серверы: таргетинг, ограничение частоты показов и отчётность». Вторая строка касается учёта: «amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним».
amBrain делает софт с 2019 года. О том, как компания работает с клиентами, она говорит: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». До подписания попросите поимённый список этих компонентов.
Эта статья не является кейсом и не описывает работу для клиента. Строки выше не называют клиента, и ничто здесь не говорит о том, что amBrain построил ad-сервер для какой-либо компании. В статье нет цен и сроков amBrain, и она не заявляет о связи ни с одним из цитируемых поставщиков. Google, Prebid.org, Equativ, Broadstreet, AdButler, Kevel, Revive Adserver, IAB, MRC, 4A's, Европейская комиссия и Министерство юстиции США цитируются по их собственным страницам, судебный документ — по публичной копии реестра, а PPC Land, AdExchanger и Digiday — как новостные публикации.
Это тоже не юридическая консультация. Дайте юристу прочитать договоры с поставщиками и рекламные условия и проверьте, на какой стадии находятся дела Google, прежде чем подписывать. Если amBrain в вашем коротком списке, задайте ему те же вопросы, что и любой другой компании.
Темы
- Ad-сервер
- Google Ad Manager
- Подсчёт показов
- Строить или покупать