Интернет вещей в маркетинге

Маячки iBeacon (и схожие, например Google Eddystone). Для работы iBeacon и взаимодействия с покупателями необходимо наличия у последнего мобильного приложения, с которым будет взаимодействовать датчик[]. iBeacon способен передавать данные в приложение, которое использует их для работы внутри приложения или показа push-уведомлений даже когда приложение не используется. Радиус действия и определения положения покупателя- от 15-20 сантиметров до 30-40 или даже 60-70 метров в зависимости от производителя и типа устройства. Количество датчиков, необходимых для работы системы в розничном магазине, сложно обозначить точно в связи с недостаточным количеством внедренных решений, в особенности в России, и недоступностью данных о количестве датчиков в готовых зарубежных кейсах. Можно предположить, что для рассылки предложений или информации для каждого отдела или прилавка магазина нужен как минимум один датчик. В небольшом продуктовом магазине (типа Магнита, помещение от 250 до 1000 м2) может присутствовать больше 20 отделов, в брендированных магазинах все более индивидуально.

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

2. Анализ данных

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

Как показано в таблице 2, большинство популярных облачных платформ имеют собственные инструменты анализа данных и облачные сервисы для хранения данных[38-43].Далее рассмотрены решения для анализа данных, которые предоставляют компании или с которыми предлагают интегрировать платформы интернета вещей, и обзор алгоритмов и технологий, которые необходимы для обеспечения функционала системы (+ обозначает наличие API к технологии, тильда (~) означает, что технология не представлена в полной мере. Как видно, почти все решения обеспечивают необходимый функционал для анализа данных.

Таблица 2 сравнение облачных систем аналитики

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

3. Хранение данных

Для дальнейшей обработки данных необходимо хранить как структурированную информацию (показатели сенсоров, данные геолокации с телефона или маячков), так и неструктурированную информацию (видео, изображения, для распознавания речи - либо готовые выработанные тексты, либо сами аудио файлы). При больших масштабах компании также необходимо использовать устройства для хранения и передачи больших объемов данных. IT вендоры и поставщики платформ, представленные выше (кроме открытой платформы Kaa), предоставляют все необходимые опции для хранения и передачи данных, в том числе для хранения и передачи терабайт и петабайт данных (а также собственные устройства для хранения терабайт данных у AWS).

4. Интеграция с CRM системами

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

· Создание нового клиента (карточки клиента) или потенциального пользователя (почта, история (посещений, история покупок, история взаимодействия (сообщений) и состояние маркетинговой активности), предпочтения и интересы клиента, род деятельности, сегмент, приоритетность, тип клиента (потенциальный, активный, пассивный), тип продаж по клиенту, оценка лояльности, оценка удовлетворенности)

· Изменение или удаление данных старого клиента

Существует несколько возможностей интеграции с CRM системами в зависимости от типа систем[50]:

· Облачные CRM с API

· CRM с другими встроенными возможностями интеграции

· Системы с SDK

· CRM с открытым кодом

Хотя API и является наиболее приоритетным способом интеграции модуля с CRM, такая возможность существует не у всех систем. Кроме того, часто они могут содержать лишь часть доступного функционала. Таким образом, интеграция с CRM системами будет происходить сложнее, чем с платформами IoT.

5. Интеграция с социальными сетями

Многие системы CRM реализуют возможность подключения к профилю клиента данных из социальных сетей. Тем не менее, эта возможность является ключевой для взаимодействия с клиентом и определения его интересов в реальном времени. Если CRM не реализует такое взаимодействие с социальными сетями, тогда необходимо подключать данные из основных социальных сетей (facebook, twitter, vk.com) напрямую. Большинство данных можно получить с помощью API, которые наиболее популярные соц.-сети разработали специально для таких целей.

6. Интеграция с мобильным приложением клиента

Приложение для офлайн-ритейла должно осуществлять несколько функций:

· Высвечивания персональных предложений

· Взаимодействие с маячками

· Отслеживание геолокации смартфона

· Коммуникация с персоналом и техподдержкой

· Дополнительный функционал - навигация в магазине

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

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

7. Интеграция с приложениями техподдержки и смартфонами консультантов

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

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

Usability, удобство использования

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

Reliability, надежность

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

· При распознавании лица средняя точность составляет около 90%, в затемнённых помещениях - от 50 до 90%, при использовании разных аппаратов для съемки - 80%, при использовании изображений, сделанных с разницей в год, точность распознавания составляет примерно 50% [39]

· Распознавание жестов - современные алгоритмы позволяют достигать точности в 90%

· Распознавание голоса - в среднем от 70% до 90% в помещении

· Точность рекомендательные системы сложно оценить до непосредственного использования, тем более что примеров и каких-либо стандартов для офлайн рекомендательных систем в данные момент нет. Стоит отметить, что наряду с непосредственно точностью у рекомендательных систем существует множество других параметров, по которым можно и нужно оценивать ее эффективность[51].

Доступность. Система должна быть непрерывно доступна для связи с умными вещами вне магазина, CRM и всеми другими системами, кроме как для доступа к системам внутри магазина (видеонаблюдение, датчики iBeacon, ценники, экраны) - они будут активно работать только во время работы магазина.

Performance, производительность

Мощность.

По данным технической документации устройств категории Edge computing компании HP, ее устройства могут осуществлять распознавание в 1-2 потоков видео при 2-х ядрах и вычислительной памяти в 8GB и до 40 потоков при оперативной памяти в 4x128 GB и 4х16 ядрах[49]. Примерно столько же вычислительной мощности необходимо для обработки данных на удаленном сервере. Таким образом, для обработки потокового видео с одного магазина может потребоваться до от 216 до 512 GB оперативной памятидля 20-40 камер.

Отзывчивость. Разные датчики при разных сценариях требуют разного уровня отзывчивости. Так, 1000 электронных ценников могут обновляться в течении 10 минут при использовании одной станции доступа, и до 2 секунд индивидуально. Отображаемые на их дисплеях цены могут обновляться раз в несколько часов, при проведении акций, зависящих от времени суток, раз в несколько дней, при проведении еженедельных или ежедневных акций, а при индивидуальных предложениях - раз в несколько секунд. Маячки iBeacon работают в постоянном режиме. В целом данные о состоянии устройств передаются раз в 30 секунд, а специальные сообщения на основе правил могут передаваться чаще.

Масштабируемость

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

Пропускная Способность

Основные нюансы пропускной способности происходят при обработке видео данных. Для обработки данных с 25 камер c частотой 25-30 к/с и кодека M-JPEG необходимо обеспечить скорость передачи данных в 25х1,5 Мб/с, то есть 37 Мб/с. Передача обычных текстовых сообщений интернета вещей потребует еще 1-2 Мб скорости. Точных данных на этот счет в технических описаниях компаний не представлено.

Supportability, поддерживаемость

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

Зависимость от платформ. При использовании готовых API вместо библиотек и SDK для разработчиков, система становится мало зависимой от платформ, таким образом поскольку большинство систем интернета вещей и инструментов аналитики, используют API для подключения, система слабо зависит от конкретных решений. Тем не менее, как уже говорилось, не у всех CRM систем существуют API и готовые инструменты для интеграции, таким образом при отсутствии таких в CRM, системе понадобится дополнительная интеграция, что сделает ее зависимой от конкретной платформы CRM.Кроме того, система сильно зависит от приложений, которые компании предлагают для использования клиентам, поскольку в каждом из них будет содержаться своё ПО и логика взаимодействия с клиентами, делая индивидуальным процессом интеграцию с каждой такой системой.

Требования +.

Физические ограничения. Для работы большинства физических устройств - роутеров, шлюзов, вычислительных центров, электронных ценников, маячков - необходимо обеспечивать определенный температурный режим. Это особенно важно для работы камеры и электронных ценников - в первом случае рабочая температура обычной комнатной камеры находится в пределах от -20 °C до +50 °C (это означает, что внешние камеры должны выдерживать низкие зимние температуры и отличаются от внутренних камер). Кроме того, часто электронные ценники должны должны находиться в пространстве с низкими температурами (в холодильных камерах), а потому для продуктовых розничных магазинов должны выбираться ценники, устойчивые к низкой температуре.

Поскольку основные ограничения проектирования и взаимодействия с внешними платформами были описаны выше, стоит перейти к юридическим ограничениям обработки персональных данных. В данный момент в России как и во всем мире не существует четких ограничений по обработке видеоданных (Статья 152.1 Гражданского кодекса РФ не дает право на запрет получения изображения человека в общественных местах, санкции только для скрытого наблюдения), их хранению (персональные данные должны храниться не более срока, необходимого для выполнения целей обработки видеоданных) и распознаванию лиц [52]. Стоит отметить, что все-таки существует несколько требований по поводу использования технологии распознавания лица человека. Например, обязательным является информирование о видеосъемки в общественных местах и использования пользовательского соглашения при работе в приложении.Кроме того, крайне не рекомендуется распознавать расу или национальность.

Рекомендации к созданию системы

Облачные системы потокового анализа данных или Edge analytics.

Для сценариев с использованием камеры, которая должна в реальном времени обрабатывать изображения и видео, целесообразно использовать предварительные вычисления без передачи данных в облако напрямую в камере или локальном вычислительном центре (Edge computing), который будет локально обрабатывать видео и при необходимости пересылать данные в облако для хранения и дальнейшего анализа[49]. Для локальных вычислительных хабов нет необходимости передавать потоковые данные серверу, а поскольку способность обрабатывать видео на локальных вычислительных центрах не отличается от вычисления в облаке, это делает локальные вычисления и обработку больших пакетов видео данных в локальных центрах очень выгодным. Хотя примерно одинаковые характеристики получаются при обработке данных на удаленном сервере и локальном центре, с отличием лишь в скорости обработки информации и стоимости передачи данных, для локальных центров необходимо специальное программное обеспечение для обработки данных и связью с сервером. Это может сделать внедрение такой технологии менее привлекательной для компаний, однако в настоящее время все больше компаний задействуют API и максимально стараются интегрировать свои решения с популярными сервисами, делая именно такой способ вычислений наиболее перспективным.

Камеры или iBeacon для создания тепловых карт и определения местоположения.

Хотя по поводу того, какой из способов локации внутри помещения является лучшим - Wi-Fi, Li-Fi или по маячкам - ходят многочисленные споры и проводятся исследования [53], к этим технологиям можно добавить и определение местоположения с помощью камер, в частности результаты одного из инструментов анализа - тепловые карты - очень похожи при использовании камер или маячков. Обе технологии делают возможным такой вид анализа, но каждая сочетает дополнительные преимущества и недостатки. Хотя на обработку видео данных тратится гораздо больше ресурсов, эти данные затем можно использовать для распознания лица. При использовании iBeacon можно легче регистрировать и анализировать путь отдельного индивида, а кроме того присылать ему персональные уведомления. Поскольку применение обеих технологий в своем роде уникально и необходимо, обе эти системы могут использоваться одновременно. Однако для анализа потоков посетителей на основе iBeacon требуется гораздо меньше вычислительных и сетевых ресурсов, а потому эта технология предпочтительней для построения тепловых карт.

Выбор платформы интернета вещей и платформы аналитики.

Хотя представленные платформы реализуют практически одинаковые функции, у них все же есть значимые отличия [38-43]. Как можно заметить из таблицы 2, где сравниваются возможности аналитики от различных поставщиков ПО, на первый взгляд наиболее полной является возможности аналитики в MSAzure, в которой присутствует API почти для всех средств анализа. Далее наиболее полными платформами являются GoogleCloudPlatform и IBMWatsonAnalytics, в которых также реализованы все алгоритмы, кроме алгоритмов распознавания лица. Тем не менее, не ко всем средствам Google Cloud Platform можно подключиться с помощью API, и кроме того нет SDK разработчика, а сервисы рассчитаны на использования в одной экосистеме Google. У платформыKaa отсутствуют какие-либо встроенные средства аналитики и потому при выборе это платформы придется либо разрабатывать, либо использовать сторонние сервисы для анализа данных. В первом пункте рекомендаций было отмечено, что очень перспективно использование локальных вычислений для обработки видеоданных. При использовании такого подхода становится не нужной опция распознавания лиц, эмоций и аудио в облаке, и наиболее функциональной в таком случае становится платформа IBM Watson Analytics. Тем не менее, если не использовать локальные вычислительные хабы, тогда становится необходимой обработка и распознавание лиц в облачной системе и платформа MSAzure, единственная из всех предоставляющая такую возможность, становится единственной, полностью охватывающей необходимый функционал нашей маркетинговой системы.

Распознавание лица и использование персональных данных

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

Использование модуля редактора сценариев

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

Выводы

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

Заключение

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

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

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

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

Список использованной литературы

1. Bang Nguyen & Lyndon Simkin (2017) The Internet of Things (IoT) and marketing: the state of play, future trends and the implications for marketing, Journal of Marketing Management, 33:1-2, 1-6

2. McCarthy J. E. (1960). Basic Marketing: A Managerial Approach. New York: Columbia University Press

3. Kotler, Philip (2012). Marketing Management. Pearson Education. p. 25.

4. Booms, B. and Bitner, M. J. "Marketing Strategies and Organizational Structures for Service Firms" in James H. Donnelly and William R. George, (eds), Marketing of Services, Chicago: American Marketing Association, 47-51

5. International Telecommunication Union, Overview of the Internet of things, Recommendation ITU-T Y.2060, June 2012

6. Hцller, J.; Tsiatsis, V.; Mulligan, C.; Karnouskos, S.; Avesand, S.; Boyle, D. (2014). From Machine-to-Machine to the Internet of Things: Introduction to a New Age of Intelligence. Elsevier. ISBN 978-0-12-407684-6.

7. Abashidze I. (2016). Internet Of Things In Marketing: Opportunities And Security Issues. Management Systems in Production Engineering No 4 (24), pp 217-221

8. Jara A. J., Skarmeta A. F. (2013). Enabling Participative Marketing through the Internet of Things. 27th International Conference on Advanced Information Networking and Applications Workshops

9. Antonio J. Jara1, Marнa Concepciуn Parra (2012) Marketing 4.0: A new value added to the Marketing through the Internet of Things. 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing

10. Mani Z., Chouk I. Drivers of consumers' resistance to smart products Journal of Marketing Management. - 2017. - Т. 33. - №. 1-2. - С. 76-97.

11. Slettemeеs D. RFID--the “Next Step” in Consumer-Product Relations or Orwellian Nightmare? Challenges for Research and Policy //Journal of Consumer Policy. - 2009. - Т. 32. - №. 3. - С. 219.

12. Woodside A. G., Sood S. Vignettes in the two-step arrival of the internet of things and its reshaping of marketing management's service-dominant logic Journal of Marketing Management. - 2017. - Т. 33. - №. 1-2. - С. 98-110.

13. Ehret M., Wirtz J. Unlocking value from machines: business models and the industrial internet of things //Journal of Marketing Management. - 2017. - Т. 33. - №. 1-2. - С. 111-130.

14. Dastjerdi A. V., Buyya R. Fog Computing: Helping the Internet of Things Realize Its Potential //Computer. - 2016. - Т. 49. - №. 8. - С. 112-116.

15. Alhamedi A. H. et al. Internet of things communication reference model Computational Aspects of Social Networks (CASoN), 2014 6th International Conference on. - IEEE, 2014. - С. 61-66.

16. А.В. Росляков, С.В. Ваняшин, А.Ю. Гребешков . Интернет Вещей. Учебное пособие. Поволжский государственный университет телекоммуникаций и информатики. Самара 2015

17. Pal A. Internet of Things: Making the Hype a Reality //IT Professional. - 2015. - Т. 17. - №. 3. - С. 2-4.

18. Wu M. et al. Research on the architecture of Internet of things //Advanced Computer Theory and Engineering (ICACTE), 2010 3rd International Conference on. - IEEE, 2010. - Т. 5. - С. V5-484-V5-487.

19. Gubbi J. et al. Internet of Things (IoT): A vision, architectural elements, and future directions //Future generation computer systems. - 2013. - Т. 29. - №. 7. - С. 1645-1660.

20. Architectural Considerations in Smart Object Networking [Электронный ресурс] / Internet Architecture Board. - URL: https://tools.ietf.org/html/rfc7452 (Дата обращения: 18.05.17).

21. Tsai C. W. et al. Data mining for Internet of Things: A survey //IEEE Communications Surveys and Tutorials. - 2014. - Т. 16. - №. 1. - С. 77-97.

22. Chen F. et al. Data mining for the internet of things: literature review and challenges //International Journal of Distributed Sensor Networks. - 2015.

23. Alam F. et al. Analysis of Eight Data Mining Algorithms for Smarter Internet of Things (IoT) //Procedia Computer Science. - 2016. - Т. 98. - С. 437-442.

24. Ricci F., Rokach L., Shapira B. Introduction to recommender systems handbook. - springer US, 2011. - С. 1-35.

25. Wedel M, Kannan P.K. (2016). Marketing analytics for data-rich environments. Journal of Marketing: AMA/MSI Special Issue, Vol. 80, 97-121

26. Vesanen J. What is personalization? A conceptual framework //European Journal of Marketing. - 2007. - Т. 41. - №. 5/6. - С. 409-418.

27. Berry M. J., Linoff G. Data mining techniques: for marketing, sales, and customer support. - John Wiley & Sons, Inc., 1997.

28. Sean J. R., McNee M., Konstan J. A. Accurate is not always good: How accuracy metrics have hurt recommender systems //extended abstracts on Human factors in computing systems (CHI06) p. - С. 1097-1101.

29. Bowyer K. W. Face recognition technology: security versus privacy //IEEE Technology and society magazine. - 2004. - Т. 23. - №. 1. - С. 9-19.

30. Koьhne M., Sieck J. Location-based services with iBeacon technology Artificial Intelligence, Modelling and Simulation (AIMS), 2014 2nd International Conference on. - IEEE, 2014. - С. 315-321.

31. William Stallings (2015) The Internet of Things: Network and Security Architecture. The internet protocol journal Volume 18, Number 4

32. Rajabi N., Hakim A. (2015). An intelligent Interactive Marketing System based on Internet of Things. 2015 2nd International Conference on Knowledge-Based Engineering and Innovation (KBEI).

Размещено на Allbest.ur