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

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

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

    КДПВ: Тепловая карта, построенная алгоритмами Locomizer для KFC

    Недавно издание 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 составлена неверно. Из-за эвристик и неполных матмоделей данные должны быть достаточно большими, чтобы результат получался достоверным.

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

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

    Ижевская часть команды Locomizer. Слева направо: Гена, я, Евгений, Аня
    Вот эти ребята.

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


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


    А без редакторских правок Нади Носковой и Полины Русиновой из команды 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. Ребята довольно заняты, но на интересные и осмысленные вопросы по обработке данных пользаков и ведению базы поёв обязательно ответят в течение нескольких дней.

    С вопросами технического плана рекомендую повременить до финала данной серии статей.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 35

      +2
      Прелестно, прелестно! ))) Прям вспомнил свой предыдущий проект.

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

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


        Хм. Мне кажется, это преувеличение. Не отношу себя к любителям макдака, хотя иногда и посещаю. Но чтобы одновременно «обходить стороной заведения бургер кинг» — это чепуха. Ну то есть, как пример — годится, но на практике нужно такое рассматривать в каждом отдельном случае.
          0
          Да, тут как пример, но в жизни будет так: пользователь пойдет в ТЦ в котором есть макдак, а не в тот где есть бургер кинг. Не сказать, что он будет Burger King обходить стороной, но точно будет держаться ближе к McDonalds.
            +1
            Ну это тоже сильное упрощение :) Скажем, у меня относительно рядом с домом есть три ТЦ, один маленький, и два огромных. Даже в маленьком есть и MD, и BK. Ну то есть, как эвристика это не хуже любой другой, и также как у любой другой тут будет куча случаев, когда она не работает.

            И да, в больших ТЦ как правило фудкорт, и для меня оба этих заведения как правило в пределах 50 метров друг от друга, так что определить их по координатам вообще скорее всего не получится (в здании-то).

            Но как пример эвристики — вполне сгодится. Скажем, мы пытались решить похожую задачу определения координат POI, имея на руках чек из него. Т.е. вы знаете, что вот в такое время человек что-то купил в заведении под названием «АБВГД», и название вам дает скажем Visa. Но вы не знаете, где оно находится. В данном тексте описано, что задача решается путем сбора информации о POI живьем, а мы пытались это определить по соседним точкам «траектории». И все решения, которые тут приходят в голову — чистая эвристика примерно такого же типа, с такими же допущениями.
              0

              Ну, я точно могу сказать, что аудитории macdonalds и бургеркинга практически не пересекаются. Примерно так же, как и зачастую люди пьют либо Кока-Колу, либо Пепси. Почему так? Ну, по совокупности факторов. Это примерно как обсуждать будет ли топ-менеджер заходить перекусывать в непонятную шаурмячную

                0
                Судя по мне — пересекаются. Если надо ребенка быстро накормить — идем, куда ближе от места прогулки.

                P.S. Мы по музеям ходим, так что районы города совсем разные.
            +1
            Ради интереса, как-нибудь выйдите во двор своей многоэтажки, и посмотрите, сколько спутников видит ваш смарт. (Скорее всего, вам потребуется рутованный андроид и/или какой-нибудь платный GPS-трекер.)

            Эээээ. С десяток, причем SNR выше 30. Иногда два десятка. GPS-трекер бесплатный, андроид нерутованный — вся эта информация доступа бог знает с какого древнего уровня SDK из Location API вместе с азимутом и углом возвышения спутника надо горизонтом.
            Телефоны среднего ценового диапазона.
              0
              У меня из здания — почти строго 2/20 (или 0/20). Собственно, один пример ничего не доказывает вообще (кроме того, что рутованный андроид скорее всего не нужен, да).
                +1
                Из здания — да. Но в процитированной фразе речь шла про двор.
                Вот прямо сейчас из квартиры — 4. С хреновым SNR 13-20, и длительным фиксом, да.
                И «в один пример» входят некоторое число устройств на платформе Snapdragon, которые ведут себя схожим образом на протяжении последних 6 лет — Motorola Milestone 2, Highscreen Boost IIse, Xiaomi RedMi 4 Prime, Lenovo Phab 2 Pro, Яндекс.Телефон.
                А если поопрашивать в чатиках — то это подтвердится для большинства девайсов от $200. Я это знаю точно, т.к. на протяжении последних лет играю в location-based игры, и там качество позиционирования очень сильно роляет.

                В общем, вышепроцитированная фраза про спутники — заблуждение.
                0
                У меня двор-колодец, закрытый с трёх сторон. Видно в лучшем случае 1–3 спутника, пока из него не выйдешь.
                  0
                  Питер-стайл? ) тогда да
                    –1
                    Ижевск — маленький Питер :)
                +3
                Раз уж Вы отсылаете читателей к той статье из NYT, то у меня и вопрос про ту же тему: Какой объем статистики по девайсу нужен, чтобы идентифицировать уникального пользователя с надежностью 95%? Понятно, что на больших группах все работает; вопрос: как оно работает на малых группах и насколько малы эти группы?
                Более частные вопросы:

                1) Насколько уникальный профиль создает история перемещений девайса? Типа, вот этот парень ездит всегда из Коньково в Лужники, по пятницам вьет на Савеловской, а по субботам в Железнодорожный на весь день. Сколько таких парней найдется в одной многоэтажке — 1, 10, 50?

                2) Можно ли понять, что вот тот же самый парень (малая группа), которую идентифицировали в вопросе #1, теперь ездит в аэропорт Шереметьево раз в неделю и покидает горд на два дня? Вряд ли таких пользователей в одной многоэтажке будет много, что дает возможность говорить о слежении за девайсом (но не об идентификации пользователя, пока).

                3) Можно ли понять по совпадающим трэкам, что владелец данного девайса на iOS является также владельцем вот того девайса на Android? В смысле, пользователь носит два телефона на работу.

                Давайте для простоты допустим, что: девайс есть смартфон совершеннолетнего жителя дефолт-сити, который работает 5/2 также в Москве, история доступна за год от одного провайдера.

                Спасибо!
                  0
                  Я думаю, вы и сами знаете ответ :) Все в принципе можно, но все с определенными ограничениями. Скажем, я ношу на работу телефон и планшет, но планшет лежит на столе, а телефон в кармане. Сможем ли мы по треку, где этаж известен очень приблизительно, это понять? Ну то есть, это допущения из той же оперы, что и «воруют, кукурузу», описанные прямо тут.
                    +1
                    Я предполагаю ответ и мне было бы интересно его проверить. Ваша компания вложилась в работу с большими массивами данных, но мне интересно Ваше мнение (поскольку Вы явно ближе к данным нужного типа, чем я), каковы были бы возможности технологии, если бы вы потратили сравнимые ресурсы на R&D в области персонального отслеживания девайсов.
                      +1
                      Я не имею отношения к данному посту, поэтому отвечать могу только за свои опыты, которые к тому же закончились полтора года назад.

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

                      Ну то есть, если вы как-то группу заранее выделите — то по ней много чего можно сказать, и эти алгоритмы не слишком сложные. А вот найти в большом множестве треков два совпадающих — это просто вычислительно очень сложно может оказаться.
                        0
                        А, я не понял, что Вы не автор, прошу прощения.
                        Ну, тогда было бы круто услышать мнение начальника транспортного цеха :)
                          +1
                          Ну да. Я просто решал очень похожие задачи немного с другой стороны, и в другом проекте.
                    0
                    1. Очень уникальный. Локация собирается покуда приложенька с картографическим и/или рекламным SDK, её собирающем, выполняется. Если она висит в фоне — то сильно реже. Закрыли или выгрузили приложеньку из фона — всё, трек оборвался. Спустились в метро — SDK послал вас непонятно куда.

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

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

                    Но если накопить объём за год, и составить несколько сотен эвристик, заточенных на частные кейсы, кто-нибудь да найдётся. Но это работа на целый исследовательский институт, как вы понимаете.
                      0
                      1) Понятно, спасибо.

                      2) Не очень понятно, почему «теряет смысл», а не «нет, понять нельзя без допущений»?

                      3) А почему так? Там эвристики настолько сильно лажают, что паттерны не совпадут?

                      Вот это самый неясный момент в статье: почему собрать статистику по 100 человек за 30 дней можно и она будет содержать предсказательную силу, а по 10 людям за 300 дней нельзя…
                        0
                        Чем больше допущений, тем больше false positives. Эвристика по определению штука неточная, она всегда работает в рамках некоей гипотезы.

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

                        Вот смотрите. Берём какой-нибудь микрорайон, из которого ведут две дороги и электричка. Все жители этого микрорайона будут пользоваться только этими двумя дорогами и электричкой, потому что других путей вовне нет. И треки у них всех до ближайшей развязки или ТПУ с пересадками на 95% будут совпадать. Эвристика, основанная на таком совпадении, сматчит вам весь микрорайон, и чем больше времени вы будете брать, тем сильнее будет совпадение, потому что за год шанс уехать в командировку через аэропорт больше людей, чем за месяц, и скорее всего все они выберут один и тот же наиболее короткий маршрут.

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

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

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

                      Данные с трекеров купить вообще нельзя, их никто не продаёт. У Стравы дыра была, отдавали данные кому попало без проверок.
                      0
                      Спасибо за текст, интересно.

                      Не очень понятно — с какой частотой обычный телефон Android пишет координаты юзера? Если человек смотрит в Google Maps, это понятно — тут GPS постоянно запущен, а в других случаях как? Если телефон просто в кармане лежит? Геолокация достаточно затратное для смартфона занятие, и обычно его стараются минимизировать или отключить. Нельзя просто так взять и писать лог GPS постоянно — телефон сядет за полдня, да и Android оповестит юзера раньше, что какая-то программа имеет фоновый доступ к геолокации.

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

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

                      В общем, мутно тут как-то.
                        0
                        Не нужно ничего устанавливать специально.
                        Скорее всего, всё что нужно у вас уже установлено.
                        Разработчики мобильных приложений уже встроили модули мониторинга.
                        Вот такой, например — www.tutela.com

                        Да и сами операторы не прочь купить геоданные у поставщиков — tenders.mts.ru/TenderDescription.aspx?tender_id=4521774

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

                        У вас просто алгоритмы под другое заточены. А вообще, если в датасете действительно есть timestamp, уникальный id девайса и координаты, то зная например из выпусков новостей, что некий политик сегодня был в Кремле, вчера на встрече ветеранов, а позавчера в театре, сопоставить нужный id с пересечением геолокаций в нужное время — тут даже machine learning и мат.моделей не надо, хватит обычных операций с множествами и простых фильтров.
                          0
                          У вас просто алгоритмы под другое заточены.

                          И я это несколько раз повторяю в статье открытым текстом, да.

                          Если вы берёте контекст извне, и заранее знаете, кого искать, задача упрощается, это должно быть очевидно.
                            +1
                            Да, очевидно конечно, но в таком случае непонятно что в статье NY Times вы собираетесь опровергать. То что вы не ищете конкретных людей, не значит что этим не занимается кто-то другой.
                              0
                              А в каком месте я кого-то опровергаю? Нет же, я просто рассказываю о том, какие реальные задачи решаются по коммерческим датасетам, и какие знания из них можно извлечь без внешнего контекста.

                              И откуда мне знать вообще, что там пытается сделать с теми же данными кто-то другой? ¯\_(ツ)_/¯
                          +1

                          Иногда навигацией занимаюсь. Могу сообщить о закольцованных треках по кругу. Наблюдал такую катину на смартфоне Samsung J 3. Приложение спотривный трекер Strava. Закольцованные виртуальные треки не настоящие возникали в случаях когда я забывал выключить на телефоне gps при этом прибор находился в многоэтажке на высоте. Примерно в метре от окна. При нечетком сигнале gps, периодически пропадающем, прибор рисует виртуальные круги. Это не чёткий сигнал приёмника. Ошибочная выборка. Сообщающая что прибор находится или в подвале или на этаже недалеко от окна.

                            0
                            Ради интереса, как-нибудь выйдите во двор своей многоэтажки, и посмотрите, сколько спутников видит ваш смарт. (Скорее всего, вам потребуется рутованный андроид и/или какой-нибудь платный GPS-трекер.)

                            Не потребуется.
                            play.google.com/store/apps/details?id=com.binarytoys.ulysse
                              0
                              На новых девайсах конкретно эта приложенька уже не работает (сколько уж лет не обновлялась). Вообще, в Play Store подобного вагон и маленькая тележка, но бесплатные поделки в основном либо такие же заброшенные, либо просто мусорные с кучей странных разрешений в манифесте.
                              0
                              Не обязательно данные могут быть из приложения, установленного на UE.

                              Операторы могут собирают трейсы, например, с eNodeB.
                              В этих трейсах нет координат, но есть много другой информации.
                              Трейсы экспортируются в GEO приложение, которое по трейсам определяет координаты и что-то ещё.
                              И вот уже эти данные идут к покупателю.
                                0
                                А вот классификатор по типам движения, работающий по принципу скользящего окна и машины состояний (методом проб и ошибок мы потратили на его разработку в сумме почти полгода), изощрён настолько, что называть его «фильтром» уже некорректно.

                                Вот про это будет особенно интересно почитать.
                                  +2
                                  Про GNSS (GPS) довольно много неточностей.

                                  Assisted GPS (AGPS) — это технология доставки альманахов и эфемерид через интернет. Альманахи и эфемериды — это данные для расчета координат спутника. Альманахи неточные, но могут служить месяц и более, транслируются с любого спутника. Эфемериды точные, могут служить 4 часа (для GPS), но транслируются только с того спутника, для которого предназначены.

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

                                  А засада тут вот в чем. Для приема эфемерид обычно используется когерентный прием. А для когерентного приёма нужен уровень сигнал-шум от 30 dB и выше. То есть всякие спутники с S/N 25 при этом игнорируются — с них не принять эфемериды без ошибок, а значит — их не удается пустить в решение.

                                  Поэтому AGPS — это прежде всего средство ускорения старта (можно стартовать за 1 секунду вместо 35 для обычного способа). А во-вторую очередь — возможность использования некогерентного приема с S/N от 25.

                                  Или отражать под непредсказуемым углом, сдвигать фазу, и так далее.
                                  Гм, чем вам мешает сдвиг фазы? Сдвиг фазы на 180 градусов — это разница в 9.5 сантиметров. Она сильно ниже шума кода (он в районе ± трех метров для дешевых приемников). И вообще, где вы видели, чтобы стена дома сдвигала фазу? Ну или «отражала под непредсказуемым углом»? 10 лет вожусь с GNSS, но пока что никаких эффектов фазированной решетки от реальных домов не видел.

                                  для нормальной точности нужно иметь 4 спутника в прямой видимости одновременно, лучше больше.
                                  Для решения без высоты достаточно 3х спутников одной системы. Для решения с высотой — четырёх одной системы, и 3+N для N систем. Это будет весьма неточное решение. Для хоть какой-то точности — ну хотя 5+N, то есть 3 GPS+3 ГЛОНАСС. Ну а хорошее решение — 8+N и лучше. Обычно видим 18+ спутников (GPS+ГЛОНАСС), использует 10-12 лучших.

                                  Ради интереса, как-нибудь выйдите во двор своей многоэтажки, и посмотрите, сколько спутников видит ваш смарт.
                                  Вопрос не в том, сколько он видит, а в том, сколько спутников с большим S/N. Мы, скажем, стараемся в высокоточку брать с S/N от 35. Обычный приемник берет от 30, а мобильник может и от 25.

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

                                  сделаны на гораздо более подходящей элементной базе, с хорошими усилителями и большими антеннами
                                  По секрету — в большой антенне больше всего воздуха. Там маленький кристалл керамики + подстилающая (экран) для предотвращения приема отраженного сигнала снизу. Любая маленькая антенна на крыше автомобиля будет принимать отлично. Скорее уж в мобильниках экономят на ПАВ-фильтре для ухода от внеполосной помехи. Элементная база в мобильниках продвинутая, что-то вроде 22нм vs 90нм в обычных приемниках. Думаю что основная экономия (после ПАВ-фильтра) — в качестве и числе разрядов АЦП на стыке аналоговой и цифровой части.

                                  P.S. Если в датасете есть количество спутников, принятых в решение — сделайте фильтр по нему. Скорее всего будет приличная корреляция с точностью решения.

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

                                  Самое читаемое