Анализ сервисов приема SMS для Android против сайтов-сервисов и опыт разработки нового функционала под Android

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

Основные качества сервисов по приему SMS

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

1. Постоянное наличие номеров и их количество — это всегда останется актуальной проблемой для всех сервисов, так как некоторые страны блокируют данный вид деятельности, а для пользователя это первостепенный фактор куда он смотрит при посещении сервиса приема SMS.
2. Цена за один номер — это следующий пункт куда смотрит пользователь при выборе сервиса.
3. Скорость прихода номера — чем быстрее, тем больше доверия у пользователя к данному сервису.
4. Количество стран с наличием номеров — постепенно расширяя сеть номеров, растет и количество заинтересованных пользователей из разных стран к сервису, поэтому этот пункт является одним из важных при разработке.
5. Локализация языков — возможность автоматической смены языка при посещении сервиса, основываясь на языке пользователя, так же является хорошим фактором SEO-продвижения и увеличение аудитории.
6. Форма прихода смс — важную роль играет как выглядит доставленный код, пользователь всегда ценит минимализм, а это означает, что в интерфейс пользователя должен быть доставлен только код.
7. Удобность интерфейса — пользователем оценивается, то на сколько читабельный предоставленный функционал, минимальное количество нажатий для заказа и прием (1 клик).
8. Возможность копирования номера с кодом страны и без него — является основным фактором, при работе сервисом, эта возможность увеличивает скорость работы с сервисом и экономит время пользователя.
9. Оповещение при доставке кода — важно не только вовремя доставить код, но и уведомить пользователя об этом, а так же возможность отключить надоедливый звук.
10. Длительность использования заказанного номера — это период за который номер доступен пользователю для заказа.
11. Принцип: «один номер, один сервис, один пользователь» — важно, чтобы сервис, который предоставляет номера следил, за использованием своих номеров и не обрушал доверие своих клиентов, за счет повторного доступа, третьих лиц к заказанному номеру.
12. Возможность повторного заказа кода на тот же номер — это является базой для таких сервисов.
13. Возможность отмены номера — важно чтобы не только имел эту функцию, но и возврат средств если код не был доставлен.
14. Многопоточность — возможность заказа большого количества номеров параллельно друг с другом, это позволит заказать коды для различных регистраций одновременно.
15. Наличие API — программный интерфейс позволит масштабировать Ваш проект и интегрировать его в различные системы (авто регистраторы аккаунтов, сервисы для продвижения, автоматизация работы сервиса для клиента).
16. Дополнительные фишки — в этот пункт включены фишки которые недоступны для сайтов-сервисов, например: авто копирование номера, авто воспроизведения кода, авто копирование присылаемого кода.

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

Борьба с сервисами приема СМС

Не для кого не секрет, что защита от автоматизированных «ботосистем», всегда велась и ведется. Каждый защищает свой проект как может и придумывает свои методы защиты, помимо базовых. Вводят ограничения по времени для регистрации, загадки головоломки помимо разгадывания капчи, по железу, мак адресам, gps, размеру окна экрана, с помощью звонка на телефон, а также многие другие и в большинстве случаем это помогает, но не на 100%, все эти следствия защиты упираются во внутреннюю безопасность любого онлайн проекта.

Наличие в нем уязвимостей, на которые закрываются глаза ленью разработчиков или не желанием заказчика, растрачивать дополнительные средства на защиту в конечном итоге вся защита ведется к тому, чтобы идентифицировать человека от «ботовидных» массовых действий.
Но это всё не мешает существовать и «ручным мобильным ботам» (пользователям, которым мало одного аккаунта, которые используют массовые регистрации в своих целях), на мобильных устройствах может насчитываться до двухсот аккаунтов telegram, для рассылок спама или накруток.

И вот мобильные мессенджеры, которые за 2020-й год набирали свою популярность в условиях мирового кризиса, за счет массовых регистраций в telegram, discord, google, whatssap, viber и других соц. сетей, показатели массовых регистраций за счет ботов взлетают по рейтингам в топ по аудитории.

Сервисы приема СМС под Android

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

Сравнение браузерных сервисов и приложений

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

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

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

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

Опыт разработки под Android

Требования к качеству(пункты 1-15, доступны выше) + дополнительный функционал которого нет в браузерных сайтах-сервисах:

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

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

Выбор стоял между Android Studio и Visual Studio Xamarin, взвесив все за и против, было выбрано платформу на Visual Studio Xamarin, так как язык С# мне более по душе, плюс были некоторые наработки по C# и в будущем если проект зайдет — можно было бы его интегрировать под IOS и UWP.

Но и тут начались подводные камни впервые я столкнулся с текстовой разметкой «xaml», которая съела одну неделю моего времени, так как задача стояла создать простой минималистичный интерфейс пользователя, без «квакозябр» и прочих анти-читабельных шрифтов. Разобравшись с текстовой разметкой, написав пару базовых функций приступили к отладке, ничего не предвещало беды.

И тут вопрос стал ребром: Зачем это приложение если им никто не сможет воспользоваться?
Понимая все риски, было куплено за 25$ аккаунт разработчика Google Play, но для его публикации, еще далеко, стал вопрос «Как монетизировать без авторизации?»

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

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

Окей, проект готов для первой версии, как его продвигать? В Google Play Console было найдено функцию, которая позволяет продвигать проект на платформе Play Market, с помощью рекламы, было решено задонатить 10$ на месяц, но особой отдачи это не принесло и за всё время было куплено только 2 ключа.

Так как и на ком тестировать, откуда привлекать клиентов?

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

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

Окей, выявили ошибки, протестировали приложение, а в Play Market по статистике удержания аудитории меньше 10ти человек и ключи никто не покупает, что же не так?

Дойдя до пункта мультиязычность, стало понятно что большая часть аудитории Play Market, англоязычная, поэтому следующим этапом было создать мультиязычное приложение, о котором как потом пришлось пожалеть и это должно было заложено быть на первых этапах проектирования приложения, так как теперь приходится выносить весь текст для перевода в ресурсы проекта, связывать через конструктор и проверять работает ли приложение с данной кодировкой, так же вскрылись теории заговора с точкой "." и запятой "," в кодировках «ru-Ru»(исключение с "." работает с ",") и «en-US»(не отображает с "," работает с "."). И да, это всё при использовании типа double. Так что используйте в своих проектах остаток от целочисленного деления правильно, не так как вышло у меня, что пришлось переписывать двухмесячный код!