Как сравнить Flash Call, Voice OTP и SMS по данным

Сравнивать каналы OTP стоит по всей воронке: доставлен ли запрос, начал ли пользователь ввод, принял ли сервис код и сколько попыток потребовалось. Цена одного сообщения показывает только часть картины. В статье разберём, какие метрики собрать, как провести тест Flash Call, Voice OTP и SMS, почему операторы иногда блокируют автоматические звонки и как выбрать основной канал с резервным сценарием.

Чем отличаются SMS, Flash Call и Voice OTP?

SMS отправляет пользователю текст с одноразовым кодом. Voice OTP передаёт код голосом во время телефонного звонка. При Flash Call система делает короткий входящий вызов, который пользователь обычно не принимает, а подтверждение строится на номере звонка или его последних цифрах.

У каждого варианта свой путь пользователя. В SMS нужно дождаться сообщения, открыть его и перенести код в форму. В Voice OTP нужно ответить на звонок и расслышать цифры. Flash Call сокращает число действий, если приложение или сайт умеет автоматически распознать входящий номер. В ручном сценарии пользователь смотрит на журнал вызовов и вводит нужные цифры самостоятельно.

У Flash Call есть практическое ограничение: системы операторов могут принять автоматические вызовы за спам. В отраслевых публикациях также описывались случаи блокировки звонков с кодами авторизации, поэтому канал нельзя оценивать только по успешным тестам внутри одной сети (Telecom Times, 2023; SIGMA messaging).

Voice OTP и Flash Call часто объединяют в одну группу, но пользовательский опыт у них разный. Голосовой звонок объясняет, что делать, зато требует слушать код. Flash Call быстрее в приложении с автоматическим распознаванием, однако доставляемость может отличаться по операторам и типам устройств.

Какие метрики показывают реальное качество OTP?

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

• Доля доставленных запросов. Считайте отдельно SMS, входящие Flash Call и Voice OTP. Для звонка полезно разделять факт попытки вызова и подтверждённый входящий вызов.
• Время до первого контакта. Измеряйте интервал от нажатия «Получить код» до появления SMS или звонка. Среднее значение скрывает задержки, поэтому дополнительно смотрите на самые долгие случаи.
• Доля начавших ввод. Пользователь мог получить код, но закрыть экран. Такой разрыв показывает проблему интерфейса, текста подсказки или самого сценария.
• Доля успешного ввода. Сравнивайте количество подтверждённых кодов с количеством начатых попыток. Для Flash Call отдельно учитывайте автоматическое и ручное распознавание.
• Число повторных запросов. Повторная отправка часто означает задержку, непонятную подсказку или отсутствие звонка. Считайте повторы на одного пользователя и на одну сессию.
• Доля отказов по причине. Разделяйте неверный код, истёкший срок, превышение попыток, техническую ошибку и недоставку. Один общий статус «ошибка авторизации» не помогает исправить воронку.

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

Метрики нужно смотреть по сегментам. Отдельно сравните новые и повторные входы, мобильный сайт и приложение, автоматический и ручной сценарий. Если Flash Call хорошо проходит в приложении, но часто требует повторной отправки на мобильном сайте, причина может быть в распознавании номера или в подсказке на экране, а не в самом канале.

Как провести честный тест трёх каналов?

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

1. Подключите журнал событий для SMS, Flash Call и Voice OTP. Записывайте канал, время запроса, статус доставки, время ввода и причину завершения.
2. Распределяйте сопоставимые запросы между каналами. Не отправляйте Flash Call только постоянным клиентам, а SMS только новым пользователям, иначе результат исказится.
3. Проверьте разные устройства, типы подключения и сети. Для Беларуси тестовые номера стоит распределить так, чтобы один оператор или одна модель телефона не определяли весь итог.
4. Сравните не только средние значения. Отдельно посмотрите задержки, повторные запросы и отказы в каждой группе.
5. После теста проверьте резервный сценарий: например, повторить попытку другим каналом после недоставки звонка, но не запускать несколько отправок одновременно.

При оценке стоимости учитывайте полный расход на успешную авторизацию. Если канал стоит дешевле за одну попытку, но пользователи чаще запрашивают повтор или переходят к оператору поддержки, итоговая цена завершённой проверки растёт. В публикации Sostav для Flash Call приводилась оценка снижения стоимости на 30–50% по сравнению с SMS, но там же указаны неоднородная доставляемость и блокировка автоматических вызовов. Для конкретного бизнеса эту цифру нужно проверять собственными данными (Sostav).

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

Для проектирования самого экрана авторизации полезно свериться с материалом о снижении отказов в форме Flash Call. Там же удобно проверить, какие подсказки нужны для автоматического и ручного сценария.

Когда нужен каскад из нескольких каналов?

Один канал редко закрывает все ситуации. Flash Call подходит для быстрого сценария, когда сервис умеет распознать номер и контролировать ограничения. SMS остаётся понятным резервом для случаев, когда звонок не дошёл или устройство не передало приложению данные о вызове. Voice OTP может пригодиться пользователю, которому трудно работать с текстовым сообщением, но код по телефону придётся услышать и ввести.

Каскад должен иметь ясную логику. Если система сначала запускает SMS, затем Flash Call, а оба кода приходят с задержкой, пользователь может ввести уже недействительный вариант. Лучше заранее определить, какой код считается активным, когда начинается резервная отправка и что увидит человек на экране.

Сравнить расходы на разные варианты авторизации можно в материале о стоимости Flash Call и Voice OTP. А если задача связана с интернет-магазином, отдельный разбор авторизации по звонку в e-commerce поможет связать OTP-события с этапами оформления заказа.

Какие ошибки искажают сравнение каналов?

• Сравнивать цену попытки с ценой успешного входа. В расчёт нужно включить повторы, резервный канал и обращения пользователей из-за неудачной авторизации.
• Считать статус отправки доставкой. Запрос, переданный провайдеру, ещё не означает, что пользователь увидел SMS или получил звонок.
• Смешивать автоматический и ручной Flash Call. В этих сценариях разное число действий, поэтому их нужно анализировать отдельно.
• Не учитывать блокировки звонков. Автоматические вызовы могут фильтроваться системами операторов, а легитимные запросы иногда попадают под такие ограничения.
• Менять одновременно канал и интерфейс. Если вместе с Flash Call добавить новую форму или другой текст, причина изменения конверсии останется неизвестной.
• Не предусмотреть резерв. Для авторизации по звонку нужен план на случай недоставки: повторная попытка с ограничением или переход на SMS.