Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1352 сообщений
Cообщения с меткой

мобильные приложения - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Мировые рынки: как добиться успеха в Индии и Бразилии

Четверг, 20 Июля 2017 г. 08:36 (ссылка)



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



Переведено в Alconost



В цифрах





Индия



Сейчас в Индии более 1 миллиарда пользователей мобильной связи. На конец 2016 года около 200 миллионов из них — пользователи со смартфонами (больше только в Китае), и это, на самом-то деле, только начало.



Планшетофоны (мобильные устройства с экраном с диагональю от 5 до 7 дюймов) занимают 61% рынка, намного больше, чем в США. И хотя самая популярная категория устройств ясна, на рынке присутствует как минимум десяток производителей, включая лидера, Samsung (с долей в 40%), а также менее известные бренды, вроде Redmi и Micromax.



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



Пик использования мобильных устройств в Индии в личных целях в приходится на 9 часов вечера. Индийцы не очень активны утром. Мобильные пользователи Индии заботятся о своей конфиденциальности, и, на сегодняшний день, не очень часто пользуются мобильными платежами (примерно 360 миллионов долларов в  2016, лишь малая толика от 27 миллиардов долларов мобильных платежей только в США), но в ближайшие месяца и годы эта цифра будет быстро расти по мере распространения смартфонов среди населения, снижения цен на мобильный Интернет и распространения эффектов демонетизации.



Бразилия



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

Страсть бразильцев к мобильных технологиям может быть одной из причин этого роста. Около 64 миллионов из 208 миллионов пользователей мобильной связи владеют смартфонами, это более трети всех пользователей в Латинской Америке. Как и в Индии, это цифра растет — к 2018 году ожидается, что проникновение смартфонов достигнет 48%, на 10 пунктов выше, чем в 2015. Это отличная новость для торговли и рынка мобильной рекламы, поскольку бразильцы — поистине ненасытные потребители цифрового контента.



Бразилия уже является самым большим розничным рынком в Латинской Америке, несмотря на экономический спад. Электронная коммерция в Бразилии уже на первом месте среди стран Латинской Америки и объемы ее продолжат расти  примерно на 12,5% в год. Одной из важных причин такого роста является высокое проникновение кредитных карт (50%) и альтернативных методов оплаты, предлагаемых местными компаниями, включая Boleto Bancario, работающую при поддержке правительства систему электронных платежей, через которую проходит примерно четверть цифровых платежей в стране.



Бразильцы относятся к рекламе куда спокойнее, чем индийцы, и рекламодатели тратят 50% рекламных бюджетов всей Латинской Америки в одной только Бразилии — а прогноз на 2019 год составляет 5,8 миллиарда долларов. Помимо этого, в Бразилии самый высокий процент полного просмотра видеорекламы в мире.



Тенденции в использовании приложений



Индия



Использование приложений в Индии растет почти в четыре раза быстрее, чем по всему миру (Индия = 43% год от года; весь мир = 11%). Это создает взрывной спрос пропускной способности и доступности мобильного Интернета. А пока инфраструктура не может удовлетворить потребности рынка, индийские потребители используют UC Browser от Softonic, очень маленькое приложение, способное отфильтровывать более 80% трафика и снижать расходы на связь.



Android доминирует в Индии (97% по состоянию на второй квартал 2016 года), здесь доступны несколько магазинов приложений, включая Amazon и Opera, а также местные магазины, вроде GetJar, самый большой из открытых магазинов приложений в мире. UC Browser с огромным отрывом лидирует среди браузеров в Индии, являясь 6 по популярности приложением в Топ 10 приложений Индии, по порядку: WhatsApp, YouTube, Google, Gmail, SHAREit, UC, Google Maps, MX Player, Facebook и Facebook Messenger. Интересно, что Индия — единственная страна, в топе которой находятся сразу два видеоприложения (YouTube и MX Player): для издателей и рекламодателей это очевидный намек на эффективность и потенциал видеорекламы на этом огромном и растущем рынке.



В 2016 году категория «Музыка, мультимедиа и развлечения» похвасталась самым большим приростом объемов использования (188%), на втором месте была категория «Бизнес и финансы» (176%), на третьем — «Утилиты и продуктивность» (99%). Еще одной особенностью индийского рынка является популярность приложений для здоровья и фитнеса (рост в 27%), которые очень нравятся индийским потребителем, вместе с носимыми устройствами для отслеживания состояния здоровья и достижения фитнес-целей.



Бразилия



В Бразилии очень социальная культура и это находит свое отражение в рейтинге — на первых местах Top 10 социальные приложения и мессенджеры (YouTube, WhatsApp, Google, Facebook, Facebook Messenger, Chrome, Google Maps, Hangouts, Gmail chat, Google+).



На самом деле, 92% пользователей Интернета в Бразилии, как мобильного, так и в целом, пользуются социальными сетями. Бразильцы — это 10% всего социального трафика в мире. Такая социализация создает огромное количество трафика: целых 34% сессий приложений во всей Латинской Америке исходят из Бразилии, намного больше, чем из любой другой страны, включая Мексику. Конфиденциальность зачастую не важна, реклама, которая подстраивается под тон социальных бесед, обычно достигает успеха.



Как и в Индии, Android доминирует с примерно 90% рынка (тут, конечно, помогает тот факт, что iPhone в Бразилии дороже, чем где бы то ни было). Помимо Google Play, популярными вариантами для поиска и скачивания приложений, рингтонов и другого контента являются местные маркеты Aptoide, Mobile9 и Mobogenie. Требования к мобильному Интернету — не проблема в Бразилии, где все гораздо лучше, чем в Индии. Примерно 20% пользователей смартфонов имеют постоянный доступ к сетям 4G, а WiFi (любимый способ бразильцев выходить в сеть) доступен повсеместно.



Активные игроки этих рынков



Индия



Прогноз проникновения смартфонов в 66% в 2018 — огромный скачок на 40 пунктов по сравнению с 2015 годом — говорит о том, что мобильный рынок Индии чрезвычайно активен. В сфере телекоммуникаций ведущим инноватором является Jio, в то время как Vodafone и Airtel начали процесс консолидации рынка через серию сделок по поглощению и объединению.



Если посмотреть на общественные процессы, стоит отметить вложение правительством 3 миллиардов долларов в создание национальной оптической сети National Fiber Optic Network, а также планы по организации бесплатного WiFi-доступа в более чем 1000 отдаленных деревень. Эти и другие смелые инициативы индийский предпринимателей, конечно же, лишь ускоряют распространение приложений.

Lookup, стартап из Бангалора, который с помощью чата связывает покупателей с магазинами поблизости, один из потенциальных лидеров рынка. Получившая посевные инвестиции от таких источников как Vinod Khosla и Biz Stone от Twitter, компания быстро была куплена NowFloats.



Бразилия



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



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



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



Прогнозы



К 2020 на растущих рынках будет более 2,5 миллиардов пользователей смартфонов, а потребности в мобильном Интернете возрастут почти в 10 раз.



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



В Бразилии, где к 2019 году смартфоны будут почти у 80 миллионов человек (половина из них с доступом к 4G), стимулами роста будут даже не развлечения и коммерция, а полезные и практичные приложения. Бразильцы, очень социальные по своей натуре, быстро принимают и распространяют новые технологии,  (включая мобильные финансовые технологии), и чатботы, внедренные в невероятно популярные по всей стране мессенджеры, станут обычным делом в жизни бразильских потребителей.



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





О переводчике



Перевод статьи выполнен в Alconost.



Alconost занимается локализацией приложений, игр и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов, перевод технических текстов.



Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.



Подробнее: https://alconost.com



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333752/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Starbucks следует открыть публичный доступ к своим API

Среда, 19 Июля 2017 г. 18:02 (ссылка)

Мобильное приложение Starbucks — один из самых известных кейсов в ecommerce. Автор материала — программист опытным путем доказывающий, почему стоит открыть API этого приложения.



image



Мотивация



Стоит отдать должное приложению Starbucks — оно просто отличное. Я использую его (как минимум) раз в день. В нем есть все, что мне нужно от отличного мобильного сервиса — кофе, плейлисты хитов 80-х в Spotify и возможность избежать живого общения с другими людьми. Я явно не одинок в своих предпочтениях, так как 20% операций Starbucks в США сейчас производится через мобильные телефоны.



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



Однако я не мог ждать и поэтому решил взять дело в свои руки.



Было нелегко



Приложение Starbucks оказалось крепким орешком. Несмотря на URL-адрес «openapi.starbucks.com», пришлось пробираться через серьезные дебри, прежде чем начать анализировать вызовы, совершаемые приложением. Как и для любого другого приложения, обрабатывающего платежи, Starbucks предпринял многочисленные меры безопасности для защиты API, используемых своим приложением, от несанкционированного использования. Вот некоторые из них:




  • SSL certificate pinning

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

  • Шифрование этого отпечатка с использованием AES, 256-битным ключом и псевдослучайным вектором инициализации

  • Подписание запросов с меткой текущего времени



Наблюдение за запросами сети



Для начала мне нужен был способ наблюдать за запросами и ответами, которыми обменивались приложение Starbucks и его сервера. Обычно я просто настраивал свой iPhone на Charles (или mitmproxy), и этого было достаточно.



Но не в этот раз! Поскольку приложение использует certificate pinning, я не смог перехватить его запросы, как обычно. Вместо этого мне пришлось откопать свой старый телефон на Android, получить root-права, установить фреймворк под названием Xposed и, наконец, установить расширение, которое внедряется в запущенные приложения и отключает SSL pinning.



image



Муахаха



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



image

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



«Это легко», — думал я, — «Я просто размещу заказ, подключившись к прокси-серверу, и потом воспроизведу запросы!»


А вот и нет.



Как выяснилось, токены доступа Starbucks действительны всего один час, поэтому нельзя просто взять и пользоваться тем токеном, который использует ваш телефон. Это создает определенные трудности…



Вход в систему



Конечная точка OAuth, используемая приложением, перед выдачей токена проверяет три параметра:




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

  • Параметр формы «deviceFingerprint». Это список различных атрибутов устройства в кодировке base64 и зашифрованный AES-256. Он также регулярно изменяется, поскольку текущее время и аптайм устройства включены в отпечаток.

  • HTTP-заголовок «X-Cbt». Еще одна строка секретного ключа в кодировке base64.



Я начал пытаться сформировать некоторые из них самостоятельно. Я смог получить ключ шифрования, используемый для создания deviceFingerprint, используя джейлбрейкнутый iPhone для расшифровки фреймворков внутри приложения Starbucks. Изучив фреймворк в Hopper в течение некоторого времени, я в конечном итоге смог отследить вызов к функции Apple CCCrypt.



image



www.youtube.com/watch?v=o8ZnCT14nRc



Затем я прилинковал фреймворк SBXData (фреймворк, который я ранее расшифровал на джейлбрейкнутом телефоне) в наскоро созданное приложение и воспользовался Fishhook для переназначения этой функции собственной реализации. Это позволило мне выгрузить ключ и связанные с ним параметры в консоль:



image



Аналогичным образом удалось выяснить, как генерировать заголовок «X-Cbt». Для краткости изложения, я оставлю эту задачу вам :)



Заключение



После того, как я смог подписать и снять отпечатки со своих запросов на вход, я объединил все в небольшой модуль Node.js, который позволяет использовать некоторые основные функции API Starbucks. Хорошие новости: он (в основном) размещен здесь на GitHub!



Вуаля! Программируемый кофе.



image
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/322800/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

7 лучших ферм устройств для тестирования мобильных приложений

Вторник, 18 Июля 2017 г. 15:30 (ссылка)

Еще в далекие времена, когда балом смартфонов заправляли Nokia и Microsoft, возникла одна характерная особенность мобильной разработки — разношерстность устройств по характеристикам и модификациям операционок. Приходилось тестировать приложение не только на разных версиях ОС, но и на разных физических устройствах. После выхода iOS самих моделей телефонов всегда было мало, поэтому с ними проблем не возникало. А вот в мире Android проблема фрагментации встала во весь рост. Моделей на рынке тысячи, и все время появляются новые, и твое приложение или игра должны гарантированно работать на каждой из них. Добавим еще разные версии прошивок на этих моделях… И поймем, что вручную потребуется куча человеко-часов для проверки каждого релиза.





Примечание: мы продолжаем серию публикаций полных версий статей из журнала Хакер. Орфография и пунктуация автора сохранены.



Фермы устройств



Так как проблема с разнообразием парка устройств возникла еще в стародавние времена, уже Nokia начала предлагать своим разработчикам сервис по аренде смартфонов. Можно было поставить приложение на устройство и в режиме удаленного управления руками пройти по ключевым сценариям. Это было бесплатно, и некоторые устройства приходилось долго ждать, зато такое тестирование давало разработчику надежду, что софт будет работать корректно на различных смартфонах и, значит, у пользователей претензий не окажется. Начинание было хорошим, и фермы устройств получили свое дальнейшее развитие — сами ОС начали предоставлять инструменты для имитации действий пользователя. То есть тестировщик или разработчик пишут скрипт, притворяющийся человеком. Добавь сюда удобные DevOps-инструменты для сборки и автоматического запуска этих скриптов — и можно забыть о той мрачной картине с кучей человеко-часов для каждого релиза.



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





Сегодня мы поговорим про популярные облачные фермы устройств: Firebase Test Lab, Samsung Remote Test Lab, AWS Device Farm, Sauce Labs, Xamarin Test Cloud, Perfecto.



Как это работает



Встроенная автоматизация UI-тестирования появилась относительно недавно: iOS 9.0 (XCTest UI) и Android 4.3 (UI Automator, хотя Espresso и работал с Android 2.2).



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



Существует несколько популярных подсистем для выполнения скриптов: Appium, Calabash, Espresso, Robotium, UI Automator for Android, XCTest for iOS, которые, в свою очередь, поддерживают один или несколько языков программирования — Ruby, C#, Java, Python, Swift.



Бесплатно и сердито



Так как проблема с разнородностью парка устройств актуальна в первую очередь для Android, то знакомство мы начнем с ферм Google и Samsung.





Samsung Remote Test Lab



Первым на очереди у нас будет сервис Samsung Remote Test Lab. Этот сервис технологически уже устарел и не стоил бы упоминания в нашей статье, если бы не одно но. Samsung — лидер и один из законодателей на рынке Android-смартфонов, поэтому ранний доступ к флагманским новинкам позволит проверить работу твоего приложения еще до появления устройств в продаже. Плюс там есть доступ к устройствам на базе Tizen: линейка смартфонов Z и смарт-часы Gear.





Работа с сервисом выглядит следующим образом: ты резервируешь устройство и запускаешь специальное Java-приложение, которое предоставляет удаленный доступ к экрану и устройствам ввода (тачскрин, кнопки). На текущий момент доступно 25 моделей смартфонов и планшетов, каждая из моделей в нескольких экземплярах и модификациях. Автоматизация делается на уровне ручной записи последовательности событий, а устанавливать приложение надо руками. В целом не ахти какие возможности, но зато совершенно бесплатно. И самое вкусное — Samsung Remote Test Lab поддерживает удобный режим удаленной отладки! Так что можно смело рекомендовать этот сервис в качестве дополнительной фермы для ручного тестирования на устройствах Samsung.



Firebase Test Lab for Android





Наш следующий сервис разработан в стенах Google и называется Firebase Test Lab for Android. В целом Firebase хорошо подходит командам, специализирующимся на разработке для Android, а ферма устройств — это лишь один из инструментов. На текущий момент доступно не так много моделей устройств (около 30, список ниже на скриншоте), однако имеется также возможность запуска на эмуляторах. Test Lab включен в единую подписку на сервис Firebase и для старта может быть совершенно бесплатен.





Firebase Test Lab, в отличие от сервиса Samsung, легко интегрировать в DevOps-конвейер. Тестовые сценарии возможно реализовать с помощью инструментов Espresso, Robotium, UI Automator 2.0 и Robo. Во время выполнения сценариев делаются скриншоты. В целом это хорошее решение для Android-разработки небольших проектов с использованием нативных инструментов. Дешево (бесплатно!) и сердито.



Специализированные профессиональные фермы



Не Samsung’ом единым живут Android-разработчики, поэтому продолжить наш обзор хотелось бы более крупными фермами, которые поддерживают iOS, имеют большой парк моделей и требуют денег.



AWS Device Farm





В AWS Device Farm доступно почти 400 устройств (около 100 моделей), цены от 0,17 доллара за минуту, есть анлим (!) и 1000 первых минут бесплатно. Стоит отметить высокое качество сервиса и возможность интеграции в DevOps-конвейер. Для написания скриптов можно использовать Appium (iOS + Android), Calabash (iOS + Android), Espresso (Android), Robotium (Android), UI Automation (iOS) и XCTest (iOS) и ряд других.



Xamarin Test Cloud





Следующий профессиональный сервис — Xamarin Test Cloud. Более 2500 (не опечатка) реальных устройств! Поддерживаются iOS, Android и полный набор возможностей (скриншоты, автоматизированные скрипты, видео, обещают еще и удаленную отладку и запись в будущем). За все про все — от 99 долларов в месяц. Сервис идеально подходит как разработчикам кросс-платформенных решений (Xamarin, React Native), так и проектам с широкой пользовательской аудиторией (как следствие — высокий охват модельного ряда). Поддерживает автоматизированные скрипты на базе Calabash и Xamarin.UITest.



Старички



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



Sauce Labs





Знакомься, это Sauce Labs. Один из старожилов рынка автоматизированного тестирования. К его созданию приложил руку сам Джейсон Хаггинс (Jason Huggins), разработчик Selenium. Sauce Labs — взрослый сервис для взрослых команд. Цены от 149 долларов в месяц, есть нативные и гибридные приложения для iOS и Android и возможность организовать свое частное облако или провести тестирование в ручном режиме. Есть поддержка интеграции с DevOps-конвейерами и запуск на эмуляторах/симуляторах, хотя самих моделей устройств заявлено не больше двадцати. Другими словами, поклонникам Selenium — самое оно.



Perfecto





И завершим мы наш обзор одной из старейших ферм устройств от компании Perfecto. Еще во времена Symbian и Windows Mobile эта компания начала предлагать свои устройства в аренду. Цены были высокие, но на триале можно было быстренько прогнать приложение и убедиться, что оно работает (или не работает). Для iOS доступно порядка 20 различных моделей, а для Android — больше 50. В качестве фреймворка предлагаю использовать Appium. Тестировать вручную можно бесплатно, а вот автоматизация будет стоить от 299 долларов в месяц.



Итого



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




  • если ты один и пишешь на Java/Kotlin для Android, то смело бери Firebase Test Lab (бесплатно);

  • хочешь подключить удаленный дебаггер — есть только у Samsung (бесплатно);

  • ищешь сервис с максимальным покрытием устройств — рекомендуем Xamarin Test Cloud (от 99 долларов в месяц).



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



До связи!



Об авторе



Вячеслав Черников — руководитель отдела разработки компании Binwell, Microsoft MVP и Xamarin Certified Developer. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone. Статьи Вячеслава вы также можете прочитать в блоге на Medium.



Другие статьи автора:





Напоминаем, что это полная версия статьи из журнала Хакер.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333606/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

React Native с колокольни Android разработки часть 2

Понедельник, 17 Июля 2017 г. 16:09 (ссылка)

Свою прошлую статью я написал спустя 3 дня, после того, как я вообще начал ковыряться в react native, до этого имея опыт только в нативной разработке под android и iOS. Спустя это время я уже успел поработать над реальным react native проектом. И теперь хочу осветить все очевидные и неочевидные моменты с которыми я столкнулся в момент работы с реальным проектом. Всем заинтересованным под кат.



Инструменты



Еще раз хочу осветить тему рабочих инструментов. React native еще не очень близок к версии, хотя бы, 1.0, чему и причина отсутствия полностью рабочего и заточенного под этот продукт IDE. Хотя, внезапно, я наткнулся на это: Deco IDE. Да, это самая настоящая IDE (только под macOS по понятным причинам), да еще и купленная airbnb. Но не все так радужно как оказалось. Да, тут можно «программировать мышкой» просто перетаскивая компоненты в код. Опять же, есть список компонентов, не нужно каждый раз лезть на оф. сайт, чтобы узнать, а какой компонент еще там есть. Так же можно запустить проект буквально 1 тыком (правда, только iOS, с андроидом всегда проблемы). Но на этом все фишки и кончаются. Тут нету ни быстрых переходов к компонентам по клику с зажатым cmd, нету даже адекватного линтера и автодополнения. По функционалу кодинга — это простой блокнот, который только не закрытый тэг сможет подсветить. Но теперь этим инструментом занята крупная компания, надеюсь на его скорое развитие.



В большинстве видео про react native, а так же в скриншотах различных статей я везде видел VS code. Штука действительно неплохая, спокойно подцепляется eslinter как плагин, можно подцепить flow, есть автокомплиты и даже переходы к компонентам. Есть встроенный git и даже интегрированный терминал. И я бы тоже его использовал, но есть огромный для меня минус — по дефолту каждый открытый файл открывается в одной вкладке, как бы заменяя предыдущий. Чтобы открыть 2 вкладки с разными файлами, нужно начать редактирование в файле, затем открывать другой, который уже и откроется во второй вкладке. Если нужно просто быстро просмотреть 2-3 разных файла, обивку на стуле приходится менять это приносит некий дискомфорт.



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



Работа с камерой, картой и другими сложными вещами



Это, пожалуй, наиболее интересный вопрос для всех. Плохая новость — дефолтных компонентов для камеры и карты нету. Нужно использовать нативный код. Хорошая новость — все уже давно сделано до нас:

Дико крутые карты под авторством airbnb. Использовал лично, все замечательно работает как на iOS, так и на андроид, так же отлично кастомизируется.

Камера уже тоже есть. Хотя, лично не пробовал, небыло необходимости, хотя и любопытно.

В геопозицию, благо, умеет из коробки.

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



Рабочий процесс



У react native есть только 1 проблема — андроид проблемы с андроидом. Уж не знаю, проблемы ли это системы или разработчиков, что клали болт на андроид, но с ним вечно какие-то странные косяки.

Самый странный случай: Date переведенный в строку формата: «YYYY-MM-DD HH:mm:ss» имеет разную длину символов на iOS и android, догадайтесь на какой платформе лишний пробел? Что приводит просто к лютой парное, вот казалось бы, код на чистом js, все работает замечательно на iOS, а на андроиде что-то может пойти не так. Поэтому ВСЕГДА нужно проверят приложение на обеих платформах после ЛЮБОГО изменения кода, никогда не знаешь в какую проблему это может вылиться.



На самом деле подобная проблема была единична для меня, почему-то криво работает Date на андроиде, а вот momentJS прекрасно. Так что сразу используйте последнее. А вот с версткой проблемы другого характера.

Во-первых, андроид вообще не умеет в тени, что указываются в стилях. Для него есть отдельный параметр — 'elevation', но только и всего. Цвет тени, радиус, прозрачность — все это проходит мимо андроида.

Во-вторых, разрешение экранов. У яблофонов просто огромные разрешения, особенно в плюсах, от чего, бывают проблемы, когда выставляешь кнопки с нужными размерами шрифтов, на iOS все смотрится хорошо, на андроиде все слипается — экран маловат будет. Благо, react native дает возможность определить платформу, на которой запустилось приложение, и от этого изменять что-то в коде, например, стили.



Что касается самого процесса разработки, то тут сложно описать то чувство свободы, которое ты обретаешь, после нативной разработки под android. Android SDK дает нам инструменты, предназначенные для чего-то конкретного, отойти от которых никак нельзя. Вот было придумано, что должна быть активити, в которой подцепляется класс к layout, и хоть что ты делай, а активити быть должна, даже сам гугл с этим ничего поделать не может. Вот дали они нам data binding, и вот используя эту библиотеку активити в 99% случаев используется как костыль, просто чтобы подцепить layout и ViewModel, попутно передав Model, хотя мы в layout'е уже явно указали и model и ViewModel. Абсолютно никакой логики в этом случае тут нету, а активити есть. Для передачи информации нужен Intent, а он без проблем может передавать только простые типы, а если хочется передать объект, то все, здравствуй Parcelable.

И таких примеров очень много. В случае с react native есть только… JavaScript и все. Ты сам решаешь как сделать тот или иной элемент. Именно поэтому для навигации можно использовать аж 3 разных библиотеки:



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



Компоненты



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

image

Тут у нас 3 разные кнопки. На самом деле не разные, это один компонент. Понимаете масштаб крутизны компонентов? Тут от слова «совсем» можно забыть про копипасту в верстке. Да, в андроиде есть стили, которые теоретически, должны избавить нас от копипасты. Но ведь они применяются к чистым компонентам. Да, я могу задать стиль button, но что бы сделать кнопку как на картинке выше, одним button в андроиде не обойдешься. Это целый отдельный layout, где будет и TextView и ImageView и у всего этого, а так же у layout будут свои параметры стиля. И все 3 кнопки будут отличаться еще и различным количеством этих компонентов, где-то нету картинок, где-то 2 текста и т.п… Другими словами, сделать все эти 3 кнопки на андроиде не сверстав их 3 раза никак не получится. Ну а как получается это делать на реакте? Тут есть 3 щепотки магии:


  1. Props

  2. Отображение только тех элементов, что существуют

  3. Наложение стилей



Подробнее обо всем.

В андроиде мы сначала создаем компонент в layout'е, затем находим его по ID'шнику в активити и передаем какие-то параметры, например, текст меняем. Это работает, если мы заранее знаем что хотим отобразить. В реактиве мы же указываем какой нам создать компонент с НУЖНЫМИ нами параметрами. В чем соль? В props мы можем передавать ВСЕ ЧТО УГОДНО, без каких либо проблем, начиная от простых типов, заканчивая объектами. Допустим, нам нужна еще 1 кнопка, такая же как по середине, только с другой стрелочкой. В андроиде мы бежим рисовать уже 4-ю кнопку, а тут же мы просто передаем через props другую иконку.



Но бОльшая магия твориться вот тут:

{true && Я существую}
{false && Я НЕ существую}


Смысл в том, что так можно не отображать несуществующие объекты. Мы ведь используем JS с динамической типизацией, и ей можно удобно пользоваться для себя, например:


const text = this.props.text;
{text && {text}


Если мы передали в props параметр text, то компонент его отрисует, а если не передали, то не отрисует, ибо зачем? Стоит еще раз акцентировать внимание на динамическую типизацию. С текстом все хорошо, текст есть — true, текста нету — false, тоже и с объектами. А вот с числами беда, отправите 0 — JS будет думать что это false… Для чисел лучше более явно проверять тип.

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

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



{this.props.text}


Стиль мы определяем как массив стилей. Что это значит? Это значит, что если мы НЕ передали в props свой стиль, то компонент будет в дефолтном, который мы определили заранее. Но что, если мы передадим в кастомный стиль 1 параметр, допустим, отступ сверху? И этот компонент будет иметь дефолтный стиль плюс отступ сверху. Смысл в том, что всегда ПОЛНОСТЬЮ применяется дефолтный стиль, только в нем заменяются лишь те параметры, которые мы передаем в кастомном стиле. Т.е. если мы хотим только изменить цвет текста — не беда, размеры, отступы и прочие радости не слетят. А если нам какой-то параметр в стиле не нужен, мы передаем в кастомном стиле этот параметр со значением null.



Заключение



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



Самый главный вопрос для кого react native? Да для всех. Делая продукт, нужно держать 2 команды разрабов — для iOS и android. Тут же хватит и одной. Во-первых, это тупо дешевле, нужно в 2 раза меньше людей, а во-вторых, удобно — появился баг, поправил сразу на 2 платформы. И серьезные ребята тоже начали втягиваться. Тут уже не только фейсбук и инстаграмм. Airbnb, walmart, testa, думаю, эти ребята что-то знают)



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




А вы пробовали писать на react native?
















































Проголосовало 3 человека. Воздержавшихся нет.





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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333518/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Авторизация OAuth для Xamarin-приложений

Четверг, 13 Июля 2017 г. 17:57 (ссылка)

Итак, сегодня мы продолжаем разбираться с различными механизмами авторизации пользователей в приложениях на Xamarin. После знакомства с SDK от Facebook и ВКонтакте (здесь и здесь), можем перейти к одному из самых популярных (на текущий момент) механизмов внешней авторизации пользователей — OAuth. Большинство популярных сервисов вроде Twitter, Microsoft Live, Github и так далее, предоставляют своим пользователям возможность входа в сторонние приложения с помощью одного привычного аккаунта. Научившись работать с OAuth вы легко сможете подключать все эти сервисы и забирать из них информацию о пользователе.









Предполагается, что вы уже знакомы с тем, как работает OAuth, а если нет — рекомендуем вот эту хорошую статью на Хабре. Если коротко, то при авторизации OAuth пользователь перенаправляется с одной веб-страницы на другую (обычно 2-3 шага) до тех пор, пока не перейдет на конечный URL. Этот финальный переход и будет отловлен в приложении (если писать логику самому) на уровне WebView, а нужные данные (token и срок его валидности) будут указаны прямо в URL.



Небольшой список популярных сервисов, которые предоставляют возможность авторизации пользователей по OAuth: Одноклассники, Mail.ru, Dropbox, Foursquare, GitHub, Instagram, LinkedIn, Microsoft, Slack, SoundCloud, Visual Studio Online, Trello.



Xamarin.Auth



Для того, чтобы работать с OAuth в Xamarin мы остановимся на простой и удобной библиотеке Xamarin.Auth, которая развивается уже не первый год и имеет все необходимые для нас механизмы:




  1. Отображение браузера со страницами авторизации

  2. Управление потоком редиректов и процессом авторизации

  3. Получение нужных данных

  4. Предоставление механизмов для дополнительных запросов к сервису, например для получения информации о пользователе



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



Рекомендуем устанавливать Xamarin.Auth из Nuget, так как версия в Xamarin Components уже давно устарела и не обновляется.







Напомню, что мы уже ранее рассказывали про авторизацию с помощью SDK от Facebook и ВКонтакте. В нашем примере мы вынесли всю логику авторизации в платформенные проекты, оставив в PCL только интерфейсы. Для OAuth мы пойдем тем же путем, несмотря на поддержку PCL в самом Xamarin.Auth.



Помимо Xamarin.Auth можем также порекомендовать библиотеку Xamarin.Forms.OAuth от Bruno Bernardo. Даже если вы используете классический Xamarin, в исходных кодах этого проекта можно найти множество готовых конфигураций для различных сервисов.



Мы же в качестве примера работы OAuth подключим авторизацию с помощью Microsoft. Первым делом создадим приложение на сайте https://apps.dev.microsoft.com и получим там Client ID (ИД клиента или приложения).





Подключаем авторизацию в PCL



На уровне PCL все как обычно — делаем простой интерфейс IOAuthService для платформенного сервиса, никаких новых зависимостей в проект не добавляем.



public interface IOAuthService
{
   Task Login();
   void Logout();
}


Ну и, конечно же, будет необходимо добавить обращение к методам DependencyService.Get().Login() и DependencyService.Get().Logout() внутри нашей страницы авторизации.



Также нет проблем добавить поддержку нескольких OAuth-сервисов. Для этого можно добавить в методы Login() и Logout() аргумент providerName (тип string, int или enum) и в зависимости от его значения выбирать поставщика услуг.



Реализация платформенной части



Как уже отмечалось ранее, необходимо добавить библиотеки Xamarin.Auth из Nuget в каждый платформенный проект, в нашем случае — iOS и Android. Дальше пишем нашу реализацию IOAuthService для каждой платформы и регистрируем ее в качестве Dependency.



Теперь нам достаточно создать экземпляр класса OAuth2Authenticator с нужными параметрами:



         var auth = new OAuth2Authenticator
           (
               clientId: "ВАШ_CLIENT_ID",
               scope: "wl.basic, wl.emails, wl.photos",
               authorizeUrl: new Uri("https://login.live.com/oauth20_authorize.srf"),
               redirectUrl: new Uri("https://login.live.com/oauth20_desktop.srf"),
               clientSecret: null,
               accessTokenUrl: new Uri("https://login.live.com/oauth20_token.srf")
           )
           {
               AllowCancel = true
           };


Теперь повесим обработчик завершения авторизации:



auth.Completed += AuthOnCompleted;


Всё, можно показать модальное окно со встроенным веб-браузером для авторизации, получаемое через метод auth.GetUI(). На iOS это можно сделать примерно так:



UIApplication.SharedApplication.KeyWindow.RootViewController.PresentViewController(auth.GetUI(), true, null);


На Android при использовании Xamarin.Forms код может получится следующим:



Forms.Context.StartActivity(auth.GetUI(Forms.Context));


После успешной авторизации вызовется наш метод AuthOnCompleted(), и для iOS будет необходимо скрыть модальное окно с браузером (на Android само скроется):



UIApplication.SharedApplication.KeyWindow.RootViewController.DismissViewController(true, null);


Теперь можно получать нужные данные (access_token и время его жизни в секундах — expires_in)



var token = authCompletedArgs.Account.Properties["access_token"];                
var expireIn = Convert.ToInt32(authCompletedArgs.Account.Properties["expires_in"]);
var expireAt = DateTimeOffset.Now.AddSeconds(expireIn);


И нам остался последний шаг — получить расширенную информацию из профиля пользователя, включая email и ссылку на аватарку. Для этого в Xamarin.Auth есть специальный класс OAuth2Request с помощью которого удобно делать подобные запросы.



             var request = new OAuth2Request("GET", new Uri("https://apis.live.net/v5.0/me"), null, account);
var response = await request.GetResponseAsync();


Теперь нам приходит JSON с данными пользователя, и мы можем их сохранить и отобразить в приложении.



             if (response.StatusCode == HttpStatusCode.OK)
{
    var userJson = response.GetResponseText();
    var jobject = JObject.Parse(userJson);
    result.LoginState = LoginState.Success;
    result.Email = jobject["emails"]?["preferred"].ToString();
    result.FirstName = jobject["first_name"]?.ToString();
    result.LastName = jobject["last_name"]?.ToString();
    result.ImageUrl = jobject["picture"]?["data"]?["url"]?.ToString();
    var userId = jobject["id"]?.ToString();
    result.UserId = userId;
    result.ImageUrl = $"https://apis.live.net/v5.0/{userId}/picture";
}


Как видим, ничего сложного нет. Вопрос в том, чтобы правильно прописать URL для процесса авторизации. Ну и помнить, что поле expires_in содержит время в секундах (это вызывает частые вопросы).







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



Заключение



Сегодня мы завершили рассмотрение всех популярных способов авторизации пользователей и получения базовой информации о них через внешние сервисы. Описанные механизмы подходят как для Xamarin.Forms, так и для классического Xamarin iOS/Android. Полные исходные коды проекта со всеми примерами можно найти в нашем репозитории:



https://bitbucket.org/binwell/login



Задавайте ваши вопросы в комментариях к статье и оставайтесь на связи!





Об авторе



Вячеслав Черников — руководитель отдела разработки компании Binwell, Microsoft MVP и Xamarin Certified Developer. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone. Статьи Вячеслава вы также можете прочитать в блоге на Medium.



Другие статьи автора:




Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332970/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Проблемы безопасности Android-приложений: классификация и анализ

Среда, 12 Июля 2017 г. 10:09 (ссылка)





Изображение: etnyk, CC BY-NC-ND 2.0



Использование смартфонов в повседневной жизни не ограничивается голосовыми звонками и СМС. Возможность загружать и выполнять программы, а также мобильный доступ в Интернет привели к появлению громадного числа мобильных приложений. Функциональность современного смартфона составляют браузеры, клиентские программы социальных сетей, офисные приложения и всевозможные сервисы, работающие в Сети. Android-устройства заняли б'oльшую часть рынка смартфонов за счет открытой архитектуры платформы Android и удобного API разработчика. На данный момент Android является наиболее популярной мобильной ОС с долей рынка более 75%. Количество приложений, загруженных из магазина Google Play, в 2016 году составило 65 миллиардов [1].



Параллельно наблюдается и бурный рост числа вредоносных приложений: в 2015 году их было обнаружено 2,3 миллиона [3]. Кроме того, около 60% Android-устройств работают на версиях ОС с известными уязвимостями, и они потенциально могут быть атакованы злоумышленниками [6]. Эти угрозы, в свою очередь, привели к развитию средств защиты. Официальный магазин Google Play ввел фильтрацию приложений с помощью песочницы Google Bouncer. Антивирусные компании стали выпускать свои продукты под Android (хотя, как показано в [8], многие из них сами по себе содержат опасные уязвимости). Число научных публикаций по данной теме также возросло: одна из обзорных работ 2015 года о решениях безопасности для Android [2] насчитывает более 40 проектов и упоминает далеко не все известные на данный момент исследования. В связи с тем, что мобильные устройства являются источником и хранилищем большого количества конфиденциальных данных, проблема безопасности ОС Android и ее приложений стоит особо остро.



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

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



1. Устройство ОС Android



В основе ОС Android лежит ядро Linux с некоторыми архитектурными изменениями, которые были сделаны инженерами Google. Приложения для операционной системы Android разрабатываются на языке Java. Начиная с версии Android 1.5 был представлен набор инструментов Android NDK, который позволяет разрабатывать модули приложений на языках С и С++ и компилировать их в машинный код [4]. Приложения поставляются в виде файлов специального формата APK, который является ZIP-архивом с определенной структурой каталогов и файлов. APK-файл приложения содержит:




  • манифест;

  • модули, скомпилированные в машинный код (разделяемые библиотеки .so);

  • различные ресурсы приложения;

  • DEX-файл;

  • прочие необходимые файлы.



Начиная с версии Android 4.4 поддерживаются две среды выполнения приложений: Dalvik VM и ART. Следует отметить, что процесс подготовки APK-файла не изменился, изменился только процесс установки приложений в новой среде выполнения ART. Начиная с версии 5.0 среда выполнения ART стала использоваться по умолчанию вместо Dalvik VM.



Среда выполнения Java-программ Dalvik VM на Android сильно отличается от «обычной» Java VM. Во-первых, при компиляции Java-программы она компилируется в байт-код виртуальной машины Dalvik, который сильно отличается от байт-кода виртуальной машины HotSpot. Виртуальная машина Dalvik является регистровой, что делает ее выполнение на RISC-архитектурах, часто используемых в мобильных устройствах, более эффективным. Также при разработке Dalvik учитывались ограничения памяти в мобильных устройствах. Начиная с версии Android 2.2 среда выполнения Dalvik содержит JIT-компилятор, который компилирует «горячие» куски кода Java-программ в машинный код [5]. Стандартные библиотеки Java были либо заменены на доработанные библиотеки из пакета Apache Harmony либо написаны заново. При компиляции Java-программы получается файл формата DEX (Dalvik Executable), который содержит байт-код для виртуальной машины Dalvik. Формат файла был разработан с целью сокращения объема занимаемой памяти и существенно отличается от стандартного формата JAR. Для вызова модулей, реализованных в машинном коде, из Java-программ используется интерфейс JNI. Стоит отметить, что имеется возможность подгружать машинные модули динамически по сети с помощью компонента DexClassLoader.



2. Проблемы безопасности



Родительским процессом для всех приложений в ОС Android является процесс Zygote. Данный процесс представляет собой каркас Android-приложения, в котором уже загружены все необходимые библиотеки окружения Android, но отсутствует код самого приложения. Запуск приложения Android с точки зрения операционной системы происходит следующим образом:




  1. Вначале происходит системный вызов fork для создания потомка от процесса Zygote (см. рис. 1).

  2. В этом новом процессе открывается файл запускаемого приложения (системный вызов open).

  3. Происходит чтение информации о файлах классов (classes.dex) и ресурсов из файла приложения. Происходит открытие сокетов для IPC.

  4. Выполняется системный вызов mmap для отображения файлов приложения в память.

  5. Среда выполнения производит настройку необходимого окружения и выполняет приложение (интерпретирует байт-код Dalvik или передает управление функциям в исполняемом коде в случае ART [7]).



На уровне ядра ОС Android каждое приложение является отдельным процессом с уникальными значениями user/group ID, которые даются ему при установке. Таким образом, каждая программа работает в своей песочнице. Начиная с версии 4.3 в дополнение к этой политике безопасности добавилось использование компонента мандатного контроля доступа SELinux [10].





Рис. 1. Запуск нового приложения в ОС Android



По умолчанию приложение ограничено в своих возможностях и не может сделать ничего, чтобы негативно повлиять на другое приложение или пользователя: ни прочитать пользовательские данные, ни модифицировать системные приложения; отсутствует доступ к сети. Для получения доступа к различным ресурсам приложение обращается к сервисам ОС Android. Разрешения на доступ задаются статически в файле манифеста приложения и выдаются приложению во время его работы по мере необходимости. Система запрашивает у пользователя согласие на выдачу этих разрешений во время установки или во время обновления приложения. Ответственность за выдачу доступа приложению лежит на пользователе, он самостоятельно решает, какому приложению давать разрешения на определенные действия, а какому не давать, — во время его установки. Использование такого подхода, при котором все разрешения выдаются разом при установке приложения, привело к тому, что пользователи стали раздавать полномочия приложениям, не задумываясь о последствиях. В свою очередь, приложения стали запрашивать все больше разрешений по мере расширения их функциональности. В Android 6 Marshmallow данная система заменена на другую: приложение запрашивает доступ к ресурсам у пользователя во время его работы, а пользователь может либо разрешить доступ, либо запретить его [11].



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



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



Компоненты под названием Service [9] производят фоновую обработку. Когда Activity нужно выполнить какую-то операцию, например загрузку файла или проигрывание музыки, и продолжить работу, когда пользователь перешел в другое приложение или свернул текущее, приложение запускает сервис, цель которого — выполнение этой операции. Разработчики могут использовать Service в качестве приложения-демона, стартующего во время загрузки системы. Компонент Service, как правило, поддерживает RPC (Remote Procedure Call), поэтому другие компоненты системы могут обращаться к нему.



Компонент Content provider сохраняет и обменивается данными, используя интерфейс реляционных баз данных. Каждый Content provider содержит уникальный URI для данных и обрабатывает запросы к нему в виде очередей SQL (Select, Insert, Delete).



Компоненты Broadcast receiver выступают в роли ящиков для сообщений от других приложений.



Проблемы безопасности, возникающие в ОС Android, рассматривались в работах [2, 12, 13], но классификация проблем по категориям дана только в статье [2]. Эта классификация достаточно подробная и охватывает многие проблемы безопасности, но у нее есть ряд существенных недостатков: некоторые категории охватывают широкую область уязвимостей, в то время как другие достаточно специализированы; приведенные категории уязвимостей никак не соотносятся с программными уровнями архитектуры ОС Android; не охвачены уязвимости из интернет-источников, а также слабо охвачены уязвимости в протоколах и аппаратуре (п. 2.7 и 2.8 в нашей классификации). Предлагаемая ниже классификация уязвимостей устраняет эти недочеты.



2.1. Уязвимости ядра Linux и его модулей



К данной категории проблем относятся уязвимости, которые присущи всем ОС, основанным на той же версии ядра Linux, что и ОС Android. Эксплойты, использующие уязвимости в ядре, могут получить данные пользователя или права администратора системы. Повысив привилегии процесса до прав администратора системы, вредоносная программа может отключить систему безопасности Android, вставить в существующие программы вредоносный код и установить руткит. К тому же производители различных устройств добавляют в ядро модули для своих устройств; в этих модулях также могут быть уязвимости. Примеры уязвимостей повышения привилегий описаны в [14, 15, 16, 64]. Также стоит отметить, что совсем недавно была обнаружена уязвимость в компоненте ashmem для межпроцессного взаимодействия в Android [62].



2.2. Уязвимости модификаций и компонентов производителей устройств



В последнее время производители различных мобильных устройств стали выпускать свои модифицированные прошивки Android. Эти прошивки могут содержать различные приложения и сервисы, разработанные производителем устройства, которые чаще всего нельзя удалить. Например, в октябре 2016 года был обнаружен скрытый бэкдор в прошивках Foxconn [63]. Анализ этих сервисов, приведенный в статьях [17], показывает, что в них содержится от 65 до 85% уязвимостей, обнаруженных во всей системе. К тому же стоит отметить, что уязвимости, которые были обнаружены и исправлены в основной ветке Android, могут долгое время оставаться в ветках производителей устройств [18, 19].



2.3. Уязвимости модулей в машинных кодах



Android-приложения поддерживают запуск машинного кода через интерфейс JNI. Это порождает еще одну категорию уязвимостей, связанную с широко известными уязвимостями утечек памяти в низкоуровневых языках (например, в С и С++ ) [20]. Поскольку на уровне процессов ОС Android нет никаких ограничений, кроме накладываемых ядром Linux, сторонние библиотеки в машинных кодах могут использовать разрешения, выданные всему приложению, для совершения вредоносной активности (см. также следующую категорию уязвимостей, п. 2.4). Также модули приложения в машинных кодах используются авторами вредоносных приложений, чтобы обойти инструменты анализа и мониторинга уровня Android. Эти модули также могут использовать техники противодействия анализу, используемые в обычных программах.



2.4. Уязвимости механизмов межкомпонентного взаимодействия



К данной категории относятся уязвимости, связанные с взаимодействием между различными компонентами приложений. Так как на уровне операционной системы приложение ограничено песочницей процесса, ему необходим механизм доступа к компонентам ОС Android для взаимодействия с ними. Это происходит через устройство /dev/Binder и различные другие сервисы ОС Android. Как уже говорилось выше, параметры этого доступа задаются в файле манифеста, в виде XML-файла с разрешениями. Анализ, приведенный в статьях [12, 21, 22, 23, 24, 25], указывает на недочеты этой системы ограничений и показывает пути их обхода. Так, например, приложение может воспользоваться правами доступа другого приложения и получить с помощью него данные через ICC. Также могут быть уязвимости, связанные со сторонними библиотеками. Сторонние библиотеки, используемые в приложении, получают тот же набор ограничений, что и само приложение. Поэтому сторонние библиотеки могут использовать разрешения, выданные всему приложению, для совершения вредоносной активности. Приложения к тому же могут перехватывать системные события, пересылаемые через широковещательный запрос, и сохранять информацию о входящих звонках и СМС.



2.5. Уязвимости в самих приложениях



Каждое приложение сохраняет какие-то данные о пользователе. Эти данные должны быть защищены должным образом, чтобы к ним не могли получить доступ другие приложения, — но такая защита предусмотрена не всегда. Например, Skype в одной из версий приложения сохранял базу данных контактов в открытом виде на диске. Таким образом, контакты можно было прочитать любым другим приложением, у которого есть доступ к диску [26]. Также приложения могут использовать криптографические библиотеки с ошибками [27] или же какие-то собственные реализации. К тому же не все приложения производят хорошую аутентификацию и авторизацию пользователя. Кроме этого, приложения могут позволять SQL-инъекции и подвержены атакам XSS. Также стоит отметить, что большинство разрабатываемых приложений написаны на Java без использования какой-либо защиты для бинарного кода, а байт-код Java, как известно, легко поддается дизассемблированию и анализу. Стоит отметить, что к этой категории уязвимостей относится также известный список Mobile OWASP-10. Многие подобные уязвимости описаны в [28, 29].



2.6. Уязвимости во встроенных сервисах и библиотеках



Стандартный набор библиотек и сервисов, работающих в Android, также содержит уязвимости. Например, недавно была обнаружена уязвимость Stagefright в библиотеке для отображения видео в MMS-сообщениях, которой были подвержены все версии Android, начиная с 2.2 [30]. Позже была обнаружена уязвимость в компоненте MediaServer, которой подвержены все версии Android c 2.3 до 5.1 [31]. В статье [13] показаны уязвимости рантайма Dalvik: запустив большое количество процессов в системе, можно добиться, что последующий процесс запустится с правами администратора.



2.7. Интернет-источники



Android-приложения распространяются через широкое количество источников помимо официального магазина приложений. Поскольку Android-приложения написаны в основном на Java, то они легко поддаются обратной разработке и переупаковке с использованием вредоносного кода [32, 33]. Кроме того, как было показано в статье [34], песочницу анализа приложений Bouncer, используемую в официальном каталоге, легко обойти. Поэтому и в самом официальном магазине содержится большое количество вредоносных программ. Кроме этого, Android поддерживает удаленную установку приложений через Google Play на устройства, связанные с Google-аккаунтом. Таким образом, если взломать учетную запись Google для устройства, можно установить из Google Play вредоносное приложение, которое туда предварительно загрузил злоумышленник. При этом на экране мобильного телефона не требуется каких-либо подтверждений этих действий, поскольку они запрашиваются в окне браузера и приложение устанавливается на телефон в фоновом режиме при получении доступа к Интернету. Также к этой категории уязвимостей относится использование социальной инженерии, когда для продолжения работы предлагают установить приложение из неавторизованного источника [35].



2.8. Уязвимости аппаратуры и связанных с ней модулей и протоколов



Мобильные устройства, работающие под управлением ОС Android, имеют широкий набор аппаратуры для взаимодействия с внешним миром. Соответствующие уязвимости можно эксплуатировать при непосредственной близости к устройству или при наличии физического доступа к устройству. Примерами таких атак служат атака типа «отказ в обслуживании» на технологию Wi-Fi Direct [36], кража данных кредитных карт с помощью NFC [37], исполнение удаленного кода через Bluetooth [38], установка вредоносного приложения без ведома пользователя через adb с помощью механизма бэкапов [39]. В работе [13] показаны уязвимости, с помощью которых можно повысить привилегии приложения, используя ошибки в реализации протокола adb.



3. Инструменты для анализа Android-приложений



С того момента, как были выпущены первые Android-телефоны, было написано большое количество инструментов для анализа Android-приложений. Наиболее полный обзор этих инструментов содержится в статьях [40, 41, 42, 2]. В первых трех источниках инструменты классифицированы по видам анализа: статический, динамический и их объединение (смешанный). В статье [2] используется классификация инструментов по стадиям развертывания приложения на Android-устройстве. В нашей работе используется классификация по видам анализа.



Статический анализ



Инструменты статического анализа можно разделить на следующие категории:




  • Инструменты, извлекающие метаинформацию из манифеста приложения и предоставляющие информацию о запрашиваемых разрешениях, компонентах Activity, сервисах и зарегистрированных Broadcast receivers. Метаинформация часто используется позже в динамическом анализе для запуска функций приложения.

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

  • Инструменты, которые реализуют декомпилятор или дизассемблер байт-кода Dalvik.



Одним из наиболее популярных инструментов обратной разработки является Apktool [43]. Он имеет возможности декодирования ресурсов приложения приблизительно в оригинальную форму, переупаковки приложений обратно в APK/JAR-файлы, отладку байт-кода smali. Для декомпилирования и компилирования в apktool байт-кода Dalvik используется другой широко известный проект smali/backsmali [44]. Также для дизассемблирования байт-кода Dalvik часто применяется инструмент Dedexer [45].



Radare2 [46] — инструмент с открытым исходным кодом для дизассемблирования, анализа, отладки и изменения бинарных файлов Android-приложения.

Один из самых разносторонних инструментов для статического анализа — Androguard [47]. Он может дизассемблировать и декомпилировать приложение обратно в исходный код Java. Получив два APK-файла, он может посчитать коэффициент их похожести для детектирования переупакованных приложений или известных вредоносных приложений. Благодаря своей гибкости он используется в некоторых инструментах смешанного анализа.



Более полный список инструментов статического анализа можно найти в статьях, указанных выше. Следует отметить, что статический анализ имеет ряд существенных ограничений, связанных с тем, что имеется лишь абстрактное представление о программе. Например, статический анализ становится намного сложнее, если к программе применены обфусцирующие преобразования. В зависимости от сложности обфускации некоторые (а может, и все) статические подходы могут стать абсолютно бесполезными. Если вызов каждого метода делается только косвенно, вряд ли удастся построить граф вызовов программы. В Android такое преобразование можно сделать, используя Java Reflection API для вызова методов и создания объектов вместо использования обычных вызовов и инструкций создания нового объекта. На рынке решений по защите исходного кода уже представлено несколько продуктов для обфускации файлов Android-приложений, которые могут свести на нет все преимущества статического анализа [48, 49]. Более подробно о техниках противодействия статическому анализу можно почитать в 50.



Динамические и смешанные инструменты анализа



Инструменты динамического анализа отслеживают поведение неизвестного приложения во время выполнения при запуске его в контролируемой песочнице для получения поведенческого следа. Для этого производится инструментирование песочницы на различных уровнях архитектуры участками кода, которые отслеживают поведение приложения и ОС Android.







Рис. 2. Уровни архитектуры песочницы Android



Архитектура песочницы Android представляет из себя эмулятор Android (чаще всего QEMU), внутри которого работает ОС Android. Инструментирование производится либо на уровне эмулятора, либо на уровне ОС Android, либо и там и там. Уровень ОС Android также делится на четыре подуровня:




  • приложения,

  • среда разработки приложения,

  • рабочее окружение приложения и библиотеки,

  • ядро и его модули.



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




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

  • Мониторинг системных вызовов. Инструменты могут записывать системные вызовы с помощью инструментирования виртуальных машин, strace или модуля ядра. Это позволяет производить трассировку машинного кода.

  • Трассировка методов (функций). Инструменты могут отслеживать вызовы Java-методов приложения в виртуальной машине Dalvik, вызовы функций в машинных кодах через JNI, системные вызовы и прерывания.



К инструментам смешанного анализа относятся инструменты, которые сочетают в себе техники динамического и статического анализа.



4. Идеальная система полносистемного анализа платформы Android



Статьи [40, 41, 42, 2] насчитывают более 40 различных инструментов как для анализа Android-приложений, так и для анализа ОС Android в целом. Как было замечено в статьях [34, 60, 61], существующие инструменты динамического анализа обладают рядом серьезных недостатков. Данные недостатки присущи и стандартному инструменту анализа приложений в магазине Google Play — Google Bouncer, вследствие чего вредоносные приложения могут распространяться через официальный магазин, не будучи обнаруженными.



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







Архитектура системы представлена на рис. 3. Основным компонентом является полносистемный эмулятор, который может загружать как прошивки ОС Android с реальных устройств, так и официальный образ Android для эмулятора. Эмулятор поддерживает проброс датчиков от реального устройства, а также исполнение отдельных участков кода на реальных устройствах. Внутри эмулятора работают модули, которые обеспечивают:




  • поддержку смешанного исполнения,

  • трассировку приложений,

  • анализ помеченных данных,

  • анализ межкомпонентного взаимодействия,

  • склейку машинного и Java-кода приложения,

  • взаимодействие с реальным оборудованием.



Список требований к данной системе:



1. Поддержка загрузки прошивок от производителей различных устройств



Существенным недостатком всех существующих инструментов анализа ОС Android и ее приложений является невозможность запуска прошивок от производителей устройств в доступных эмуляторах. Как было показано в п. 2.2, модифицированные прошивки от производителей устройств содержат от 65 до 85% уязвимостей, обнаруженных во всей системе. На данный момент не существует инструментов для анализа, которые позволяли бы запускать прошивки от производителей. Все существующие решения работают на специальной сборке Android для виртуальной платформы GoldFish.



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



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



3. Проброс данных от датчиков оборудования реальных устройств в эмулятор



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



4. Совместный анализ на уровне Java-кода и машинного кода



Затруднением для многих систем анализа Android-приложений является то, что приложения содержат как модули в байт-коде Dalvik, так и модули в машинных кодах. Из существующих решений поддержка анализа всех модулей реализована только в DroidScope [57] и CopperDroid [58, 59]. Идеальная система анализа должна позволять отслеживать потоки данных и управления на уровне пользовательского и системного кода. Для пользовательского кода, когда это возможно, следует поднимать уровень представления до Java-кода, являющегося высокоуровневым языком разработки. Также необходимо обеспечивать «склейку» потоков данных и управления при переходе от машинного кода к Java и наоборот.



5. Поддержка анализа межкомпонентного взаимодействия



В статье о CopperDroid [58] показана реализация поддержки анализа межкомпонентного взаимодействия как внутри Android-приложения, так и между различными приложениями. Это сделано с помощью перехвата данных, проходящих через компонент ядра Binder, так как все взаимодействие проходит через него. Подход, реализованный в CopperDroid, позволяет не производить модификации исходного кода Android, что делает возможность его переноса на новые версии ОС Android и новую среду запуска приложений ART с минимальными изменениями.



6. Защита от статических эвристик обнаружения



Как показано в статьях [[57], 61], большинство песочниц для анализа можно обнаружить, просто проверив значения IMEI, IMSI или номера сборки прошивки у устройства. Также эмулятор может быть обнаружен, если проверить на стандартные значения таблицу маршрутизации. Из существующих решений защита от обнаружения по статическим эвристикам реализована только в проекте ApkAnalyzer [65].



7. Минимальные изменения прошивок Android



Также стоит отметить, что многие решения динамического анализа основаны на инструментировании кода различных компонентов ОС Android, в частности виртуальной машины Dalvik. Это осложняет их дальнейшую поддержку, а также миграцию в новую среду запуска приложений ART. Многие песочницы ограничиваются только анализом кода компонентов Java, тогда как все больше и больше приложений используют компоненты в машинных кодах.



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



Стоит отметить, что многие из инструментов динамического анализа используют анализ помеченных данных, используя для этого инструмент TaintDroid [56]. В статье [60] были показаны успешные способы обхода анализа данного инструмента. Причиной успешности данных атак являются следующие факты: 1) TaintDroid отслеживает только потоки данных и не отслеживает потоки управления, 2) TaintDroid отслеживает потоки данных только на уровне виртуальной машины Dalvik и проходящих через интерфейс JNI. Возможные пути разрешения данных недостатков описаны в [60] и дают направление для дальнейших исследований.



9. Поддержка символьного исполнения и частичного исполнения с конкретными значениями с использованием данных, полученных из статического анализа кода (concolic execution — смешанное исполнение)



В статье [51] описана среда анализа, реализующая данный подход. Эта среда сочетает в себе техники статического анализа графа потока управления программы, символьного исполнения программы и исполнения программы с конкретными значениями. Подходы, сочетающие техники символьного исполнения и исполнения программы с конкретными значениями, описаны в статьях [52, 53, 54, 55]. Целью данного метода является наблюдение путей исполнения, которые приводят к секциям программы, содержащим «интересный» код. Под «интересным» кодом понимают такой код, выполнение которого зависит от каких-либо произошедших внешних событий или настроек окружения системы. Например, код классов в Android, динамически подгружаемый с помощью компонента DexClassLoader или вызов «машинных» методов через интерфейс JNI.



Заключение



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



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



Несмотря на такую пессимистичную картину, в последнее время наблюдается ряд позитивных движений в сторону улучшения безопасности Android. В частности, компания Google запустила программу выпуска обновлений безопасности: они выходят каждый месяц и некоторые вендоры все же добавляют их в свои версии прошивки (устройства, поддерживаемые Google, получают эти обновления первыми). Кроме того, пользователи могут самостоятельно установить на свои устройства версию ОС Android CyanogenMod (ныне LineageOS), которая поддерживает эти обновления безопасности. Также пользователь может снизить риски, если ограничится набором популярных приложений только из официального магазина Google Play. Уязвимости типа RCE (удаленное выполнение кода) встречаются все реже, поэтому доставка вредоносных приложений на телефоны чаще происходит через фишинговые сайты, неофициальные магазины приложений или с помощью социальной инженерии. Среднестатистический пользователь ОС Android, соблюдая определенную технику безопасности, может быть спокоен за свой смартфон.



Автор: Михаил Романеев (@melon)



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




  1. statista.com/statistics/281106/number-of-android-app-downloads-from-google-play

  2. Tan D. J. J. et al. Securing Android: A Survey, Taxonomy, and Challenges // ACM Computing Surveys (CSUR). 2015. Vol. 47. № 4. P. 58.

  3. file.gdatasoftware.com/web/en/documents/whitepaper/G_DATA_Mobile_Malware_Report_H1_2016_EN.pdf

  4. developer.android.com/ndk/guides/stable_apis.html

  5. Dalvik VM Internals // sites.google.com/site/io/dalvik-vm-internals

  6. securityweek.com/overwhelming-majority-android-devices-dont-have-latest-security-patches

  7. Google I/O 2014 — The ART runtime // youtube.com/watch?v=EBlTzQsUoOw

  8. media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Huber-Rasthofer-Smartphone-Antivirus-And-Security-Applications-Under-Fire.pdf

  9. developer.android.com/guide/components/services.html

  10. source.android.com/devices/tech/security/selinux

  11. developer.android.com/preview/features/runtime-permissions.html

  12. Enck W., Ongtang M., McDaniel P. Understanding android security // IEEE security & privacy. 2009. № 1. P. 50—57.

  13. Shabtai A., Mimran D., Elovici Y. Evaluation of Security Solutions for Android Systems // arXiv preprint arXiv:1502.04870. — 2015.

  14. Hei X., Du X., Lin S. Two vulnerabilities in Android OS kernel // Communications (ICC), 2013 IEEE International Conference on. IEEE, 2013. P. 6123—6127.

  15. forum.xda-developers.com/showthread.php?t=2048511

  16. Zhou X. et al. Identity, location, disease and more: Inferring your secrets from android public resources // Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013. P. 1017—1028.

  17. Wu L. et al. The impact of vendor customizations on android security // Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013. P. 623—634.

  18. en.wikipedia.org/wiki/Stagefright_(bug)

  19. Zhou X. et al. The peril of fragmentation: Security hazards in android device driver customizations // Security and Privacy (SP), 2014 IEEE Symposium on. IEEE, 2014. P. 409—423.

  20. Sun M., Tan G. NativeGuard: Protecting android applications from third-party native libraries // Proceedings of the 2014 ACM conference on Security and privacy in wireless & mobile networks. ACM, 2014. P. 165—176.

  21. Octeau D. et al. Effective inter-component communication mapping in android with epicc: An essential step towards holistic security analysis // USENIX Security 2013.

  22. Chin E. et al. Analyzing inter-application communication in Android // Proceedings of the 9th international conference on Mobile systems, applications, and services. ACM, 2011.

  23. Felt A. P. et al. Permission Re-Delegation: Attacks and Defenses // USENIX Security Symposium. 2011.

  24. Bugiel S. et al. Xmandroid: A new android evolution to mitigate privilege escalation attacks // Technische Universit"at Darmstadt, Technical Report TR-2011-04.

  25. Bugiel S. et al. Towards Taming Privilege-Escalation Attacks on Android // NDSS. 2012.

  26. cvedetails.com/cve/CVE-2011-1717

  27. Fahl S. et al. Why Eve and Mallory love Android: An analysis of Android SSL (in) security // Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012. P. 50—61.

  28. owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks

  29. Lu L. et al. Chex: statically vetting android apps for component hijacking vulnerabilities //Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012. P. 229—240.

  30. kb.cert.org/vuls/id/924951

  31. CVE-2015-3842 // cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3842

  32. Zhou Y. et al. Hey, You, Get Off of My Market: Detecting Malicious Apps in Official and Alternative Android Markets // NDSS. 2012.

  33. Nolan G. Decompiling android. – Apress, 2012.

  34. Petsas T. et al. Rage against the virtual machine: hindering dynamic analysis of android malware // Proceedings of the Seventh European Workshop on System Security. ACM, 2014. P. 5.

  35. Android Security Underpinnings // youtube.com/watch?v=NS46492qyJ8

  36. coresecurity.com/advisories/android-wifi-direct-denial-service

  37. securityaffairs.co/wordpress/37667/hacking/nfc-attack-credit-card.html

  38. zerodayinitiative.com/advisories/ZDI-15-092/

  39. securityfocus.com/archive/1/535980/30/150/threaded

  40. Neuner S. et al. Enter sandbox: Android sandbox comparison // arXiv preprint arXiv:1410.7749. 2014.

  41. Hoffmann J. From Mobile to Security: Towards Secure Smartphones: дис. – 2014.

  42. Faruki P. et al. Android Security: A Survey of Issues, Malware Penetration and Defenses.

  43. ibotpeaches.github.io/Apktool

  44. github.com/JesusFreke/smali

  45. dedexer.sourceforge.net

  46. radare.org/r

  47. github.com/androguard/androguard

  48. dexprotector.com

  49. guardsquare.com/dexguard

  50. PANDORA applies non-deterministic obfuscation randomly to Android, Schulz P. Code protection in android // Insititute of Computer Science, Rheinische Friedrich-Wilhelms-Universit"at Bonn, Germany. 2012.

  51. Sch"utte J., Fedler R., Titze D. Condroid: Targeted dynamic analysis of android applications // in review. 2014.

  52. Sen K. DART: Directed Automated Random Testing // Haifa Verification Conference. 2009. Vol. 6405. P. 4.

  53. Sen K., Marinov D., Agha G. CUTE: a concolic unit testing engine for C. ACM, 2005. Vol. 30. № 5. P. 263—272.

  54. Godefroid P. Random testing for security: blackbox vs. whitebox fuzzing // Proceedings of the 2nd international workshop on Random testing: co-located with the 22nd IEEE/ACM International Conference on Automated Software Engineering (ASE 2007). ACM, 2007. P. 1.

  55. Jayaraman K. et al. jFuzz: A Concolic Whitebox Fuzzer for Java // NASA Formal Methods. 2009. P. 121—125.

  56. Enck W. et al. TaintDroid: an information-flow tracking system for realtime privacy monitoring in smartphones // ACM Transactions on Computer Systems (TOCS). 2014. Vol. 32. № 2. P. 5.

  57. Yan L. K., Yin H. DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis // USENIX Security Symposium. 2012. P. 569—584.

  58. Tam K. et al. CopperDroid: Automatic Reconstruction of Android Malware Behaviors // Proc. of the Symposium on Network and Distributed System Security (NDSS). 2015.

  59. copperdroid.isg.rhul.ac.uk/copperdroid

  60. Sarwar G. et al. On the Effectiveness of Dynamic Taint Analysis for Protecting against Private Information Leaks on Android-based Devices // SECRYPT. 2013. P. 461—468.

  61. Jing Y. et al. Morpheus: automatically generating heuristics to detect Android emulators // Proceedings of the 30th Annual Computer Security Applications Conference. ACM, 2014. P. 216—225.

  62. googleprojectzero.blogspot.ru/2016/12/bitunmap-attacking-android-ashmem.html

  63. bbqand0days.com/Pork-Explosion-Unleashed

  64. powerofcommunity.net/poc2016/x82.pdf

  65. apk-analyzer.net

  66. www.phdays.ru/program/fast-track/45984


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332904/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Какая вовлеченность нужна вашему продукту и как ее точнее измерить

Вторник, 11 Июля 2017 г. 10:54 (ссылка)





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



Очень длинная статья содержит обзор подходов, методов и результатов исследований вовлеченности пользователей мобильных приложений. В ней не будет простых и быстрых «топ-10» советов по гарантированному повышению DAU, MAU, ARPU и др. Вместо этого, попробуем разобрать виды вовлеченности и прийти к пониманию, что и когда лучше измерять, а что измерять не имеет смысла. Сложные моменты разберем «на пальцах». В дополнение посмотрим на несколько переведенных методик измерения вовлеченности из научных рецензируемых журналов.



Статья может оказаться полезной создателям мобильных приложений, менеджерам продуктов, аналитикам, исследователям, UX-специалистам.



Я решила вынести выводы в начало.



Самые короткие выводы из статьи

1. Что хотите исследовать?

1) Как пользователь относится к продукту/бренду: исследуйте маркетинговую вовлеченность.

2) Насколько пользователь вовлекается в использование приложения: исследуйте пользовательскую вовлеченность.

2. Как определяют вовлеченность: Таблица 1.

3. Через что исследуют вовлеченность: Таблица 2.

4. Как измерять уровни вовлеченности: Таблица 3.

5. Что исследовать для разных типов приложений и вовлеченности: Таблица 4.

6. Как выбрать метод на разных стадиях развития продукта: Таблица 6.

7. Какие анкеты используют исследователи: см. Приложения.



А теперь, я напишу, как это все появилось.



Все началось не просто так. Более двух лет назад я придумала идею SAAS сервиса для автоматизации рекрутинга и оценки, нашла инвестора, наши компании в партнерстве создали сервис и запустили его в работу. Кроме прочего, я занималась маркетингом, исследованиями и следила за тем, как пользователи воспринимают и покупают продукт. Об одном из таких исследований я писала в прошлой статье .



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



Сейчас мы разрабатываем мобильное приложение для оценки профессиональных компетенций. Чтобы снова не потерять время, я решила с самого начала разобраться, как измеряется вовлеченность в мобильных приложениях и как ее можно повышать. Статьи описывают, в основном, метрики типа DAU, MAU, retention, ARPU. Но до того времени, как эти метрики смогут мне что-то сказать, будет уже много потрачено.


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



1. Что такое вовлеченность



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



Действительно, а что такое вовлеченность? Все интуитивно понимают, что это. И активно ее исследуют. Но определение дают редко. И это вызывает замешательство. Вовлеченность – это особое состояние во время использования приложения, или общая лояльность к продукту, или готовность с ним активно взаимодействовать и рекомендовать другим, или что-то еще?



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



Раз мы говорим об исследовании вовлеченности, то этап концептуализации (определения, что она такое с точки зрения конкретного продукта) пропустить нельзя. Поэтому сейчас будет немного занудства и работы со словарями.



Часто в исследованиях понятие вовлеченности сужается только до эмоций, которые испытывает пользователь по отношению к продукту, или бренду компании. Иногда речь ведется только об исследовании реальных поступков пользователей. В исследовании вовлеченности игроков упоминается погруженность, психологическая поглощенность, состояние потокаи диссоциация [21]. В обзоре M. Lamas с соавторами перечислены подходы к исследованию вовлеченности через анализ позитивных эмоций, сфокусированного внимания, достижимости и контроля, новизны и др. [1] Я нашла несколько определений, сделала посильный перевод и прилагаю оригиналы. Если у вас будут рекомендации по улучшению перевода здесь и далее, буду рада им в комментариях.



Таблица 1. Варианты определений пользовательской вовлеченности.





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



Краткий итог раздела

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

– положительные эмоции, fun,

– любопытство, интерес,

– отношение, аттитюды,

– предпочтение,

– мотивацию,

– поведение,

– привычку,

– концентрацию внимания,

– диссоциацию,

– поглощенность,

– состояние потока.



Отсутствие единственного определения – это хорошая новость. Теперь можно подбирать удобное определение под задачи исследования, под тип приложения и – в конечном итоге – под этап развития продукта.



Уже сейчас явно видны два типа вовлеченности:

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

Маркетинговая вовлеченность – вовлеченность в бренд: интенсивность потребительской заинтересованности в товаре.



Разберем на пальцах.





Рисунок 1. Виды вовлеченности на пальцах.

Как это применить к моему приложению?

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

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


2. Как операционализируется вовлеченность



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





Если я узнаю, что в мое приложение пользователи часто заходят. Или узнаю, что они остаются в нем подолгу. Это хорошие показатели? Вроде, да. Какой из них лучше? А что, если я узнаю, что при открытом приложении пользователь ничего не делает – что это будет значить с точки зрения вовлеченности?



Я обнаружила в литературе 2 подхода к операционализации вовлеченности:

1. Вовлеченность как состояние пользователя.

2. Вовлеченность как метрика продукта.



1. Вовлеченность как состояние пользователя

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



В обзоре M. Lamas перечислены такие способы операционализации вовлеченности [1]:

1. Сфокусированное внимание. Для вовлечения пользователи должны быть максимально сфокусированы. Для измерения сфокусированности и вовлеченности используются нарушения в субъективном восприятии времени.

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

3. Эстетика. Сенсорное, визуальное оформление интерфейса стимулируют пользователя и приводит к фокусировке внимания.

4. Долговечность. Люди запоминают приятный и полезный опыт и хотят его повторить. Характеристика выражается в готовности людей порекомендовать продукт другим людям.

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

6. Доступность и контроль. Доступность обеспечивает рост активности пользователей, а контроль отвечает за то, какого уровня активности могут достичь пользователи.

7. Репутация, доверие и ожидания. Доверие – необходимое условие для вовлечения пользователей. Существует негласный контракт между пользователями и продуктами, который выходит за рамки технологических требований.

8. Мотивация, интересы, стимулы и награды.



2. Вовлеченность как метрика продукта.

Здесь никто не копается в мотивах и состояниях пользователей. Оценивается только их поведение по отношению к продукту (количество новых пользователей, DAU, WAU, MAU, возвраты, «stiсky factor» и др.).



Для измерения пользовательской вовлеченности на стороне продукта в 2008 году Forrester описали подход «4I» [цит. по 1].

Вовлечение (Involment). Присутствие пользователя. Измеряется количеством посещений, временем сессий и т.д.

Взаимодействие (Interaction). Активность пользователя. Измеряется CTR, on-line действиями, загружаемыми фото и видео.

Близость (Intimacy). Привлечение, или отвращение пользователя. Измеряется рейтингами удовлетворенности, анализом настроений в блогах, комментариями, опросами.

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



Компании AppLift и Localytics оценивают вовлеченность по одной метрике: через среднее время, проводимое пользователем в приложении в течение месяца (ASL). Самой большой вовлеченностью, продолжающей расти от года к году, по их оценкам, обладают новостные приложения со средней продолжительностью сессий 6 минут и среднемесячным временем 90 минут (2015 г.). На втором месте оказались развлечения: 8 минут и 77 минут соответственно [2].



Оценка вовлеченности через продолжительность сессий часто встречается и в анализе игр. Например, в недавнем большом исследовании влияния создаваемых разработчиками и пользователями дополнений на вовлеченность игроков (2017) [9]. Но с продолжительностью сессий все не так прозрачно и связано несколько интересных моментов.



2 истории о том, как сбоила продолжительность сессий.



История 1: Отличие usability-эффективности и ux-вовлеченности.

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

Возникает вопрос: в каких случаях для монетизации нужна большая продолжительность сессий, а в каких маленькая? И что делать, например, с приложениями-магазинами: если покупатель проводит много времени в приложении – это хорошо, или плохо? Он вовлечен, или дезориентирован?



Франция, 2017 [19].

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


История 2. Отличие истинной и формальной вовлеченности.

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



Португалия, 2015 [16].

Гейм-аналитик компании «Miniclip» R. Vladimiro описал ситуацию, когда аналитика игры (гонки) показывала в целом хороший уровень возврата игроков, но его насторожила продолжительность сессий. Он обнаружил 2 группы игроков: первые возвращались в игру по 3-4 раза в день и играли в среднем по 6 минут, вторые приходили в игру в среднем 1 раз в день, но не выходили из приложения часами. Он начал анализировать поведение игроков и понял, что вторые игроки просто пассивно накапливают валюту для обновления автомобиля, но не участвуют в гонках. То есть, в сущности, не играют. В статье он написал, что вовлеченность логично увеличивает удержание, но высокое удержание игроков не обязательно означает их высокую вовлеченность: «Вовлеченность – это удовольствие от игры, а удовольствия не может быть без осмысленного взаимодействия».


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



Краткий итог раздела

1. Два типа операционализации вовлеченности почти полностью соответствуют двум типам определения вовлеченности: маркетинговую вовлеченность чаще всего измеряют через метрики продукта, а пользовательскую вовлеченность – через состояния пользователя. Есть и пересечения, о них мы поговорим в следующем разделе.



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



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



Таблица 2. Варианты операционализации пользовательской вовлеченности.





Разберем на пальцах





Рисунок 2. Виды опрационализации на пальцах.

Как это применить к моему приложению?

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


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



4. Уровни вовлеченности



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



Некоторые исследователи не выбирают один концепт вовлеченности, а представляют ее разные виды, как иерархию состояний.

Например, L.C. Vieira и др. (2016), [12] различают уровни:

– вовлечение,

– поглощение,

– погружение.

И только последний уровень – погружение – они считают истинным состоянием потока, называя предыдущие состояниями микро-потока (рис. 3).





Рисунок 3. Уровни вовлеченности и эмоции игроков согласно L.C. Vieira и др. [12].



В маркетинге используют такие уровни вовлеченности:

– осведомленность о продукте/ бренде,

– удовлетворенность продуктом/ брендом,

– лояльность к продукту/ бренду,

– вовлеченность в продукт/ бренд.

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



Краткий итог раздела

Вовлеченность можно измерять по уровням.

Попробуем совместить варианты операционализации с уровнями вовлеченности (Таблица 3). Теперь выбор метрик становится понятнее. В таблице я соотнесла уровни вовлеченности с вариантами операционализации и выделила курсивом, когда их методы пересекаются.



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





Еще раз проговорим это на пальцах.



Рисунок 4. Уровни маркетинговой и пользовательской вовлеченности «на пальцах».



Как это применить к моему приложению?

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

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




4. Вовлеченность разных групп пользователей.

Здесь узнаем 4 истории о том, как индивидуальные различия пользователей повлияли на аналитику приложений и запутали все карты.



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



История 1. Недовольные максимайзеры.

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



США, 2013 [18].

Исследование поведения и удовлетворенности этих групп показало, что длительность использования приложения не связана с большим доходом. Сатисфайеры быстро выбирают и покупают, а максимайзеры могут много раз возвращаться и долго выбирать, но в итоге ничего не купить, или вернуть покупку. Максимайзерами чаще являются люди более молодого возраста, а также люди, имеющие больше денег и больше власти. Кроме того, максимайзеры способны значимо больше времени потратить на возврат покупки и написание негативных отзывов [18].


История 2. Постоянные интроверты.

Связана ли вовлеченность в использование фитнес-устройств с личностными, демографическими и культурными особенностями? Какие сегменты пользователей можно выделять, чтобы тоньше рассматривать аналитику по фитнес-приложениям?



США, 2017 [10].

В исследовании участвовало 700 студентов. Им раздали браслеты Fitbit Charge HR и попросили регулярно надевать браслеты и синхронизировать данные.

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

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

1) интровертированные,

2) менее открытые новому опыту,

3) с более низким уровнем невротизма,

4) дольше спящие,

5) в общем более подвижные.

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


История 3. Женщины без браслетов.

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



Великобритания, 2017 [8].

A.E. Whitehead и др. опросили 578 взрослых мужчин и женщин. Оказалось, что женщины гораздо реже использовали фитнес-устройства и реже считали, что есть причины для их использования.


История 4. Щедрые киллеры.

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



Россия, 2015 [17].

Самое распространенное деление игроков – на персоны Бартла – показывает существенные различия в метриках вовлеченности в зависимости от типажа игрока. «Cоциальные» игроки проводят меньше всего времени в игре, но больше других приводят в игру друзей (у них высокий social ratio — коэффициент привлечения). Они могут привести «киллеров», которые приносят в игру больше всего денег. На втором месте по тратам «карьеристы». Максимальный «retention 28-го дня» у «исследователей» – они самые преданные, но приносят в игру меньше денег, чем остальные игроки.


Краткий итог раздела

Разные люди ведут себя по-разному. Иногда по-разному ведут себя большие группы пользователей. Поэтому простая аналитика может давать сбои. Чтобы их уменьшить, можно сегментировать пользователей (выделять разные группы по поведению и потребностям, называть персоны).



Разберем на пальцах.



Рисунок 5. Различия в поведении разных типов пользователей «на пальцах».



Как это применить к моему приложению?

Теперь перед тем, как собирать аналитику и исследовать в общем поведение моих пользователей, я разделю их на группы. Затем я смогу анализировать, как отличается поведение разных групп, какая группа больше вовлечена и для какой группы нужно что-то переделать, или усилить вовлечение. Но мне еще не понятно, какие сегменты / персоны нужно выбрать, как их найти и назначить. Об этом поговорим дальше.




5. Три типа приложений и виды вовлеченности.



Здесь подберемся к модному Jobs-to-be-done и когда-то забытой, но теперь вспоминаемой теории деятельности. После, наконец, поговорим о третьем виде вовлеченности. И разберемся, как разделить все приложения на 3 группы, чтобы понять, какую вовлеченность нужно исследовать.



Чтобы точнее исследовать вовлеченность и верно сегментировать пользователей, нужно понимать, какая деятельность стоит за использованием приложения. Является ли приложение посредником, инструментом для хорошо знакомой пользователю деятельности, или содержит в себе новые цель и мотив деятельности. И здесь довольно хорошо вписывается подход Jobs-to-be-done и, в более широком смысле, деятельностный подход и теория деятельности А. Леонтьева.



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



В сущности, в зависимости от целей и деятельности, все приложения можно разделить на 3 типа. Я назвала их так: самозадачные приложения, процессные посредники и результатные посредники. Подробное описание в таблице 4.



Таблица 4. Типы приложений и вовлеченности.





Разберем типы приложений на пальцах.





Рисунок 6. Типы приложений «на пальцах».



Как это применить к моему приложению?

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



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



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



Благодаря анализу деятельности моих пользователей и Jobs-to-be-done приложения я начинаю понимать, какие метрики мне стоит ожидать от каждой группы пользователей, а что вовсе не имеет смысла исследовать.

Теперь мне становится интересно, смогу ли я увеличивать не только вовлеченность в бренд, но и вовлеченность в деятельность. Какие механики вовлечения мне применять, чтобы они сработали? Начинаем об этом говорить прямо сейчас.




6. Как связаны вовлеченность в приложение и вовлеченность в деятельность.



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



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



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

Это как молоток с удобной ручкой. Дизайн инструмента – это необходимое и достаточное условие. Мы будем его использовать дольше из-за удобной ручки. Но только из-за ручки мы не будем с ним работать – в основе его использования лежит деятельность (стройка, ремонт, творчество). И если эта деятельность нас достаточно увлекает, то мы будем выбирать между удобными молотками. Но если не увлекает, то удобство ручки молотка нас не заставит заниматься ремонтом. Или все-таки заставит?



Бывает ли повторное вовлечение в деятельность из-за вовлечения в приложение?



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



Вовлечь пользователя в off-line деятельность за счет хорошей стратегии вовлечения в приложение – задача сложная. Скорее всего, она выполнима только для некоторых видов деятельности (вряд ли, казалось бы, пользователь начнет больше ездить только из-за того, что ему удобен навигатор, хотя вовлекающие методы перевозчиков типа Uber и сервисов бронирования типа Booking показывают, что и здесь могут быть варианты).



В исследованиях вовлечения в длительное использование приложений чаще всего используются теории из области психологии взаимоотношений. Одна из них – инвестиционная модель отношений – получила больше всего эмпирических подтверждений (Rusbult, Drigotas, and Verette 1994). По этой модели, вовлеченность в длительные отношения усиливается, если пользователь ощущает:

1) увеличение выгоды от взаимодействия (например, от полезной информации, или развлечения),

2) снижение личных затрат,

3) увеличение личных вложений в систему,

4) уменьшение числа достойных альтернатив.



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

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

Один из таких примеров – про игроков, получавших монеты в гоночках, – мы уже обсуждали в разделе 2. Здесь расскажу еще про 2 таких примера, упомянутые в статье A. Weston [11].



Англия, США, 2007.

Исследования эффективности геймификации, проведенные Baker et al. показали, что иногда дети учатся играть в игру, созданную для обучения математике, типа Zombie Division, показывают хорошие успехи в игре, но не начинают лучше разбираться в математике (рис. 2).




Рисунок 2: Кадры из игры Zombie Division (Источник)



США, 2010 [20].

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

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




Рисунок 3: Виртуальный помощник из исследований T. Bickmore [20].



Краткий итог раздела

Вовлеченность в приложения типа «посредники» взаимосвязана с вовлеченностью в деятельность вне приложений: вовлеченность в деятельность может усиливать и ослаблять вовлеченность в приложение. Но и вовлеченность в приложение может усиливать и ослаблять вовлеченность в деятельность.

При создании механик вовлечения пользователей важно не допустить «сдвига мотива на цель», когда пользователи вовлекаются в приложение и отвлекаются от основной деятельности.





Рисунок 7. Различия внешней и внутренней мотивации «на пальцах».



Как это применить к моему приложению?

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

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

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


7. Подходы к измерению вовлеченности

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



In-app / Web-аналитика

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



Когда используют аналитику, говорят об интрасессионном и интерсессионном вовлечении [1]. Первое показывает, насколько долго продукт способен удерживать пользователя во время одного сеанса (продолжительность сессий). Второе оценивается через возвращения пользователя (количество сессий, динамика возвратов) и в конечном итоге может быть измерено через Lifetime value («пожизненная стоимость клиента», размер чистой прибыли, которую компания получает от клиента за все время, которое клиент использует продукт).



Испания, США, 2012 [3].

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

Популярность (общее количество пользователей, количество визитов, количество кликов).

Активность (количество просмотренных страниц за один визит, время, потраченное за один визит).

Лояльность (количество дней, в течение которых пользователь заходит на сайт, количество визитов, общее время, проведенное на сайте).


Таблица 5. Модели пользовательской вовлеченности для разных видов сервисов (согласно J. Lehman и др.).





Исследования с самоотчетами

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



Литва, 2017 [5].

A. Tarute с соавт. в операционализации разделили вовлеченность на привычные для социальных исследований аспекты анализа (когнитивный, эмоциональный и поведенческий) и добавили социальный аспект.

1. Когнитивный аспект. Проявляет ли пользователь интерес к товару, или бренду?

2. Эмоциональный аспект. Испытывает ли пользователь воодушевление, или гордость от использования продукта, или сопричастности с брендом?

3. Поведенческий аспект. Вероятно ли, что пользователь предпримет какое-то действие навстречу бренду, или товару, сделает покупку и др.

4. Социальный аспект. Взаимодействует ли пользователь с брендом в социальном окружении, вовлекает ли других людей, участвует ли в совместном создании продукта?



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



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

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

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

4. Качество информации (возможность получить своевременную и релевантную информацию, качественный контент).



Для исследования были случайным образом отобраны активные пользователи мобильных приложений. Средний возраст 25 лет, 42.5% мужчин и 57.5% женщин. Участников просили выбрать мобильное приложение, которое они используют чаще всего, и отвечать на вопросы анкеты, имея в виду это приложение.



В результате факторного анализа были отобраны 27 вопросов анкеты (см. Дополнения, № 4). Анкета оценивала вовлеченность, готовность продолжать использование приложения, а также четыре качества мобильных приложений. Интересно, что в итоговую версию анкеты в блок оценки вовлеченности вошли только 4 вопроса про эмоции и 1 про поведение. Авторы хоть и упоминали когнитивный и социальный аспекты вовлеченности, но не использовали их в диагностике.



Большинство участников исследования (61,3%) сообщили, что чаще всего используют мобильные приложения социальных сетей (Facebook Messenger, Instagram, Viber, WhatsApp). Кроме приложений социальных сетей, наиболее используемыми оказались приложения для навигации (Trafi, Busas Kaunas, Here WeGo Maps), банкинга (Swedbank, DNB bank, SEB bank), обучения (Duolingo, Todoist, MyStudyLife) и здоровья (e.g. Endomondo Sports tracker, Noom Walk, WaterDrink). Их называли в 14,1% случаев.



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


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



США, 2013 [4].

Y. H. Kim с соавторами предложили теоретическую модель вовлечения пользователей мобильных устройств (MoEN) (рис. 4).






Рисунок 8: Модель вовлечения пользователей мобильных устройств согласна Y. H. Kim с соавторами.



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



Дополнительно Y. H. Kim и коллеги ввели конструкт мотивации пользователей мобильных устройств и разделили ее на 3 группы:

– функциональная (эффективность, простота использования, экономия времени),

– гедонистическая (радость, наслаждение, приятные эмоции),

– социальная (желание быть связанным и делиться эмоциями и информацией с другими).



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



Для проверки модели исследователи разработали опросник (см. Приложения, №3). В основном исследовании приняли участие 297 студентов (50,3% мужчин и 49,3% женщин). Модель подтвердилась, подробнее: [4].


Испания, 2017 [13].

В этом исследовании снова все параметры – от простоты использования до вовлеченности – измерялись опросником (см. Дополнения, №6). В исследовании участвовало 750 испанских студентов (16–35 лет). Авторы хотели проверить, как бесплатный доступ, простота использования и тип контента влияют на удовлетворенность сервисом. И как удовлетворенность, в свою очередь, влияет на лояльность, вовлеченность, взаимодействие и желание рекомендовать сервис.

Оказалось, что только простота использования была связана с удовлетворенностью. А удовлетворенность оказалась связана с лояльностью и вовлеченностью и – меньше – с желанием рекомендовать и взаимодействием (рис. 9).






Рисунок 9. Модель влияния качеств приложения на удовлетворенность и вовлеченность.



Эксперимент

Италия, 2015 [11].

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

Авторы намеренно измеряли вовлеченность двумя способами: 1) вовлеченность в приложение – через количество заполненных вопросов теста и 2) вовлеченность в проблему – через кривую научения (по количеству ошибок в тесте).




Эксперименты на вовлеченность иногда проводятся и в естественных условиях. И признаки вовлеченности могут быть тоже естественными, как в домашнем эксперименте моего знакомого (рис. 10).



Россия, 2017.

Скорее всего, сохранившиеся пельмени стали бы показателем более глубокого уровня вовлеченности.




Рисунок 10. Пост моего знакомого о жизни, водке и женщинах.



Комбинированные исследования

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



США, 2017 [6].

Д. Леджер и Д. МакКафри провели анализ фитнес-устройств и выделили факторы, которые обеспечивают долгосрочную вовлеченность пользователей. Авторы измеряют вовлеченность просто, как длительность использования устройства, но все же обратили внимание на психологические условия для ее возникновения. Они сравнили устройства по 9 техническим и 3 психологическим условиям создания вовлеченности. По мнению авторов, даже если одно условие не будет соблюдено, вовлечение может не состояться. 3 психологических условия напрямую связаны с назначением устройств и могут быть применимы только к ограниченной группе приложений. Так, для фитнес-устройств психологическими факторами вовлечения являются: формирование привычки, социальная мотивация и подкрепление целей. На картинке представлен результат сравнения 8 устройств.



К сожалению, мне не удалось найти методологию назначения баллов по каждому условию (возможно, это был метод опроса экспертов). Тем не менее, графическое сравнение выглядит любопытно и дополняется подробным описанием каждого условия с примерами (рис. 7). Отчет находится в открытом доступе в Интернете [6].






Рисунок 11. Сравнение фитнес-устройств по фактором долгосрочной вовлеченности пользователей.



США, 2017 [7].

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



Методы:

– заполнение on-line дневников дважды в неделю в течение 4 недель (см. Дополнения, №5),

– опросник самоэффективности «Healthcare Technology Self-efficacy (HTSE)» с 7-ступенчатой шкалой Лайкерта (от «полностью не согласен» до «полностью согласен»),

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



Выборка: 34 пользователя фитнес-трекеров Fitbit и Jawbone. Исследование показало, что на мотивацию пользователей больше всего влияют 3 аспекта: данные, геймификация и контент.




Методы без участия пользователя

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

Создатели приложений часто все решают сами, а при вопросах об исследовании пользователей ссылаются на высказывания Г. Форда («Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь»), С. Джобса «Создавать продукт, опираясь на фокус-группы, по-настоящему трудно. Чаще всего люди не понимают, что им на самом деле нужно, пока сам им этого не покажешь» и А. Лебедева («Ответ одного дурака с улицы никого не волнует. Но ответы сотни дураков называются результатом исследования фокус-группы и продаются за деньги»).


В принципе, все верно: какие фокус-группы могут быть на этапе создания идеи? Тут нужны совсем другие методы. И группа методов без участия пользователя – только небольшая часть из них.

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



Физиологические измерения

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

Обзор таких методов в исследовании пользователей требует отдельной статьи. А пока, можно посмотреть англоязычные обзоры из списка источников [1, 12, 13].



Португалия, 2017 [21].

Исследователи решили проверить, насколько применимы программы по распознаванию эмоций в изучении вовлеченности игроков компьютерных игр. Оборудованием служила камера, снимающая лицо игрока, и программное обеспечение: скрипт, написанный Ergo VR Laboratory c использованием Affdex SDK для Unity от Affectiva.

Проверка прошла удачно. Распознанные программой эмоции соответствовали тому, что выражали игроки, и хорошо отражали затруднения, которые испытывали некоторые пользователи во время игры (рис. 12).




Рисунок 12. Различия эмоций 2 игроков в одинаковых ситуациях игры.



Как это применить к моему приложению?

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


7. Как выбрать метод на разных этапах разработки продукта.

Все, путешествие заканчивается. Здесь мы обсудим еще один подход к выбору метода исследования: подход с позиции стадий развития продукта. Разговаривать почти не будем – сразу перейдем к таблицам, в которых представлены все выводы.



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



Я использовала такие стадии развития продукта: Поиск идеи – Оценка прототипа – Оценка MVP (минимально жизнеспособного продукта) – Оценка полной версии – Оценка обновления. А затем отметила, какие методы уместно использовать на каждой стадии развития продукта.



Таблица 6. Выбор методов исследования для разных этапов развития продукта и типов приложений.





Еще раз разберем на пальцах самые распространенные методы исследования.





Рисунок 13. Самые распространенные методы исследования на разных стадиях развития продукта «на пальцах».



Как это применить к моему приложению?

Я прошла стадию разработки идеи и использовала на ней дизайнерские эвристики и бенчмаркинг. Теперь у меня есть набор методов для каждой стадии развития моего приложения.




На случай, если вы пропустили выводы в начале статьи:



Самые короткие выводы из статьи

1. Что хотите исследовать?

1) как пользователь относится к продукту/бренду: исследуйте маркетинговую вовлеченность.

2) насколько пользователь вовлекается в использование приложения: исследуйте пользовательскую вовлеченность.

2. Как определяют вовлеченность: Таблица 1.

3. Через что исследуют вовлеченность: Таблица 2.

4. Как измерять уровни вовлеченности: Таблица 3.

5. Что исследовать для разных типов приложений и вовлеченности: Таблица 4.

6. Как выбрать метод на разных стадиях развития продукта: Таблица 6.

7. Какие анкеты используют исследователи: см. Приложения



Надеюсь, мое расследование и придуманные классификации помогут в понимании и исследовании вовлеченности. Буду рада вашим дополнениям.



Полезные источники

1. Measuring user engagement / M. Lamas, H. O’Brien, E. Yom-Tov. – 2013. – Презентация.

2. Media & Entertainment Apps: A World of Engagement [Infographic] / T. Sommer. – 2015.

3. Models of User Engagement / J. Lehmann [et al.] // Lecture Notes in Computer Science. – 2012. – Vol. 7379. – P. 164–175.

4. A study of mobile user engagement (MoEN): Engagement motivations, perceived value, satisfaction, and continued engagement intention / Y. H. Kim, D. J. Kim, K. Wachter // Decision Support Systems. – 2013. – 56. – P. 361–370.

5. Mobile Application Driven Consumer Engagement / A. Tarute, S. Nikou, R. Gatautis // Telematics and Informatics. – 2017.

6. How The Science of Human Behavior Change Offers The Secret to Long-Term Engagement / D. Ledger, D. McCaffrey. – 2014.

7. Motivation and User Engagement in Fitness Tracking: Heuristics for Mobile Healthcare Wearables / S. Asimakopoulos, G. Asimakopoulos, F. Spillers // Informatics. – 2017, 4(1), 5.

8. Mobile Technology Usage Mediates Gender Differences in Physical Activity / Whitehead, A.E. [et al.] // International Journal of Sport Psychology – 2017.

9. If You Let Them Build It, They Will Stay! An Empirical Study of Add-on Content and User Engagement / I. Kanat [et al.] // Hawaii International Conference on System Sciences. – 2017.

10. Exploring Compliance: Observations from a Large Scale Fitbit Study / L. Faust [et al.] // Proc. of Social Sens. – 2017.

11. Measurements of engagement in mobile behavioural interventions? / A. Weston // Digital Health. – 18 — 20 May 2015. – 8 p.

12. Assessment of fun in interactive systems: A survey / L.C. Vieira, F.S. Corr^ea da Silva // Cognitive Systems Research. – 2017.

13. Exploring technology satisfaction: An approach through the flow experience / C. Calvo-Porral, A. Fa'in~a-Med'in, M. Nieto-Mengotti // Computers in Human Behavior. – 2017. – 66. – P. 400–408.

14. The development and evaluation of a survey to measure user engagement / H. L. O'Brien, E. G. Toms // Journal of the american society for information science and technology. – 2010. – № 61. – P. 50–69. 

15. Measuring emotion: The self-assessment manikin and the semantic differential / M.M. Bradley, P.J. Lang // Journal of Behavior Therapy and Experimental Psychiatry. – Vol. 25, Iss. 1. – 1994. – P. 49–59.

16. The Tale of High Retention, Low Engagement Game / R. Vladimiro //https://ongamesndata.wordpress.com/2015/08/04/engagement-101.

17. Психотипы Бартла и балансировка аудитории / Сахнов К. // https://habrahabr.ru/company/mailru/blog/263839/.

18. Maximizers and Satisficers: A Look into Consumer Regret and Dissatisfaction / T. Correia // Poster presented at the McDonough Undergraduate Research Symposium on November 7th, 2013.

19. Lab Testing Beyond Usability: Challenges and Recommendations for Assessing User Experiences / C. Lallemand, V. Koenig // Journal of usability studies. – Vol. 12, Iss. 3. – 2017. – P. 133–154.

20. Maintaining engagement in long-term interventions with relational agents / Bickmore, T., Schulman, D., and Yin, L. // Applied Artificial Intelligence. – 2010. – № 24, 6. – Р. 648–666.

21. Potentialities of a Face Reading Tool to a Digital Game Evaluation and Development: A Preliminary Study / Y. Trindade, F. Rebelo, P. Noriega // Advances in Ergonomics in Design. – 2017. – P. 371–381.



8. Приложения. Несколько переведенных методик.

Не то, чтобы эти методики были образцовыми. Большинство из них, кроме №2, я не стала бы применять без редакции. Размещаю их для знакомства, так как выше мы обсуждали исследования, построенные на их использовании.



1. Шкала оценки эмоций PANAS (Positive and Negative Affect Schedule)

Насколько каждое слово отражает ваши чувства в данный момент (1 = совершенно не отражает; 2 = в малой степени отражает; 3 = умеренно отражает; 4 = довольно точно отражает; 5 = совершенно точно отражает). Пункты рекомендуется давать не по порядку.

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

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



2. Методика самооценки эмоций Self-Assessment Manikin (SAM) [15].

Довольно старая методика (1994 г.). Она помогает оценить эмоции визуально. Участник исследования последовательно выбирает по 1 карточке в каждом ряду, чтобы лучше описать эмоцию, которую он испытывает: 1 ряд – модальность эмоции, 2 ряд – уровень возбуждения, 3 ряд – доминирование, сила эмоции. Методика хороша тем, что обходит лингвистические барьеры и позволяет проводить исследования с детьми и представителями разных культур.

При этом, результаты замеров можно кодировать в числовые значения и переводить в количественные измерения, как это сделали авторы методики, сравнивая ее показания с показаниями семантического дифференциала [15].







1. Анкета для измерения вовлеченности пользователей мобильных устройств [4].

Вопросы оце
Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Почему мобильные приложения занимают все больше места

Пятница, 07 Июля 2017 г. 11:41 (ссылка)

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



Инфографика 1

Инфографика 2



Авторы инфографик в оригинальных статьях выделяют две причины такого роста:




  • повышение максимального допустимого размера приложений AppStore

  • оснащение телефонов все большим объемом памяти



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

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



Инфографика 3



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



Лишние копии ресурсов в приложении



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



В одной из статей автор решил детально разобрать внутреннее строение приложения Facebook для iOS после того, как оно увеличилось за полгода с 165 до 253 мегабайт. Он обнаружил, что в приложении содержалось свыше 40 мегабайт избыточных дублирующих данных. В основном это были картинки, но также были и абсолютно идентичные внутренние программные файлы. Таким образом, просто удалив дубликаты, можно было бы уменьшить размер приложения на 15% процентов. Что, кстати, Facebook впоследствии и сделал.



А/Б тестирование и внедрение новых функций



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



Переход на более комфортные языки программирования



В случае с приложениями под iOS переход с Objective-C на Swift может дать увеличение размера скомпилированного кода приложения в 3-4 раза. Это происходит из-за того, что ради удобства и скорости разработки новые языки могут:




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

  • вводить дополнительные тесты и проверки в код при компиляции

  • использовать большую стандартную библиотеку функций



Сюда же можно отнести переход приложений на новые фреймворки, которые тащат с собой много необходимых им файлов.



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



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



Среди наиболее популярных "велосипедов", заменяющих стандартные средства ОС, можно выделить:




  • Браузеры

  • Работа с камерой

  • Ввод текста и обработка жестов

  • Проверка орфографии



Рост требований к приложениям



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




  • После появления Retina разработчиков обязали добавлять картинки с большей детализацией и соответственно размеров.

  • Переход iOS с 32 на 64 бита впоследствии заставил всех разработчиков выпускать именно 64-битные приложения.



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332602/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Запуск Zelle — доказательство того, что финтех-компании могут оказывать влияние на крупные банки

Среда, 05 Июля 2017 г. 10:44 (ссылка)

https://habrahabr.ru/post/319752/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<мобильные приложения - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda