Да, все так. Только MAC-адреса сопоставляются не мобильным приложениям, а конкретным пользователям. Реклама же может прилететь вообще из других каналов и устройств.
Как вы собрались направлять на кого-то рекламную кампанию?
В рекламных сетях есть инструмент выбора аудитории, когда вы на всех жертв, доступных рекламной сети (вы пользуетесь Яндексом, Мейлом или Гуглем — поздравляю, вас посчитали), фильтруете по какому-либо признаку. Если рекламная сеть знает о принадлежности вам какого-либо устройства (а она знает, если у вас есть приложение с аутетифицированным аккаунтом), то она знает и MAC-адрес устройства. Например, так. Соответственно, рекламодатель может по списку MAC-адресов подобрать аудиторию и сказать «вот эту рекламу покажите этим пользователям». А дальше уже вопросы сети, как она это будет делать.
Да, отключение WiFi в публичных местах и использование блокировщика рекламы выключит вас из этого увлекательного процесса. Но это — нетипичное поведение. At mass определенная часть пользователей все же попадет «под раздачу». Разумеется, как потом их настигнет реклама заведения, мимо которого они ходят каждый день — головная боль рекламной сети.
Встроить баннер в HTTP?
Вы что-то путаете. Вышеописанное в статье устройство пассивно слушает эфир и собирает данные. Для встраивания в трафик необходимо завернуть на себя мобильное устройство (например, притворившись популярной открытой точкой доступа) и уже в этом случае можно говорить о каком-то встраивании через DPI или transparent proxy. Это другая интересная задача, впрочем, как вы верно отметили, абсолютно бесполезная вследствие повального использования HTTPS. Поэтому особо хитрые используют для этого captive portal непосредственно при подключении к точке доступа. А, поскольку анонимный доступ к публичному wifi запрещен законодательно, можно посредством captive portal и данных dhcp еще и выудить телефон подключенного пользователя. На особых параноиках не сработает, а вот с остальными не уверен.
Если вы маленькая точка — то и ассортимент фиксирован, а если кто-то вроде М.Видео — да в жизнь не угадаете, зачем человек зашел — ноутбуки посмотреть или телевизоры.
Основная цель такой рекламы — получить проходящего мимо клиента. Ну и предлагать определенный товар человеку, который уже сходил за ним в магазин — малоэффективно.
Стартап я понял, с рандомизацией MAC адреса он нежизнеспособен.
Вы не совсем правильно понимаете. Рандомизация MAC-адресов происходит при сканировании эфира в поисках новых точек доступа, к которым можно подключится. При наличии известной точки доступа рандомизация не используется, устройство работает на своем «родном» MAC-адресе.
Больше похож на какой-то развод, если честно.
Тут я не доктор. Но беглый гуглинг выдал пять штук аналогичных проектов. Особое впечатление произвело как эти ребята бодаются на ЦП.
правильно ли я понимаю, что МАС генерируются рандомно, но их начало хотя бы соответствует вендору железки?
Необязательно. В MAC-адресе есть бит — признак локальности сгенерированного адреса. Другой бит отвечает за broadcast-вещание. Возможно, префикс действительно берется из исходного устройства (да, забыл написать, что в серверной инкарнации я импортировал себе справочники производителей и показывал, чье устройство источник адреса).
а как ваще таргетировать рекламу, если кроме вендора проходимцев, неизвестно ничего больше?
Или все же известно? Но что же это?
Очень просто. Рекламная платформа, как правило, знает ваш MAC-адрес (приложения Гугла и Яндекса есть почти на каждом смартфоне, равно как и привязка их к аккаунтам). Вы просто загружаете список адресов в рекламную сеть, они отбирают только те, что им известны, после чего на них можно настроить рекламную компанию. Можно посмотреть в самой первой ссылке на стартап — там у них на сайте все хорошо описано.
почему коллега mkrentovskiy решил его опубликовать под статьёй "Сколько лет тайга ходи — понимай нету"
Могу объяснить. Я кинул ссылку на статью в небольшой чат разработчиков (стохастически сложившийся еще со времен ЖЖ, да-да, я тоже старый пердун) и коллега в ответ на эту ссылку поделился историей. Я посчитал, что это будет хорошим комментарием, но, поскольку у автора нет аккаунта на Хабре, я ответил с его великодушного разрешения.
Кто знал, что это приведет к таким далеко идущим выводам...
У меня в позапрошлом году был офигенный клиент, это ещё когда я брал чистый «кризис».
У клиента в девгруппе две команды, каждая занимается своей частью продукта (условно, бэкофис и сторфронт, т.е. софт работающий над формированием заказа и софт, работающий над исполнением заказа), изредка между собой интегрирующийся.
Команда бэкофиса прям вот совсем в днище ушли: полгода сплошных косяков, собственники грозятся всех уволить, наняли консультанта, после консультанта наняли более другого (меня). Причём вторая команда (сторфронт) работала норм и продолжала работать норм, именно бэкофисная, которая до этого тоже норм работала, стала косячить. Команды в разных офисах сидят, друг на друга привыкли псить.
Причина: стор и бэк это одна система, в ней куча зависимостей, команды в разных офисах, между собой не общались. На сторфронт все время «смотрят» собственники, соответственно у них там новые фичи, идеи и контроль. В ней был мальчик-на-все-руки, такая комбинация из БА, дизайнера и «принеси нам кофе». Вот этот мальчик, незаметно для своей команды, выполнял кучу мелких задач типа «предупредить вторую команду о деплое», «проапдейтиь документацию» и т.п. рутину, вплоть до «внести в жире в тикет всякие номера версий и компоненты». Но код мальчик не писал и в один момент собственники решили его оптимизировать, нафиг уволив. Для команды стора ниче не поменялось, они просто не вносили и не апдейтили доки, а команда бэкофиса оказалась в ситуации, когда релизы стора ломают у них что-то, и это их проблемы, а если их релизы ломают что-то у стора, это опять их проблемы, потому что стор на виду у собственников :)
В теории должно хватить. Звуковые утилиты не сильно прожорливые, можно повыкидывать кучу сетевого софта, если не собираетесь его использовать как роутер.
Ну, если учесть, что описанный подход заработал неделю назад, то ответ будет — пока нигде. Планы имеются, но пока рано говорить что-то конкретное.
Ранее я применял Erlang в таких устройствах для отображения картины проходящего трафика и прототипа сигнализации с ретрансляцией видео с камер и получением показателей с кучи датчиков и детекторов.
В рекламных сетях есть инструмент выбора аудитории, когда вы на всех жертв, доступных рекламной сети (вы пользуетесь Яндексом, Мейлом или Гуглем — поздравляю, вас посчитали), фильтруете по какому-либо признаку. Если рекламная сеть знает о принадлежности вам какого-либо устройства (а она знает, если у вас есть приложение с аутетифицированным аккаунтом), то она знает и MAC-адрес устройства. Например, так. Соответственно, рекламодатель может по списку MAC-адресов подобрать аудиторию и сказать «вот эту рекламу покажите этим пользователям». А дальше уже вопросы сети, как она это будет делать.
Да, отключение WiFi в публичных местах и использование блокировщика рекламы выключит вас из этого увлекательного процесса. Но это — нетипичное поведение. At mass определенная часть пользователей все же попадет «под раздачу». Разумеется, как потом их настигнет реклама заведения, мимо которого они ходят каждый день — головная боль рекламной сети.
Вы что-то путаете. Вышеописанное в статье устройство пассивно слушает эфир и собирает данные. Для встраивания в трафик необходимо завернуть на себя мобильное устройство (например, притворившись популярной открытой точкой доступа) и уже в этом случае можно говорить о каком-то встраивании через DPI или transparent proxy. Это другая интересная задача, впрочем, как вы верно отметили, абсолютно бесполезная вследствие повального использования HTTPS. Поэтому особо хитрые используют для этого captive portal непосредственно при подключении к точке доступа. А, поскольку анонимный доступ к публичному wifi запрещен законодательно, можно посредством captive portal и данных dhcp еще и выудить телефон подключенного пользователя. На особых параноиках не сработает, а вот с остальными не уверен.
Основная цель такой рекламы — получить проходящего мимо клиента. Ну и предлагать определенный товар человеку, который уже сходил за ним в магазин — малоэффективно.
Вы не совсем правильно понимаете. Рандомизация MAC-адресов происходит при сканировании эфира в поисках новых точек доступа, к которым можно подключится. При наличии известной точки доступа рандомизация не используется, устройство работает на своем «родном» MAC-адресе.
Тут я не доктор. Но беглый гуглинг выдал пять штук аналогичных проектов. Особое впечатление произвело как эти ребята бодаются на ЦП.
Увы, у меня не было в тот момент OPI Zero с SPI-флешкой, они, вроде, стали их напаивать только в LTE-инкарнации. Поэтому пришлось MicroSD + Armbian.
Необязательно. В MAC-адресе есть бит — признак локальности сгенерированного адреса. Другой бит отвечает за broadcast-вещание. Возможно, префикс действительно берется из исходного устройства (да, забыл написать, что в серверной инкарнации я импортировал себе справочники производителей и показывал, чье устройство источник адреса).
Очень просто. Рекламная платформа, как правило, знает ваш MAC-адрес (приложения Гугла и Яндекса есть почти на каждом смартфоне, равно как и привязка их к аккаунтам). Вы просто загружаете список адресов в рекламную сеть, они отбирают только те, что им известны, после чего на них можно настроить рекламную компанию. Можно посмотреть в самой первой ссылке на стартап — там у них на сайте все хорошо описано.
У Гугла есть такой интересный патент на этот счет — patents.google.com/patent/US9501777B1/en
Могу объяснить. Я кинул ссылку на статью в небольшой чат разработчиков (стохастически сложившийся еще со времен ЖЖ, да-да, я тоже старый пердун) и коллега в ответ на эту ссылку поделился историей. Я посчитал, что это будет хорошим комментарием, но, поскольку у автора нет аккаунта на Хабре, я ответил с его великодушного разрешения.
Кто знал, что это приведет к таким далеко идущим выводам...
Коллега в чате поделился историей:
У меня в позапрошлом году был офигенный клиент, это ещё когда я брал чистый «кризис».
У клиента в девгруппе две команды, каждая занимается своей частью продукта (условно, бэкофис и сторфронт, т.е. софт работающий над формированием заказа и софт, работающий над исполнением заказа), изредка между собой интегрирующийся.
Команда бэкофиса прям вот совсем в днище ушли: полгода сплошных косяков, собственники грозятся всех уволить, наняли консультанта, после консультанта наняли более другого (меня). Причём вторая команда (сторфронт) работала норм и продолжала работать норм, именно бэкофисная, которая до этого тоже норм работала, стала косячить. Команды в разных офисах сидят, друг на друга привыкли псить.
Причина: стор и бэк это одна система, в ней куча зависимостей, команды в разных офисах, между собой не общались. На сторфронт все время «смотрят» собственники, соответственно у них там новые фичи, идеи и контроль. В ней был мальчик-на-все-руки, такая комбинация из БА, дизайнера и «принеси нам кофе». Вот этот мальчик, незаметно для своей команды, выполнял кучу мелких задач типа «предупредить вторую команду о деплое», «проапдейтиь документацию» и т.п. рутину, вплоть до «внести в жире в тикет всякие номера версий и компоненты». Но код мальчик не писал и в один момент собственники решили его оптимизировать, нафиг уволив. Для команды стора ниче не поменялось, они просто не вносили и не апдейтили доки, а команда бэкофиса оказалась в ситуации, когда релизы стора ломают у них что-то, и это их проблемы, а если их релизы ломают что-то у стора, это опять их проблемы, потому что стор на виду у собственников :)
Опытные разработчики, стаж от 8-10 лет. Ранее, в основном, писали на С/С++ и Python.
Erlang изучается за месяц практически любым разработчиком-полиглотом. Подсадил на него так десяток человек. :)
downloads.lede-project.org/releases/17.01.5/targets/ar71xx/generic/lede-17.01.5-ar71xx-generic-tl-mr3020-v1-squashfs-sysupgrade.bin
А так-то да, придется попрыгать.
Ранее я применял Erlang в таких устройствах для отображения картины проходящего трафика и прототипа сигнализации с ретрансляцией видео с камер и получением показателей с кучи датчиков и детекторов.