Разметка Schema.org под AI: сущности вместо ключей

Разметка Schema.org - код внутри страницы, который сообщает машинам, что за фрагмент перед ними: где название компании, где автор, где дата публикации, где цена. Прироста цитирований в AI-ответах она сама по себе не дает. Ее работа - убрать догадки при разборе: без нее краулер не отличит цену от номера телефона, а страницу компании в LinkedIn сочтет отдельной организацией.

Советы по разметке расходятся до противоположных. Одни источники называют ее обязательной для попадания в AI-ответы, другие приводят замеры, где эффект колеблется около нуля. Обе стороны опираются на цифры, и обе цифры сходятся, если посмотреть, каким сайтам разметка помогает. Она остается одним техническим куском работы над видимостью в AI-выдаче, причем не первым в очереди: сперва краулер должен хотя бы получить HTML страницы.

Что дает разметка и чего от нее ждать не стоит

Страница для человека и страница для машины - разные объекты. Человек видит заголовок, цену и телефон по расположению, размеру шрифта и привычке. Бот получает поток текста, в котором число 4900 может оказаться ценой, номером кабинета или площадью склада в квадратных метрах. JSON-LD снимает этот вопрос: цена лежит в поле `price`, телефон в `telephone`, название компании в `name`. Догадываться движку больше не нужно.

Ближе всего сюда аналогия с технической документацией на автомобиль. По фотографии две похожие модели одного завода не различить, по документации - за секунду. Google и AI-ассистенты не тратят ресурсы на полный разбор верстки, если суть страницы им отдали отдельным структурированным блоком. Страницы с разметкой краулеры обходят заметно быстрее, это наблюдение повторяется на разных проектах.

Словарь Schema.org собирали Google, Microsoft и Yandex вместе, поэтому один и тот же код читают все крупные движки, а следом за ними и генеративные. В мае 2025 Google обновил документацию и прописал требования к структурированным данным для своих AI-функций.

Дальше цифры, которые противоречат друг другу. Подтвержденных данных о том, что установка разметки сама по себе повышает шанс цитирования, нет. Ahrefs замерял эффект на своих страницах: после добавления разметки цитирования в AI Overviews просели на 4,6%, а в ChatGPT и AI Mode изменения оказались неотличимы от нуля. Вывод авторов замера: отдельно под AI-выдачу разметку внедрять смысла мало, но если она уже стоит ради поиска - пусть стоит.

Отраслевой отчет по локальному бизнесу дает картину наоборот. Компании с корректно собранной разметкой LocalBusiness, Service, FAQ, Article и WebSite попадают в цитаты AI Overviews до трех раз чаще, чем конкуренты без нее.

Разброс слишком велик, чтобы списать его на погрешность выборки.

Оба замера сходятся, если посмотреть на исходное состояние сайта. Ahrefs - крупный домен с выстроенной структурой, известным брендом и текстом, который движок разбирает без подсказок. Догадок там и так не было, добавлять нечего. Сервисная компания из Ташкента или Бишкека выглядит иначе: название встречается на сайте в трех вариантах написания, адрес спрятан в картинке, часы работы утоплены в абзаце, а страница услуги подписана как «Наши работы». Разметка закрывает эти пробелы, и разница в цитировании появляется.

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

В очереди технических задач разметка стоит не первой. Сперва контент важных страниц: услуги, товары, ответы на вопросы, с которыми люди приходят. Потом проверка, что боты Google и ChatGPT забирают этот контент без потерь. Разметка - третий шаг. На пустой странице она не работает, потому что описывать нечего.

Рядом стоит вопрос про llms.txt. Оба формата решают задачу машинного чтения, но с разных сторон: llms.txt отдает моделям карту сайта, а разметка описывает конкретную страницу изнутри. Одно другое не заменяет и не отменяет.

Organization: с чего начинают

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

Набор полей идентичности, который держат на всем сайте, невелик: WebSite, Organization, Person, ContactPoint, PostalAddress, Brand. Первые два отвечают на вопрос, что это за сайт и чья это компания. Остальные уточняют людей, адрес и способы связи. Organization с названием, логотипом и ссылками на профили питает панель знаний Google - карточку компании справа от выдачи.

Частая ошибка выглядит так: разметку поставили на главной и успокоились. Бот приходит на страницу услуги из AI-ответа, а не с главной, и получает документ, где о компании не сказано ничего. Правильный вариант - один и тот же блок Organization на каждой странице сайта, а на странице «О нас» дополнительно AboutPage.

Сложная структура компании путает даже модель. Головное юрлицо в Узбекистане, операционный офис в ОАЭ, отдельная сущность в ЕС для европейских клиентов: если связи между ними не описаны, движок читает три разные организации с похожими названиями. Поля `parentOrganization` и `subOrganization` показывают иерархию, а `legalName` отделяет юридическое название от бренда. Разговор с клиентом про то, как устроена группа компаний, дает структуру, которую потом переносят в код почти без правок.

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

Локальному бизнесу нужен тип LocalBusiness с адресом, телефоном, часами работы и зоной обслуживания. Минимум обязательный, но недостаточный: карточка компании в Google Картах весит для локальной выдачи больше, чем поля в коде.

Дальше - пример на реквизитах HITZ Agency, GEO-агентства в Центральной Азии. Код рабочий, копируется и правится под свои данные.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://hitz.agency/#organization",
  "name": "HITZ Agency",
  "url": "https://hitz.agency",
  "description": "GEO-агентство в Центральной Азии: видимость бренда в AI-поиске и классической выдаче",
  "areaServed": [
    {"@type": "Country", "name": "Uzbekistan"},
    {"@type": "Country", "name": "Kazakhstan"},
    {"@type": "Country", "name": "Kyrgyzstan"}
  ],
  "knowsAbout": [
    "Generative Engine Optimization",
    "Search Engine Optimization",
    "Performance marketing"
  ]
}
</script>

Что делает каждое поле. `@id` - постоянный идентификатор компании внутри сайта, на него ссылаются остальные блоки разметки. `name` пишут в той же форме, в какой название стоит в тексте страниц и в профилях: разнобой написания размывает сущность. `url` указывает на домен, который считается основным. `description` пересказывает деятельность теми словами, которыми компанию описывают клиенты. `areaServed` перечисляет страны или города обслуживания, `knowsAbout` связывает компанию с темами, в которых она работает.

К этому набору добавляют `logo` со ссылкой на файл, `foundingDate` с годом основания, `contactPoint` с телефоном и почтой, `address` с юридическим адресом. Свойство `sameAs` идет туда же, но у него отдача другая, и разбирается оно ниже отдельно.

Article и FAQPage: разметка содержимого страниц

Тип разметки выбирают под то, что на странице лежит:

• статья или пост в блоге - Article, для блога чаще BlogPosting
• карточка товара - Product с вложенным Offer, разметка для магазина заслуживает отдельного разбора
• справочный раздел с вопросами - FAQPage
• пошаговая инструкция - HowTo
• страница с видео - VideoObject
• раздел «О нас» - AboutPage поверх Organization
• контакты - ContactPage
• услуга - Service со ссылкой на организацию-исполнителя

Список закрывает сайт средней сложности. Остальное - редкие случаи.

Как раскладка выглядит на большом магазине, видно у Gymshark: на главной Organization и WebSite, на страницах категорий CollectionPage с ItemList, на карточках Product с Offer и отзывами, в блоге Article. Каждая страница описана тем типом, который отвечает ее содержимому, и лишнего сверху не навешано.

Со Schema.org соседствует другой формат структурированных данных - XML-фиды Яндекс.Вебмастера. Их около двенадцати под разные тематики: недвижимость, медицина, врачи, мероприятия. Фид дает расширенный сниппет с характеристиками объекта отдельным блоком выдачи, и зависимость там прямая: у медицинских сайтов отвалившийся фид роняет позиции, а после его включения трафик возвращается за два-три дня.

Article с датой публикации, автором и заголовком дает движку два сигнала: когда материал вышел и кто за ним стоит. Поле `dateModified` забывают чаще остальных, и статья, которую обновляли неделю назад, выглядит для машины трехлетней. Скучное, но рабочее правило: тронули текст - подвиньте дату.

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

FAQPage требует оговорки. Google перестал показывать расширенные результаты по FAQ-разметке, и часть специалистов после этого сняла ее с сайтов. Ставить ее все равно стоит: формат вопрос-ответ модели разбирают охотно, а сами вопросы совпадают по формулировкам с тем, как люди пишут запросы ассистентам. Пока формат нужен хотя бы одному из двух каналов, его делают.

HowTo ставят на пошаговые инструкции. В отраслевых публикациях встречается наблюдение, что Perplexity цитирует страницы с HowTo втрое чаще обычных. Цифра пришла не из замера на собственных проектах, поэтому относиться к ней стоит как к ориентиру, а не как к обещанию.

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

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

sameAs и @id: как склеить разрозненное в одну сущность

Склейку делают в две стороны. Свойство `sameAs` связывает компанию с ее профилями за пределами сайта. Свойство `@id` связывает блоки разметки внутри одной страницы. Первое отвечает за то, чтобы вас не приняли за трех разных субъектов в интернете. Второе - за то, чтобы блоки кода на странице не читались как три независимых описания.

sameAs: собрать себя снаружи

Без `sameAs` сайт компании, ее страница в LinkedIn и профиль в соцсети выглядят для движка тремя отдельными организациями с похожими названиями. Свойство перечисляет адреса профилей и сообщает: это один и тот же субъект.

Профили в этом поле работают как поручители. Модель проверяет утверждение о компании по внешним источникам - примерно как человек, который перед сделкой спрашивает про подрядчика у знакомых. Сайт заявляет одно, LinkedIn показывает другое, в каталоге третье название - доверие к утверждению падает. При неуникальном названии `sameAs` снимает путаницу с однофамильцами и одноименными компаниями. Для агентства с распространенным словом в названии это первая по важности вещь после Organization.

В поле идут не только страницы в соцсетях. Ссылки на Wikidata и DBpedia указывают на сущности, которые движку уже известны: у них есть идентификаторы в графе знаний, и привязка к ним весит больше, чем еще один профиль. Рядом работает `knowsAbout` - поле, которое связывает компанию или автора с темами. Свойства `about`, `mentioned` и `alias` уточняют, что относится к сущности, а что нет. Часть из них Google напрямую не рекомендует, но на разбор они влияют.

Небольшой компании есть смысл собрать в `sameAs` то, что уже подтверждено: страницу в LinkedIn, профиль основателя, карточку в отраслевом каталоге, канал в мессенджере, аккаунт в соцсети с контентом. Профилей два или три - начинают с них, остальное добавляют по мере появления. Пустое поле лучше ссылки на заброшенный аккаунт с логотипом пятилетней давности.

Структура блока при этом не меняется, меняются только адреса.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://vash-sayt.com/#organization",
  "name": "Название компании",
  "url": "https://vash-sayt.com",
  "sameAs": [
    "https://www.linkedin.com/company/nazvanie-kompanii",
    "https://t.me/nazvanie_kompanii",
    "https://2gis.uz/tashkent/firm/00000000000000000",
    "https://www.wikidata.org/wiki/Q12345678"
  ],
  "knowsAbout": [
    "тема, в которой работаете",
    "вторая тема"
  ]
}
</script>

Последняя строка в `sameAs` - пример ссылки на Wikidata. Если у компании или основателя там есть карточка, ставят ее: у такой записи в графе знаний уже есть идентификатор, и привязка к нему стоит дороже, чем ссылка на свежесозданный профиль. Карточки нет - строку убирают, выдумывать номер бессмысленно.

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

@id: собрать себя внутри

На странице лежит несколько блоков разметки сразу: Organization, WebSite, Article, BreadcrumbList. Без явных связей движок читает их как отдельные описания. Организация сама по себе, статья сама по себе, и то, что статью выпустила эта компания, нигде не сказано.

Главной сущности присваивают `@id` - чаще адрес страницы с якорем вида `#organization`. Остальные блоки ссылаются на этот идентификатор через `publisher`, `author` или `about`.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://hitz.agency/#organization",
      "name": "HITZ Agency",
      "url": "https://hitz.agency"
    },
    {
      "@type": "WebSite",
      "@id": "https://hitz.agency/#website",
      "url": "https://hitz.agency",
      "name": "HITZ Agency",
      "publisher": {"@id": "https://hitz.agency/#organization"}
    }
  ]
}
</script>

Строка `publisher` здесь важнее всего остального. Без нее WebSite остается описанием сайта без владельца, а Article - текстом без издателя: два объекта на одной странице, между которыми движок связи не видит. С ней получается граф, где у сайта есть владелец, у статьи издатель и автор, а у автора профили.

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

Сущности против ключевых слов

Сущность в понимании движка - человек, место, компания или предмет с машинным идентификатором. Движок присваивает идентификатор и накапливает вокруг него факты из разных источников. Цель работы с AI-выдачей формулируется через это: стать для модели узнаваемой сущностью с подтвержденными фактами, а не набором страниц с повторяющейся фразой.

Сведения в графе знаний хранятся тройками вида субъект - действие - объект. «HITZ Agency работает в Узбекистане», «HITZ Agency занимается GEO», «Марат Аксанов основал HITZ Agency» - такие утверждения движок складывает в граф и потом использует при сборке ответа. Текст, где нужная фраза встречается пятнадцать раз, но проверяемых утверждений нет, для машины пустой. Ключи он посчитает, а класть в граф ему нечего.

Движок хранит утверждения. Хранить количество вхождений фразы ему незачем.

На письме это выглядит как конкретика в названиях. «Google Keyword Planner показывает частотность запросов» работает лучше, чем «этот инструмент помогает с семантикой»: в первом варианте названы два объекта и связь между ними, во втором нет ни одного. Чем больше в тексте названных сущностей - продуктов, компаний, городов, людей, - тем больше материала для разбора.

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

В графе знаний Google порядка 500 млрд фактов о 5 млрд сущностей. Для текстов отсюда следуют две привычки. Первая: определять термины при первом употреблении, потому что модель не обязана знать вашу внутреннюю лексику. Вторая: держать одну терминологию по всему сайту. Если на одной странице стоит «GEO», на другой «оптимизация под нейросети», на третьей «AI SEO», для человека это синонимы, а для машины - три разные темы, между которыми связь еще надо доказать.

Как выглядит размытая сущность на практике, видно на примере двух B2B-платформ. Demandbase позиционирует себя как платформу с искусственным интеллектом. Модели описывают ее иначе - как ABM-платформу, а на вопрос про решения с AI называют конкурента, 6sense. Причина лежит в контенте: у Demandbase нет ни отдельного оффера под эту тему, ни раздела, где она раскрыта, ни материалов, где компания и тема упоминались бы вместе. Модель описывает компанию по тому, что нашла, а не по тому, как компания себя называет. Разметка такой разрыв не закроет - тут нужны страницы и упоминания.

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

Разметка и текст на странице работают вместе

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

Без блока вопросов на странице разметка FAQPage бессмысленна и читается движком как конфликт. Обратный случай проще: блок вопросов без кода машина разберет сама, если он оформлен по-человечески - вопрос заголовком, ответ первым абзацем под ним, без разгона на три абзаца.

Отсюда порядок работы. Сначала текст, потом его описание в коде. Как писать так, чтобы фрагменты забирали в ответы, - тема отдельная, и по очередности она идет раньше разметки.

Проверка и частые ошибки

Формат по умолчанию - JSON-LD: отдельный блок в коде страницы, не перемешанный с версткой. Микроданные встречаются в старых проектах, новые собирают на JSON-LD.

Проверяют двумя инструментами. Валидатор Schema.org ловит ошибки синтаксиса, несуществующие поля и показывает граф связей. Google Rich Results Test показывает, что из разметки Google готов использовать в выдаче. Инструменты ловят разное, поэтому прогоняют оба и сверяют отчеты.

Обновляют код вместе с содержимым страницы. Поменяли цену, часы работы или автора - поправили и разметку. Иначе разрыв копится незаметно, а всплывает через полгода, когда сайт отдает движку устаревшие факты. У Bing на этом построена отдельная механика: получив сигнал IndexNow, он сверяется со структурированными данными, чтобы понять, что на странице поменялось.

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

Часть систем ставит разметку сама. WordPress с SEO-плагином, Ghost, Webflow собирают Organization и Article без участия человека, а добавленный сверху ручной блок дает на странице два описания одной компании с разными полями. Перед внедрением открывают исходный код страницы и смотрят, что система выдает без вас. Дальше выбирают: либо чистят автогенерацию и ведут разметку руками, либо достраивают то, что система не умеет.

Перед работой полезно прогнать через Rich Results Test два-три сайта конкурентов из первой десятки и посмотреть, какие типы у них подтверждаются. Список того, что Google показывает сейчас, лежит в его галерее результатов поиска - сверяться стоит с ней, а не со статьями трехлетней давности.

Стоит смотреть, какие типы поисковики показывают сейчас. Типы, снятые с показа, оценивают по остаточной пользе: полезны моделям - оставляют, стоят ради галочки в отчете - убирают. Закрытым от индексации и служебным страницам разметка не нужна вовсе.

Сгенерировать разметку моделью можно, порог входа низкий. Результат проверяют валидатором и глазами: модели охотно придумывают поля, которых в словаре Schema.org нет, и подставляют факты, которых нет на сайте.

Ошибки, которые встречаются чаще остальных:

• блок Organization стоит на главной, а на страницах услуг его нет
• `dateModified` не заполнен или не обновляется годами
• название компании в разметке и в тексте написано по-разному
• `sameAs` ведет на профили, которых больше нет
• тип описывает содержимое, которого на странице нет
• система сгенерировала свой блок, а сверху добавили ручной - на странице два Organization
• блоки не связаны через `@id` и читаются по отдельности

Коротко

• Микроразметка сообщает машине, что на странице лежит. Позиции она не двигает, зато убирает догадки при разборе.
• Замеры дают разный результат по понятной причине: прозрачному сайту прирост маленький, запутанному заметный.
• Первый шаг - Organization по всему сайту. Второй - список подтвержденных профилей в `sameAs`.
• Без `@id` блоки на странице читаются вразнобой, со связями - как одно описание компании.
• Типы ставят под содержимое: Article для статей, FAQPage для вопросов, Product для товаров, HowTo для инструкций.
• Валидаторов два, и прогоняют оба. После правок текста разметку правят следом.

Частые вопросы

Если вы пришли из Google Ads или Meta Ads и слышали про Display & Video 360, у вас два вопроса: чем DV360 отличается от привычных кабинетов и стоит ли вообще переходить.

Я работаю с DV360 несколько лет, в основном на рынках СНГ и ОАЭ. Расскажу что внутри платформы, кому она подходит, и где входной порог - не тот, который пишут в обзорах, а тот, который видишь в счете от агентства.

DV360 в одном предложении и его место в Google Marketing Platform

DV360 (Display & Video 360) - это DSP. Расшифровывается как Demand-Side Platform, платформа закупки рекламы со стороны рекламодателя. Ее делает Google, и она входит в Google Marketing Platform (GMP) - корпоративную линейку рекламных и аналитических продуктов. Рядом с DV360 в GMP живут Campaign Manager 360 (ad-сервер для трекинга), Search Ads 360 (управление поисковой рекламой) и Google Analytics.

Главное отличие DSP от обычного рекламного кабинета - в источнике инвентаря. Google Ads показывает рекламу в инвентаре, который Google продает сам: Google Display Network, YouTube, Gmail, Google Maps. DV360 подключается к 80+ ad exchanges (рекламных бирж - площадок, где издатели и рекламодатели торгуются за показы) одновременно. Это значит, что одна и та же платформа покупает показы и в Google-сетях, и в OpenX, Magnite, PubMatic, Index Exchange, Xandr и десятках других. Через эту инфраструктуру DV360 охватывает примерно 90% программатик-инвентаря веба и приложений.

Технически реклама в DV360 работает по схеме RTB (real-time bidding - аукцион в реальном времени). Пользователь заходит на сайт, у площадки появляется свободный показ, и этот показ уходит на ad exchange. SSP (Supply-Side Platform - платформа на стороне площадки) со стороны паблишера выставляет показ на торги, DSP со стороны рекламодателя получает сигнал и решает, делать ставку или нет. Аукцион проходит за 100-200 миллисекунд. Если DV360 выиграл, пользователь видит ваше объявление.

Подробнее про работу programmatic я разбираю в отдельной статье - здесь нам важно понять место DV360 в этой схеме.

Чем DV360 отличается от Google Ads

Коротко: DV360 дает больше контроля над инвентарем и сделками, но требует ощутимо больше бюджета, людей и времени на ведение. Если разбирать подробнее, отличий пять.

Инвентарь и охват

Google Ads ограничен GDN (Google Display Network - контекстно-медийная сеть Google) и YouTube. DV360 покупает показы в 80+ ad exchanges. Это дает доступ к премиум-площадкам уровня Forbes, ESPN, New York Times, Vogue. В Google Ads они появляются редко и только в остаточной части инвентаря, в DV360 - регулярно и через прямые сделки.

Типы закупки

В Google Ads вы участвуете только в открытом аукционе и боретесь со всеми рекламодателями за одни и те же показы. В DV360 доступны еще три формата: PMP, Preferred Deals, Programmatic Guaranteed. Это дает возможность договориться с площадкой напрямую о фиксированной цене и гарантированном объеме. Подробнее про каждый тип ниже в этой статье.

Контроль частоты показов

В DV360 единый частотный кап работает через все форматы и кампании одновременно. Если вы запускаете display, видео и аудио параллельно, DV360 не даст показать одному пользователю 50 раз одно и то же сообщение через разные каналы. Google Ads такого не умеет: там лимит частоты живет на уровне отдельной кампании, и два запуска бренда могут показать одному пользователю по 25 показов каждый.

Бренд-сейфти

В Google Ads вы можете исключить категории контента и список доменов, но контроль остается грубым. В DV360 главный рабочий уровень настройки - Line Item. На нем вы строите whitelist (белый список разрешенных площадок) и blacklist (черный список исключенных доменов) под конкретные требования бренда, подключаете внешние сервисы верификации (DoubleVerify, IAS), задаете требования к viewability - доле показов, которые реально были видны пользователю на экране. Для крупных брендов с жесткими требованиями к окружению это критическая разница.

Сторонние данные

Что недоступно в Google Ads - сторонние сегменты от внешних провайдеров. В DV360 к собственным аудиториям Google добавляются данные Oracle Data Cloud, Experian, LiveRamp. Это дает точные сегменты вроде «топ-менеджеры компаний из списка Fortune 500», «владельцы автомобилей премиум-класса возрастом 3-5 лет», «активные путешественники с расходами от $X в месяц».

Полное сравнение DV360 и Google Ads - в отдельной статье, с разбором по сценариям и реальным цифрам.

Структура аккаунта DV360

В иерархии DV360 шесть уровней. На первый раз это сбивает с толку, особенно если вы привыкли к двух- или трехуровневой структуре Google Ads и Meta Ads.

Partner

Верхний уровень. Обычно принадлежит агентству, ресселеру или крупному рекламодателю с несколькими брендами. На уровне Partner живут права доступа, платежный профиль, общие настройки. Если DV360 ведет ресселер, ваш Advertiser создается внутри его Partner. Если у вас прямой контракт с Google (Self-Serve), Partner ваш собственный.

Advertiser

Уровень рекламодателя. Один Advertiser - один бренд или одна бизнес-единица. Здесь подключается Floodlight (система измерения через CM360), линкуются GA4 и YouTube-канал, хранятся аудитории и креативы.

Campaign

Уровень маркетинговой задачи. Например: «Запуск нового продукта в первом квартале», «Brand awareness Казахстан», «Performance ОАЭ». В DV360 Campaign не управляет бюджетом - это организационный контейнер, не финансовый.

Insertion Order

Уровень бюджета. Здесь вы задаете сумму, период расхода, дневные лимиты и общую стратегию ставок. Внутри одной Campaign может быть несколько IO с разными бюджетами под отдельные задачи: prospecting (привлечение новой аудитории), retargeting (повторный показ ушедшим), CTV.

Line Item

Главный рабочий уровень. Здесь настраивают все, что определяет сам показ: таргетинг, ставки, частота, расписание, выбор сделки или открытого аукциона, формат. Большая часть рабочего времени в DV360 проходит на уровне Line Item.

Creative

Сам рекламный материал. Креатив загружают отдельно и привязывают к Line Item. Один креатив можно использовать в разных Line Item.

Ключевой инсайт для тех, кто пришел из Google Ads: бюджет в DV360 живет на Insertion Order, не на уровне Campaign. Это другая логика. Когда вам нужно увеличить расход или поставить дневной лимит - вы идете в IO, не в Campaign. Полный разбор иерархии с примерами - в отдельной статье про структуру аккаунта DV360.

Как покупается реклама в DV360 - четыре типа сделок

Четыре варианта закупки, у каждого свой сценарий применения.

Open Auction

Открытый аукцион. Самый базовый сценарий. Вы конкурируете со всеми остальными рекламодателями на инвентаре, который площадка выставила в свободную продажу. Это аналог того, что происходит в Google Ads, только источников показа на порядок больше. Цены ниже, чем в прямых сделках, но контроль над размещением ограниченный: бренд-сейфти, whitelist, viewability задаете вы, но конкретные домены и моменты показа выбирает аукцион.

Private Marketplace (PMP)

Закрытый аукцион с ограниченным составом участников. Площадка приглашает определенный список рекламодателей и продает им инвентарь по специальной цене или с приоритетом. PMP используют, когда нужны конкретные премиум-домены или когда у бренда строгие требования к окружению.

Preferred Deals

Прямая сделка с площадкой по фиксированной цене, но без гарантии объема. Вы договариваетесь, например, что будете покупать показы на конкретных страницах сайта по $X за тысячу. Точный объем показов зависит от трафика площадки. Этот формат используют реже двух предыдущих, обычно для нишевых задач.

Programmatic Guaranteed

Прямая сделка с фиксированной ценой и гарантированным объемом показов. Самый дорогой формат и самый предсказуемый. Programmatic Guaranteed подходит для запусков с жестким KPI на охват, когда нужно гарантировать конкретный объем показов на премиум-инвентаре. Например, takeover (полный захват главного экрана) на главной странице крупного издания на день старта продукта.

Все четыре формата комбинируются в одном Line Item или внутри одной Campaign. У меня в проектах рабочая структура обычно такая: Open Auction для базового prospecting, PMP для премиум-окружения, Programmatic Guaranteed для пиковых охватных моментов вроде запуска. Подробный разбор типов закупки - с переговорной механикой и реальными ценами в отдельной статье.

Кому подходит DV360 - три рабочих сценария

Когда DV360 имеет смысл и какие сценарии работают на практике.

Сценарий 1. Крупный бренд со строгим бренд-сейфти

Чаще всего я подключаю DV360 международным брендам, для которых критичен контроль площадок размещения. Это производители бытовой техники, косметики, автопроизводители, реже - премиум-FMCG (товары повседневного спроса верхнего сегмента: алкоголь, парфюмерия, премиальная косметика). Объединяет их одно: репутационные риски стоят дороже, чем сэкономленные на Google Ads деньги.

Один из последних кейсов: премиум-бренд бытовой техники для рынков Казахстан + ОАЭ + Турция. Категорически нельзя было показывать рекламу рядом с новостным контентом про конфликты, политику, происшествия, медицинские темы. На Google Ads такой контроль настраивается грубо: либо исключаешь категории целиком и теряешь до 60% инвентаря, либо ставишь whitelist на пару сотен доменов и недобираешь охват.

В DV360 я собрал whitelist около 800 доменов через комбинацию открытого аукциона на премиум-сегменте и нескольких PMP-сделок с крупными издателями. По нашим брендам whitelist обычно варьируется от 200 до 1500 доменов в зависимости от ниши и аудитории. Подобрать и поддерживать такой список руками возможно только в DV360 - в Google Ads нет нужного уровня детализации.

Сценарий 2. Кросс-канальная стратегия

Если в маркетинговом плане одновременно display, видео, CTV (Connected TV), аудио и YouTube, DV360 - единственная платформа Google, которая объединяет все это в одной системе с общей логикой частоты и охвата. Один частотный кап на пользователя через все форматы. Общий пул аудиторий. Сводный отчет на выходе.

Это критично для запусков, где KPI считается через unique reach (уникальный охват): «достучаться до X миллионов уникальных людей с частотой не больше 5 показов на каждого». В Google Ads вы будете считать это через костыли и Excel, в DV360 это базовый функционал.

Сценарий 3. Большие охватные бюджеты

Когда вы упираетесь в потолок инвентаря Google Display Network, а доступа к премиум-площадкам через Google Ads почти нет - DV360 расширяет картину в десятки раз. Это сценарий для брендов с бюджетами от $20-30K в месяц на медийку, где задача не «получить лиды дешевле», а «накрыть аудиторию определенного профиля на премиум-площадках».

Сценарий 4. Международный запуск с разными рынками

Если кампания идет одновременно в нескольких странах с разной стоимостью инвентаря и разными требованиями к локализации, DV360 управляет этим как одной системой. Для бренда, который параллельно крутит рекламу в ОАЭ, Турции и Казахстане, можно собрать единый Advertiser с тремя Insertion Order под каждый рынок и прозрачно распределять бюджет по фактической стоимости. В Google Ads это либо три отдельных кабинета, либо одна кампания с грубой балансировкой между странами.

Кому DV360 не подходит - типичные ошибки выбора

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

Несколько раз ко мне приходили с запросом «хочу DV360 для узнаваемости». Чаще всего это были застройщики, бухгалтерские агентства, клининговые компании. Когда разбираешь ситуацию подробнее, оказывается одна и та же история: человеку нужны заявки и звонки прямо сейчас, а не охват и brand recall через 3-6 месяцев. Слово «узнаваемость» используется как синоним «больше показов», а фактическая цель - performance, то есть прямые продажи и лиды.

В таких случаях DV360 не подходит как инструмент. Платформе нужно 2-4 недели на сбор данных и калибровку оптимизации, а к этому моменту короткое окно атрибуции уже закроется. Frequency capping (ограничение частоты показов одному пользователю) без накопленной частоты не работает, премиум-инвентарь не успевает раскрыть свою стоимость в конверсиях. Тот же бюджет в Google Ads и Meta Ads принесет в разы больше заявок за то же время.

Я обычно отговариваю переходить на DV360, если выполняется хотя бы одно из условий:

Бюджет меньше $5-7K в месяц на стабильной основе, не разовым запуском. Ниже этого порога DV360 проигрывает Google Ads и Meta Ads по любой метрике, кроме разве что повода поставить в кабинете галку «работаю в DV360».

Цель - прямая лидогенерация на коротком окне. Если KPI это «лиды на этой неделе» или «продажи в этом месяце», DV360 не успевает выйти на стабильную работу. Платформе нужно 2-4 недели только на накопление данных и калибровку оптимизации.

Нет ресурса на ежедневное ведение. DV360 не работает в режиме «настроил и забыл». Это инструмент, который требует выделенного специалиста или агентства, которое будет смотреть на кампании каждый день, ловить аномалии, корректировать ставки, обновлять whitelist. Если такого ресурса нет, лучше остаться на Google Ads.

Нет аналитики и измерения. Без CM360 или хотя бы Floodlight (система отслеживания конверсий внутри DV360) платформа теряет половину преимуществ. Если у бизнеса не настроен трекинг, начинать с DV360 - значит платить за инструмент, которым вы не сможете пользоваться.

Локальная гео без премиум-инвентаря. На некоторых рынках просто нет программатик-инвентаря в нужном объеме - нет смысла подключать DSP туда, где SSP-партнеров мало. Это надо проверять заранее по конкретной стране.

Как получить доступ к DV360 - три варианта и реальные цены

Подключиться можно тремя путями.

Через ресселер-агентство

Самый частый сценарий на рынках СНГ и ОАЭ. Ресселер - это сертифицированное Google агентство со своим Partner-аккаунтом в DV360. Внутри своего Partner ресселер создает Advertiser под ваш бренд. Подключение занимает от нескольких дней до пары недель. Ресселер берет комиссию с медиа-бюджета (5-15% в среднем) и иногда фиксированную плату за ведение.

По моему опыту работы с агентствами в Казахстане, ОАЭ, Турции, Грузии - пороги входа на практике такие:

• От €1000 в месяц если клиент уже сидит на других платформах через то же агентство (Google Ads, Meta, TikTok). Агентству выгодно открывать DV360 как дополнительный канал - они уже зарабатывают на других продуктах
• От €2000-5000 в месяц если DV360 в одиночку, без других платформ. Агентству невыгодно открывать кабинет ради одного канала, и они поднимают порог
• Иногда отказывают совсем. Если бюджет ниже €2000 и нет других продуктов - агентство просто не возьмет в работу

Это цифры с рынка, не из обзоров. В обзорах часто пишут «от $10000 в месяц», но это либо устаревшие данные, либо порог при прямом подключении через Google.

Через Self-Serve напрямую от Google

Прямой контракт с Google без посредников. Вы получаете свой Partner-аккаунт и сами управляете всем. Этот путь подходит крупным in-house командам с собственным программатик-специалистом. Self-Serve - это самостоятельное подключение и ведение, без обертки агентства между вами и платформой. Лично я этим путем не ходил - в моих проектах всегда было выгоднее работать через ресселера.

Через крупное network-агентство

Publicis, OMG, GroupM и другие сетевые агентства имеют корпоративные контракты с Google. Этот путь - для брендов, которые уже работают с такими агентствами по основному маркетингу. Вход через них самый дорогой, но и самый управляемый: специалисты внутри агентства имеют прямой доступ к support GMP.

Подробнее про каждый путь - в статье про доступ к DV360. Минимальные бюджеты по странам - в статье про вход в DV360.

Что внутри - короткий обзор возможностей

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

Аудитории. Свои (ремаркетинг и customer match - загрузка списка клиентов из CRM), от паблишеров, сторонние от Oracle, Experian, LiveRamp. Подробнее в статье про аудитории DV360.

Креативы. Статичные баннеры, HTML5, видео, аудио, dynamic creatives (динамические креативы, которые подстраиваются под пользователя - геолокацию, время, поведение) через Google Web Designer и Studio, in-stream и out-stream видео.

Измерение. Floodlight для конверсий, связка с CM360 для трекинга по всем каналам, Brand Lift для замера роста бренд-метрик. Floodlight разобран в отдельной статье, Brand Lift - в статье про измерение бренд-эффекта.

Оптимизация. Автоматические стратегии ставок, Custom Bidding (когда вы пишете свой алгоритм оптимизации под уникальную метрику - например, не CPC и не CPA, а взвешенный score с учетом качества трафика), Insights Finder для поиска новых аудиторий по поведенческим сигналам с YouTube и Search. Custom Bidding - тема большой отдельной статьи, Insights Finder тоже разбираю отдельно. Эти два инструмента в Google Ads недоступны вообще, и для меня это одна из главных причин не уводить клиента из DV360 после обкатки.

Отчеты. Встроенный reporting на 30+ метриках, шаблоны под разные форматы, выгрузка в BigQuery для своей аналитики.

Что не делать в DV360 - три типичные ошибки

Их я регулярно вижу у новых клиентов или в чужих кабинетах при аудите.

Запускать без измерения. Если не подключен Floodlight или CM360, платформа показывает вам только показы и клики. Что произошло с пользователем дальше, какие сегменты дали конверсии, какая частота сработала - этого вы не увидите. Половина смысла DV360 живет в продвинутой атрибуции. Без трекинга вы платите за платформу корпоративного уровня, а пользуетесь возможностями обычного медийного кабинета.

Смешивать все в одном Line Item. Когда специалист только начинает работать с DV360, первый соблазн - собрать всю активность в одном Line Item: разные аудитории, форматы, ставки, расписание. После запуска разобрать, что именно сработало, не получится. Логика правильной структуры: один Line Item решает одну задачу с одной аудиторией и одним форматом.

Не считать комиссии. В DV360 несколько слоев стоимости: платформа Google берет свою долю, ресселер берет свою, иногда добавляется DSP fee (дополнительная комиссия за использование биржи) на уровне ad exchange, плюс плата за сторонние данные. Если вы видите в отчете «потрачено $5000», фактический бюджет с учетом всех комиссий мог быть $5800-6500. Это надо считать вручную и закладывать в планирование.

Что в итоге

DV360 - не альтернатива Google Ads и не следующий шаг после Meta Ads. Это инструмент другого класса со своими задачами, своей экономикой и своим порогом входа.

Имеет смысл подключать, если ваш фокус - охват, бренд-сейфти, кросс-канальная медийка с премиум-инвентарем, и бюджет от $5-7K в месяц. Реальный порог входа на рынках СНГ через ресселера от €1000-2000 при условии других платформ или €2000-5000 в одиночку. Меньше - не имеет смысла даже на старте.

Если ваши KPI завязаны на лиды и продажи в коротком окне, оставайтесь в Google Ads и Meta Ads. DV360 не справляется с performance на ограниченных бюджетах.

Если решение в пользу DV360 принято - дальше смотрите структуру аккаунта, как получить доступ, и полный разбор типов закупки. Полная навигация по кластеру - на главной странице раздела DV360.

Частые вопросы