Публикация приложения в Магазине 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);
},В заключение: телеметрия как инвестиционный проект
Сбор телеметрических данных и просмотр результатов их анализа, безусловно, важны для улучшения приложения и решения проблем, возникающих у клиентов. Более того, каждое приложение, инструментируемое для поддержки телеметрии, становится долгосрочным инвестиционным проектом. Она помогает в создании всех приложений: новые знания, полученные от каждого приложения, заметно повышают качество последующих. Вы намного лучше поймете, чего ожидают пользователи и что их больше всего привлекает, и сможете применить эти знания в каждом проекте. В числе причин для выпуска одного или нескольких бесплатных приложений и создания большой базы пользователей для каждого из них –– сбор телеметрических данных. Они помогут сделать серьезное вложение в приложение, которое вы хотели бы монетизировать.
Как я уже говорил в начале статьи, все собранные данные и полученные с помощью аналитики знания — это настоящая золотая жила, а затраченные сегодня усилия по инструментированию приложения с высокой вероятностью приведут к получению дивидендов в будущем.