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

 

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

Автор: admin от 26-01-2020, 20:11, посмотрело: 77

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




  • Как мы за два года ускорили расчёт тепловой карты в 20000 раз (послезавтра)

  • Открываем One Ring — инструментарий для гибкой конфигурации сложных процессов обработки данных на Spark в облаке (скоро)

[/quote]

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



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




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



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



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

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 бессмысленно, потому что высота над уровнем моря плохо переводится в номера этажей зданий, а пролетающих на самолёте можно отсеять и без него (но об этом разговор пойдёт чуть позже).



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



Так что из контекста имеется только пользовательская GDPR (он стабильный, между разными месячными дампами одно и то же устройство будет представлено одинаково).[/quote]

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



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



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



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



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



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



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



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



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



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




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



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




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



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



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



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

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

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



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



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



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



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



— Надо найти всех пользователей из Усть-Пердуйска, которые любят воровать свежую кукурузу с колхозного поля в конце августа.

— Простите?

— Ну, во-он то кукурузное поле. Август прошлого года.

— Мы про «воровать»…

— Определите как-нибудь, вы же специалисты!

— Ок. Ещё что-нибудь?

— Они должны курить Pall Mall.

— (про себя) Почему именно Pall Mall… хотя пофиг, нас это не интересует. Если дадут явки, так ведь найдём :D (вслух, твёрдо) Только если дадите инфу, где они его покупают.




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



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



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




  • проживающие в геофенсе / работающие в геофенсе,

  • распределение по уровню дохода домохозяйств,

  • автомобилисты,

  • любители посещать рестораны и кафе,

  • шопоголики,

  • спортивные болельщики,

  • мамочки с маленькими детьми,

  • командировочные,

  • иностранные туристы…



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



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



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



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



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



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





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



Но это вырожденный случай. А стандартные случаи рассчитываются по базе 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 августа? Он (или она) лечил зубы, заключал договор КАСКО, или под конец месяца купил абонемент в спортзал? Контекста у нас никакого нет, и можно было бы посмотреть данные по другим месяцам, чтобы хотя бы выявить абонемент в спортзал по регулярным посещениям, но часто заказ бывает строго на какой-нибудь один только август без сентября, и всё. Мы делаем допущение, что с равной вероятностью верны все три варианта, и засчитываем некий @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. Ребята довольно заняты, но на интересные и осмысленные вопросы по обработке данных пользаков и ведению базы поёв обязательно ответят в течение нескольких дней.



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

    Источник: Хабр / Интересные публикации

    Категория: Информационная безопасность

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

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *