

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.

# Konfiguration des Ablaufs von RCS-Nachrichten
<a name="rcs-message-expiration"></a>

Time-sensitive Nachrichten wie Einmalpasswörter (OTPs), Flash-Sale-Ankündigungen und Terminerinnerungen verlieren an Wert, wenn sie erst nach Ablauf des entsprechenden Zeitfensters zugestellt werden. Wenn Sie den `TimeToLive` Parameter in eine `SendRcsMessage` Anfrage aufnehmen, entfernt AWS End User Messaging die Nachricht, wenn sie nicht innerhalb der angegebenen Anzahl von Sekunden zugestellt wurde. Der Empfänger sieht nie eine abgelaufene Nachricht.

Sie können den Fallback pro Nachricht `TimeToLive` kombinieren, sodass automatisch ein SMS- oder MMS-Fallback gesendet wird, wenn die RCS-Nachricht abläuft. Einzelheiten zur Konfiguration des Fallbacks finden Sie unter. [Konfiguration von SMS- oder MMS-Fallback pro Nachricht](rcs-fallback-per-message.md)

## So funktioniert das Ablaufen von Nachrichten
<a name="rcs-message-expiration-how-it-works"></a>

Der TTL-Countdown beginnt, wenn AWS End User Messaging die `SendRcsMessage` Anfrage akzeptiert. Die folgenden Ergebnisse sind möglich:
+ **Zugestellt, bevor TTL abläuft**: Die Nachricht erreicht den Empfänger und AWS End User Messaging gibt ein Zustellungsereignis aus. Weitere Informationen über -Ereignisse finden Sie unter [RCS-Meldungsereignisse](rcs-events.md).
+ **TTL läuft vor der Zustellung ab (mit Fallback)**: Wenn Sie für die `FallbackConfiguration` Anfrage eine Option festlegen, sendet AWS End User Messaging die SMS- oder MMS-Fallback-Nachricht an den Empfänger. Die ursprüngliche RCS-Nachricht wird entfernt und der Empfänger sieht sie nie.
+ **TTL läuft vor der Zustellung ab (kein Fallback)**: Die Nachricht schlägt fehl. AWSEnd User Messaging entfernt die RCS-Nachricht und gibt ein TTL-Ablaufereignis aus. Der Empfänger sieht die Nachricht nie.

## TimeToLive Parameter-Referenz
<a name="rcs-message-expiration-parameter"></a>

Sie legen den Ablauf der Nachricht fest, indem Sie den `TimeToLive` Parameter in Ihre `SendRcsMessage` Anfrage aufnehmen.


**TimeToLive Parameterdetails**  

| Eigenschaft | Wert | 
| --- | --- | 
| Parametername | TimeToLive | 
| Typ | Ganzzahl | 
| Einheit | Sekunden | 
| Mindestwert | 1 | 
| Maximaler Wert | 172800 (48 Stunden) | 
| Standardverhalten | Wenn Sie es weglassenTimeToLive, wendet AWS End User Messaging kein Ablauffenster an. Die Nachricht bleibt ausstehend, bis die Zustellung erfolgreich ist oder der Transporteur sie entfernt. | 

**Wichtig**  
Stellen Sie `TimeToLive` den Wert auf mindestens 10 Sekunden ein. Werte unter 10 erhöhen das Risiko, dass die Nachricht abläuft, bevor der Transporteur versuchen kann, sie zuzustellen. Ein Wert von 0 oder eine negative Zahl gibt a zurück`ValidationException`.

## Ablauf und Fallback
<a name="rcs-message-expiration-fallback"></a>

Wenn Sie beide `TimeToLive` und `FallbackConfiguration` in derselben `SendRcsMessage` Anfrage angeben, verwendet AWS End User Messaging die folgende Logik:

1. AWSEnd User Messaging versucht, über RCS zuzustellen.

1. Wenn die Nachricht nicht innerhalb von `TimeToLive` Sekunden zugestellt wird, entfernt AWS End User Messaging die ausstehende RCS-Nachricht.

1. AWSEnd User Messaging sendet die Fallback-Nachricht auf dem Kanal, den Sie angegeben haben `FallbackConfiguration.Channel` (entweder oder`SMS`). `MMS`

Wenn Sie `TimeToLive` keine Option angeben`FallbackConfiguration`, schlägt die Nachricht nach Ablauf fehl und es wird kein Fallback gesendet. Überwachen Sie Ablaufereignisse, um diese Fälle zu erkennen. Weitere Informationen finden Sie unter [RCS-Meldungsereignisse](rcs-events.md).

Vollständige Informationen zur Fallback-Konfiguration, einschließlich der `FallbackConfiguration` Struktur, finden Sie unter[Konfiguration von SMS- oder MMS-Fallback pro Nachricht](rcs-fallback-per-message.md).

## Empfohlene TTL-Werte
<a name="rcs-message-expiration-recommendations"></a>

Wählen Sie einen `TimeToLive` Wert, der dem Relevanzfenster des Inhalts entspricht, den Sie senden.


**Empfohlene TTL-Werte nach Anwendungsfall**  

| Anwendungsfall | Empfohlene TTL | Begründung | 
| --- | --- | --- | 
| One-time Passwörter (OTPs) | 30 bis 120 Sekunden | OTP-Codes haben kurze Gültigkeitsfenster. Die Lieferung nach Ablauf verwirrt die Empfänger. | 
| Betrugs- oder Sicherheitswarnungen | 60 bis 300 Sekunden | Time-critical Sicherheitsbenachrichtigungen müssen schnell eintreffen oder einen Fallback-Kanal auslösen. | 
| Terminerinnerungen | 3600 bis 7200 Sekunden (1 bis 2 Stunden) | Nützlich nur vor dem Termin. | 
| Flash-Verkäufe | Passen Sie die Verkaufsdauer an | Eine Nachricht, die nach dem Verkauf zugestellt wurde, führt zu einem negativen Kundenerlebnis. | 
| Tägliche Werbeaktionen | 43200 bis 86400 Sekunden (12 bis 24 Stunden) | Nur für den aktuellen Tag relevant. | 
| Benachrichtigungen über die Lieferung | 1800 bis 3600 Sekunden (30 bis 60 Minuten) | Der Paketstatus ändert sich schnell; ein veraltetes Update ist irreführend. | 

Bei allgemeinen Inhalten, für die es keine bestimmte Zeitbeschränkung gibt, sollten Sie diese Option weglassen `TimeToLive` und AWS Endbenutzer-Messaging versuchen, sie auf unbestimmte Zeit zuzustellen.

## Bewährte Methoden
<a name="rcs-message-expiration-best-practices"></a>
+ Wählen Sie `TimeToLive` stets zeitkritische Inhalte wie OTPs, Sicherheitswarnungen und Terminerinnerungen aus.
+ Geben Sie dem Transporteur mindestens 10 Sekunden Zeit, um die Lieferung zu versuchen.
+ Kombinieren Sie es `TimeToLive` mit a `FallbackConfiguration` für kritische Nachrichten. Dadurch wird sichergestellt, dass der Empfänger den Inhalt auf einem alternativen Kanal erhält, falls das RCS-Zustellungsfenster geschlossen wird.
+ Überwachen Sie TTL-Ablaufereignisse, um die Erfolgsquoten der Zustellung zu verfolgen und Ihre TTL-Werte im Laufe der Zeit zu optimieren. Weitere Informationen zu den Ereignistypen finden Sie unter [RCS-Meldungsereignisse](rcs-events.md).
+ Bei Rich-Media-Nachrichten (Rich Cards und Carousels) sollten Sie eine längere TTL in Betracht ziehen, um die Download-Zeit der Medien zu berücksichtigen. Informationen zu Rich-Messaging finden Sie unter. [Senden umfangreicher RCS-Nachrichten](rcs-rich-messaging.md)