Connect with us

Статьи

Пользовательское тестирование игры: зачем это нужно и как его провести своими силами

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

Playtestix

Опубликовано

/

     
     

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

Playtestix-logo-BW-no-bck

playtest

Антон Ульяненков, аналитик Playtestix

Ожидания и реальность

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

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

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

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

Формулировка целей и задачи

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

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

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

Кого тестировать?

Как только определились с задачами, можно начинать думать, кто будет тестировать вашу игру. Лучше всего выбрать людей, которые никак не связаны с разработкой вашей игры, разработчики знакомы с игрой слишком близко и это может впоследствии искажать их мнение об игре. Друзья и члены семьи также скорее всего не откажут вам в просьбе поучаствовать, но велика вероятность того, что они не захотят вас расстраивать, если им что-то не понравится, или изначально будут расположены очень положительно к тому, что вы им предоставите.  Не ищите легких путей, уделите поиску нужных людей больше времени. Определитесь с целевой аудиторией вашей игры и попытайтесь привлечь “независимых” тестеров, игровые сообщества и форумы дают сегодня такую возможность. Например, для нашей игры в жанре ферма, это могут быть женщины возрастной группы 30+, пользующийся устройством Android, игравшие в Hay Day или Farmville и достигшие в одной из этих игр 10 уровень.  Тестеров можно мотивировать подарками, но все же основной их мотивацией должна быть любовь к играм. Остерегайтесь профессиональных респондентов.

Выбор методов сбора фидбека от игры

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

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

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

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

Следите за нашими новостями!

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Разработка

Интересные материалы для разработчика мобильных приложений #234 (5-11 ноября)

В нашей новой подборке новости с Android Dev Summit, Continuous integration в Яндексе, тотальная интеграция в Google и интересное руководство по жизненному циклу пользователей. Заходите!

AppTractor

Опубликовано

/

Автор:

Гнущиеся смартфоны и другая информация с Android Dev Summit

Сейчас Google проводит Android Dev Summit, и уже состоялся открывающий кейноут. В основном рассказанное там предназначается Android-разработчикам, но есть и новость, способная заинтересовать более широкие массы: «сгибающиеся смартфоны». Внимательно посмотрев онлайн-трансляцию, мы написали и о поддержке таких устройств, и о другой информации из кейноута.

Руководство по разработке Web-приложений на React Native

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

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 AI, Устройства, IoT

 Вакансии

Комментарии
Продолжить чтение

Маркетинг и монетизация

«Мои игры никто не покупает»: пара простых советов

Компания Inlingo перевела для нас интересный пост Reddit, объясняющий успех тех или иных игр.

AppTractor

Опубликовано

/

Автор:

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

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

Собственно, вот эти игры:

Pillar

The Path of Motus

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

Всю суть авторского вопроса передает следующая цитата:

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

А вот мой ответ:

Прежде всего — я посмотрел трейлер к Pillar и это полный крышеснос.   Очень тягучая, жуткая атмосфера, немного похоже на «I Have No Mouth and I Must Scream».

Далее: вот мой пост на Reddit, очень рекомендую с ним ознакомиться – “Я не зарабатывал деньги до 14 игры“.

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

Если честно — я понимаю, почему ваши игры плохо продаются. Не то чтобы я мог конкретно сказать, что не так… Подача будто бы любительщиной отдает.  Может, вы просто переоцениваете свои навыки как аниматора — игры будто бы изо всех сил кричат, что их делал профи, что они выглядит как Braid. Это не так. А вот та же Castle Doctrine со своим лоу-фай исполнением даже не пытается конкурировать с Braid, так что никому и в голову не придет их сравнивать.

One Hour One Life еще слишком свежа в моей памяти, я необъективен (и да, она выглядит ОФИГЕННО), но люди обычно описывают визуалку в ней как «милую». Почему-то всем нравятся простая мультяшная визуалка, она обезоруживает. Это даже не пиксельная графика, это что-то типа… что-то типа каракулей. Каракулей от руки. Это была моя первая пиксельная игра за добрых десять лет, но я все равно умудрился попасть в яблочко.

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

Далее: что за фигня в игре творится?

Инновации в играх должны быть МАКСИМАЛЬНО ОЧЕВИДНЫ. Человек смотрит трейлер и сразу понимает: так, а в такое я еще ни разу не играл.

Давайте посмотрим на трейлер The Castle Doctrine или One Hour One Life. Человек смотрит и видит, что это, как в это играть (почти как обучение!) и насколько это непохоже на все остальные игры.

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

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

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

Эти концепты сразу заинтриговывали всех, кому бы я их ни рассказывал. Даже не-геймеров.

Иногда я просто сижу и жду, пока меня не осенит. Чтобы так «Ох ты!». Что-то настолько очевидное, что я срываюсь гуглить: а вдруг такую игру уже делали? Концепт, до которого мог бы додуматься абсолютно любой.

Я навскидку могу назвать 5 своих друзей, которые работали над играми, похожими на The Castle Doctrine. Я нервничал, это была почти что гонка. А потом я увидел кино «Судная ночь» (The Purge), она тоже примерно про это же.

В общем: хороший концепт легко ложится в трейлер и легко цепляет игрока.

И последнее: ценность.

Люди обычно решают потратить деньги на игру по одной из двух причин.

  1. Они в таком восторге, что покупают игру сразу, не раздумывая. Это часто связано с нереально крутым визуальным исполнением, как в The Last Night. Люди просто сделают ЗАТКНИСЬ И БЕРИ ДЕНЬГИ, так что игра окупится в любом случае. Сюда же относится Hyper Light Drifter. Такие проекты выстреливают сразу же. Это как левитроны — все хотят, чтобы у них над столом парила какая-нибудь ерунда.
  2. Они долго и вдумчиво взвешивают все pro et contra, их надо завлекать холодными цифрами. Их надо завлекать тем, что игра глубокая, что в нее можно играть неделю, месяц, год. Они обойдут ее, покивают себе, помнут игру между пальцами — да, это стоит двадцать баксов. Для них игра — она как рюкзак. Возьмешь что попало и обязательно прогадаешь, тут надо посмотреть, повыбирать, чтобы одну — и на всю жизнь (да, прямо как жену).

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

И именно поэтому, к сожалению, однопользовательские игры понемногу вымирают, успех Braid или Fez повторяют единицы, да и те играют на эмоциях (см. п. 1). Зато провалившихся игр с внушительным бюджетом — пруд пруди, хотя лет пять назад все они прекрасно окупились бы. И это я даже не говорю о том, что успех Braid или Gone Home нельзя сравнить с успехом Stardew Valley или Factorio, это принципиально разные уровни.

Я не считаю, что инди-игры обречены, я просто считаю, что люди стали играть в разные жанры инди-игр. Старички в шоке от того, что короткие однопользовательские игры стали плохо продаваться, новички в шоке от того же (потому что почти любая первая игра короткая и однопользовательская), но это не означает, что инди в принципе не продаются. Наоборот!

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

И именно поэтому лучше полагаться на второй тип игроков.

Уже 11 месяцев множество людей каждый день играет в The Castle Doctrine. За семь месяцев много кто наиграл в One Hour One Life по 900 часов. Если игра сможет удерживать внимание долгое время — на это и нужно полагаться.

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

Проще всего реализовать это через мультиплеер. Да, конечно, есть варианты и для однопользовательских проектов. Просто моя первая хитовая игра (15-я по счету, Sleep is Death) была многопользовательской…

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

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

Комментарии
Продолжить чтение

Статьи

Тестирование не (только) поиск багов

О тестировщиках и обезьянах рассуждает руководитель QA компании Redmadrobot Марина Куликова.

Redmadrobot

Опубликовано

/

Автор:

Почему-то принято считать, что тестирование — самая простая точка входа в мир IT. За годы работы в разных компаниях, странах и ролях — от тестировщика до Head of QA Redmadrobot — я успела на себе испытать разные подходы и наступить на разнообразные грабли. В этой статье постараюсь ответить на самые популярные вопросы и помочь начинающим QA-инженерам сориентироваться в том, что их ждет.

Открыть и потыкать

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

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

А кто будет тестировать зашитую логику, бекенд, краевые сценарии и остальное?

В теории в обязанности тестировщика входит

  • составление тест-дизайна, тест-кейсов, стратегии тестирования
  • репорт и проверка багов
  • проверка и создание документов (артефактов) тестирования
  • проверка безопасности
  • рекомендации о выпуске сборки (продукта) — да-да, во всех утопичных постулатах прописано, что только QA/QC может дать добро на выпуск продукта.

О том, что разработка тест-дизайна и тест-кейсов не так проста, в большинстве компаний хотя бы догадываются, привлекая к этому и написанию кейсов для тест-дизайна QA Team Lead’ов или Senior QA. Или даже создают для этого отдельную роль — TC Designer (writer). Разнообразные стратегии проверки краевых значений, тестирование интерфейсов, нагрузочное и другие кейсы пишут Senior инженеры.

Само тестирование выполняют рядовые тестировщики — люди, в лучшем случае обладающие навыками пользователя компьютером и каким-то продуктом. Хотя некоторые сценарии и запуск SQL-скриптов, работа со сторонними tools доступны не каждому опытному пользователю. И бизнес считает нормальным содержать 20-30 таких специалистов-обезьянок, называя их тестировщиками.

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

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

Чтение кода

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

Да, в идеальном мире процесс должен исполняться по модели чёрного ящика, но если сервис работает медленно, хоть и верно — может, стоит оптимизировать код? Или, к примеру, нужно спроектировать негативный сценарий — для подготовки такого теста может понадобиться что-то дописать в коде или подложить программе нужные данные. И да, это задача QA/QC-специалистов — вы же хотите, чтобы после прохождения тестирования у вас был качественный продукт?

Тестировщик должен не бояться заглядывать в код и помогать разработчику разбираться с проблемами. Ревью кода, дебаггинг и юнит-тестирование — не прерогатива разработчиков. Мы не ставим под сомнение их компетенции, но обеспечение качества — ответственность всей команды. Тестировщики же должны напоминать об этом и нести бремя контроля. QA — Quality Assurance — обеспечение качества, QC — quality control — контроль качества. Об этом полезно напоминать тем, кто не чувствует разницы.

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

Безудержная автоматизация

Знать код не значит безудержно все подряд автоматизировать.

Почему-то считается, что тестировщики делятся на автоматизаторов и ручных (мануальных). И большинство ручных мечтает стать автоматерами.

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

Целесообразность автоматизации сильно зависит от специфики проекта: сроков, поддержки, повторяемости, стабильности и других параметров.

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

Если нужно проверить, что продукт точно взлетит, к обязательному набору можно добавить бета-тестирование. И, конечно, нужно грамотно проводить приемочное тестирование (acceptance).

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

Отечественное тестирование

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

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

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

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

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

Важно помнить, что хороший отдел QA — это не 20 обезьян, а 2-3 нормальных специалиста. Они знают, как выстроить процессы, как избежать багов в сценариях и дизайне, что изменить, чтобы продукт взлетел. Но для этого, в первую очередь, нужно изменить отношение к отделу тестирования и понимание того, кто такие тестировщики.

В идеале управление качеством (QA) и тестирование это две разные сущности. Ну, а о процессах и разнице между QA и QC уже в другом тексте!

Комментарии
Продолжить чтение

Аналитика пользователей

Жизненный цикл пользователя: руководство профессионалов

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

AppTractor

Опубликовано

/

Автор:

В среднем по рынку, единожды пользуется приложением 80% установивших его  пользователей. А на седьмой день сохраняется лишь 12% аудитории, которую вы смогли привлечь. Но значит ли это, что все ушедшие потеряны навсегда? Совсем нет — многие ушедшие могут вернуться в ваше приложение через месяц или даже через год.

Ушедшие… и вернувшиеся

Мы привыкли, что возвраты считаются на горизонте одного месяца, однако, если посмотреть на действиях пользователей за год, то можно узнать много нового и интересного. Так, по подсчетам Adjust, в среднем 11% ушедших пользователей возвращается в приложение после трехмесячной паузы, а после двух месяцев — 17%. Даже отсутствующие шесть месяцев могут вернуться — их доля достигает 4%.

Количество “вернувшихся ушедших”, конечно, зависит от категории. Так, в “Играх”, “Утилитах” и eCommerce приложениях их, обычно, больше среднего. А в категориях “Социальные сети”, “Стиль жизни”, “Путешествия”, “Развлечения” и “Бизнес” — меньше.

Например, если в eCommerce-приложения после трехмесячного отсутствия возвращается 18% пользователей, то для “Бизнеса” это всего около 2%.

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

Например, ваше приложение получает 2,000 новых установок каждый день и в среднем 26% это платные рекламные кампании. На четвертый месяц около 60 “платных” пользователей будут как раз те, кто отвалился в начале, но через три месяца снова открыл приложение. Но вместо того, чтобы учесть таких людей как вернувшихся, их припишут к новым установкам и потребуют за них оплату. Если взять среднюю цену установки в $2.26, то вы потеряете на неправильной атрибуции 150 долларов. В день. За месяц это уже 4,500 долларов.

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

Удаление приложений

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

Adjust Lifecycle Tracking определяет средний “срок жизни” приложения на устройстве в 6 дней для органической установки и в 5 с половиной дней для платной.

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

А что с повторными установками? По данным Adjust, в среднем 40% пользователей, удаливших приложение, установят его заново!

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

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

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

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

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

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

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

Отслеживание жизненного цикла на практике: пример Viber

Моши Блюм, глава приобретения пользователей в Viber:

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

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

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

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

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

Жизненный цикл — это процесс

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

Подробнее обо всех тонкостях жизненного цикла – в новом руководстве Adjust.

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.