На этой странице представлены лучшие практики создания эффективных и привлекательных интерфейсов RCS для бизнеса, охватывающие как техническую реализацию , так и проектирование диалоговых интерфейсов .
Технические рекомендации
Проверьте возможности устройства.
Перед началом разговора с пользователем убедитесь, что его устройство может принимать сообщения RCS. Чтобы определить возможности пользователя, отправьте запрос на проверку возможностей и соответствующим образом настройте взаимодействие с агентом. Взаимодействуйте с пользователями только теми способами, которые поддерживаются их устройствами. Если устройство пользователя не поддерживает RCS, настройте резервный способ связи с использованием другого канала, например, SMS.
Соблюдайте максимальный размер сообщения.
Существуют ограничения на максимальный размер сообщения RCS for Business и на медиафайл, который оно может содержать. Подробнее см. раздел «Максимальные размеры сообщений» .
Предотвратите отправку дублирующихся сообщений.
Чтобы избежать отправки пользователям дублирующих сообщений, ваша система должна сначала подтвердить, что сообщение не было доставлено, прежде чем пытаться переключиться на SMS.
Следуйте этим рекомендациям, чтобы повысить надежность вашей системы и предотвратить дублирование сообщений:
- Установите время жизни пула соединений в соответствии со временем жизни DNS (TTL): используйте пулы соединений и объектов клиентов для повторного использования существующих соединений и объектов клиентов. Чтобы избежать использования устаревших IP-адресов после обновлений DNS, установите максимальное время, в течение которого соединение или объект остаются в пуле, в соответствии со временем жизни DNS, заданным API.
- Не следует предполагать, что истечение времени ожидания соединения означает сбой: не следует считать, что истечение времени ожидания соединения означает, что сообщение RCS for Business не было доставлено. Сообщение может все еще обрабатываться на стороне сервера.
- Проверяйте подтверждения доставки: всегда проверяйте наличие подтверждений доставки перед отправкой резервного сообщения.
- Согласуйте значение TTL с таймаутом соединения: По возможности устанавливайте значение TTL сообщения равным таймауту соединения.
- Отзыв сообщений перед отправкой резервного SMS: Всегда пытайтесь отозвать исходное сообщение перед отправкой резервного SMS. Если отзыв не удается, обработайте ошибку, так как это может указывать на то, что сообщение уже было доставлено пользователю.
- Повторная отправка сообщений : Если отправка сообщения не удалась из-за ошибки, допускающей повторную попытку, или истечения времени ожидания соединения, повторите операцию отправки. Используйте начальный
messageID, чтобы предотвратить дублирование, и реализуйте экспоненциальную задержку для распределения попыток.
Проверьте наличие дубликатов входящих сообщений.
При проверке входящих сообщений от пользователей и ответе на них, проверьте messageId и убедитесь, что вы еще не получили это сообщение и не ответили на него.
В распределенных системах существует два способа отправки сообщений:
- Не более одного раза : система отправляет сообщение один раз, но если в процессе передачи возникают ошибки в сети или связи, сообщение может быть не получено.
- Хотя бы один раз : система может отправлять сообщение несколько раз, но сообщение может быть получено даже при наличии сетевых или коммуникационных ошибок.
Google Cloud Pub/Sub использует систему " как минимум один раз" . Хотя это может привести к дублированию входящих сообщений, удалить дубликаты сообщений довольно просто, отслеживая строки messageId . Если вы уже получили сообщение, можно смело игнорировать любые дополнительные сообщения с тем же messageId .
Используйте уникальные идентификаторы для всех исходящих сообщений.
Когда ваш агент отправляет сообщение пользователю, messageId , который вы указываете в вызове API, должен быть уникальным для каждого сообщения.
Для получения дополнительной информации о получении сообщений см. раздел «Обработка входящих событий» .
Не используйте устаревшие IP-адреса.
Ваша система всегда должна использовать правильный, актуальный IP-адрес при подключении к API RBM. Различные программные платформы используют таймауты кэширования DNS по умолчанию, которые могут быть значительно дольше, чем значение TTL DNS от Google, что может привести к попыткам подключения к устаревшим IP-адресам и, как следствие, к таймаутам. Значение TTL для кэша DNS домена RBM составляет 300 секунд .
Чтобы убедиться, что ваша логика подключения учитывает наше значение TTL в 300 секунд, выполните следующие шаги.
- Установите время ожидания пула соединений равным TTL: если вы используете пул объектов соединений или клиентов, установите максимальное время жизни пула равным 300 секундам (или меньше). Это заставит вашу систему получать новый IP-адрес при обновлении объекта.
- Убедитесь в обновлении DNS: проверьте, что ваша платформа или библиотека HTTP-клиента настроена на обновление кэша DNS каждые 300 секунд или реже.
- Проверьте текущее значение TTL: Мы рекомендуем программно проверить значение TTL домена API RBM, чтобы убедиться, что вы используете правильное максимальное значение. Вам необходимо проверить домен, соответствующий вашему региону развертывания:
dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort
Реализуйте повторные попытки с экспоненциальной задержкой.
При вызове любого API возможны сбои из-за проблем с инфраструктурой, перегрузки сервиса, ограничений по количеству запросов в секунду и других ошибок. Для корректного восстановления после сбоев API следует реализовать повторные попытки с экспоненциальной задержкой.
Используя повторные попытки с экспоненциальной задержкой, ваша инфраструктура автоматически выполняет следующие действия:
- Выявляет неудачный вызов API.
- Устанавливает начальную продолжительность ожидания и максимальное количество повторных попыток.
- Пауза на время ожидания.
- Повторная попытка вызова API.
Оценивает ответ на вызов API:
- В случае успеха переходите к следующему шагу в рабочем процессе.
- В случае сбоя увеличивается время ожидания, и происходит возврат к шагу 3.
- Если после достижения максимального количества попыток происходит сбой, система переходит в состояние сбоя.
Оптимальная продолжительность ожидания и оптимальное максимальное количество повторных попыток зависят от конкретного сценария использования. Определите эти значения, исходя из требований к инфраструктуре и задержке рабочего процесса.
Оптимизация производительности API с использованием региональных конечных точек.
Для оптимизации производительности API и снижения задержки:
Используйте ближайшие к региону пользователя конечные точки.
В таблице ниже приведены рекомендации по выбору региональных точек доступа RBM в зависимости от номера телефона пользователя.
префикс телефонного номера Рекомендуемая конечная точка Географический регион +1 us-rcsbusinessmessaging.googleapis.com Америка +2 europe-rcsbusinessmessaging.googleapis.com Европа +3 europe-rcsbusinessmessaging.googleapis.com Европа +4 europe-rcsbusinessmessaging.googleapis.com Европа +5 us-rcsbusinessmessaging.googleapis.com Америка +6 asia-rcsbusinessmessaging.googleapis.com Азия +7 europe-rcsbusinessmessaging.googleapis.com Европа +8 asia-rcsbusinessmessaging.googleapis.com Азия +9 asia-rcsbusinessmessaging.googleapis.com Азия По умолчанию us-rcsbusinessmessaging.googleapis.com Америка Рекомендуется размещать серверы вблизи выбранной конечной точки.
Информацию о центрах обработки данных Google можно найти по ссылке https://www.google.com/about/datacenters/locations/ .
Для получения дополнительной информации об определении региона агента см. документацию по созданию агента .
Разговорный пользовательский интерфейс и пользовательский опыт
Разговорный пользовательский интерфейс, а не интерфейс приложения.
Агенты RCS for Business отлично подходят для эффективного и целенаправленного выполнения задач пользователями в диалоговом пользовательском интерфейсе. Лучшие из них обеспечивают целенаправленное, понятное и структурированное взаимодействие, подобное естественному разговору.
Операторы не могут полагаться на визуальный интерфейс приложения или веб-страницы и не должны пытаться его имитировать. Вместо этого операторам необходимо полагаться на тщательно выстроенные диалоги, которые отвечают потребностям пользователей, направляя их с помощью вербальных подсказок, предложений и эффективной обработки ошибок.
Операторы также не должны имитировать телефонные меню или интерфейсы, которые полагаются на то, что пользователи будут отвечать номером, обозначающим определенное действие. Пользователи должны иметь возможность общаться с операторами естественно, так же, как они общались бы с другим человеком в разговоре.
Начните разговор
Начало разговора формирует у пользователя ожидания относительно возможностей агента. Начинайте разговор с убедительной позиции: покажите индивидуальность вашего агента, сразу предоставьте информацию, которая важна для пользователей, и расскажите о том, на что способен ваш агент. Предоставьте пользователям четкие варианты взаимодействия с агентом и продолжения разговора.
Продемонстрируйте индивидуальность вашего агента : задайте тон, поприветствовав пользователя и представив свой бренд. Если вы создаете для агента определенный образ, например, виртуального помощника или цифрового консьержа, четко дайте понять, что это чат-бот, а не реальный человек. Вы можете установить имя агента в соответствии с образом. Аватар — отличный способ укрепить ваш имидж. Это может быть ваш логотип, но графический персонаж в мультяшном стиле тоже хорошо подойдет.
Расскажите о возможностях вашего агента : Хорошее приветственное сообщение четко дает понять, о чем идет речь в разговоре. Оно в общих чертах описывает возможности агента. Оно также включает в себя предлагаемые ответы и действия , которые помогут пользователям двигаться по определенным путям. Используйте эти предложения, чтобы помочь пользователям ориентироваться в разговоре и понимать, в каких задачах агент может помочь.
Пишите четкие и последовательные сообщения.
Отправляйте сообщения, которые пользователям легко понять и на которые легко ответить. Создавайте тексты сообщений, побуждающие пользователей к ответу. Поддерживайте единый стиль, формат и темп, чтобы завоевать доверие пользователей.
При создании текста сообщения следует учитывать следующие дополнительные рекомендации:
Не создавайте тупики. Каждое сообщение должно вести к осмысленному следующему шагу.
- Если пользовательский сценарий включает в себя задачу, состоящую из нескольких этапов, используйте дискурсивные маркеры, чтобы направлять пользователя по этому процессу.
Например, «Теперь…», «И…», «Понял!». Вот, пожалуйста…
- Будьте краткими, поскольку предлагаемые ответы и действия содержат максимум 25 символов.
- Если в разговоре происходит передача информации другому лицу, быстрое подтверждение может сгладить переход.
Например: «Хорошо. Дальше всё сделает ваш менеджер по работе с клиентами».
Например, напишите: «Отлично! Думаю, я знаю, что вы ищете», и добавьте ссылку на свой сайт.
Подтвердите получение сообщения от пользователя словом или фразой, выражающей признательность.
Например, «Отличный выбор!», «ОК», «Хорошо» или «Понял».
Обращайтесь к пользователю напрямую, используя его имя (если известно) или местоимение «вы». Избегайте обращения к пользователю как «я» или «мне», так как это может вызвать путаницу.
Для заголовков и подписей используйте регистр предложений, а не регистр заголовков.
Например, «Выписка по счету», а не «Выписка по счету».
Используйте сокращения, что уместно даже при сильном или повышенном мышечном тонусе.
Например, "it's" звучит более разговорно, чем "it is".
Используйте восклицательные знаки умеренно.
Используйте последовательную запятую, то есть "A, B и C", а не "A, B и C".
Записывайте числа цифрами.
Например, "1, 2, 3", а не "один, два, три".
При использовании эмодзи убедитесь, что игривый тон соответствует ситуации.
Например, пользователи, которые заказывают эвакуатор или ищут результаты медицинских анализов, могут быть не в настроении.
Сохраняйте порядок сообщений.
Если вы отправляете несколько сообщений подряд, важно, чтобы пользователи получали их в правильном порядке. Сообщения с медиафайлами обрабатываются дольше, чем сообщения только с текстом. Чтобы убедиться, что пользователи получают сообщения в правильном порядке, дождитесь получения ответа 200 OK на сообщение, прежде чем отправлять следующее в последовательности.
Создавайте увлекательные диалоги с помощью предлагаемых ответов и действий.
Предлагаемые ответы и действия — мощные инструменты для управления и улучшения диалога с пользователем. Они могут следовать за сообщением или расширенной карточкой и предлагать варианты продолжения или изменения темы разговора.
Предлагаемые варианты ответов : Помогите пользователям быстро отвечать вашему агенту, предоставляя предопределенные варианты. Используйте предлагаемые варианты ответов, когда это возможно, особенно когда ожидаются конкретные ответы.
Рекомендуемые действия : Разрешите вашему агенту интегрироваться с функциями устройства, что упростит такие задачи, как звонок в службу поддержки или поиск местоположения.
Чтобы сделать общение более интересным и эффективным, следуйте этим ключевым рекомендациям:
- Актуальность : Убедитесь, что предложения соответствуют текущей дискуссии.
- Краткость : Ограничьте количество предложений, чтобы не перегружать пользователей.
- Четкость : Используйте ясный и лаконичный язык для текста предложения.
Помогите пользователю
Ваш агент должен отвечать на сообщения с инструкциями от пользователей и рассказывать им о своих возможностях. Список предлагаемых ответов, адаптированный к возможностям вашего агента, может превратить негативный пользовательский опыт в полезный.
Убедитесь, что ваш логотип и главное изображение хорошо отображаются.
- Оставьте достаточно места вокруг логотипа для обрезки и сохранения визуальной целостности.
- Избегайте растягивания или искажения логотипа или главного изображения, так как это может негативно повлиять на восприятие бренда.
- Для оптимальной видимости и эстетики протестируйте логотип и главное изображение как в светлом, так и в темном режимах.
Дополнительные ресурсы, которые помогут вам разработать логотип или устранить неполадки, см. в разделе «Рекомендации по разработке логотипа» .
Логотип
- Дизайн разработан с учетом возможности отображения закругленных квадратов. Логотипы RCS for Business отображаются в виде «закругленных квадратов» в списке диалогов, на экране диалога и в подробностях диалога в соответствии со стандартами Google и отраслевыми стандартами.
- Чтобы элементы бренда оставались четкими после обрезки, расположите логотип по центру изображения.
- Утвержденные агенты автоматически получают отметку о подтверждении рядом со своим именем. Эта отметка защищена от подделки и не может быть добавлена вручную.
- Для логотипов с прозрачным фоном убедитесь, что контраст как со светлым, так и с темным фоном достаточен для работы в темном режиме. Если вы не уверены, используйте сплошной белый фон.
Главное изображение
- Используйте соотношение сторон 45:14, чтобы избежать нежелательной обрезки.
При разработке главного изображения учитывайте перекрытие логотипа, чтобы ключевые элементы не были скрыты.
Проявляйте уважение к пользователям, когда они не хотят получать сообщения.
Поддержание доверия пользователей означает уважение их предпочтений в общении. Когда пользователь указывает, что хочет прекратить получать сообщения, ваш агент должен уважать его выбор. Это включает в себя понимание и надлежащее реагирование на различные варианты отказа от подписки, такие как «СТОП», на всех соответствующих языках.
Ознакомьтесь с законами и передовой практикой вашей страны, касающимися реагирования на команды «СТОП» и другие обязательные команды.
Например, обратитесь к рекомендациям CTIA .
Обработка событий отписки и подписки
В Google Сообщениях предусмотрены встроенные функции отписки и подписки , позволяющие пользователям контролировать свои беседы. Когда пользователь решает отписаться, ваш агент получает событие веб-перехватчика UNSUBSCRIBE . Событие SUBSCRIBE означает намерение пользователя возобновить взаимодействие с вашим агентом.
Подробную информацию об обработке событий отписки и повторной подписки , включая сведения о полезной нагрузке, бизнес-правила и примеры, см. в документации по событиям, создаваемым пользователями .
Обработка отказов от участия
Платформа RCS for Business не предоставляет прямого способа управления списками пользователей, отказавшихся от получения сообщений. Вы несете ответственность за ведение собственной базы данных пользователей, которые решили прекратить получение сообщений путем отписки или другими способами отказа от подписки.
Возобновить разговоры
Если пользователь удаляет свою переписку с вашим агентом, ему необходимо возобновить контакт через другой канал, например, подписку на рассылку на сайте, короткий SMS-код или другой механизм согласия. Это новое взаимодействие сигнализирует о возобновлении интереса к получению сообщений.