

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
<a name="rcs-best-practices"></a>

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-suggestions.md), [RCS-Rich Cards versenden](rcs-rich-cards.md)[RCS-Karussells senden](rcs-carousels.md), [Konfiguration des Ablaufs von RCS-Nachrichten](rcs-message-expiration.md) und. [Konfiguration von SMS- oder MMS-Fallback pro Nachricht](rcs-fallback-per-message.md) [RCS-Meldungsereignisse](rcs-events.md)

## Konversationsorientiertes und interaktives Design
<a name="rcs-best-practices-conversational-design"></a>

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
<a name="rcs-best-practices-suggestions"></a>

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 unter[Konfiguration von RCS-Vorschlägen](rcs-suggestions.md).

### Verfassen Sie präzise Aktionsbeschriftungen
<a name="rcs-best-practices-suggestions-labels"></a>

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
<a name="rcs-best-practices-suggestions-count"></a>

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
<a name="rcs-best-practices-suggestions-postback"></a>

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 (wie`book_`,,,`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
<a name="rcs-best-practices-rich-cards"></a>

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](rcs-rich-cards.md) und. [RCS-Karussells senden](rcs-carousels.md)

### Eigenständige Rich Cards
<a name="rcs-best-practices-standalone-cards"></a>
+ 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
<a name="rcs-best-practices-carousels"></a>
+ 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` (`TALL`wird 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
<a name="rcs-best-practices-media"></a>

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](rcs-rich-messaging.md)
+ 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
<a name="rcs-best-practices-ttl-fallback"></a>

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](rcs-message-expiration.md) [Konfiguration von SMS- oder MMS-Fallback pro Nachricht](rcs-fallback-per-message.md)

### TTL-Werte festlegen
<a name="rcs-best-practices-ttl"></a>

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
<a name="rcs-best-practices-fallback"></a>

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
<a name="rcs-best-practices-monitoring"></a>

Verwenden Sie Ereignisziele und Zustellungsereignisse, um die Nachrichtenleistung zu überwachen und Ihre Messaging-Strategie zu optimieren. Einzelheiten zu Ereignistypen und Konfiguration finden Sie unter[RCS-Meldungsereignisse](rcs-events.md).
+ 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
<a name="rcs-best-practices-device-variance"></a>

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
<a name="rcs-best-practices-display-name-ios"></a>

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
<a name="rcs-best-practices-agent-profile-ios"></a>

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
<a name="rcs-best-practices-testing-platforms"></a>

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
<a name="rcs-best-practices-opt-out"></a>

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.