Чтобы создать лучший опыт, инженерам нужны лучшие доступные данные.
Мобильные устройства усложняют эту задачу, поскольку переменные включают в себя типы устройств, различные операционные системы и возможности подключения, и это лишь некоторые из них.
С растущим числом инструментов, каждый из которых предлагает различные уровни прозрачности состояния, производительности и стабильности вашего мобильного приложения, может быть сложно точно определить, какие показатели вам следует отслеживать.
В этом посте мы опишем наиболее важные показатели производительности, которые необходимо отслеживать, и то, как они помогут вам быстрее выявить первопричину проблем и улучшить качество мобильного взаимодействия.
Мобильные пользователи обычно проверяют свои приложения на ходу и привыкли получать мгновенные результаты. Поэтому они не будут сидеть и ждать, пока приложение загрузится. Например, если приложение Uber загружается слишком долго, пользователь, скорее всего, вместо этого переключится на приложение Lyft. Кроме того, пользователи, у которых был плохой опыт работы с приложением Uber и приличный опыт работы с приложением Lyft, с гораздо большей вероятностью станут лояльными пользователями Lyft.
Теперь вы не только потеряли доход от сеанса этого пользователя, но и ваши затраты на привлечение и отток увеличились, не говоря уже о LTV, который этот конкретный клиент мог бы принести компании.
Поэтому обеспечение того, чтобы время запуска вашего приложения соответствовало ожиданиям пользователей, имеет важное значение для его успеха.
Однако если мобильная команда имеет доступ только к среднему времени запуска , они, вероятно, пропустят ключевые изменения и будут реагировать скорее реактивно, чем проактивно.
Например, предположим, что компания запускает свое приложение на новый рынок, и общий отзыв отрицательный. Среднее время запуска показывает, что приложение работает на несколько миллисекунд дольше, чем было до запуска, но это не означает, что во время запуска оно стало значительно медленнее. Значит, должна быть еще одна проблема, верно?
К сожалению, поскольку процент пользователей на новом рынке составляет лишь часть общей базы пользователей, вполне логично, что даже ужасное время запуска на новом рынке лишь минимально повлияет на общее время запуска базы пользователей.
Вместо этого команде необходимо иметь возможность сегментировать данные, чтобы лучше понять, как время запуска влияет на бизнес.
Например, как ценные пользователи страдают от медленных запусков? Пользователи на новом рынке испытывают худшую производительность? Некоторые устройства запускаются медленнее?
Эти данные возвращают вашей компании контроль над ситуацией и позволяют избежать догадок в срочных сценариях, которые влияют на ваш доход.
Чтобы узнать больше, прочтите нашу электронную книгу о том , как улучшить время запуска мобильного приложения .
Сбои — верный способ разозлить клиентов, и на это есть веская причина! По сути, это то же самое, что покупатель заходит в обычный магазин, где персонал выгоняет его за дверь на полпути с покупками.
Это серьезная проблема для бренда компании по двум причинам:
Это наносит ущерб репутации вашего бренда , поскольку клиенты чувствуют, что к их времени не уважают.
Это вредит вашему доходу, поскольку клиенты не могут завершить свою немедленную транзакцию, и вы теряете пожизненную ценность этого клиента, если он решит переключиться на конкурента.
Вот лишь несколько примеров из различных отраслей, где крах напрямую приводит к потере доходов:
Приложения для электронной коммерции. Если приложение электронной коммерции выходит из строя во время оформления заказа, клиент не сможет совершить покупку и, скорее всего, не вернется.
POS-системы : если POS-система выйдет из строя во время живого мероприятия, ни один из живых клиентов не сможет совершить покупку или войти на место проведения.
Приложения для смарт-устройств . Если смарт-устройство, например зубная щетка, выходит из строя во время процесса установки, весьма вероятно, что клиент вернет продукт.
Однако, хотя отслеживание средней частоты сбоев является хорошим началом, этого все же недостаточно, чтобы понять, как сбои влияют на ваш бизнес .
Например, если текущий уровень сбоев составляет всего 0,5%, вы можете не видеть необходимости копать глубже. Однако что, если все сбои происходят на экране оформления заказа? Этот крошечный процент может лишить бизнес значительных доходов.
Таким образом, помимо рассмотрения основных показателей, также важно иметь данные, показывающие закономерности в частоте сбоев. В частности, как работают различные важные области вашего приложения? Какие устройства чаще всего подвержены сбоям? Как приложение работает для ценных пользователей? Есть ли регионы с особенно низким уровнем аварийности? И если да, то следует ли исправить приложение или удалить его из этих регионов?
Сегментируя детали сбоев, ваша команда сможет лучше расставить приоритеты в устранении проблем.
Ошибки «Приложение не отвечает» (ANR) обычно описываются как зависания или сбои.
По сути, если основной поток заблокирован, приложения не могут работать эффективно. Таким образом, пользователь не может продолжить работу, что может оказать серьезное влияние на ваш бизнес.
Например, у розничного продавца, с которым мы работали, возникла проблема с ANR. Эта проблема привела к увеличению времени запуска почти на 60%, что привело к предполагаемой потере дохода в размере 6,5 миллионов долларов США в год. Имея правильные данные , команда инженеров смогла быстро решить проблему и вернуть потерянный доход.
Помимо дохода, ошибки ANR также могут негативно повлиять на рейтинг приложения в Google Play Store и сделать его менее заметным для новых клиентов.
Чтобы эффективно отслеживать ошибки ANR, вы можете просмотреть трассировку стека и узнать, как пользователи отреагировали на проблему.
Отсюда мобильная команда может расставить приоритеты, что исправить в первую очередь, исходя из того, сколько людей уходят при различных пороговых значениях, где наиболее ценные пользователи страдают больше всего и на какие типы устройств и экраны больше всего влияют ошибки ANR.
Чтобы узнать больше, прочтите этот пост о расследовании сбоев Android, таких как ANR .
Отслеживание показателей региона также очень важно, поскольку пользователи в разных регионах имеют разные устройства и разные возможности подключения.
Это может оказать серьезное влияние на бизнес по нескольким причинам.
Во-первых, регионы различаются по своему значению для прибыли бизнеса.
Например, возможно, только часть ваших пользователей находится в Сингапуре, но они могут составлять значительную часть вашего общего годового дохода. Таким образом, проверка показателей региона на детальном уровне позволит выявить возможности для улучшения приложения, особенно для ценных пользователей.
Отслеживание показателей сегментированного региона также важно при запуске нового региона.
Например, предположим, что вы расширяетесь в Австралию, но на момент запуска эта географическая область составляет только 5% всех пользователей. В этом случае это не окажет достаточного влияния на медианные/средние показатели, чтобы команда могла эффективно отслеживать производительность.
Также важно принимать во внимание культурные различия, и с помощью инструмента, который предоставляет показатели для конкретного региона, команда может протестировать определенные аспекты приложения только для этого региона.
Например, экран оформления заказа в электронной коммерции, который хорошо конвертируется в США, может не так же конвертироваться в Дубае.
Кроме того, детальные показатели региона позволяют легко и медленно развертывать новые функции. Например, команда может развернуть новую функцию в меньшем регионе и посмотреть, как она работает. Если он работает хорошо, распространите его на все больше и больше регионов с более ценными пользователями.
Эти данные могут помочь вашей команде ответить на такие важные вопросы, как:
Еще один ключевой показатель, за которым следует следить, — это продолжительность сеанса, поскольку она сигнализирует о том, как долго пользователи используют ваше приложение. Если средняя продолжительность сеанса резко меняется в течение недели, это хороший намек на то, что с приложением возникла проблема.
Например, если у вас есть игровое приложение и вы заметили, что средняя продолжительность сеанса снизилась с 15 минут до 5 минут, велика вероятность, что у пользователей остались плохие впечатления.
Используя эту подсказку, вы можете задавать такие вопросы, как:
Отслеживание продолжительности сеанса также позволяет команде исследовать закономерности среди затронутых отдельных сеансов и обнаруживать основную причину проблем. Анализируя продолжительность сеанса параллельно с другими показателями, мобильные инженеры могут составить более четкое представление о том, какие проблемы наиболее беспокоят пользователей.
Например, в магазине электронной коммерции может возникнуть проблема OOM в основном прокручиваемом канале продуктов, которая сильно коррелирует с более короткой продолжительностью сеанса, тогда как медленные сетевые вызовы на другом экране практически не коррелируют с продолжительностью сеанса.
Таким образом, отслеживание продолжительности сеанса — отличный способ определить приоритетность проблем, которые следует устранить в первую очередь, поскольку это напрямую указывает на снижение вовлеченности пользователей.
Привлечение нового клиента обходится гораздо дороже, чем поддержание удовлетворенности текущего клиента, а основной причиной оттока пользователей мобильных приложений является плохой пользовательский опыт.
Загрузка нового приложения занимает всего несколько секунд, поэтому, если работа с приложением отвлекает пользователя и занимает более нескольких секунд его времени, не ждите, что он задержится.
Таким образом, отслеживайте не только общий уровень оттока и удержания, но также уровень оттока и удержания сегментов пользовательской базы (по устройствам, способам подключения, регионам и т. д.).
Это высветит различные возможности для улучшения и определения приоритетов удержания. Например, вы можете обнаружить, что, хотя в одном конкретном регионе уровень оттока очень высок, в этом регионе мало ценных пользователей. Поэтому вы можете решить инвестировать инженерные ресурсы в другое место, где они принесут более значительные результаты для бизнеса.
Отслеживание оттока и удержания также является отличным способом понять, как пользователи реагируют на новые выпуски и различные эксперименты. Если существует корреляция между высоким оттоком и новым обновлением функции, это явный признак того, что команде необходимо откатить это обновление функции.
Подробные данные позволят команде отслеживать отток различных сегментов (например, определенных регионов или устройств), на которые распространяется обновление.
Без сегментированных данных будет трудно увидеть влияние, которое различные обновления функций оказывают на небольшие группы тестирования. Таким образом, только после того, как функция будет развернута для большой группы пользователей (и, предположительно, это приведет к уходу многих активных пользователей в месяц), станет очевидно, что внедрение функции было преждевременным.
Хотя некоторые пользовательские завершения являются не чем иным, как тем, что пользователь наводит порядок на своем телефоне, многие завершения происходят из-за того, что приложение зависло, и у пользователя нет другого выбора, кроме как провести пальцем вверх и завершить сеанс.
Конечно, пользователь, вынужденный завершить сеанс, скорее всего, будет недоволен и вместо этого выберет приложение конкурента.
Чтобы предотвратить это, отслеживание среднего показателя увольнения пользователей является отличным индикатором потенциальных проблем, которые могут привести к оттоку, в том числе:
Помимо предоставления обзора средних показателей увольнений пользователей, мобильным командам необходимо знать источник каждого плохого пользовательского опыта. Поэтому одна из ключевых функций, которые мы встроили в Embrace, — это возможность увидеть , какие экраны заставляют разочарованных пользователей покидать ваше приложение .
Таким образом, вместо того, чтобы тратить драгоценное время и терять продажи, пока инженеры гадают, где происходят отключения, мобильная команда немедленно направляется к проблеме, чтобы они могли устранить проблему максимально эффективно.
Вероятно, в вашем приложении есть несколько действий пользователя, которые обязательно должны работать в 100% случаев. Например, если офис предлагает вход без ключа, эта функция должна работать каждый раз. В противном случае люди не смогут войти в офис без вызова дополнительной поддержки.
Поэтому выберите несколько ключевых действий пользователя и добавьте их в список показателей эффективности, которые отслеживает мобильная команда.
Во многих случаях в отзывах клиентов не говорится, где они столкнулись с проблемой в приложении, поэтому отслеживание конкретных действий пользователя — отличный способ выявить проблемы, которые в противном случае не проявляются сразу.
Это также поможет вам ответить на такие вопросы, как:
Сколько пользователей испытывают проблемы в этих критических областях приложения?
Существует ли прямая связь между проблемами в конкретных областях приложения и оттоком?
Как долго пользователи пробуют, прежде чем сдаться и отказаться от приложения?
Например, один из наших клиентов заметил, что около 1% всех попыток покупки заканчиваются неудачей. Однако оба связанных сетевых вызова разрешались успешно, поэтому очевидных ошибок, требующих проверки, не было.
Поэтому они начали отслеживать точный момент, когда клиент совершал покупку, и обнаружили, что два сетевых вызова происходили не по порядку в 1% попыток покупки, что приводило к неудачной покупке. Хотя клиенты жаловались на эту проблему, мобильная команда не смогла определить основную причину, не зная времени, результата и порядка всех событий в затронутых сеансах. Высокоточные данные о пользовательском опыте были жизненно важны для того, чтобы помочь им вернуть 1% от общего объема продаж. Для компании, годовой объем продаж которой составляет 10 миллионов долларов, это 100 000 долларов, которые в противном случае были бы потеряны каждый год!
Важно отслеживать потребление памяти вашим приложением, чтобы выявить любые потенциальные утечки памяти. Эффективность использования памяти вашим приложением напрямую зависит от того, насколько отзывчивым является ваш пользовательский интерфейс.
Вот почему мониторинг и оптимизация использования памяти играют решающую роль в обеспечении бесперебойной работы пользователя.
Вы можете избежать проблем с использованием памяти вашим приложением:
Оптимизация вашей кодовой базы и выявление областей, в которых память непреднамеренно сохраняется, приводит к увеличению использования памяти.
Регулярное отслеживание потребления памяти вашим приложением, отмечая любые изменения после новых выпусков.
Тщательный мониторинг операций с интенсивным использованием памяти, таких как загрузка больших изображений или обработка больших файлов, а также создание предупреждений об аномальных пиках или постоянном высоком использовании памяти.
Тщательно настроенная стратегия в отношении потребления памяти вашим приложением позволяет создавать отзывчивые, стабильные и эффективные приложения, которые понравятся вашим пользователям.
Мобильные приложения работают в различных средах с разными условиями сети , включая 3G, 4G, 5G, Wi-Fi, а иногда и с ограниченным или нестабильным подключением.
Вот почему важно осознавать проблемы, возникающие в этих различных условиях, чтобы создать отличный пользовательский опыт. К показателям плохой производительности сети относятся:
Задержка и медленное время отклика.
Использование полосы пропускания.
Неэффективные вызовы API.
Автономные возможности для конкретного устройства.
Например, Farm Dog — это сельскохозяйственное приложение, которое позволяет фермерам и агрономам документировать свои результаты, пока они находятся в поле со своими коллегами и коллегами.
Приложение часто аварийно завершало работу, когда время ответа сети было очень медленным и когда устройства не могли определить, подключены ли они. Они заметили, что время ответа Google Maps составляет 18–22 секунды, хотя должно быть всего несколько секунд.
Без надлежащего инструментария им пришлось бы использовать сложные обходные пути для решения проблем с использованием прокси-сервера для имитации плохого сетевого соединения. Однако благодаря более точным данным они могут увидеть точные условия, в которых находятся пользователи в полевых условиях, в том числе:
Сетевые вызовы между типами устройств, версиями приложений, Wi-Fi и сотовой связью.
Анализ тенденций ошибок 4xx и 5xx в общих областях для выявления проблемных путей.
Неработающие конечные точки, которые не позволяют вашим пользователям запускать приложение, загружать ключевой контент или выполнять важные транзакции.
Продолжительность каждого сетевого вызова со стороны клиента выявляет скрытые точки задержки.
Вооружившись этой информацией, команда Farm Dog смоделировала проблемы, с которыми столкнулись их пользователи, легко определила проблемные условия и устранила их.
Если вас волнует мобильный опыт, вам нужны данные, которые позволят вашей команде увидеть все показатели, упомянутые выше.
Embrace помогает вам улучшить мобильный опыт, предоставляя вам только эти данные, что делает ваших инженеров более эффективными и менее утомленными утомительной работой.
Узнайте больше об Embrace и загрузите отчет «Состояние мобильного опыта» , чтобы узнать об основных разочарованиях в приложении, по мнению пользователей.
Также опубликовано здесь .