View a markdown version of this page

Melhores práticas de RCS - AWS SMS de mensagens para o usuário final
Design conversacional e interativoEstratégia de sugestãoDesign rico em cartões e carrosselPráticas recomendadas de mídiaTTL e estratégia de fallbackMonitoramento e eventosVariação de renderização de dispositivos e clientesOpt-out manuseio

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Melhores práticas de RCS

Com mensagens ricas em RCS, você pode criar experiências conversacionais e interativas que vão além do SMS tradicional. Este tópico fornece orientação para criar mensagens RCS eficazes, incluindo estratégia de sugestões, layout de rich card e carrossel, otimização de mídia, expiração de mensagens, planejamento de fallback e monitoramento.

Para obter detalhes sobre recursos individuaisConfigurando sugestões de RCS, consulte Enviando cartões ricos em RCSEnviando carrosséis RCS,Configurando a expiração da mensagem RCS,Configurando o fallback de SMS ou MMS por mensagem,, Eventos de mensagem RCS e.

Design conversacional e interativo

As mensagens RCS oferecem suporte a elementos interativos, como respostas sugeridas, ações sugeridas, rich cards e carrosséis. Para usar esses recursos de forma eficaz, trate cada troca de mensagens como parte de uma conversa contínua, em vez de uma notificação unidirecional.

Abra com contexto e opções

Inclua uma saudação clara, diga o que o usuário pode fazer e forneça sugestões de respostas para orientar a próxima etapa. Isso define as expectativas e reduz o atrito.

Mantenha as mensagens concisas

Procure usar menos de 300 caracteres por mensagem de texto. Divida informações complexas em várias mensagens ou use um rich card para conteúdo estruturado.

Evite becos sem saída

Cada mensagem deve levar à próxima etapa. Ofereça sugestões de acompanhamento, uma opção do menu principal ou um caminho até um agente humano.

Dirija-se diretamente ao usuário

Use a segunda pessoa. Escreva “Seu compromisso está confirmado” em vez de “O compromisso foi confirmado”.

Estratégia de sugestão

As sugestões (respostas e ações) aparecem como chips interativos abaixo da sua mensagem. Eles reduzem a digitação, aumentam o engajamento e permitem que você direcione as respostas por meio de PostbackData valores estruturados. Para ver a lista completa dos tipos de sugestão, consulteConfigurando sugestões de RCS.

Escreva rótulos de ação concisos

O Text campo tem um limite de 25 caracteres. Use uma linguagem orientada à ação que diga ao usuário exatamente o que acontece ao tocar.

Exemplos de rótulos de sugestão
Evitar Prefiro
“Opção 1" “Reserve para segunda-feira”
“Clique aqui” “Exibir status do pedido”
“Mais informações” “Veja os detalhes dos preços”

Ofereça de 3 a 5 opções

Três sugestões são ideais para a maioria das interações. Você pode incluir até 11 sugestões por mensagem (4 por rich card), mas mais de 5 opções por vez tendem a sobrecarregar os usuários. Se precisar de mais opções, use um carrossel ou divida o fluxo em várias etapas.

Rota em PostbackData

Use PostbackData para lógica de roteamento de back-end em vez de analisar o texto exibido. Essa abordagem oferece suporte à localização (você pode alterar a visibilidade do usuário Text sem modificar seu roteamento) e fornece contexto estruturado para seu aplicativo.

Codifique a ação, a entidade e o contexto no valor do postback. Por exemplo:

confirm_order_12345
cancel_appointment_20260615
nav_main_menu

Use prefixos consistentes (comobook_,, confirm_cancel_,nav_) para simplificar o roteamento em seu back-end.

Importante

Manuseie postbacks obsoletos com elegância. Um usuário pode escolher uma sugestão horas depois de recebê-la. Verifique se a entidade referenciada ainda existe e informe ao usuário se a ação não for mais válida.

Design rico em cartões e carrossel

Cartões e carrosséis ricos apresentam conteúdo estruturado (imagens, títulos, descrições e sugestões) em um formato visual. Para obter detalhes sobre a implementação, consulte Enviando cartões ricos em RCS Enviando carrosséis RCS e.

Cartões ricos independentes

  • Use a VERTICAL orientação para obter a renderização mais consistente em todos os dispositivos.

  • Use a altura da TALL mídia para dar às imagens espaço de exibição adequado no Android e no iOS.

  • Mantenha o título e o texto descritivo concisos. Alguns clientes cortam o texto além de três linhas.

  • Os URLs no texto da descrição não funcionam como links em todos os clientes. Use uma ação OpenUrl sugerida em vez de incorporar links nas descrições.

  • Inclua uma sugestão clara de apelo à ação por cartão. Várias ações concorrentes reduzem as taxas de conversão.

Carrosséis

  • Coloque a opção recomendada ou mais relevante na primeira posição do cartão. Os usuários interagem mais com o primeiro cartão visível.

  • Use sugestões externas (em nível de mensagem) para ações de navegação, como “Voltar ao menu” ou “Ajuda”. Reserve sugestões em nível de cartão para ações específicas desse cartão.

  • Mantenha o conteúdo do cartão mais conciso do que os cartões independentes, pois os cartões de carrossel têm menos espaço vertical.

  • A altura da mídia da placa de carrossel é limitada a SHORT ou MEDIUM (não TALL é suportada em carrosséis).

  • Certifique-se de que a mídia combinada em todos os cartões permaneça abaixo de 100 MB. Otimize as imagens antes de fazer o upload.

Práticas recomendadas de mídia

Os arquivos de mídia (imagens, vídeos, PDFs) aprimoram o engajamento das mensagens, mas aumentam o tamanho da carga útil e a variabilidade de renderização. Para requisitos de formato e tamanho de arquivo, consulteEnviando mensagens ricas de RCS.

  • Comprima as imagens antes de fazer o upload. Use JPEG para fotografias e PNG para gráficos com transparência.

  • Mantenha os arquivos de vídeo com menos de 5 MB para entrega confiável entre operadoras e dispositivos.

  • Forneça um ThumbnailUrl para mensagens de vídeo e arquivos grandes. As miniaturas são exibidas enquanto a mídia completa é carregada e melhoram a experiência do usuário em conexões lentas.

  • As animações GIF são reproduzidas no Android, mas são exibidas como um primeiro quadro estático no iOS. Não confie na animação GIF para transmitir informações críticas.

  • Hospede mídia em URLs HTTPS ou no Amazon S3 (s3://usando URIs). Todos os URLs de mídia devem corresponder ao padrão^(https://|s3://).+$.

TTL e estratégia de fallback

A configuração de tempo de vida (TTL) e de fallback trabalham juntas para garantir que sua mensagem chegue ao usuário mesmo quando a entrega do RCS falha. Para obter detalhes sobre a implementação, consulte Configurando a expiração da mensagem RCS Configurando o fallback de SMS ou MMS por mensagem e.

Definindo valores de TTL

Sempre defina um TimeToLive valor para conteúdo urgente. Combine o TTL com a janela de relevância do conteúdo.

Valores de TTL recomendados por tipo de conteúdo
Tipo de conteúdo TTL recomendado
One-time senha (OTP) ou código de verificação 30 a 120 segundos
Notificação de venda instantânea Duração até o final da venda
Lembrete de compromisso Tempo até a consulta
Atualização de entrega 1 a 4 horas
nota

O mínimo da API é de 1 segundo, mas um TTL de pelo menos 10 segundos é recomendado para permitir um tempo de entrega suficiente. O máximo é 172.800 segundos (48 horas).

Recuo de SMS ou MMS

Configure um FallbackConfiguration para mensagens críticas (OTPs, confirmações de pedidos, alertas de segurança) para que o conteúdo chegue ao usuário se a entrega do RCS falhar ou expirar.

  • Defina o Channel campo como SMS ou MMS dependendo se você precisa de mídia no fallback.

  • Mantenha MessageBody dentro de 1.600 caracteres (o limite de fallback, que é menor que o limite de texto RCS de 3.072 caracteres).

  • Teste a entrega de fallback de ponta a ponta enviando para um número de telefone que não seja compatível com RCS e verificando se a mensagem SMS ou MMS chega.

Monitoramento e eventos

Use destinos de eventos e eventos de entrega para monitorar o desempenho das mensagens e otimizar sua estratégia de mensagens. Para obter detalhes sobre tipos e configurações de eventos, consulteEventos de mensagem RCS.

  • Configure os destinos dos eventos antes de iniciar o envio da produção. Isso garante que você capture eventos de entrega, leitura e expiração desde o início.

  • Monitore as taxas de expiração das mensagens para determinar se seus valores de TTL são apropriados. Uma alta taxa de expiração sugere que o TTL é muito curto ou que muitos destinatários não têm RCS-capable dispositivos.

  • Rastreie os recibos de leitura para comparação relativa (A/B teste) e não como uma métrica absoluta. Nem todos os clientes relatam o status de leitura.

  • Use eventos de confirmação de entrega para cancelar temporizadores de fallback redundantes na lógica do seu aplicativo se você gerenciar o fallback externamente.

Variação de renderização de dispositivos e clientes

As mensagens RCS são renderizadas de forma diferente nos clientes Android e iOS. Projete com o menor denominador comum e teste nas duas plataformas antes de lançar uma campanha.

Diferenças de renderização entre Android e iOS
Recurso Android iOS
Imagens GIF Animado Estático (somente no primeiro quadro)
Pré-visualizações de links em texto URL em qualquer lugar na mensagem O URL deve ser o último elemento. Um URL seguido por texto adicional pode não ser clicável.
Alturas da mídia do cartão Respeita BAIXOS, MÉDIOS e ALTOS Renderiza todas as alturas verticais de forma idêntica. Pode ignorar a propriedade de altura.
Sugestão de pedido de chip Preservado conforme enviado Pode reordenar fichas
Persistência da ação sugerida As ações fora dos cartões desaparecem após o toque. Os botões do cartão persistem. Todos os botões (com e sem cartão) persistem após o toque.
Nome de exibição com caracteres de caminho (/,\,:) Renderizado como registrado Os caracteres podem ser removidos pela camada de renderização do iOS
Imagem do banner do agente Visível no perfil do agente Não exibido
Link da política de privacidade Visível no perfil do agente Não exibido
Vários contatos por tipo Todas as entradas de contato visíveis Somente o primeiro contato por tipo visível (por ordem de lista)
Mídia com grandes tamanhos de texto de acessibilidade Renderização estável Pode cortar imagens quando tamanhos de texto grandes estão habilitados
Crachá de verificação da transportadora “Verificado pela [operadora]” ou “Verificado pelo Google” Mesmos valores de crachá. Renderização controlada pela Apple.

Recomendações de design com base nessas diferenças:

  • Use a orientação VERTICAL do cartão para um layout consistente.

  • Coloque URLs no final das mensagens de texto para garantir que as visualizações prévias de links sejam renderizadas no iOS.

  • Não dependa da animação GIF para comunicar informações essenciais.

  • Teste a ordenação das sugestões em ambas as plataformas se a sequência for significativa para o fluxo do usuário.

Renderização de nomes de exibição no iOS

O aplicativo iOS Messages da Apple pode remover caracteres que se assemelham a separadores de caminho do sistema operacional (/,\,:) ou sequências de escape de URL do nome do agente exibido. Esse comportamento é controlado no nível do sistema operacional e não pode ser substituído pela AWS, pelo Google, pelas operadoras ou pelos parceiros de mensagens.

Para evitar incompatibilidades de nomes de exibição:

  • Use somente caracteres alfanuméricos, espaços, hífens, pontos e pontuação padrão (como&,',!) em seu nome de exibição.

  • Não use barras dianteiras, barras invertidas ou dois pontos como parte do nome da sua marca.

  • Se o nome da sua marca incluir esses caracteres, considere uma representação alternativa (por exemplo, use um hífen ou espaço em vez de uma barra).

  • Sempre verifique a aparência do seu agente em um dispositivo de teste iOS durante a fase de teste antes de solicitar o lançamento da operadora. Esse é um dos principais objetivos dos agentes de teste.

Se você já lançou um agente com um nome de exibição afetado e precisa alterá-lo, entre em contato com o AWS Support. As alterações do nome de exibição nos agentes lançados exigem a reaprovação da transportadora.

Visibilidade do perfil do agente no iOS

Alguns elementos do perfil do agente que são visíveis no Android não são exibidos no iOS:

  • Imagem do banner: não exibida no iOS. Não confie no banner para comunicar informações críticas da marca.

  • Link da política de privacidade: não visível na visualização do perfil do agente iOS. Certifique-se de que sua política de privacidade esteja acessível por outros meios (como seu site ou uma ação sugerida em sua mensagem de boas-vindas).

  • Vários contatos: se você configurar vários números de telefone, e-mails ou sites, o iOS mostrará somente a primeira entrada por tipo de contato. Coloque seu contato principal em primeiro lugar na lista ao configurar seu agente.

Testando em várias plataformas

A renderização do RCS depende da versão do sistema operacional, do modelo do dispositivo e da configuração da operadora do destinatário. Antes de solicitar o lançamento da operadora:

  • Envie mensagens de teste para dispositivos Android e iOS.

  • Verifique o nome de exibição, o logotipo, o banner, a descrição, as ações sugeridas, os rich cards e a mídia nas duas plataformas.

  • Teste com diferentes tamanhos de texto e configurações de acessibilidade no iOS.

  • Confirme se as visualizações de links são renderizadas corretamente nas duas plataformas.

A implementação do RCS da Apple ainda está evoluindo. Os comportamentos podem mudar com as atualizações do iOS. Monitore sua experiência de mensagens após o lançamento do iOS e ajuste seu conteúdo de acordo.

Opt-out manuseio

Respeite as preferências de exclusão do usuário de forma imediata e consistente em todos os canais de mensagens.

  • Honre as palavras-chave STOP e UNSUBSCRIBE encerrando todas as mensagens não essenciais imediatamente após a solicitação de cancelamento.

  • Envie uma breve confirmação de cancelamento que inclua o nome da sua marca para que o usuário saiba de qual remetente ele cancelou a assinatura.

  • Mantenha seu próprio banco de dados de exclusão e sincronize-o em todos os canais (RCS, SMS, MMS) para evitar o envio em um canal depois que o usuário optou por não participar em outro.

  • Consulte sua equipe jurídica sobre quais tipos de mensagem (como OTPs ou alertas de fraude) ainda podem ser enviados após uma desativação.

nota

AWS O End User Messaging fornece gerenciamento de listas de exclusão para SMS e MMS. Para o RCS, coordene seu tratamento de exclusão com as listas de exclusão do AWS End User Messaging e com seus próprios registros em nível de aplicativo.