[кейс Locomizer] Какие знания можно на самом деле извлечь из анонимизированного датасета с координатами пользователей

Данная статья является частью серии «Кейс Locomizer», см. также

• Как за два с половиной года ускорить расчёт тепловой карты в 20 000 раз
• Открываем One Ring — инструментарий для гибкой конфигурации сложных процессов обработки данных на Spark в облаке

Здравствуйте.



Недавно издание The New York Times опубликовало претендующую на сенсационность статью о том, как отследить пользователей по коммерчески доступным анонимизированным датасетам с координатами их перемещений, и здесь, на Хабре её вольный перевод с дополнениями от неизвестного корпоративного копирайтера собрал большое количество комментариев разной степени обеспокоенности.

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

Но есть и доля истины по ту сторону чёрного зеркала, возможно, куда большая. Или интересная.

Так вот, давайте я подробно расскажу, как мы следим (и следим ли мы вообще в смысле шпионажа) за вами (и за вами ли лично), и что за знания о пользователе можно получать, не обладая ровно никаким контекстом, кроме координат его перемещений, собранных с мобильных абонентских терминалов. Без излишнего журнализма и хайпожорства, с точки зрения технического специалиста, который обладает некоторым реальным опытом решения невыдуманных задач для невыдуманных заказчиков, среди которых не только различные рекламные агентства, Coca-Cola и Guinness, но и, к примеру, ООН. И с огоньком.

Более того! В конце данной серии статей я хочу поделиться инструментарием, который мы разрабатывали в течении двух с половиной лет, чтобы вы самостоятельно могли заняться исследованиями, если купите (ну или достанете) подходящий датасет. До сих пор, насколько мне известно, никто не выкладывал в открытый доступ таких инструментов. По крайней мере, когда два года назад мы искали, ничего не нашлось, и пришлось писать самим. Путь к быстрым расчётам был труден и долог, о нём будет вторая часть.

Итак. Оглавление данного анамнеза:

• Анатомия анонимизированного датасета
• Проблемы точности координат в средней полосе
• Эвристики очистки данных от шума и мусора
• Да что за «знания» такие?
• Points of Interest
• Проблемы извлечения знаний
• Скоринг пользовательских интересов

Бонус:

• Благодарности и краткий FAQ

Анатомия анонимизированного датасета

Возьмём коммерческого поставщика Tamoco и посмотрим, какие файлы он отгружает. Например, вот кусочек реального датасета по стране Соединённое Королевство Великобритании и Северной Ирландии, дата — 4 декабря 2019 года:

sdk_ts,device_id,latitude,longitude,accuracy,country,device_type,device_make,device_model,device_language,device_os,device_os_version,device_hw_version,device_screen_width,device_screen_height,device_battery,altitude,inv_id,trigger_type,app_account_id
1575390011,d75f97488c430502046fdb4ebfcc0ffd,51.516766,-0.1279744,10,GB,,,SM-G950W,en-CA,,,,0,0,0,0,4260328,GEO_FENCE_ENTER,115
1575414847,d75f97488c430502046fdb4ebfcc0ffd,51.516766,-0.1279821,10,GB,,,SM-G950W,en-CA,,,,0,0,0,0,4260328,GEO_FENCE_ENTER,115
1575424373,7e3323b382ddaafb9f774af95631cc44,51.51379,-0.0999953,7.6,GB,,,SM-G925F,en-GB,,,,0,0,0,0,31572218,GEO_FENCE_ENTER,115
1575417663,90165d78553fb37b0d62500733b39d11,53.724384,-6.879851,11,IE,aaid,,SM-A605FN,,android,9,,0,0,0,138,0,UNKNOWN_TRIGGER,229
1575417977,b6f2375275a21c40e03e4c6ea9ea4da0,52.75558,-7.9915,5,IE,idfa,,iPhone7.1,,ios,12.4.3,,0,0,0,122,0,UNKNOWN_TRIGGER,229

Вот что мы видим в полях этого датасета:

• sdk_ts — штамп времени в Unix Epoch,
• device_id — анонимизированный ID устройства (мобильного абонентского терминала, такого как смартфон или планшет),
• latitude/longitude — географические координаты,
• accuracy — горизонтальная точность координат, метры,
• country — страна,
• остальные поля — мусор, не несущий особой смысловой нагрузки.

Почему сразу «мусор»?

К сожалению, такое полезное, казалось бы, поле altitude бессмысленно, потому что высота над уровнем моря плохо переводится в номера этажей зданий, а пролетающих на самолёте можно отсеять и без него (но об этом разговор пойдёт чуть позже).

В отличие от журналистов из указанных в начале статей, у нас нет никакого дополнительного контекста о пользователях, и мы не делаем голословных предположений «по умолчанию», типа «был в Пентагоне — значит, работает в Пентагоне». Мы также не фейсбук какой-нибудь, который знает о вас всё, что вы сами о себе рассказали (а средний пользователь рассказывает о себе очень дофига), плюс весь ваш социальный граф. Мы купили сырые данные, и мы им — не верим.

Так что из контекста имеется только пользовательская локаль — она может помочь определить иностранных туристов, но это не точно.

Ну, также помимо координат и времени есть ещё модель телефона — теоретически она открывает возможность по отдельности обрабатывать владельцев различных устройств на iOS и Andriod. В комментариях к статье из того корпоративного блога кое-кто предполагал заняться гоп-стопом с отжимом особо дорогих мобил, отследив их по геолокации… Хм, вы знаете, но такая бизнес-модель нормальным конторам, которые могут себе позволить купить данные, будет несколько невыгодна :)

Важно понимать, что данные от поставщика приходят сырые, то есть, взятые с устройств, и никаким образом не обработанные, кроме, возможно, замены реального device_id на хеш по требованиям GDPR (он стабильный, между разными месячными дампами одно и то же устройство будет представлено одинаково).

У каждого поставщика набор и формат полей свой, но координаты, точность, время, и device_id есть у всех, а Tamoco я взял для примера как самый среднестатистический. И что можно предположить о пользователе, глядя на строку сырых данных, если не заниматься инсинуациями и гаданием на кофейной гуще?

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

Проблемы точности координат в средней полосе

GPS — офигенная штука. Недавно была отличная статья о её возможностях, обязательно прочитайте, если ещё не.

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

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

Во-вторых, городская среда — это очень, очень сильно пересечённая местность. Подумайте сами, — если откинуть американскую одноэтажную субурбию, любая современная городская улица представляет собой глубокий овраг с очень крутыми стенами, не то, что горизонта не видно, так и кусок неба над головой виден весьма небольшой. А для нормальной точности нужно иметь 4 спутника в прямой видимости одновременно, лучше больше. Ради интереса, как-нибудь выйдите во двор своей многоэтажки, и посмотрите, сколько спутников видит ваш смарт. (Скорее всего, вам потребуется рутованный андроид и/или какой-нибудь платный GPS-трекер.)

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

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

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

В-шестых, автомобили вокруг тоже сделаны из металла.

В-седьмых, глубоко внутри здания GPS обычно не ловит, а уж в метро — тем более.



Все эти факторы делают GPS в городе крайне ненадёжным, и производителям мобильных абонентских терминалов (а также поставщикам location services для мобильных операционок) приходится выкручиваться с различными Assisted GPS технологиями.

Самыми распространёнными являются триангуляция по базовым станциями сотовой связи и сетям WiFi (и даже Bluetooth).

Все эти смешные гугловые и яндексовские автомобильчики с камерами, снимающие панорамы для street view, на самом деле в основном собирают информацию о CellID, именах сетей и уровнях сигнала роутеров, а фотки — так, попутное баловство. Кроме них, массово собирает эту информацию HERE Maps, — а в развитых странах Apple, и ещё с десяток контор поменьше. Ну и те библиотеки, которые зашиты в мобильных приложениях, и поставляют данные о геолокации, постоянно делают ровно то же самое, just for instance, как и почти любой виджет, показывающий карту.

Основной вопрос тут в точности.

В отличие от GPS, LBS с ней всё плохо. Метров 20 для LTE в самом идеальном случае (в общем же — до пары километров), а что касается Wi-Fi, то тут диаграммы направленности роутеров, протяжённые меш-сети с репитерами, и сами физические характеристики сигнала частот 2.4 и 5 ГГц снижают достоверность вне помещений до 150 метров и более.

А это уже постоянные скачки пользователя на другую сторону улицы или перекрёстка, а то и вовсе за полквартала от того места, где он есть на самом деле — если, например, роутер стоит на 5 этаже, а вокруг ущелье из высоток, то сигнал не будет ловиться у подъезда, зато прекрасно поймается в конце этого ущелья.

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

Москва, Кремль, небольшой датасет от ноября 2019 года

В отмеченной на иллюстрации маркером точке с координатами (55.75270; 37.61720) находится сразу 208776 сигналов. Это не определившиеся с должной точностью точки, попавшие в «центр» соответствующего геофенса Сенатской площади, он же «центр» Кремля.

Кроме неё, также следующие координаты слишком уж «горячие»:

(55.75222; 37.61556) 193
(55.75111; 37.61537)  53
(55.74988; 37.61701)  45
(55.74988; 37.61700)  36

А во всех остальных точках c этой картинки — ровно по одному сигналу.

Хуже того, такие «центры районов» в каждой картографической подложке разные, и если от жилых зданий Apple и Google стараются их перемещать (в Штатах были нехорошие прецеденты с судебными исками), то сдвигом точки от нежилого здания никто заморачиваться не будет.

Определение положения внутри большого торгового центра площадью тысячи квадратных метров — отдельная боль. GPS не поймать, сотовая сеть на весь центр обычно одна и та же, и чтобы понять, какой из сотни магазинов посетил пользователь, надо ещё и этаж каким-то образом узнать. Good luck with that.

Собственно, если даже и есть поле altitude, то не всегда понятно, по какому геоиду оно посчитано (не обязательно WGS84), да и фиг его знает, какой высоты этажи в здании, чтобы посчитать самим. И сколько их? В азиатских странах из-за суеверий, например, не бывает не только 13-х, но и 4-х этажей. Такую информацию очень сложно найти, и при массовой обработке трудозатраты никогда не окупятся.

Потому, как бы нам того ни не хотелось, к сырым датасетам приходится применять изощрённые

Эвристики очистки данных от шума и мусора

Но для начала расскажу, кто наш пациент.

Наш пациент анонимен, и имя ему — тысячи, а лучше, миллионы, ибо наши заказчики платят за статистику, собранную en masse. Конкретный человек не делает погоды для Coca-Cola, даже если он купит грузовик газировки разом. Коммерсантам нужны общие паттерны и тенденции, а также картина того, как они устанавливаются с течением времени. Владельцам сетей лондонских пабов важно знать, в какую погоду и время суток у них будет поток посетителей в пабах, расположенных на углу у станции подземки, а в какое — рядом с кинотеатрами, и им совершенно по барабану, входит ли в эти выборки из тысяч анонимов некий Vassily Poupkine из Рязани, или нет.

Главное, чтобы их было много, и были они релевантны. Мы работаем с популяциями.

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

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

И всё это означает, что нам нужно иметь треки, качественные по следующим параметрам:

• без низкой точности координат,

• без глитчей геолокации:
— телепортов на полквартала в сторону и обратно,
— скачков через дорогу,
— вне «горячих точек»,

• классифицированные по типу перемещения:
— пешком,
— на машине,
— в автобусе,
— на велике или скутере,
— на Синкансене или на самолёте…

• без случайно затесавшихся в геофенсе нецелевых пользаков,

• без обрывочных треков, бесконечно нарезающих круги по маленькой площади (откуда они берутся, не совсем понятно, но их достаточно, чтобы выделить в отдельный проблемный класс, — наиболее вероятно, что это всякие замки с GSM-сигнализацией или радионяни — они тоже собирают геолокацию).

И если самое первое условие тривиально — проитерироваться по датасету и выкинуть все точки, у которых поле accuracy < 10 метров, то с остальными просто ворох проблем.

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

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

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

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

Мы набираем большую статистику, вручную находим в ней нежелательные паттерны, формулируем задачу, отлаживаем в интерактивном режиме, и пишем отдельную обработку, а затем встраиваем её в процесс обработки датасета — в том случае, если уверены, что он требует такой подготовки.

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

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

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

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

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

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

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

Да что за «знания» такие?

Отличный вопрос.

— Надо найти всех пользователей из Усть-Пердуйска, которые любят воровать свежую кукурузу с колхозного поля в конце августа.
— Простите?
— Ну, во-он то кукурузное поле. Август прошлого года.
— Мы про «воровать»…
— Определите как-нибудь, вы же специалисты!
— Ок. Ещё что-нибудь?
— Они должны курить Pall Mall.
— (про себя) Почему именно Pall Mall… хотя пофиг, нас это не интересует. Если дадут явки, так ведь найдём :D (вслух, твёрдо) Только если дадите инфу, где они его покупают.

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

Но если есть некоторая матмодель, то применяя к большому набору обогащённых (то есть, качественных, без аномалий) данных статистические методы, вполне можно выцепить подходящую популяцию. Оценки все будут вероятностные. Мы не можем однозначно утверждать, что один пользователь точно живёт в Усть-Пердуйске, и ворует кукурузу каждый август, но если таковых наберётся хотя бы тысяча, мы таких найдём с 90% вероятности. Возможно, сможем и курильщиков, но относительно марки сигарет скорее всего потребуется дополнительный контекст, и если его предоставит заказчик, найдём среди них нужных — но точность не гарантируем.

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

• проживающие в геофенсе / работающие в геофенсе,
• распределение по уровню дохода домохозяйств,
• автомобилисты,
• любители посещать рестораны и кафе,
• шопоголики,
• спортивные болельщики,
• мамочки с маленькими детьми,
• командировочные,
• иностранные туристы…

Для каждой из категорий (всего их пара тысяч) процесс обработки строится по шаблону из предопределённых операций с кучей настроек, и параметризуется в зависимости от конкретных требований заказчика.

Операции разрабатываются следующим образом: data scientist пишет матмодель в виде white paper, затем она программируются и отлаживаются на эталонных наборах данных на Python, и в конце собирается обработка на Spark (мы пишем на Java, но можно и на Scala), которую я оптимизирую. (Ага, примерно как в известном меме про рисование совы, впрочем, подробнее будет во второй части моего повествования.)

Сами шаблоны для конкретных проектов конкретных заказчиков собирает специально обученный человек — data analyst. Хотите задать ему вопрос — напишите keskiy в комментах, и Гена вам ответит. Он же, кстати, подготавливает конечное визуальное представление в виде тепловой карты или большой красивой Excel-таблицы, потому что заказчики, как правило, плохо понимают многомегабайтные портянки из цифр.

Когда шаблон составлен, датасет загружается в S3 на Amazon Web Services, и при помощи магии (которую я подробно опишу в третьей статье данного цикла), запускается его обработка в сервисе EMR.

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

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

Я сам однажды непреднамеренно нагрел полигон на тепловой карте.

Дело было так: мисклик на рекламу в браузере. Оказалось, ткнул на кружевное женское бельё, и попал в магазин с аббревиатурой WB, но не Warner Bros., а с фиолетовыми буквами. Ну а что, подумал я. Смотреть на фотки девушек в красивом нижнем белье мне нравится.

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

А потом в соседнем доме открылся пункт выдачи этого интернет-магазина, и я поставил адблокер.

Эвристика — шутка такая, её можно обмануть. Результат будет анекдотическим. «Пользователи, которые активно интересуются женским бельём в интернет-магазинах, кучкуются тут.» Ну-ну.

Но это вырожденный случай. А стандартные случаи рассчитываются по базе POI.

Points of Interest

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

Как я уже сказал, у нас тысячи категорий, к которым может относиться то или иное интересное в плане посещения место. Точнее, дерево категорий. Взять «77 кафе и рестораны»:

• 77-1 кафе
• 77-8 рестораны
 o 77-8-6 сетевые рестораны быстрого питания
   77-8-6-90 McDonalds
    • 77-8-6-90-1 MacAuto
   77-8-6-91 Burger King
   77-8-6-92 Pasta Hut

— ну и так далее.

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

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

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

Если у вас вдруг есть интерес по ведению базы POI, можете поспрашивать в комментариях координатора проекта Евгения mitra_kun.

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

Проблемы извлечения знаний

Можно попробовать пойти инновационным методом журналистов из The New York Times — «был в Пентагоне в рабочее время, значит, работник Пентагона». Но данный путь полон различных импликаций.

Что есть «рабочее время»? Я уже упоминал о неправильности расхожего представления, что рабочий график 5/2 подходит всем, но ведь и 8-часовой рабочий день в границах с 9 до 18 тоже верен только для офисного планктона. Это, в лучшем случае, даёт покрытие где-то половины целевой популяции (наша эмпирическая оценка, выведенная из практики). А помимо упомянутых графиков «два дня через день» бывают и другие, а также ещё различные смены типа утренней и ночной, где рабочие часы соответствуют времени сна типичного представителя популяции.

Ситуация в даунтаунах крупных городов, таких как Лондон, Нью-Йорк, или Токио ещё интереснее: там много зданий смешанного типа с офисами, отелями, и апартаментами, и разделить по-простому части популяций, которые в таких кварталах «живут» (то есть, спят — в ночное время) и «работают» (то есть, находятся в дневное время с, возможно, перерывом на обед) довольно сложно. А дополнительного контекста у нас, как я уже неоднократно подчёркивал, нет. Только координаты и время.

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

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

Ну и, многоэтажные локации. В одном и том же офиснике на разных этажах могут располагаться POI из целевых для одного проекта категорий. Например, стоматологический кабинет, страховая компания, тренажёрка. И в какую категорию засчитывать двухчасовой визит какого-нибудь пользака, если он произошёл, допустим, 29 августа? Он (или она) лечил зубы, заключал договор КАСКО, или под конец месяца купил абонемент в спортзал? Контекста у нас никакого нет, и можно было бы посмотреть данные по другим месяцам, чтобы хотя бы выявить абонемент в спортзал по регулярным посещениям, но часто заказ бывает строго на какой-нибудь один только август без сентября, и всё. Мы делаем допущение, что с равной вероятностью верны все три варианта, и засчитываем некий скор по каждой из этих категорий.

Скоринг пользовательских интересов

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

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

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

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

Или же — ничего путного не получается, если датасет слишком мал, зашумлён, неточен, или база POI составлена неверно. Из-за эвристик и неполных матмоделей данные должны быть достаточно большими, чтобы результат получался достоверным.

Но большие данные — это на самом деле не про размер.

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


Вот эти ребята.

Благодарности и краткий FAQ

Без фидбэка замечательных коллег — инженеров по большим данным эта статья не получилась бы настолько понятной:

• Павел @ajtkulov
• Григорий pomadchin
• Андрей fall_out_bug Жуков

А без редакторских правок Нади Носковой и Полины Русиновой из команды HUDWAY она не вышла бы настолько легко читаемой. Спасибо!

Теперь краткий FAQ по вопросам рецензентов.

Q. Сколько точек за час/день/минуту есть у «среднего» человека? То есть в целом мы можем сгруппировать по device_id и понять где человек находился в течение дня? Можно ли склеить данные непрерывно за неделю?
A. Ярко выраженного среднего нет, точек может быть от одной до миллионов (проблема «длинного хвоста»; мы убираем пользаков с количеством точек под 5-й и за 95-й персентилью), это сильно зависит от поставщика. Сгруппировать можно, склеить тоже, но полученное облако точек не обладает закономерностями, очевидными «на глаз», это просто хаотически накиданное на карту облако. После обогащения уже видны траектории, но они обычно рвутся в самых неожиданных местах и не сильно помогают.

Q. Можно ли джойнить семьи? Что 2-3 устройства ходят вместе в течение нескольких выходных? Отсечь от соседей?
A. Сомнительно. Вряд ли у членов семьи идентичный набор приложений на абонентских терминалах, и вряд ли паттерны использования полностью совпадут. До сих пор у нас такой задачи не было, но попробовать можно. Если нам кто-нибудь закажет такое исследование, конечно, бесплатно тратить время на проверку гипотезы мы не можем.

Q. С точки зрения бизнеса, есть ли возможность таргетировать конкретных клиентов? Как? Есть только какой-то device_id, но очевидно мы не знаем ни номер сотового, ни почты. Только если этот пользователь снова где-то пройдет мимо с тем же device_id? Он статический? Либо что-то типа finger_print и может меняться от провайдера данных?
A. Провайдер назначает device_id, и это не то, что видно, например, в настройках телефона, то есть, имеет место двойная анонимизация. Никаких данных помимо того, что расписано в анатомии датасета, у нас нет. Внутри провайдера он остаётся одинаковым для одного устройства, и можно склеивать месячные датасеты, пользак с большой вероятностью останется тем же самым.

Q. Провайдер данных, пояснить подробнее. То есть это не сотовый оператор по вышкам, но «нечто запущенное на телефоне» что в фоне собирает локации и потом пачкой куда-то сливает? Если телефон старый, без интернета, включенного блютуза — соберут ли кто-то такие данные? Если я на трассе на заправке, нигде вайфая нет, то можно ли собрать инфу?
A. Это та же самая библиотека, что показывает тебе рекламу в твоих приложениях, или является его частью, такой как показ мест на карте. Работает на твоём телефоне, если ты разрешил приложениям собирать геолокацию (или это разрешение прописано у них в манифесте). Информация собирается непрерывно, пока приложение работает в фоне, при доступности сети накопленная информация отсылается пакетом в облако провайдера рекламной сети или картографического сервиса, а оттуда уже забирается агрегаторами.

Q. Чуть подробнее про провайдеров данных ещё. Получается, их более одного. Они все равно собирают только часть потока, 10/20/40/70%? Они как-то разбиты по территории? Могут ли пересекаться по времени/локации, по сотовому оператору, еще чему-то? Или только тупо количества можем отвечать, никакого таргетинга?
A. Да, их много, но про доли мы точно не знаем. У кого-то лучше по одной стране, у кого-то — по другой. Заказчики обычно сами говорят, чьи данные они хотят обработать. Склеить пользаков в датасетах разных поставщиков по одному и тому же региону за один и тот же промежуток времени у нас достоверно не получилось. Таргетинг у всех поставщиков одинаковый — по геофенсу региона. Страна, префектура, город, и т.п., но пересечений между ними не заметно.

Если у вас есть ещё вопросы, не стесняйтесь их задавать в комментах Гене keskiy и Евгению mitra_kun. Ребята довольно заняты, но на интересные и осмысленные вопросы по обработке данных пользаков и ведению базы поёв обязательно ответят в течение нескольких дней.

С вопросами технического плана рекомендую повременить до финала данной серии статей.