View a markdown version of this page

Bewährte Methoden von RCS - AWS SMS-Nachrichten für Endbenutzer
Konversationsorientiertes und interaktives DesignStrategie für VorschlägeReichhaltiges Karten- und KarusselldesignBewährte Methoden für MedienTTL und Fallback-StrategieÜberwachung und EreignisseVarianz beim Rendern von Geräten und ClientsOpt-out Handhabung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden von RCS

Mit RCS Rich Messaging können Sie interaktive Konversationserlebnisse schaffen, die weit über herkömmliche SMS hinausgehen. Dieses Thema bietet Anleitungen für die Gestaltung effektiver RCS-Nachrichten, einschließlich Vorschlagsstrategien, umfangreichem Karten- und Karussell-Layout, Medienoptimierung, Ablauf von Nachrichten, Notfallplanung und Überwachung.

Einzelheiten zu den einzelnen Funktionen finden Sie unter,Konfiguration von RCS-Vorschlägen, RCS-Rich Cards versendenRCS-Karussells senden, Konfiguration des Ablaufs von RCS-Nachrichten und. Konfiguration von SMS- oder MMS-Fallback pro Nachricht RCS-Meldungsereignisse

Konversationsorientiertes und interaktives Design

RCS-Nachrichten unterstützen interaktive Elemente wie Antwortvorschläge, Aktionsvorschläge, umfangreiche Karten und Karussells. Um diese Funktionen effektiv nutzen zu können, sollten Sie jeden Nachrichtenaustausch als Teil einer laufenden Konversation behandeln und nicht als Einwegbenachrichtigung.

Öffnen Sie mit Kontext und Optionen

Fügen Sie eine klare Begrüßung hinzu, geben Sie an, was der Benutzer tun kann, und geben Sie Antwortvorschläge als Leitfaden für den nächsten Schritt. Das weckt Erwartungen und reduziert Reibungsverluste.

Halten Sie Ihre Botschaften kurz

Bemühen Sie sich um weniger als 300 Zeichen pro Textnachricht. Teilen Sie komplexe Informationen in mehrere Nachrichten auf oder verwenden Sie eine umfangreiche Karte für strukturierte Inhalte.

Vermeiden Sie Sackgassen

Jede Nachricht sollte zu einem nächsten Schritt führen. Bieten Sie weitere Vorschläge, eine Option im Hauptmenü oder einen Pfad zu einem menschlichen Agenten an.

Sprechen Sie den Benutzer direkt an

Benutze die zweite Person. Schreiben Sie „Ihr Termin ist bestätigt“ statt „Der Termin wurde bestätigt“.

Strategie für Vorschläge

Vorschläge (sowohl Antworten als auch Aktionen) werden als interaktive Chips unter Ihrer Nachricht angezeigt. Sie reduzieren das Tippen, erhöhen das Engagement und ermöglichen es Ihnen, Antworten anhand strukturierter PostbackData Werte weiterzuleiten. Die vollständige Liste der Vorschlagsarten finden Sie unterKonfiguration von RCS-Vorschlägen.

Verfassen Sie präzise Aktionsbeschriftungen

Das Text Feld hat ein Limit von 25 Zeichen. Verwenden Sie eine handlungsorientierte Sprache, die dem Benutzer genau mitteilt, was beim Tippen passiert.

Beispiele für Vorschlagsetiketten
Vermeiden Bevorzugen
„Option 1" „Für Montag buchen“
„Hier klicken“ „Bestellstatus anzeigen“
„Weitere Informationen“ „Preisdetails anzeigen“

Bieten Sie 3 bis 5 Optionen an

Drei Vorschläge sind für die meisten Interaktionen ideal. Sie können bis zu 11 Vorschläge pro Nachricht hinzufügen (4 pro Rich-Karte), aber mehr als 5 Optionen gleichzeitig überfordern die Benutzer in der Regel. Wenn Sie mehr Auswahlmöglichkeiten benötigen, verwenden Sie ein Karussell oder teilen Sie den Ablauf in mehrere Schritte auf.

Route weiter PostbackData

Wird PostbackData für die Backend-Routing-Logik verwendet, anstatt den Anzeigetext zu analysieren. Dieser Ansatz unterstützt die Lokalisierung (Sie können den für den Benutzer sichtbaren Bereich ändern, Text ohne Ihr Routing zu ändern) und bietet einen strukturierten Kontext für Ihre Anwendung.

Codieren Sie die Aktion, die Entität und den Kontext im Postback-Wert. Beispiel:

confirm_order_12345
cancel_appointment_20260615
nav_main_menu

Verwenden Sie konsistente Präfixe (wiebook_,,,nav_) confirm_cancel_, um das Routing in Ihrem Backend zu vereinfachen.

Wichtig

Gehen Sie elegant mit veralteten Postbacks um. Ein Benutzer kann sich Stunden nach Erhalt für einen Vorschlag entscheiden. Vergewissern Sie sich, dass die Entität, auf die verwiesen wird, noch existiert, und informieren Sie den Benutzer, wenn die Aktion nicht mehr gültig ist.

Reichhaltiges Karten- und Karusselldesign

Umfangreiche Karten und Karussells präsentieren strukturierte Inhalte (Bilder, Titel, Beschreibungen und Vorschläge) in einem visuellen Format. Einzelheiten zur Implementierung finden Sie unter RCS-Rich Cards versenden und. RCS-Karussells senden

Eigenständige Rich Cards

  • Verwenden Sie die VERTICAL Ausrichtung für ein möglichst konsistentes Rendern auf allen Geräten.

  • Verwenden Sie die TALL Medienhöhe, um Bildern sowohl auf Android als auch auf iOS ausreichend Anzeigefläche zu geben.

  • Halten Sie Titel und Beschreibung kurz. Manche Kunden beschneiden Text auf mehr als drei Zeilen.

  • URLs im Beschreibungstext funktionieren nicht auf allen Clients als Links. Verwenden Sie eine OpenUrl vorgeschlagene Aktion, anstatt Links in Beschreibungen einzubetten.

  • Fügen Sie pro Karte einen klaren Vorschlag zur Handlungsaufforderung hinzu. Mehrere konkurrierende Aktionen reduzieren die Konversionsraten.

Karussells

  • Platzieren Sie die empfohlene oder relevanteste Option in der ersten Kartenposition. Benutzer interagieren am meisten mit der ersten sichtbaren Karte.

  • Verwenden Sie Vorschläge von außen (auf Nachrichtenebene) für Navigationsaktionen wie „Zurück zum Menü“ oder „Hilfe“. Reservieren Sie Vorschläge auf Kartenebene für Aktionen, die für diese Karte spezifisch sind.

  • Halten Sie den Karteninhalt prägnanter als bei eigenständigen Karten, da Karussellkarten weniger vertikalen Platz haben.

  • Die Medienhöhe von Karussellkarten ist auf SHORT oder begrenzt MEDIUM (TALLwird in Karussells nicht unterstützt).

  • Stellen Sie sicher, dass die Summe der Medien auf allen Karten unter 100 MB bleibt. Optimieren Sie Bilder vor dem Hochladen.

Bewährte Methoden für Medien

Mediendateien (Bilder, Videos, PDFs) verbessern die Interaktion mit der Botschaft, erhöhen aber auch die Größe der Nutzlast und die Variabilität beim Rendern. Informationen zu den Anforderungen an das Dateiformat und die Größe finden Sie unter. Senden umfangreicher RCS-Nachrichten

  • Komprimieren Sie Bilder vor dem Hochladen. Verwenden Sie JPEG für Fotos und PNG für transparente Grafiken.

  • Bewahren Sie Videodateien unter 5 MB auf, um eine zuverlässige Übertragung zwischen Mobilfunkanbietern und Geräten zu gewährleisten.

  • Stellen Sie eine ThumbnailUrl für Video- und Großdateinachrichten bereit. Miniaturansichten werden angezeigt, während das gesamte Medium geladen wird, und verbessern das Benutzererlebnis bei langsamen Verbindungen.

  • GIF-Animationen werden auf Android abgespielt, auf iOS jedoch als statischer erster Frame angezeigt. Verlassen Sie sich nicht auf GIF-Animationen, um wichtige Informationen zu vermitteln.

  • Hosten Sie Medien auf HTTPS-URLs oder in Amazon S3 (mithilfe von s3:// URIs). Alle Medien-URLs müssen dem Muster ^(https://|s3://).+$ entsprechen.

TTL und Fallback-Strategie

Time to Live (TTL) und Fallback-Konfiguration sorgen zusammen dafür, dass Ihre Nachricht den Benutzer auch dann erreicht, wenn die RCS-Zustellung fehlschlägt. Einzelheiten zur Implementierung finden Sie unter und. Konfiguration des Ablaufs von RCS-Nachrichten Konfiguration von SMS- oder MMS-Fallback pro Nachricht

TTL-Werte festlegen

Legen Sie immer einen TimeToLive Wert für zeitkritische Inhalte fest. Ordnen Sie die TTL dem Fenster mit der Relevanz des Inhalts zu.

Empfohlene TTL-Werte nach Inhaltstyp
Inhaltstyp Empfohlene TTL
One-time Passwort (OTP) oder Bestätigungscode 30 bis 120 Sekunden
Flash-Verkaufsbenachrichtigung Dauer bis zum Ende des Verkaufs
Erinnerung an einen Termin Zeit bis zur Verabredung
Aktualisierung der Lieferung 1 bis 4 Stunden
Anmerkung

Das API-Minimum beträgt 1 Sekunde, es wird jedoch eine TTL von mindestens 10 Sekunden empfohlen, um eine ausreichende Lieferzeit zu gewährleisten. Das Maximum ist 172.800 Sekunden (48 Stunden).

SMS- oder MMS-Fallback

Konfigurieren Sie einen FallbackConfiguration für kritische Nachrichten (OTPs, Auftragsbestätigungen, Sicherheitswarnungen), sodass der Inhalt den Benutzer erreicht, falls die RCS-Zustellung fehlschlägt oder abläuft.

  • Stellen Sie das Channel Feld auf SMS oder ein, MMS je nachdem, ob Sie Medien für den Fallback benötigen.

  • Halten Sie den Wert MessageBody innerhalb von 1.600 Zeichen ein (das Fallback-Limit, das unter dem RCS-Textlimit von 3.072 Zeichen liegt).

  • Testen Sie die Fallback-Zustellung von Anfang bis Ende, indem Sie an eine Telefonnummer senden, die RCS nicht unterstützt, und überprüfen, ob die SMS- oder MMS-Nachricht ankommt.

Überwachung und Ereignisse

Verwenden Sie Ereignisziele und Zustellungsereignisse, um die Nachrichtenleistung zu überwachen und Ihre Messaging-Strategie zu optimieren. Einzelheiten zu Ereignistypen und Konfiguration finden Sie unterRCS-Meldungsereignisse.

  • Konfigurieren Sie die Ziele der Ereignisse, bevor Sie mit dem Versand in die Produktionsumgebung beginnen. Dadurch wird sichergestellt, dass Sie Zustellungs-, Lese- und Ablaufereignisse von Anfang an erfassen.

  • Überwachen Sie die Ablaufraten von Nachrichten, um festzustellen, ob Ihre TTL-Werte angemessen sind. Eine hohe Ablaufrate deutet darauf hin, dass die TTL zu kurz ist oder dass viele Empfänger keine Geräte haben RCS-capable .

  • Erfassen Sie Lesebestätigungen für relative Vergleiche (A/B Tests) und nicht als absolute Metrik. Nicht alle Clients melden den Lesestatus.

  • Verwenden Sie Ereignisse zur Empfangsbestätigung, um redundante Fallback-Timer in Ihrer Anwendungslogik zu stornieren, wenn Sie den Fallback extern verwalten.

Varianz beim Rendern von Geräten und Clients

RCS-Nachrichten werden auf Android- und iOS-Clients unterschiedlich gerendert. Entwerfen Sie das Design für den kleinsten gemeinsamen Nenner und testen Sie es auf beiden Plattformen, bevor Sie eine Kampagne starten.

Rendering-Unterschiede zwischen Android und iOS
Feature Android iOS
GIF-Bilder Animiert Statisch (nur erstes Bild)
Link-Vorschauen im Text URL an einer beliebigen Stelle in der Nachricht URL muss das letzte Element sein. Eine URL, gefolgt von zusätzlichem Text, kann möglicherweise nicht angeklickt werden.
Höhe des Kartenmediums Geeignet für SHORT, MEDIUM und TALL Rendert alle vertikalen Höhen identisch. Ignoriert möglicherweise die Höheneigenschaft.
Vorschlag: Chip-Bestellung Konserviert wie gesendet Könnte Chips nachbestellen
Persistenz der vorgeschlagenen Aktion Aktionen außerhalb der Karten verschwinden nach dem Tippen. Die Kartentasten bleiben bestehen. Alle Tasten (Karten- und Nicht-Kartentasten) bleiben auch nach dem Tippen erhalten.
Anzeigename mit Pfadzeichen (/,,\) : Als registriert gerendert Zeichen können durch die iOS-Renderebene entfernt werden
Bannerbild des Agenten Sichtbar im Agentenprofil Wird nicht angezeigt
Link zur Datenschutzrichtlinie Sichtbar im Agentenprofil Wird nicht angezeigt
Mehrere Kontakte pro Typ Alle Kontakteinträge sichtbar Nur der erste Kontakt pro Typ ist sichtbar (in der Reihenfolge der Liste)
Medien mit großen Textgrößen für Barrierefreiheit Stabiles Rendern Kann Bilder zuschneiden, wenn große Textgrößen aktiviert sind
Bestätigungsausweis für den Transporteur „Von [Mobilfunkanbieter] verifiziert“ oder „Von Google verifiziert“ Gleiche Badge-Werte. Das Rendern wird von Apple gesteuert.

Designempfehlungen, die auf diesen Unterschieden basieren:

  • Verwenden Sie die VERTICAL Kartenausrichtung für ein einheitliches Layout.

  • Platzieren Sie URLs am Ende von Textnachrichten, um sicherzustellen, dass die Linkvorschauen auf iOS gerendert werden.

  • Verlassen Sie sich nicht auf GIF-Animationen, um wichtige Informationen zu vermitteln.

  • Testen Sie die Reihenfolge der Vorschläge auf beiden Plattformen, ob die Reihenfolge für den Benutzerfluss von Bedeutung ist.

Rendern von Anzeigenamen auf iOS

Die iOS Messages-App von Apple entfernt möglicherweise Zeichen, die Betriebssystem-Pfadtrennzeichen (/,\,:) oder URL-Escape-Sequenzen ähneln, aus dem angezeigten Agentennamen. Dieses Verhalten wird auf Betriebssystemebene gesteuert und kann von AWS, Google, Mobilfunkanbietern oder Messaging-Partnern nicht außer Kraft gesetzt werden.

Um Diskrepanzen zwischen Anzeigenamen zu vermeiden:

  • Verwenden Sie in Ihrem Anzeigenamen nur alphanumerische Zeichen, Leerzeichen, Bindestriche, Punkte und Standardinterpunktion (wie&,',!).

  • Verwenden Sie keine Schrägstriche, umgekehrten Schrägstriche oder Doppelpunkte als Teil Ihres Markennamens.

  • Wenn Ihr Markenname diese Zeichen enthält, sollten Sie eine alternative Darstellung in Betracht ziehen (verwenden Sie z. B. einen Bindestrich oder ein Leerzeichen anstelle eines Schrägstrichs).

  • Überprüfen Sie während der Testphase immer, ob Ihr Agent auf einem iOS-Testgerät angezeigt wird, bevor Sie den Start des Mobilfunkanbieters beantragen. Dies ist einer der Hauptzwecke des Testens von Agenten.

Wenn Sie bereits einen Agenten mit einem betroffenen Anzeigenamen gestartet haben und diesen ändern müssen, wenden Sie sich an den AWS-Support. Bei Änderungen des Anzeigenamens auf den gestarteten Agenten ist eine erneute Genehmigung durch den Transporteur erforderlich.

Sichtbarkeit des Agentenprofils auf iOS

Einige Agentenprofilelemente, die auf Android sichtbar sind, werden auf iOS nicht angezeigt:

  • Bannerbild: Wird auf iOS nicht angezeigt. Verlassen Sie sich nicht auf das Banner, um wichtige Markeninformationen zu vermitteln.

  • Link zur Datenschutzrichtlinie: In der Profilansicht des iOS-Agenten nicht sichtbar. Stellen Sie sicher, dass Ihre Datenschutzrichtlinie auch auf andere Weise zugänglich ist (z. B. über Ihre Website oder durch eine vorgeschlagene Aktion in Ihrer Willkommensnachricht).

  • Mehrere Kontakte: Wenn Sie mehrere Telefonnummern, E-Mails oder Websites konfigurieren, zeigt iOS nur den ersten Eintrag pro Kontakttyp an. Platzieren Sie Ihren Hauptansprechpartner bei der Konfiguration Ihres Agenten an erster Stelle in der Liste.

Plattformübergreifendes Testen

Das RCS-Rendering hängt von der Betriebssystemversion, dem Gerätemodell und der Netzbetreiberkonfiguration des Empfängers ab. Bevor Sie den Start des Mobilfunkanbieters beantragen:

  • Senden Sie Testnachrichten an Android- und iOS-Geräte.

  • Überprüfen Sie den Anzeigenamen, das Logo, das Banner, die Beschreibung, die vorgeschlagenen Aktionen, die Rich-Cards und die Medien auf beiden Plattformen.

  • Testen Sie mit verschiedenen Textgrößen und Barrierefreiheitseinstellungen auf iOS.

  • Vergewissern Sie sich, dass die Linkvorschauen auf beiden Plattformen korrekt wiedergegeben werden.

Die RCS-Implementierung von Apple befindet sich noch in der Entwicklung. Das Verhalten kann sich mit iOS-Updates ändern. Überwachen Sie Ihr Messaging-Erlebnis nach der Veröffentlichung von iOS und passen Sie Ihre Inhalte entsprechend an.

Opt-out Handhabung

Respektieren Sie die Abmeldepräferenzen der Benutzer sofort und einheitlich auf allen Messaging-Kanälen.

  • Beachten Sie die Stichwörter STOP und UNSUBSCRIBE, indem Sie alle unwichtigen Nachrichten sofort nach der Abmeldeanfrage beenden.

  • Senden Sie eine kurze Abmeldebestätigung mit Ihrem Markennamen, damit der Nutzer weiß, von welchem Absender er sich abgemeldet hat.

  • Pflegen Sie Ihre eigene Opt-Out-Datenbank und synchronisieren Sie sie kanalübergreifend (RCS, SMS, MMS), um zu verhindern, dass auf einem Kanal gesendet wird, nachdem sich der Benutzer auf einem anderen abgemeldet hat.

  • Erkundigen Sie sich bei Ihrer Rechtsabteilung, welche Nachrichtentypen (wie OTPs oder Betrugswarnungen) nach einer Abmeldung möglicherweise noch versendet werden.

Anmerkung

AWS End User Messaging bietet die Verwaltung von Abmeldelisten für SMS und MMS. Bei RCS koordinieren Sie den Umgang mit der Abmeldung sowohl mit den Abmeldelisten für AWS Endbenutzernachrichten als auch mit Ihren eigenen Datensätzen auf Anwendungsebene.