Исправили баги и увеличили аудиторию приложения с 50 тыс. до 110 тыс. Кейс федеральной аптечной сети

Допустим, в Appstore была заявлена версия 1.1.2, но на сервере эти цифры ошибочно складывались между собой — вместо того, чтобы выдаваться такими, какие они есть. Сервер предлагал четвертую версию (1+1+2=4), а не 1.1.2 — учитывая то, что четверки вовсе не существует. И требовал невозможного — обновиться до нее!

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

2. Парализация приложения при переходе на главный экран после оформления заказа

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

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

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

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

3. Вместо карточек товаров — белые поля

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

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

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

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

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

4. Баг с неправильной датой доставки

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

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

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

5. Падение приложения при оформлении карты лояльности

Не очень здорово, когда приложение крашится на основном функционале. Особенно, когда юзер уже ввел все свои данные и нажал кнопку «Подтвердить». Будет ли он пытаться это сделать снова? Вряд ли. Он пойдет путем наименьшего сопротивления и закажет что-то у конкурентов.

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

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

Основные баги разобрали, теперь переходим к фичам.

1. Добавили фильтры

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

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

2. Сделали поп-ап с предложением перейти в приложение

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

Статистика от заказчика: число пользователей, установивших приложение с мобильной версии сайта — 51%, и это при нормальном показателе в 4%!

3. Сделали окно с выбором темы обращения в блоке «Обратная связь»

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

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

4. Улучшили механизм сторис

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

5. Показали товары в видео

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

6. Сделали так, чтобы лекарство можно было получить по QR-коду

Теперь любой заказ можно получить по QR-коду — как на самых популярных маркетплейсах. А из соображений безопасности он будет обновляться раз в сутки.

7. Добавили стикеры с акциями в карточки товаров

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

8. Разработали сервис личного учета медикаментов и самочувствия

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

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

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

Легаси проект — это ящик Пандоры

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

• Помогли партнерам сделать удобный супер-апп для 110 000+ пользователей;
• 40 000+ новых пользователей после устранения багов;
• 43% всех юзеров сделали заказ в приложении после апдейта;
• Количество crash-free сессий приблизилось к 100%;
• CR установок — 51% при нормальном показателе в 4%.

...в общем, год работы того стоил.

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

Кстати, вот графики с нашими результатами, ниже объясним, что они означают.

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

Процент crash-free сессий увеличился с июля прошлого года. Почти 100% сессий проходят ровно, а приложение не вылетает.

Вот такой кейс у нас получился. Жмем руки всем, кто дочитал до конца, а заказчика благодарим за доверие такой крутой и ответственной задачи!

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

Ниже ждем ваши комментарии по кейсу. Пишите, что думаете!