Компании хотят знать, понравился ли клиенту товар или услуга, а что можно улучшить. Некоторые опрашивают потребителей сразу после приобретения услуги, понравилась ли им поездка на такси или доставка из интернет-магазина. Получается моментный срез о качестве услуги, но очень общий. Особенно если никаких эксцессов не было. Услуга оказана, таксист получил свои пять баллов, чего ещё надо?
Для комплексного тестирования привлекают тайных покупателей с заранее подготовленными скриптами, опросниками, диктофонами или специальными приложениями. Но всё можно забыть, человека с диктофоном и заученным скриптом легко обмануть. К тому же, поиск и найм этих людей стоит денег.
Есть нюанс: наш заказчик — S7 Airlines, и сама услуга — перелёт — растянута во времени. В принципе, авиаперелет в этом плане услуга совсем не уникальная. Любая перевозка, путешествие, доставка также состоят из нескольких этапов, происходящих друг за другом. И в каждой из этих ситуаций нельзя надеяться, что клиент запомнит все детали и сможет постфактум развернуто о них рассказать. Нужно что-то простое и в моменте, пока человек ещё не забыл.
Так появилось наше приложение для пассажиров S7 Airlines под iOS и Android, которые хотят помочь авиакомпании стать лучше. Для этого достаточно скачать приложение на смартфон и пройти все опросы, которые там появятся. Ниже расскажем подробнее, как мы определяем, кого, когда и в какой момент спрашивать.
Они получают письмо или sms-сообщение с приглашением стать тайным пассажиром с прямой ссылкой на приложение. Ссылка сделана с помощью технологии глубинного связывания Deep Link. Благодаря этому при переходе по ссылке со смартфона система самостоятельно определяет, что это за устройство — IOS или Android. В зависимости от этого, пользователя переадресовывают в App Store или Google Play для скачивания приложения. В этой ссылке также зашит номер билета и фамилия пассажира. После установки приложения пользователь автоматически логинится в приложении с полученными из deep link-а данными.
Благодаря этой технологии в устройстве уже есть все нужные данные для авторизации. Номер билета и фамилия пробрасываются из ссылки в приложение.
При создании опроса сервер генерирует короткую ссылку deep link, при помощи которой пользователь будет переходить в соответствующий магазин приложений и сможет открыть приложение с этой ссылкой внутри. Серверная часть принимает на вход номер билета или номер бронирования и фамилию пассажира. На этой основе генерируется опрос. Информация для опроса есть в базе данных и задана наперёд. Для создания опроса сервер опрашивает:
Вся эта информация компонуется, и делается большой опросник.
Для реализации deep link мы использовали технологию Firebase Dynamic Links. Она предоставляет REST-сервис для генерации ссылок, а также Sdk для обработки ссылок в мобильном приложении. Ссылки генерируются двумя способами:
Во время разработки IOS-приложения нашёлся баг, связанный с авторизацией. В Firebase IOS SDK с версии 4.0.4 до версии 4.8.1 при установке приложения из AppStore на некоторых устройствах приходила неправильная ссылка вида bundle_id://google/link/?dismiss=1&is_weak_match=1. Из-за этого не запускалась авторизация пользователя в приложении. Проблему решили апдейтом версии фреймворка Firebase.
После генерации ссылки советуем сразу удостовериться в правильности схемы переходов по deeplink-у, добавив в конец deep link GET-параметр d=1. Так можно проверить корректность работы deep link для мобильных устройств или браузера.
По номеру брони из системы вытаскивается билет и данные по перелёту, когда и каким рейсом летит пассажир и какой «пакет услуг» купил. После этого создаётся опросник,
На схеме показана общая логика, как мы привязываем открытие блоков вопросов к «жизненному циклу» перелета:
Вся конфигурация вопросов скачивается вместе с приложением единым JSON-файлом и разворачивается в колонки. Вопросы по более поздним тапам перелета заблокированы, чтобы пассажир не ответил заранее на все вопросы.
Как мы сообщаем, что пора отвечать
Пассажир проходит опросник до полёта, в самолёте и после приземления. О каждом блоке мы напоминаем локальными уведомлениями. Пуши использовать невозможно, поскольку большую часть времени приложение будет работать в оффлайн-режиме. Время рассчитываем из часового пояса, где находится пассажир, информацию берем из телефона. Все заполненные опросы хранятся на устройстве и отправляются при подключении к сети.
Маршрутизация в процессе ответов
Первая секция вопросов появляется за сутки до перелёта — это вопросы, связанные с покупкой билетов. Последняя — приходит в аэропорту прилёта.
Мы строим граф вопросов, внутри которого есть переходы в зависимости от ответов, и мы можем пропустить следующий блок вопросов. Например, пассажира спрашивают: «Предлагали ли вам еду?». И если нет, то не будем спрашивать, насколько ему понравилось съеденное, а перейдем к вопросу о напитках.
Для этого на сервере задаются дополнительные связи, которые мы научились читать и выстраивать на клиенте.
Перед взлётом мы вычисляем диапазон времени, за который пройдёт перелёт. Для этого используется локальная нотификация, которая вычисляется автоматически. Для каждой секции («В аэропорту вылета», «На борту», «В аэропорту прилёта») есть свой диапазон времени, когда она активна и валидна. По этому диапазону времени мы высчитываем, когда лучше показать нотификацию. Например, блок вопросов «В самолёте» включается через час после взлёта в расчёте на то, что пассажир уже достал телефон, чтобы поиграть или почитать. Пусть заодно и опрос пройдёт.
После прилёта мы шлём уведомление, где предлагаем отправить ответы. Человек может отказаться или пройти часть ответов позже, поэтому мы шлём ещё одно уведомление с напоминанием. Сообщение отправляем только в дневное время (с 10 до 18) с учетом временной зоны пользователя, чтобы ненароком никого не разбудить и не разгневать. Потом мы кэшируем все ответы и передаём JSON-файлом на сервер.
Дальше все ответы выгружаются в базу данных. Заказчик может строить запросы и получать аналитику, распределенную по времени. Например, насколько пассажирам понравилось обслуживание в Домодедово или как пассажиры оценивают сервис на определенном рейсе. Это инструмент, который позволит оперативно получать обратную связь и прослеживать закономерности, когда наберется достаточно ответов для релевантной выборки.
Мы решили две важные задачи:
А дальше какие планы?
Для комплексного тестирования привлекают тайных покупателей с заранее подготовленными скриптами, опросниками, диктофонами или специальными приложениями. Но всё можно забыть, человека с диктофоном и заученным скриптом легко обмануть. К тому же, поиск и найм этих людей стоит денег.
Есть нюанс: наш заказчик — S7 Airlines, и сама услуга — перелёт — растянута во времени. В принципе, авиаперелет в этом плане услуга совсем не уникальная. Любая перевозка, путешествие, доставка также состоят из нескольких этапов, происходящих друг за другом. И в каждой из этих ситуаций нельзя надеяться, что клиент запомнит все детали и сможет постфактум развернуто о них рассказать. Нужно что-то простое и в моменте, пока человек ещё не забыл.
Так появилось наше приложение для пассажиров S7 Airlines под iOS и Android, которые хотят помочь авиакомпании стать лучше. Для этого достаточно скачать приложение на смартфон и пройти все опросы, которые там появятся. Ниже расскажем подробнее, как мы определяем, кого, когда и в какой момент спрашивать.
Как пользователи получают приложение
Они получают письмо или sms-сообщение с приглашением стать тайным пассажиром с прямой ссылкой на приложение. Ссылка сделана с помощью технологии глубинного связывания Deep Link. Благодаря этому при переходе по ссылке со смартфона система самостоятельно определяет, что это за устройство — IOS или Android. В зависимости от этого, пользователя переадресовывают в App Store или Google Play для скачивания приложения. В этой ссылке также зашит номер билета и фамилия пассажира. После установки приложения пользователь автоматически логинится в приложении с полученными из deep link-а данными.
Благодаря этой технологии в устройстве уже есть все нужные данные для авторизации. Номер билета и фамилия пробрасываются из ссылки в приложение.
Deep Link: серверная часть и мобильная разработка
При создании опроса сервер генерирует короткую ссылку deep link, при помощи которой пользователь будет переходить в соответствующий магазин приложений и сможет открыть приложение с этой ссылкой внутри. Серверная часть принимает на вход номер билета или номер бронирования и фамилию пассажира. На этой основе генерируется опрос. Информация для опроса есть в базе данных и задана наперёд. Для создания опроса сервер опрашивает:
- сервис расписания рейсов, чтобы понять время вылета и прилёта,
- сервис бронирования, чтобы понять, какие дополнительные услуги приобрёл пассажир,
- базу бронирований, чтобы определить, где был куплен билет.
Вся эта информация компонуется, и делается большой опросник.
Для реализации deep link мы использовали технологию Firebase Dynamic Links. Она предоставляет REST-сервис для генерации ссылок, а также Sdk для обработки ссылок в мобильном приложении. Ссылки генерируются двумя способами:
- вручную через firebase-консоль,
- через Firebase deep link API, если вам нужно динамически генерировать параметры для deep link у себя на сервере. Поскольку он работает нестабильно, мы каждую секунду пытаемся сгенерировать ссылку, а если не получается — ждём секунду, после чего возобновляем попытки.
Внимание, баг
Во время разработки IOS-приложения нашёлся баг, связанный с авторизацией. В Firebase IOS SDK с версии 4.0.4 до версии 4.8.1 при установке приложения из AppStore на некоторых устройствах приходила неправильная ссылка вида bundle_id://google/link/?dismiss=1&is_weak_match=1. Из-за этого не запускалась авторизация пользователя в приложении. Проблему решили апдейтом версии фреймворка Firebase.
После генерации ссылки советуем сразу удостовериться в правильности схемы переходов по deeplink-у, добавив в конец deep link GET-параметр d=1. Так можно проверить корректность работы deep link для мобильных устройств или браузера.
О чем будем спрашивать?
По номеру брони из системы вытаскивается билет и данные по перелёту, когда и каким рейсом летит пассажир и какой «пакет услуг» купил. После этого создаётся опросник,
- привязанный к сервисам, которыми пользуется пассажир. (Если тариф с багажом, значит, будет его сдавать. Нам интересно узнать о всех этапах, поэтому человеку с багажом мы добавим блок вопросов о сдаче и получении багажа.)
- и ко времени, когда этот сервис будет оказан — когда и о чём спрашивать этого пассажира.
На схеме показана общая логика, как мы привязываем открытие блоков вопросов к «жизненному циклу» перелета:
Вся конфигурация вопросов скачивается вместе с приложением единым JSON-файлом и разворачивается в колонки. Вопросы по более поздним тапам перелета заблокированы, чтобы пассажир не ответил заранее на все вопросы.
Как мы сообщаем, что пора отвечать
Пассажир проходит опросник до полёта, в самолёте и после приземления. О каждом блоке мы напоминаем локальными уведомлениями. Пуши использовать невозможно, поскольку большую часть времени приложение будет работать в оффлайн-режиме. Время рассчитываем из часового пояса, где находится пассажир, информацию берем из телефона. Все заполненные опросы хранятся на устройстве и отправляются при подключении к сети.
Маршрутизация в процессе ответов
Первая секция вопросов появляется за сутки до перелёта — это вопросы, связанные с покупкой билетов. Последняя — приходит в аэропорту прилёта.
Мы строим граф вопросов, внутри которого есть переходы в зависимости от ответов, и мы можем пропустить следующий блок вопросов. Например, пассажира спрашивают: «Предлагали ли вам еду?». И если нет, то не будем спрашивать, насколько ему понравилось съеденное, а перейдем к вопросу о напитках.
Для этого на сервере задаются дополнительные связи, которые мы научились читать и выстраивать на клиенте.
Перед взлётом мы вычисляем диапазон времени, за который пройдёт перелёт. Для этого используется локальная нотификация, которая вычисляется автоматически. Для каждой секции («В аэропорту вылета», «На борту», «В аэропорту прилёта») есть свой диапазон времени, когда она активна и валидна. По этому диапазону времени мы высчитываем, когда лучше показать нотификацию. Например, блок вопросов «В самолёте» включается через час после взлёта в расчёте на то, что пассажир уже достал телефон, чтобы поиграть или почитать. Пусть заодно и опрос пройдёт.
После прилёта мы шлём уведомление, где предлагаем отправить ответы. Человек может отказаться или пройти часть ответов позже, поэтому мы шлём ещё одно уведомление с напоминанием. Сообщение отправляем только в дневное время (с 10 до 18) с учетом временной зоны пользователя, чтобы ненароком никого не разбудить и не разгневать. Потом мы кэшируем все ответы и передаём JSON-файлом на сервер.
Анализ данных
Дальше все ответы выгружаются в базу данных. Заказчик может строить запросы и получать аналитику, распределенную по времени. Например, насколько пассажирам понравилось обслуживание в Домодедово или как пассажиры оценивают сервис на определенном рейсе. Это инструмент, который позволит оперативно получать обратную связь и прослеживать закономерности, когда наберется достаточно ответов для релевантной выборки.
Итоги и планы
Мы решили две важные задачи:
- Научились оперативно собирать достоверные данные в онлайн-режиме за счет того, что мы можем в цифровом формате опрашивать пассажиров и именно в тот момент, когда событие происходит.
- Получили возможность сегментировать пассажиров и задавать им только те вопросы, которые им релевантны. Мы опрашиваем всех, но подстраиваем опрос таким образом, чтобы все вопросы в нем уже учитывали опыт пассажира, состав его бронирования, класс перелета и пр.
А дальше какие планы?
- Самостоятельная регистрация
Пользователи, которые имеют активное бронирование с перелетом S7 Airlines, смогут самостоятельно авторизоваться в приложении без приглашения по Email. Для этого достаточно только ввести номер билета и фамилию пассажира на этапе авторизации.
- Начисление бонусов за ответы
В будущем планируется система вознаграждений за пройденные опросы. Что это будет, компания пока хранит в секрете. Как говорится, stay tuned.
- Динамическая подстройка под изменения в перелете
Вопросы будут не только генерироваться под каждого пассажира, но и подстраиваться под изменения. Например, в случаях, если рейс задержали или пассажир опоздал на самолёт, мы будем передвигать вопросы к новому времени вылета.
