Инструментирование приложения с помощью средств телеметрии и аналитики

Публикация приложения в Магазине Windows и Магазине Windows Phone — это лишь первый шаг к налаживанию отношений с клиентами. Конечно же, вы надеетесь, что многие пользователи найдут и установят ваше приложение, поставят ему оценку и напишут отзыв. На информационных панелях Магазина представлено множество сведений: ежедневная средняя частота использования приложения в сравнении с другими приложениями из данной категории, отчеты о качестве (аварийные дампы, случаи зависания и исключения), оценки и отзывы, показатель принятия новинки, история загрузок, покупки внутри приложения и продажи самого приложения). Для получения более подробной информации, в том числе о том, как подключить системы сбора данных, обратитесь к статье «Сбор телеметрических данных приложений». Кроме того, полезную аналитическую информацию по всему Магазину предоставляют сторонние поставщики, такие как Distimo и AppFeds, что позволяет отслеживать тенденции и активность по всему рынку.

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

Журналирование или телеметрия?

Возможно, вы сейчас думаете: «Нет проблем — в моем коде полно всяческих способов журналирования. Разве они не подходят?» Конечно, журналирование — это хорошее начало, но обычно его используют только в процессе разработки для диагностики ошибок и выполнения кода. Журналирование ориентировано на внутреннюю структуру приложения и не отражает поведения пользователей на практике. Иными словами, журналирование — это лабораторный сбор данных о приложении. Оснастив же приложение средствами телеметрии, вы сможете собирать данные после выпуска приложения.

Телеметрия, или телеизмерение, — это автоматическое удаленное измерение и сбор данных. Ее используют в различных отраслях, например, для наблюдения за космическими аппаратами, дикими животными, для мониторинга в медицине, правозащите и т. п. Электрический счетчик, подключенный к моему дому, автоматически отсылает показания в энергоснабжающую компанию; специальные работники, снимающие показания, не требуются. Мне особенно нравится рассматривать телеметрию в контексте космических аппаратов, где она является единственным способом наблюдения за состоянием и работой очень дорогой аппаратуры сотрудниками ЦУП.

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

Золотая жила

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

• Как пользователи взаимодействуют с приложением? Используют ли пользователи те возможности, которые, как вам казалось, им были нужны?
• На что они тратят (или не тратят) свое время? Как долго длится каждый сеанс работы с приложением, сколько времени проходит между сеансами, между паузой и продолжением работы?
• Какие конфигурации устройств предпочитают пользователи (размер области просмотра, ориентация экрана, тип дисплея, метод ввода)?
• Как пользователи используют опции из предоставленных вами настроек приложения?
• Что происходит при аварийном завершении работы приложения? Как часто пользователи сталкиваются с ошибками, не ведущими к аварийным сбоям (неудавшимися HTTP-запросами, синхронизациями, истечением срока ожидания и т. п.)?
• Насколько удачны и привлекательны функции приложения? Используются ли социальные возможности? Есть ли модели использования, которые следует поощрить (или нет) определенным образом, чтобы повлиять на поведение пользователей?
• Насколько удачны пробные версии и (или) покупки из интерфейса приложения? Каково наиболее удачное расположение напоминаний о возможном преобразовании пробной версии в коммерческую и (или) встроенных покупках? Сколько пользователей просматривают варианты приобретения, но ничего не покупают?
• Щелкают ли пользователи по рекламным объявлениям (или переходят на коммерческую версию для того, чтобы от них избавиться)?
• Как часто пользователи работают в режиме онлайн в сравнении с автономным режимом?
• На чем стоит сфокусировать инвестиции, чтобы повысить качество и производительность приложения, а также разработать новые функции? Какие идеи можно протестировать в следующем обновлении или отдельном приложении?
• Соответствует ли приложение намеченным бизнес-целям?

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

Проектирование телеметрии для намеченных бизнес-задач

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

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

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

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

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

Если вы думаете о диаграммах (наверное, это самый популярный способ изучения аналитических данных), важно понимать, что на них также будут отражаться присвоенные событиям свойства и атрибуты. Именно поэтому числовые атрибуты с широким спектром значений лучше группировать в сегменты или диапазоны, а не выводить в виде дискретных значений. К примеру, вы можете отслеживать время, потраченное на определенную страницу или прохождение одного уровня игры в диапазонах 0–5, 6–10, 11–20, 21–60, 61–120 сек. и т. д., и выводить на круговой диаграмме или гистограмме столько элементов, чтобы она была понятна.

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

Инструментирование приложения

Надеюсь, я убедил вас, что инструментирование приложения с целью поддержки телеметрии — это хорошая идея! Как тогда это сделать? Имеются два варианта:

• Сложный метод: внедрить собственный API для отслеживания и журналирования, разместить вызовы этого API по всему приложению, создать серверную службу, на которую будут регулярно загружаться собранные данные (и обеспечить ее масштабирование до тысяч или десятков тысяч пользователей), а затем построить целый механизм аналитики для переработки этих данных в понятные отчеты.
• Простой метод: зарегистрироваться у стороннего поставщика средств аналитики, который делает всю сложную работу за вас. Внедрить его SDK в собственное приложение, создать вызовы его API там, где нужно, и проводить большую часть времени, совершенствуя приложение с учетом полученных аналитических данных!

Если у вас нет готовой инфраструктуры, полагаю, вы выберете простой метод! Если вы посетите Каталог партнеров Windows и щелкнете фильтр Analytics (Аналитика) слева, то увидите несколько компаний, предлагающих нужные инструменты. Эти компании занимаются тем, что превращают необработанные данные телеметрии в полезную аналитику — и тут я с радостью полагаюсь на их опыт!

Обратите внимание, что в этом каталоге указаны не только партнеры, предоставляющие услуги телеметрии, которые мы обсуждаем. Имеются также партнеры, предоставляющие средства отслеживания ошибок, рыночной эффективности или инструменты для составления отчетов о рыночных тенденциях (это полезно, но не совсем то, что мы рассматриваем). Потратьте немного времени на просмотр данного списка, и вы найдете тех, кто вам нужен: например, Localytics,  MarkedUp, AppFireworks,  mtiks,  Adobe Omniture и Parse. (Обратите внимание, что Flurry, самый популярный SDK для аналитики на Windows Phone и других платформах, не указан в списке, поскольку в настоящее время недоступен для приложений Магазина Windows.) Многие другие компании, указанные в списке, работают с приложениями и Магазина Windows, и Магазина Windows Phone. Кроме того, не забудьте проверить, поддерживает ли SDK поставщика используемый в вашем приложении язык. В настоящее время компания Майкрософт работает над созданием собственной платформы для аналитики –– Application Insights.

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

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

Несколько советов

• Используйте отдельные ключи для разработки, бета-тестирования и готовой версии. Цель телеметрии состоит в сборе информации, имеющей практическую ценность, от реальных пользователей. Лучше держать данные, собранные на стадии разработки, отдельно от нее. Вероятно, вам понадобится отделить данные бета-тестирования (например, для загрузки неопубликованных версий, имеющих корреляции с отдельными периодами времени) от конечных данных готовой версии (для приложения, полученного из Магазина). Это означает создание отдельных ключей на портале поставщика и смену их при сборке каждого варианта приложения.
• Создание слоя телеметрии в приложении. Вы сможете с легкостью менять поставщиков в любое время, когда это понадобится, и инкапсулировать любую вычислительную логику или логику сегментирования за интерфейсом слоя, чтобы она не мешала работе приложения. Если включить в каждый метод слоя простой флаг, то это упростит включение и выключение телеметрии (как в случае, если пользователь откажется от нее), не затрагивая другие части кода.
• Протестируйте телеметрию, посещая портал на самых ранних этапах (желательно делать это почаще). В итоге вы занимаетесь этим, чтобы получить важные практические данные из аналитической информации, предоставляемой поставщиком. Когда вы начнете инструментирование, соберите немного данных, а затем зайдите на портал поставщика и просмотрите результаты. Вы быстро поймете, значимы ли события, достаточно ли детальны включаемые в них атрибуты и свойства, правильно ли передаются данные. Например, если вы увидите, что в каком-то атрибуте стоит null, то поймете, что использовали неверную переменную при отправке данных события.
• Тестируйте в автономном режиме. Так вы исключите вероятность того, что слой телеметрии повлияет на состояние сети.
• Не забудьте отключить возможность Internet (Client) в манифесте. Иначе данные так и не доберутся до сервера! Обратите внимание, что если вы не собираете персональную информацию, адреса электронной почты, снимки экрана или историю просмотра веб-страниц, то сбор телеметрических данных не должен влиять на возрастную категорию приложения. Однако вам нужно будет включить политику конфиденциальности.
• Информируйте пользователя и дайте ему возможность отказаться. Данные телеметрии — это один из видов информации о пользователе, пусть даже и не позволяющий вычислить его личность. Поэтому удостоверьтесь, что в описании приложения в Магазине и в политике конфиденциальности указано, что именно вы собираете и как эти данные будут использоваться. Предоставьте опцию для полного отключения телеметрии, если пользователь захочет это сделать.

Приведу небольшой пример: я инструментировал посредством телеметрии игру 15+Puzzle из Магазина Windows, чтобы определить шаблоны использования и особенно шаблоны, влияющие на стратегии монетизации. Я использовал Localytics SDK для JavaScript, но изолировал весь код этого SDK в телеметрическом слое. Этот слой был внедрен в мое собственное пространство имен Telemetry, который определялся следующим образом (все стартовало с функции init):

WinJS.Namespace.define("Telemetry", {
 inputType: { touch: 0, mouse: 1, keyboard: 2},
session: null,
 enabled: true,
 _curPage: null,
 _lastNavTime: 0,
 _settingsTime: 0,

 _timeLastStarted: 0,
 _timeLastCompleted: 0,
 _inputTally: new Array(3),

 _now: function () {
 return new Date().getTime();
 },

 _convertToRange: function (value, granularity) {
 //Для телеметрии не нужно записывать каждое число, лучше сгруппировать числа
 // в диапазоны. Этот метод возвращает строку на основе уровня детализации. Для 25, к
 // примеру, он создаст строки "0-24", "25-49", "50-74" и т. д.

 //Особый случай для настоящего нуля
 if (value === 0) {
 return "0";
 }

 var rangeBase = Math.floor(value / granularity);
 return (granularity * rangeBase) + "-" + ((granularity * (rangeBase + 1)) — 1);
 },

 init: function () {
 var keyDeveloper = "...";
 var keyBeta = "...";
 var keyProduction = "...";

 Telemetry.session = LocalyticsSession(/* key */);
 Telemetry.session.open();
 Telemetry.session.upload();
 } else {
 Telemetry.session = null;
 }

 Telemetry.enabled = (Telemetry.session !== null);

 // Автоматическое журналирование ошибок приложения
 WinJS.Application.addEventListener("error", function I {
 Telemetry.error("WinJS.Application.onerror", { "Line": e.detail.errorLine,
 "Character": e.detail.errorCharacter, "File": e.detail.errorUrl,
 "Message": e.message });
 });
 },

 // Другие методы, связанные с событиями, например с ошибками
}

Как видите, я использую здесь стандартный метод сегментирования, _convertToRange, как и в другом месте в этом слое; остальные методы слоя отражают мой дизайн событий. В том числе: error, appStarted, syspending, resuming, visibilityChange, licenseChanged, appResized, newGrid, restarted, pageNav, scoredCleared, scoresViewChanged, gameStarted, gameRestarted, gameCompleted, tallyInput, optionsEnter, optionsExit, settingsEnter, settingsExit и feedback.

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

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

appResized: function () {
 if (Telemetry.session === null || !Telemetry.enabled) { return; }

 var wgd = Windows.Graphics.Display;
 var displayInfo = wgd.DisplayInformation.getForCurrentView();
 var w = document.body.clientWidth;
 var h = document.body.clientHeight;

 //Конвертация orientation enum в простое значение string
 var orientation = "landscape";

 if (displayInfo.currentOrientation == wgd.DisplayOrientations.portrait
 || displayInfo.currentOrientation == wgd.DisplayOrientations.portraitFlipped) {
 orientation = "portrait";
 }

 //Здесь я группирую размеры окон с детализацией в 200 пикселей для улучшения аналитики
 var data = {
 "Display Orientation": orientation,
 "Scale": displayInfo.resolutionScale,
 "View Orientation": (w < h) ? "portrait" : "landscape",
 "Width": Telemetry._convertToRange(w, 200),
 "Height": Telemetry._convertToRange(h, 200)
 };

 Telemetry.session.tagEvent("View resized", data);
},

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

gameCompleted: function (data) {
 if (Telemetry.session === null || !Telemetry.enabled) { return; }

 data = data || {};
 Telemetry._timeLastCompleted = Telemetry._now();

 //Добавляем диапазон для использованных в игре способов ввода
 data["InputTally_Touch"] =
 Telemetry._convertToRange(Telemetry._inputTally[Telemetry.inputType.touch], 25);
 data["InputTally_Mouse"] =
 Telemetry._convertToRange(Telemetry._inputTally[Telemetry.inputType.mouse], 25);
 data["InputTally_Keyboard"] =
 Telemetry._convertToRange(Telemetry._inputTally[Telemetry.inputType.keyboard], 25);

 //Добавляем атрибут для состояния сети. Сейчас я не использую это в игре,
 //но данные помогут мне понять, стоит ли добавлять сетевые функции
var connected = false;
 //Возвращает null при автономном режиме
 var profile = Windows.Networking.Connectivity.NetworkInformation.getInternetConnectionProfile();

 if (profile != null) {
 var level = profile.getNetworkConnectivityLevel();

 //internetAccess или constrainedInternetAccess, скорее всего, допустимы; none или limitedAccess — нет
 connected = (level == Windows.Networking.Connectivity.NetworkConnectivityLevel.internetAccess) ||
 (level == Windows.Networking.Connectivity.NetworkConnectivityLevel.constrainedInternetAccess);
 }

 data["Has Connectivity"] = connected;
 Telemetry.session.tagEvent("Game completed", data);

},

В заключение: телеметрия как инвестиционный проект

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

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