Ликбез по TCP/IP интернет-рекламе

В канале шла реклама про систему рекламы. Поскольку этот пост не оплачен, то упоминания не будет :)

Идея системы следующая:

1. В некой локации устанавливается прибор, который фиксирует все mac-адреса прохожих. В смысле - устройств прохожих, где включен Wi-Fi;
2. Адреса фиксируются и упорядочиваются;
3. Потом на крупных интернет-площадках демонстрируется реклама именно этим прохожим;
4. ...
5. PROFIT!!

Мне написали несколько человек, что "здесь что-то не так". Посему, считаю долгом объяснить что не так, и как это в действительности работает.

За одно разберем учебный (с дыркой в стволе) кейс по принципу работы сетей TCP/IP.

Все непонимание состоит в том, что интернет-технологии стали столь сложными, что в отрасли появились очень жесткие вертикали специализаций, которые кажутся далекими друг от друга, но все же про одно и то же. Но очень специфично. Я хочу сказать, что спецы по интернет-рекламе иногда не очень хорошо понимают принципы организации связи, а сетевые инженеры далеки от технологий, находящихся за стеком TCP/IP.

Разделим проблему на две составляющих: рекламные интернет-технологии и организацию связи.

Реклама

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

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

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

Такие изощрения довольно обычная тема.

Вот, например, так делает ВКонтакте. Вот вам Pixel от Facebook (eng). Вот очень хорошая статья от Яндекса.

В общем, все крупные рекламные сети умеют эту штуку.

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

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

Ну, например, наш потенциальный потребитель в моменте находится в торговом центре "Покупавка" и ищет в Яндексе "красные сапоги". Логично было бы ему показать рекламу недавно открытого бутика "Мир красных сапог". И конверсия (превращение рекламы в покупку) была бы великолепная.

Еще круче (для "Мира красных сапог") было бы показывать рекламу тем, кто в принципе бывал в ТЦ "Покупавка". Ну, потому что раз был, значит потентен купить. А жителям другого города такая реклама без надобности - они все равно не поедут в "Покупавку" за красными сапогами. Это же логично.

Вопрос: как сделать так, чтоб реклама "МКС" показывалась только тем, кто бывает в районе "Покупавки"?

Логика простая: если конкретный терминал пользователя физически был зафиксирован в районе "Покупавки", то этот пользователь сильно ценнее для "Мира Красных Сапог" в плане демонстрации ему своего рекламного послания. Таким идентификатором может быть, например, IMSI мобильника или mac-адрес Wi-Fi модуля.

Проблема только в том, что IMSI (MSISDN) мобильный оператор нипочем не отдаст, а mac-адрес не транслируется на уровнях стека TCP/IP, где работают рекламщики. На уровне протоколов HTTP и выше. Mac-адрес же находится на уровне физического доступа и никак не транслируется выше оного.

И тут на помощь приходят Wi-Fi HotSpot. Например. Потому что хотспот может зафиксировать mac-адрес терминала и занести его в специальную базу данных.

Стек TCP/IP

Предыдущая глава была для сетевиков, а эта - для рекламщиков. Которые могли и подзабыть (или не знать) что-как там все устроено. Напомню картинку, описывающую стек:

И еще напомню, что есть такой "принцип инкапсуляции":

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

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

Как-то вот так это выглядит:

Еще mac-адрес можно получить из приложения под Andriod или iOS. Но это не точно.

И в общем, вот что делает в данном кейсе Хотспот (напомню про рекламу):

1. При подключении абонента система хотспота фиксирует mac-адрес и назначает ему IP-адрес из собственного стека DHCP
2. Перебрасывает на страничку кэптив-потрала, где, в том числе, подсовывает куку системы ретаргетинга
3. Абонент как-то там авторизуется (это для Роскомнадзора, а для маркетинга это и не надо, на самом деле)
4. В БД оператора хотспота записывается факт коннекта, мак, хеш куки
5. ...
6. PROFIT!!

При этом вот что происходит при сканировании всех мак-адресов в локации:

1. Маршрутизатор в режиме сканера фиксирует все маки и пишет их в логирующую таблицу. Отмечая еще и собственный айдишник в любой форме, принятой оператором хотспота - это для геолокации.
2. Сверяет каждый mac-адрес с существующей БД, где есть записи абонентов, которые уже подключались и имеют хеш куки.
3. Если совпадения найдены, то делается пометка нахождения абонента в ТЦ "Покупавка".
4. Если нет такого мака, то ничего не происходит, ибо логировать с целью ретаргетинга нечего.

Отсюда выводы:

1. Для работы ретаргетинга недостаточно просто зафиксировать мак-адрес в локации. Нужно чтоб обладатель этого прибора еще и подключался к сети оператора хотспота хоть где-то.
2. Сам ретаргетинг работает поверх рекламных сетей. Впрочем, можно крутить рекламу и на самом хотспоте на странице входа (каптив-портале)
3. Собственно ретаргетинг может работать не только на мобильном устройстве, но и на других приборах абонента, если абонент пользуется синхронизированным браузером на разных устройствах.

Проблемы

Я этой темой начал заниматься еще год назад. Проводил и натурные эксперименты и технически это вполне рабочая схема.

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

Проблема заключается в том, что на малых объемах вся эта схема не работает. Давайте посчитаем:

1. Всего в локации будет фиксироваться N mac-адресов. Например.
2. Из них к хотспоту подключалось M адресов. Остальные мы никак не можем фиксануть и ретагретировать. Понятно, что всегда M < N. И вопрос конверсии стоит очень остро. Например, максимально у меня получалось 10%. Но реально 1-2%.
3. Группа "попавших в ретаргетинг" - это те, кому есть где показывать рекламу. То есть - это люди, которые попали в число тех, которым реклама может показываться в принципе - они зашли на страницы, где есть "адверт-крутилка", у них не включен adBlock и не чищены куки. Это будет S, которое всегда S < M. И тут тоже встает вопрос конверсии, где практика показывает не более 20%, а в среднем - опять 5%.

Итого мы получаем формулу, где A - количество показанной рекламы:

A = N / M / S

Попробуем в цифрах:

На хотспоте мы, например, зафиксировали 1000 мак-адросов. Это довольно много - тысяча человек прошло мимо. Из них только, пусть будет 5%, нам известны. То есть - 50 человек.

Из них только, пусть будет - 10% было осуществлены показы. То есть, на выходе мы имеем всего 5 показов.

Этого просто мало для создания хоть какого-то вменяемого автоматизированного бизнеса класса "кэш-машин".

И я закрыл тему...