В онлайн отображении рекламы, очень полезно делать рекламу целенаправленной, или таргетированной, основываясь на информации о пользователе. Это работает в целом для онлайн-рекламы, но особенно важно для рекламы, которая более фокусируется на бренде, для которой использование, например, текстовой составляющей несвойственно. Рекламодатели заинтересованы в поиске целевой аудитории с определенными интересами или демографией, или пользователей с интересной историей посещения страниц рекламодателя. Служба соответствия cookies Google предоставляет рекламодателям возможность «играть» на интересах определенных пользователей с помощью уже накопленной информации о них.

Служба обмена рекламной информацией DoubleClick 2.0 и их партнерские сети используют различные методы идентификации пользователей. Обычно пользователи определяются по cookies, хранящимися в настройках браузера, каждые из которых принадлежат тому участнику домена, который их назначил (doubleclick.net – это и есть Ad Exchange (обмен рекламной информацией), или домен третьего лица рекламной сети партнера). Механизм защиты браузера не позволяет одной стороне считывать cookies, определенные второй стороной, даже в случае соглашения на обмен подобной информацией между обеими сторонами.

Google идентифицирует пользователей для третьих лиц – своих рекламных партнеров – с помощью специального идентификатора партнера Google. Идентификатор Google – это усложненная версия cookies, принадлежащих doubleclick.net, которые Google передает своему партнеру для идентификации пользователей. Это своего рода производное от cookies, принадлежащих Google в домене doubleclick.net, под которым Google предлагает рекламу, но это не сами cookies. Партнеры могут участвовать в «конкурсе» на определенные Google-идентификаторы, используя приложение, которое поддерживает протокол обмена рекламной информацией в режиме реального времени.

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

Сервис соответствия cookies дает возможность создавать таблицы, основанные на соответствиях между идентификаторами Google и партнерскими cookies, так называемые таблицы соответствия. Таблица соответствия – это структурированные данные, в которых хранятся связанные один к одному cookies партнера и идентификаторы Google.

В интересах конфиденциальности пользователя, служба соответствия cookies не принимает никакой информации о пользователе от третьих лиц. Это исключает возможность поддержания связи между идентификаторами Google и cookies партнера на серверах Google. Таким образом, служба соответствия cookies предоставляет информацию, необходимую партнеру для составления таблицы соответствия, и только партнер ответственен за ее составление и поддержку.

С целью создания ассоциации в таблице соответствия партнер должен обслуживать 1х1 пиксельные тэги, предоставляемые Google, - тэги соответствия. Тэг соответствия должен работать с рекламой партнера, или помещен в его web-настройки. Он имеет следующую структуру:

<img src="http://cm.g.doubleclick.net/pixel?nid=1234">

В данном случае  1234  заменяется идентификатором партнера (чтобы обслуживаться Google). Партнер должен поддерживать только этот тэг, если он все еще не имеет совпадений для этого пользователя (или является устаревшим).

При получении запроса по данному тэгу из браузера пользователя, Google будет давать перенаправление к своему партнеру. Это перенаправление включает в себя идентификатор Google, номер версии и cookie партнера. К примеру:

http://ad.network.com/pixel?id=dGhpcyBpcyBhbiBleGFtGxl&cver=1

Идентификатор Google – это неполная строка URL-адреса в безопасной кодировке base64. Если ваша таблица соответствия хранит двоичные (декодированные base64) значения, вам придется дополнить их перед декодированием.

В качестве альтернативы вы можете использовать поле google_user_id, которое соотносится с идентификатором Google, возвращенным службой соответствия cookies.

Параметр cver  указывает числовой номер версии Google-идентификатора. Google могут часто менять схему «спутывания», или усложнения cookies, что увеличивает значение cver. Оба значения напрямую добавляются к URL, предоставляемых партнером, как показано выше. Партнер получает это перенаправление вместе с cookies и обновляет таблицу соответствия в согласии с cookies партнера и идентификатором Google. Партнер также поддерживает 1х1 пиксельный тэг для браузера пользователя. Записи добавляются в таблицу соответствия таким образом, чтобы реклама работала для уникального пользователя.

Этот процесс представлен посредством диаграммы ниже. Запросы отправляются в порядке от (1) до (4). В данной диаграмме каждый запрос сопровождается информацией, которая посылается вместе с запросом (в скобках).

При желании, можно добавлять дополнительные параметры в конце запроса:

<img src="http://cm.g.doubleclick.net/pixel?nid=1234&extra1=xx&extra2=yy">

В данном случае нужный параметр всегда указывается в первую очередь.
Все дополнительные параметры копируются дословно до конца перенаправления, следуя за идентификатором Google и параметром cver:

http://ad.network.com/pixel?id=dGhpcyBpcyBhbiBleGFtGxl&cver=1&extra1=xx&extra2=yy

Вы можете использовать данные параметры для передачи дополнительной информации об интересах пользователя.

В этом разделе объясняется принцип пользования службой соответствия cookies.

Необходимые условия:

Вы должны быть пользователем обмена рекламной информацией DoubleClick, чтобы иметь возможность пользоваться Сервисом соответствия cookies.

Прежде чем начать, вы должны предоставить URL, на которые будет ссылаться служба соответствия cookies. (http://ad.network.com/pixel?id= в предыдущем примере). Свяжитесь со своим менеджером по обмену рекламной информацией DoubleClick для передачи этой информации.

Использование таблиц соответствия

Вы должны обеспечить ваши серверы структурированными данными, которые содержат соответствия между идентификаторами Google, переводом и cookies партнера. Это структура данных должна быть проиндексирована как Google-идентификатором, так и партнерскими cookies, таким образом, данные будут одинаково доступны в обоих направлениях. Базовому сервису соответствия cookies требуются только cookies партнера для поиска идентификатора Google (чтобы проверить ограничение частоты показа существующей записи), но для использования этого соответствия и всех остальных служб Google требуется эффективный идентификатор Google/перевод для просмотра партнерских cookies.

Вы должны иметь возможность добавления поддерживаемого Google пиксельного тэга соответствия в браузер пользователя. Вы можете выбрать между размещением данного пиксельного тэга совместно с вашей рекламой, или в web-настройках под собственный контроль.

Обслуживание пикселей

Ваши серверы должны ловить URL перенаправления и своевременно снабжать браузер пользователя пустым 1х1 пикселем. В процессе обработки входящих запросов по перенаправлению в URL, ваши серверы должны анализировать URL для извлечения идентификатора Google и ошибочных кодов, и обновлять таблицу соответствия.

Обработка ошибок

Служба соответствия cookies связывает ошибки с помощью специальных Google-идентификаторов, которые начинаются с прописной буквы «E» и следующим за ней кодом ошибки, выраженным целым числом. Изначально служба поддерживает следующие кодовые ошибки:

Если вы получили отчет об ошибке, вы можете отправить запрос о соответствии тэга еще раз, но не чаще одного раза в 14 дней.

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

Обеспечение конфиденциальности пользователей

Служба соответствия cookies защищает конфиденциальность пользователя, придерживаясь следующих принципов:

Google не принимает никакой информации о своих пользователях, предоставленную партнером (в том числе cookies, идентификатор пользователя, демографию пользователя, и т.д.).

• Google запрещает нескольким партнерам присоединяться к своим таблицам соответствия.


• Служба соответствия cookies не раскрывает DoubleClick Google cookies.


• Цель таблицы соответствия позволить партнерам использовать собственную информацию о пользователях в сотрудничестве с Google. Ни при каких условиях служба соответствия cookies не может использоваться исключительно для сбора данных, что оговаривается в условиях пользования системой обмена рекламной информацией.

Ограничение частоты показа

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

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

Максимальная скорость запроса

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

В этом разделе рассказывается о том, как наилучшим образом использовать протоколы RTB при разработке приложений.

1. 1.      Управление соединениями


2. 1.      Поддержание связи


3. 2.      Решение проблем перегрузки


4. 3.      Ответы на пинги


5. 4.      Пиринг

Поддержка связи

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

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

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

Как избежать закрытия соединений

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

• Время ожидания – 2 минуты


• Максимальное количество запросов для одного соединению - максимальное возможное значение


• Максимально возможное значение соединений, которая способна выдержать оперативная память, но не приближаясь к критическому значению

В Apache, для примера, подобные настройки повлекут за собой следующие изменения:  KeepAliveTimeout до 120,  MaxKeepAliveRequests  до нуля, и  MaxClients  до значения, которое зависит от типа сервера (см. документация для подробностей).

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

К началу

Решение проблемы перегрузки

В идеале, квоты устанавливаются достаточно большие для того, чтобы покупатель мог получить все запросы, которые он в состоянии обработать, но не более того. На практике, поддержание квоты на оптимальном уровне – трудная задача, и по некоторым причинам перегрузки все равно случаются: обрыв сервера в часы пик и изменения потока траффика занимают больше времени для обработки каждого запроса в случаях, когда квота предоставлена больше возможной. Следовательно, нужно обратить внимание на то, как ведет себя ваш соискатель в случае большого количества входящего траффика.

В терминах о поведении в условиях высокой нагрузки, соискатели делятся на три больших группы:

• ·         Соискатель, который отвечает на все запросы


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


• Когда количество запросов растет, задержки появляются до тех пор, пока все запросы не станут в очередь ожидания


• Задержки стремительно растут, т.к. количество запросов достигает пика


• Происходит остановка процесса регулирования, значительно уменьшается количество позволенных запросов


• Задержки снова восстанавливаются, регулирование снижается


• Цикл начинается снова

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

• ·         Соискатель с ошибкой при перегрузке


• 
  Соискатель  принимает определенное количество запросов, затем начинает исправлять ошибки во время некоторых запросов. Это происходит во время внутренних таймаутов, вызывая дестабилизацию в очередности соединений (контролируется с помощью ListenBackLog в Apache), делая вероятным полный обрыв соединения, когда количество задержек становится слишком высоким. Если Google обнаруживает более 15% ошибок, он начинает процесс регуляции. В отличие от соискателя отвечающего на все запросы, данный соискатель сокращает свои потери, что позволит ему мгновенно восстановиться при условии снижения количества запросов. График задержек этого соискателя похож на мелкий пилообразный узор во время перегрузок, где пик наступает на максимально допустимой скорости.


•  


• ·         Соискатель, не отвечающий на запросы при перегрузке


• 
  Этот соискатель принимает запросы до определенного момента, при превышении количества допустимых запросов включается опция «не-ответа» на запросы в любом количестве. По аналогии с «ошибкой при перегрузке», это может осуществляться несколькими способами. Но что отличительно: сигнал не возвращается к Google, поэтому мы никогда не включаем процесс регуляции запросов, т.к. в данном случае переизбыток поглощается интерфейсными механизмами, которые пропускают ровно такое количество траффика, с которым сервер способен справиться. График задержек этого сценария отображает плоский (искусственный) обрыв запросов во время часа пик, что влияет снижение количества ответов на запросы.

Мы советуем комбинировать режим «ошибка при перегрузке» с режимом «не отвечать пи перегрузке» следующим образом:

• Установите обеспечение пользовательского интерфейса на режим «ошибка при перегрузке» с целью увеличения количества соединений, на которые он сможет ответить.


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


• Проверка состояния серверов. В случае если ни один из них не обладает достаточной мощностью, включается режим «не-ответа».


•  

Это позволяет поглощать избытки и дает серверу возможность обрабатывать максимальное количество запросов, которые он в принципе способен принять. Можно сказать, это своеобразная функция «не-ответа при перегрузке», при которой механизм интерфейса выдает «ошибку при перегрузке», когда количество запросов значительно выше ожидаемого.

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

К началу

Ответы на пинги

Убедитесь, что ваш соискатель может ответить на ping-запрос, что очень важно для отладки. Google использует ping-запросы для проверки состояния и отладки статуса соискателя, закрытия соединений, задержек, и т.д. Ping-запросы имеют следующий вид:

  


  BidRequest <


    id: "1234567890123456"


    is_test: true


    is_ping: true


>

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

К началу

Пиринг

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

• В Интернете транзитные связи выбираются по принципу «горячей картошки», т.е. находят ближайшую ссылку вне пределов нашей сети, которая может доставить пакет по назначению, и направляет пакет по выбранному пути. Когда траффик проходит часть пути, принадлежащую провайдеру, с которым у Google много пирингованных связей, наиболее вероятно, что именно эта связь будет использована для передачи пакета. Далее, мы не уже не контролируем передачу пакета соискателю, таким образом, он может быть отправлен в любую другую автономную систему.


• И напротив, при вступлении в силу соглашения о прямом пиринговании, пакеты с информацией отправляются только по пути пирингованной связи. Не важно, откуда приходит пакет, он проходит по ссылкам, которые принадлежат Google до тех пор, пока не достигает точки обмена, которая должна быть наиболее близка к месту нахождения соискателя. Обратный путь начинается с небольшого «скачка» в сеть Google и продолжается до самого конца обмена. Выбор пути передачи через управляемую Google структуру помогает избежать задержек при передаче пакета, а также некоторых вариативных изменений.

Проверьте наш канал YouTube на наличие туториалов и иной информации о форматах Ad Exchange и прочих разработках.

• Протокол обмена рекламной информацией в режиме реального времени


• Протокол соответствия cookies.


• Некоторые иные предложения от Ad Exchange.