а вопрос «как отправлять SMS в больших масштабах» есть два честных ответа, и они указывают на разные команды. Первый — это веб-консоль, в которую вы входите и запускаете кампании. Второй — это API который вы интегрируете в собственное программное обеспечение. Оба варианта отправляют одно и то же сообщение по одним и тем же каналам связи; разница заключается в том, кто выполняет работу и когда отправляется сообщение. Правильный выбор в основном сводится к вопросу о том, кто отвечает за отправку — человек со списком или приложение, реагирующее на событие.
Консоль: отправка запуска пользователями
Платформа для массовой SMS — это веб-приложение. Вы входите в систему, загружаете или выбираете список контактов, выбираете идентификатор отправителя, пишете сообщение (часто из сохраненного шаблона), а затем отправляете сейчас или планируете отправку. Отчеты отображаются на том же экране: доставлено, не доставлено, ожидание, отказы. Ничего разрабатывать не нужно.
Это подходит для маркетинговых и операционных команд, которые рассылают сообщения партиями и мыслят категориями кампаний — рекламная акция, напоминание о мероприятии, уведомление для определенной группы пользователей. Ценность заключается в охвате без необходимости заниматься технической настройкой. Человек, понимающий свою аудиторию, может составить, настроить таргетинг и измерить результаты рассылки за считанные минуты, а затем повторить ее на следующей неделе без создания заявки в службу поддержки.
API: отправка, выполняемая программным обеспечением.
API для массовой SMS — это программный интерфейс (обычно REST по HTTPS или SMPP для высокоскоростных соединений), который ваше приложение использует для отправки сообщения. Вместо того чтобы пользователь нажимал кнопку «Отправить», ваш код делает это в ответ на какое-либо событие: отправка заказа, необходимость ввода одноразового кода для входа в систему, назначенная встреча на завтра, неудачная оплата.
Это подходит разработчикам и продуктовым командам. Сообщение становится частью потока, а не записью в календаре. Вы отправляете одно сообщение одному человеку точно в нужный момент, тысячи раз в день, и никто не следит за экраном. Транзакционные и триггерные сообщения — коды, подтверждения, оповещения — относятся к этой категории, поскольку они определяются временем и контекстом, а не списком.
Сантехника общая для обоих случаев.
В основе работы консоли и API лежат одни и те же механизмы, и полезно знать, чего ожидать от каждого из них:
- Контакты и списки управляются и загружаются в консоли; через API они обычно передаются или ссылаются по идентификатору.
- Шаблоны представляют собой многократно используемые тела сообщений с переменными, поэтому сообщение "Привет, {имя}, ваш код {код}" отображается для каждого получателя через любой из вариантов.
- Подтверждения доставки (DLR) — это подтверждение оператора о том, что сообщение достигло мобильного устройства. В консоли они отображаются как статус; API возвращает их посредством обратного вызова или опроса, поэтому ваша система может реагировать.
- Ограничения по скорости и пропускной способности применяются ко всем маршрутам. Консоль управляет темпом кампании, а через API вы контролируете параллельное выполнение и остаетесь в пределах лимитов вашей учетной записи.
- Отчетность представляет собой панель мониторинга в консоли и необработанные записи, передаваемые через API, которые вы можете хранить и анализировать вместе со своими собственными данными.
Суть в том, что API и консоль — это два входа в один уровень доставки: одинаковая маршрутизация, одинаковое покрытие, одинаковая обработка согласия и отказов.
Когда вам нужны оба
Большинство организаций в итоге используют оба варианта, и чаще всего это правильное решение. Схема проста: API передает транзакционный трафик, генерируемый вашим приложением — коды, квитанции, оповещения, — а консоль передает кампании, которые ваша маркетинговая команда запускает вручную. Одна и та же учетная запись, одни и те же идентификаторы отправителей, одна и та же отчетность, два интерфейса, подходящие для двух типов работы.
Такое разделение обязанностей также позволяет распределить ответственность между теми, кому она положена. Разработчики не привлекаются к каждой рекламной рассылке, а маркетологи не вынуждены ждать релиза, чтобы изменить строчку текста.
Выбор и перемещение между ними
Начните с определения того, кто является владельцем отправляемого контента. Если человек решает, что и кому отправлять, начните с консоли — это кратчайший путь к работающей программе. Если же это решает ваше программное обеспечение, интегрируйте API. Если верны оба условия, создайте одну учетную запись и используйте каждую из них по назначению.
Миграция обычно происходит поэтапно, а не путем полной замены. Команды, которые начинают работу с консолью, а затем нуждаются в автоматизации, сохраняют свои контакты, шаблоны и идентификаторы отправителей, а затем добавляют вызовы API для автоматизированных процессов. Команды, которые начинают с API, часто добавляют консоль позже, чтобы нетехнические сотрудники могли запускать кампании без добавления кода. Поскольку обе системы используют одно и то же соединение, переход между ними не означает повторного подтверждения доставляемости или повторного одобрения идентификаторов отправителей.
BroadNet использует этот уровень доставки с 2003 года, охватывая более 200 стран через более чем 1000 операторских соединений. Выбор, который мы предлагаем клиентам, почти всегда один и тот же: сопоставить интерфейс с отправителем и использовать оба варианта, когда оба условия выполняются.