Методы сбора данных об интернет-пользователях

Речь пойдет о первом пункте — сборе аудиторных данных. В зависимости от того, где хранится первоначальная информация, источниками пользовательских данных для DMP могут служить тэги на веб-сайтах (1), файлы куки (2), первичный ввод данных (3) и API (4). Итак, о каждом пункте поподробнее.

I. Теги (TAGS)

Самый простой способ для DMP собрать необходимую информацию об аудитории клиента — это добавить теги на его же сайт. Получаемые таким образом данные — данные третьего порядка (third-party data ссылка), а теги — это сниппеты (фрагменты кода), которые вставляются в код самой веб-страницы.

Как только сайт привязан к DMP, платформа начинает собирать данных о его посетителях. И зачастую делает это старым и проверенным способом: с помощью установки JavaScript пикселей на целевых страницах.

В зависимости от информации, которую отслеживают теги, их можно разделить на:

• Теги активности пользователей применяются для фиксирования событий, совершенных посетителями на сайте. Теги могут записывать название самого действия, местоположение и параметры. Параметры — это кусочки информации, которые передаются обратно в DMP и которые вручную еще необходимо предопределить. Это может быть абсолютно любые данные, доступные на веб-странице: объем заказа, чек покупки, ID посетителя и др.
• Медиа-теги используются для отслеживания показов и кликов в медийной рекламе. Эту информацию также собирают DSP, SSP, рекламные серверы и другие платформы, но DMP она необходима, прежде всего, для улучшения таргетинга в рамках программатик рекламы.

Если DMP собирает аудиторные данные с веб-сайтов непосредственно с помощью тегов, то для отслеживания активности пользователей мобильных приложений необходимо вставить код через SDK. Затем, как обычно, полученные данные отправляются на сервер DMP. Платформы DMP имеют SDK для iOS и Android.

II.Синхронизация файлов cookies и ID мобильных устройств

Рекламные платформы — DMP, SSP, DSP, рекламные сети, рекламные биржи — и иные поставщики информации зачастую обмениваются между собой готовыми аудиторными сегментами, созданными с помощью файлов cookies. Они представляют собой текстовые файлы, хранящие в себе информацию о просмотренном контенте, посещенных страницах пользователем и т.п. Файлы cookies создаются браузером при каждом визите пользователя на сайт и сохраняются на его компьютере.

Привязка cookies к ID пользователей. Из-за множества функций файлы cookie теоретически могут хранить в себе огромный объем информации, однако сами файлы ограничены в размере. Для решения этой проблемы некоторые cookies, хранящиеся на компьютерах пользователей, содержат лишь их уникальный ID. Это позволяет рекламодателям и другим рекламным платформам хранить остальную информацию в их собственных системах. Это позволяет не только сделать размер куки файлов меньше, но также и получать и анализировать больше информации о юзере. И главное преимущество использования идентификатора — это возможность для рекламодателей использовать синхронизацию cookie (cookie syncing) для пополнения аудиторных данных при запуске рекламы.

В мобильных приложениях вместо файлов cookie, которые идентифицируют пользователя в браузере, данные связаны с идентификаторами (IDs) мобильных устройств: AAID для Android и IDFA для iOS.

Синхронизация cookies и ID мобильных устройств

Как уже было отмечено выше, созданные файлы куки с помощью одного third-party трекера не могут быть прочитаны другим third-party трекером. Это, в свою очередь, ограничивает потенциальный объем информации, которую рекламодатели и агентства могут получить о пользователе. Так, чтобы настроить более точный таргетинг на целевую аудиторию, необходимо объединить данные о пользователе с разных доменов и источников. В рамках программатик рекламы это возможно путем сопоставления ID пользователя с одной технологической платформы на другую — к примеру, с DSP на DMP. Этот и есть синхронизация cookie-файлов.

Процесс сбора информации о пользователе выглядит следующим образом:

1. Пользователь заходит на сайт, который содержит рекламу;
2. Браузер отправляет запрос в рекламную биржу — Ad Exchange;
3. В свою очередь рекламная биржа отвечает на запрос и создает third-party cookie;
4. Рекламная биржа переадресовывает рекламный запрос пикселю URL (to the pixel URL) со стороны DMP, передавая ID пользователя в параметр URL. DMP читает свой собственный cookie (если уже есть в ее базе пользователь с таким ID) или создает новый и сохраняет его в таблице;
5. Если синхронизация двунаправленная, то DMP передает рекламной бирже информацию о своем собственном ID в параметре URL. Рекламная биржа получает этот запрос, сопоставляет полученный файл cookie со своим и сохраняет идентификационный номер платформы DMP вместе с собственным ID в таблице;

III. Загрузка первичных данных

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

Подготовка первичных данных для загрузки в общем виде выглядит так:

1. Создаются файлы с информацией о потребителях, которой, по субъективному мнению, DMP должны владеть;
2. Происходит тщательное форматирование этих файлов;
3. Отформатированные, в основном, в CSV файлы отправляются в DMP в виде пакетных файлов. В них будет множество строк с примерно таким содержанием: “12929387,1,3,6,27,01-07-17 …”;
4. Предоставляется файл для декодирования (расшифровки) отправленных данных. Он помогает DMP расшифровать все цифры, буквы и запятые, находящиеся в CSV файле, и интерпретировать их;

Загрузка первичных данных будет отличаться в зависимости от используемой платформы. Стандартный процесс интеграции предполагает загрузку оффлайн данных с помощью специальных платформ (к примеру, LiveRamp, Neustar или iBehavior) и их хеширование — процесс удаления любой персональной информацию о пользователях (например, email-адрес, имена, физический адрес и др.). Затем загруженные оффлайн данные сопоставляются с имеющимися онлайн данными о пользователях с помощью идентификаторов (ID).

IV. API

DMP-платформы также могут собирать информацию с помощью веб-служб API*, которые обмениваются объектами JSON** с веб-сервера на сервер DMP и в обратном направлении. Таким способом может передаваться большое количество информации, но использование API требует тщательной настройки и много времени.

Веб-службы API используются для обмена данными между веб-серверами и DMP. Этот вариант обмена информацией идеально подходит компаниям, в распоряжении которых находится несколько хранилищ данных.

*API (Application Programming Interface — интерфейс прикладного программирования) — это способ, с помощью которого можно писать код, который взаимодействует с другим кодом.**JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript.