Häufige Fehlerbehebungsszenarien für Live-Aktivitäten troubleshoot-mobile-live

Sie können Assurance verwenden, um die Token-Registrierung zu überprüfen:

1. Filtern Sie in Assurance über die Ereignisse-Liste oder suchen Sie eventType = "liveActivity.pushToStart" nach Ereignissen.
2. Wählen Sie Ereignis aus und überprüfen Sie die Payload.
3. Überprüfen Sie, ob die Werte für token, appId und attributeType vorhanden sind.
4. Bestätigen Sie, dass das Ereignis erfolgreich gesendet wurde.

Sie können auch das Adobe Experience Platform-Profil einchecken.

1. Rufen Sie in Adobe Experience Platform über Ihr Profil die Registerkarte Ereignisse auf.
2. Nach liveActivity.pushToStart Ereignissen suchen.
3. Überprüfen Sie den Zeitstempel und die Payload des Ereignisses.

Wenn keine Ereignisse gefunden werden, ruft die App Messaging.registerLiveActivities nicht korrekt auf. Korrigieren Sie die SDK-Integration.

1. Rufen Sie von Profil aus die Registerkarte Attribute auf.

2. Suchen Sie liveActivityPushNotificationDetails.

3. Überprüfen Sie die Token-Konfiguration:

   code language-json
   { "liveActivityPushNotificationDetails": [ { "appId": "com.example.myapp", "token": "abc123def456...", "platform": "apns", "denylisted": false, "attributeType": "OrderTrackingAttributes", "identity": {} } ] }

Validieren jedes Felds:

Wenn ein Feld falsch ist, aktualisieren Sie die Mobile App, registrieren Sie sich mithilfe von Messaging.registerLiveActivities erneut, warten Sie 5 bis 10 Minuten und überprüfen Sie dann erneut.

Wenn liveActivityPushNotificationDetails fehlt, wurde das Token noch nicht synchronisiert. Warten Sie 5-10 Minuten, nachdem Sie das liveActivity.pushToStart Ereignis in Assurance gesehen haben, und überprüfen Sie es dann erneut.

Android verwendet das standardmäßige FCM-Registrierungstoken für Live-Aktivitäten. Es gibt kein liveActivity.pushToStart Ereignis oder separates Live-Aktivitäts-Push-Token.

1. Öffnen Sie in Assurance die Liste Ereignisse und suchen Sie das standardmäßige Registrierungsereignis für Push-Token.
2. Wählen Sie das Ereignis aus und überprüfen Sie seine Payload, um sicherzustellen, dass das FCM-Registrierungstoken vorhanden ist.
3. Bestätigen Sie, dass das Registrierungsereignis erfolgreich gesendet wurde.
4. Öffnen Sie in Adobe Experience Platform die Registerkarte Attribute und bestätigen Sie, dass das Token in pushNotificationDetails vorhanden ist, wie in Schritt 2 beschrieben.

Wenn das Registrierungsereignis oder Profil-Token fehlt, stellen Sie sicher, dass die App das FCM-Registrierungs-Token mithilfe von MobileCore.setPushIdentifier(token) an die SDK weiterleitet.

1. Rufen Sie von Ihrem Profil aus die Registerkarte Attribute auf.

2. Suchen Sie pushNotificationDetails. Android verwendet dieses Objekt anstelle von liveActivityPushNotificationDetails und erfordert kein attributeType.

3. Stellen Sie sicher, dass die Token-Konfiguration dieser Struktur folgt:

   code language-json
   { "pushNotificationDetails": [ { "appId": "com.adobe.marketing.mobile.liveupdatessample", "token": "fcm-registration-token...", "platform": "fcm", "denylisted": false, "identity": {} } ] }

Validieren jedes Felds:

Wenn ein Feld falsch ist, korrigieren Sie die App-Konfiguration nach Bedarf, leiten Sie das FCM-Token mithilfe von MobileCore.setPushIdentifier(token) erneut weiter, warten Sie 5 bis 10 Minuten und überprüfen Sie dann erneut das Profil.

Wenn pushNotificationDetails fehlt, wurde das Token noch nicht synchronisiert. Warten Sie nach der Bestätigung der Token-Registrierung in Assurance 5-10 Minuten und überprüfen Sie dann das Profil erneut.

1. Öffnen Sie in Journey Optimizer Ihre Kampagne und navigieren Sie zum Menü Aktionen .
2. Überprüfen Sie Ihre Konfiguration der Live-Aktivität. Die Oberfläche muss für die iOS-App mit einer Bundle-Kennung konfiguriert werden, die mit der appId in der liveActivityPushNotificationDetails Ihres Profils übereinstimmt. Wenn Ihr Profil beispielsweise über "appId": "com.example.myapp" verfügt, muss die Oberfläche dieselbe App ansprechen.
3. Vergewissern Sie sich dass der Aktivitätstyp“ in Ihrer Kampagnenkonfiguration genau mit dem attributeType in der liveActivityPushNotificationDetails Ihres Profils übereinstimmt. Wenn Ihr Profil beispielsweise über "attributeType": "FoodDeliveryLiveActivityAttributes" verfügt, muss die Kampagne denselben Aktivitätstyp angeben.

Stellen Sie beim Ausführen der Kampagne über die API sicher, dass die Payload der richtigen Struktur entspricht.

Unitäre Payload:

{
   "campaignId": "your-campaign-id",
   "recipients": [{
      "type": "aep",
      "userId": "user@example.com",
      "namespace": "email",
      "context": {
         "requestPayload": {
            "aps": {
               "content-available": 1,
               "timestamp": 1756984054,
               "event": "start",
               "attributes-type": "FoodDeliveryLiveActivityAttributes",
               "content-state": { ... },
               "attributes": { ... }
            }
         }
      }
   }]
}

Häufige Payload-Probleme:

Kritisch: Verwenden Sie immer einen neuen Zeitstempel

• Legen Sie timestamp auf die aktuelle Unix-Epochenzeit (in Sekunden) fest, wenn Sie jeden API-Aufruf ausführen. Dies gilt für alle Ereignistypen: start, update und end.
• Ein veralteter oder wiederverwendeter Zeitstempel führt dazu, dass Update- und End-Anfragen fehlschlagen oder vom Gerät ignoriert werden. Verwenden keine Zeitstempel aus früheren Anfragen oder zwischengespeicherten Werten.

Optionale Felder (alle Ereignistypen):

• requestId: Eindeutige Kennung für das Tracking (empfohlen).
• alert: Objekt mit title und body für die Benachrichtigung. Nützlich, um Aufmerksamkeit auf Updates zu lenken.

Über dismissal-date:

• Optional. Unix-Epochenzeit in Sekunden. Nur relevant, wenn event "end" ist.
• Gibt an, wann die Live-Aktivität automatisch vom Gerät entfernt wird. Wenn Sie sie auslassen, bleibt die Live-Aktivität sichtbar, bis der Benutzer sie schließt.
• Muss ein zukünftiger Zeitstempel sein, der nach timestamp liegt.

Stellen Sie sicher, dass Ihre API-Payload mit der ActivityAttributes Implementierung Ihrer iOS-App übereinstimmt. Das LiveActivityAttributes-Protokoll von Adobe SDK erweitert iOS ActivityAttributes und erfordert eine liveActivityData.

Validieren der Zuordnung:

1. Ihr ActivityAttributes muss das LiveActivityAttributes-Protokoll von Adobe implementieren. Beispiel:

   code language-swift
   struct FoodDeliveryLiveActivityAttributes: LiveActivityAttributes { public struct ContentState: Codable, Hashable { var orderStatus: String var estimatedDeliveryTime: String } // Adobe SDK requirement var liveActivityData: LiveActivityData // Your custom attributes var restaurantName: String }

   Hinweis dass das Feld liveActivityData für Adobe SDK erforderlich ist und in allen Implementierungen enthalten sein muss.

2. Ihre API-Payload muss die iOS-Struktur widerspiegeln:

   code language-json
   { "aps": { "event": "start", "timestamp": 1756984054, "attributes-type": "FoodDeliveryLiveActivityAttributes", "content-state": { "orderStatus": "Preparing", "estimatedDeliveryTime": "20 mins" }, "attributes": { "liveActivityData": { "liveActivityID": "order-12345" }, "restaurantName": "Pizza Palace" } } }

Validierungs-Checkliste:

• Alle ContentState Felder in content-state einbeziehen (für alle Ereignistypen erforderlich).

• Alle LiveActivityAttributes Felder in attributes einbeziehen (nur Startereignisse), einschließlich:

  • liveActivityData (erforderlich; enthält normalerweise liveActivityID oder eine ähnliche Kennung)
  • Alle benutzerdefinierten Felder aus Ihrer Struktur

• Exakte Übereinstimmung der Feldnamen (unter Berücksichtigung von Groß- und Kleinschreibung)

• Übereinstimmende Datentypen (String, Int, bool, verschachtelte Objekte).

• Verschachtelte Objektstruktur beibehalten.

Häufige Fehler:

Weitere Beispiele finden Sie auf ​ Seite „Live-Aktivität erstellen.

Überprüfen der API-Ausführung und der Payload-Bereitstellung mithilfe von Assurance:

1. Öffnen Sie Ihre Assurance-Sitzung.

2. Ausführen des API-Aufrufs zum Trigger der Live-Aktivität.

3. Prüfen Sie der-Liste nach:

   • Ausführungsereignisse der Kampagne.
   • Versandereignisse für Live-Aktivitäten.
   • Payload-Validierungsfehler-Ereignisse.

4. Überprüfen Sie Ereignis-Payloads zur Überprüfung:

   • Payload wurde korrekt verarbeitet.
   • Keine Validierungsfehler aufgetreten.
   • Live-Aktivität wurde an APNs gesendet.

1. Öffnen Sie in Journey Optimizer Ihre Kampagne und navigieren Sie zum Menü Aktionen .
2. Überprüfen Sie Ihre Konfiguration der Live-Aktivität. Die Oberfläche muss die Android-App mit einem Paketnamen ansprechen, der mit dem appId im pushNotificationDetails des Profils übereinstimmt.
3. Stellen Sie sicher, dass die Oberfläche die FCM-Anmeldeinformationen für diese App verwendet. Die Token-Plattform des Profils muss "fcm" sein.
4. Vergewissern Sie sich, dass die notification_channel_id in der Payload mit einem von der App erstellten Benachrichtigungskanal übereinstimmt.

Platzieren Sie Android Live-Aktivitätsfelder unter context.requestPayload.fcm.

Unitäre Start-Payload:

{
   "requestId": "your-request-id",
   "campaignId": "your-campaign-id",
   "recipients": [
      {
         "type": "aep",
         "userId": "your-device-ECID",
         "namespace": "ECID",
         "context": {
            "requestPayload": {
               "fcm": {
                  "notification_id": "flight-DL-321",
                  "timestamp": 1756984054,
                  "notification_channel_id": "live_updates_channel",
                  "priority": "PRIORITY_HIGH",
                  "event_type": "start",
                  "title": "Flight DL-321",
                  "body": "Boarding starts shortly",
                  "critical_text": "25 min",
                  "content_state": {
                     "custom_key_template_type": "progress",
                     "custom_key_journey_start": "DEL",
                     "custom_key_journey_progress": 10,
                     "custom_key_journey_end": "MUM"
                  }
               }
            }
         }
      }
   ]
}

Ersetzen Sie den Beispiel-Zeitstempel durch die aktuelle Unix-Epochenzeit in Sekunden. Die content_state Schlüssel sind Beispiele und müssen mit dem Stilanbieter Ihrer App übereinstimmen.

Verwenden Sie für Sendungen eine API-ausgelöste Marketing-Kampagne mit audience.id und platzieren Sie das fcm Objekt unter context.requestPayload. Legen Sie topic_name auf das FCM-Thema fest, das von den Zielgeräten abonniert wird. Thema und notification_id bei Start-, Update- und End-Ereignissen unverändert lassen. Siehe die Beispiele für Android Broadcast-Payloads.

Häufige Payload-Probleme:

Zeitstempel und Lebenszyklusprüfungen:

• Verwenden Sie für jedes Start-, Update- und End-Ereignis einen neuen timestamp in Epochensekunden. Stellen Sie sicher, dass der vorherige Wert für dieselbe notification_id (oder topic_name für Sendungen) überschritten wird, auch wenn die Anfragen innerhalb derselben Sekunde erfolgen.
• Ältere oder gleiche Zeitstempel werden ignoriert. Zwischengespeicherte Zeitstempel nicht wiederverwenden.
• Das optionale Feld when steuert die angezeigte Zeit der Benachrichtigung, nicht die Reihenfolge der Nachrichten. Halten Sie ihn auf einem vernünftigen Stand und drücken Sie ihn in Epochensekunden aus.
• Um eine Aktivität zu aktualisieren oder zu beenden, ändern Sie event_type, ohne notification_id Änderungen vorzunehmen. Android verwendet dasselbe FCM-Registrierungstoken für alle drei Lebenszyklus-Ereignisse. Es ist kein separates Aktualisierungstoken erforderlich.

Abweisung des Endereignisses:

Legen Sie event_type: "end" optional dismiss_after auf die Anzahl der Sekunden fest, die die abgeschlossene Live-Aktivität vor dem Entfernen sichtbar bleiben soll. Dies ist eine Dauer, kein Epochenzeitstempel.

Der Stilanbieter der App bestimmt, wie content_state Werte in der Live-Aktivitätsbenachrichtigung gerendert werden.

1. Vergewissern Sie sich, dass Messaging und die Erweiterung Live-Aktivitäten in die App integriert sind.
2. Überprüfen Sie, ob jedes Feld in content_state mit einem vom Stilanbieter verarbeiteten Schlüssel übereinstimmt, einschließlich des erwarteten Werttyps.
3. Überprüfen Sie, ob title, body und critical_text den gewünschten Anzeigetext enthalten. critical_text wird für den Statusleisten-Chip verwendet.
4. Vergewissern Sie sich, dass Benachrichtigungsberechtigungen erteilt werden und dass der durch notification_channel_id identifizierte Kanal vorhanden ist.

Häufige Fehler:

Weitere Beispiele finden Sie unter Live-Aktivitäten erstellen.

Verwenden von Assurance auf einem verbundenen Android-Testgerät.

1. Öffnen Sie eine Assurance-Sitzung und bestätigen Sie, dass die FCM-Token-Registrierung sichtbar ist.
2. Führen Sie den API-Aufruf aus, um die Live-Aktivität zu starten, und senden Sie dann Aktualisierungs- und End-Ereignisse mit demselben notification_id und zunehmenden Zeitstempeln.
3. Überprüfen Sie die verfügbaren SDK-Ereignisse und Payloads auf Verarbeitungs- oder Validierungsfehler. Vergewissern Sie sich, dass die Android-Payload fcm und die vorgesehenen Lebenszykluswerte verwendet.
4. Überprüfen Sie auf der Registerkarte Ereignisse des Profils übereinstimmende message.feedback. Vergewissern Sie sich, dass serviceProvider fcm ist, und überprüfen Sie feedbackStatus, errorCode und errorMessage auf fehlgeschlagene Sendungen.
5. Wenn der Versand erfolgreich ist, die Live-Aktivität jedoch nicht gerendert wird, überprüfen Sie die App-Protokolle, Stilanbieter-Zuordnungen, Benachrichtigungsberechtigungen und die Kanalkonfiguration auf dem Gerät.

Überspringen Sie diesen Schritt, wenn Kampagnenbericht keine Versandfehler anzeigt. Ordnen Sie andernfalls den Fehler aus der Tabelle Fehlerursachen den folgenden gängigen APNs-Fehlern zu:

1. Navigieren Sie Journey Optimizer zu > Profile.

2. Suchen Sie nach dem Profil und öffnen Sie es.

3. Wählen Sie die Ereignisse aus.

4. Filtern oder suchen Sie nach Ereignissen mit eventType = "message.feedback".

5. Suchen Sie nach Feedback-Ereignissen, die dem liveActivityID und event Ihrer Live-Aktivität entsprechen.

6. Überprüfen Sie die folgenden Schlüsselfelder:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Feld	Mögliche Werte	Bedeutung
   feedbackStatus	sent, error, denylist	Versandergebnis vom Dienstleister
   serviceProvider	apns/apnsSandbox	Sollte APNs für iOS Live-Aktivitäten sein
   errorCode	Numerischer Code oder null	APNs-spezifischer Fehler-Code, wenn fehlgeschlagen
   errorMessage	Fehlerbeschreibung oder null	Lesbare Fehlermeldung

7. Wenn feedbackStatus: "error":

   • Überprüfen Sie die errorCode und errorMessage auf spezifische APNs-Fehler.
   • Zu den häufigen APNs-Fehlern gehören abgelaufene Token, ungültiges Zertifikat und eine falsche Paket-ID.

8. Wenn kein Feedback-Ereignis gefunden wird:

   • Die Push-Benachrichtigung wurde möglicherweise nicht versucht.
   • Überprüfen Sie, ob das Profil im Kampagnenbericht“ ausgeschlossen ​.

Wenn feedbackStatus sent ist: Journey Optimizer hat die Benachrichtigung an APNs weitergeleitet. Dadurch wird das Geräte-Rendering nicht bestätigt. Fahren Sie mit den geräteseitigen Prüfungen in Schritt 4 fort.

1. Öffnen Sie Ihre Assurance-Sitzung und lassen Sie sie während des API-Aufrufs aktiv.

2. Ausführen des API-Aufrufs (Starten, Aktualisieren oder Beenden).

3. Suchen Sie in Ereignisliste nach Versandereignissen für Live-Aktivitäten.

4. Suchen Sie nach Ereignissen im Zusammenhang mit dem APNs-Push-Versand.

5. Prüfen Sie die folgenden Indikatoren:

   • Push-Anfrage an APNs: Bestätigt, dass Adobe die Push-Benachrichtigung an die Server von Apple gesendet hat
   • APNs-: Zeigt an, ob APNs die Push-Benachrichtigung akzeptiert oder abgelehnt haben
   • Versandstatus: Erfolgs- oder Fehleranzeige

6. Wenn Probleme festgestellt werden, lesen Sie die folgenden häufigen Probleme bei der Bereitstellung von APNs:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
   Problem	Symptom in Assurance	Lösung
   APNs-Zertifikat abgelaufen	Authentifizierungsfehler	Neues APNs-Zertifikat erneuern und hochladen
   Falsche Umgebung (Entwicklung vs. Produktion)	Fehler wegen nicht übereinstimmender Token	Sicherstellen, dass das Zertifikat mit dem App-Build-Typ übereinstimmt
   Paket-ID stimmt nicht überein	Ungültige Bundle-Kennung	Überprüfen, ob die Zertifikatpaket-ID mit der App übereinstimmt
   Token abgelaufen	InvalidToken-Fehler von APNs	Live-Aktivitäts-Token erneut registrieren
   Ratenbegrenzung	Zu viele Anfragen	Verringern der API-Aufruffrequenz

Wenn Adobe einen erfolgreichen Versand anzeigt, das Gerät jedoch keine Live -Aktivität:

• Überprüfen Sie die iOS-Geräteprotokolle auf Fehler bei Live-Aktivitäten.
• Stellen Sie sicher, dass sich die App im Vordergrund oder Hintergrund befindet (nicht beendet).
• Vergewissern Sie sich, dass das Gerät über eine Netzwerkverbindung verfügt.
• Testen Sie auf mehreren Geräten, um gerätespezifische Probleme auszuschließen.
• Stellen Sie sicher, dass iOS Version 16.1 oder höher ist.

Wenn Sie alle Schritte ausgeführt haben und das Problem weiterhin nicht behoben ist, wenden Sie sich an die Adobe-Kundenunterstützung mit:

Erforderliche Informationen:

• Kampagnen-ID und -name
• Profil-Namespace und ID
• liveActivityID aus API-Payload
• Zeitstempel von API-Aufrufen
• Screenshots des Kampagnenberichts mit Versandstatistiken, Fehlerursachen und Ausschlussgründen
• Relevante Profilereignisse (liveActivity.updateToken für Probleme und message.feedback bei der unitären Aktualisierung/Beendigung)
• Assurance-Sitzungsdetails und Screenshots zu relevanten Ereignissen
• Payload und Antwort der API-Anfrage mit Anmeldeinformationen und Geräte-Token kopiert
• APNs-Zertifikatdetails (Ablauf, Umgebung, Paket-ID)

Überspringen Sie diesen Schritt, wenn Kampagnenbericht keine Versandfehler anzeigt. Ordnen Sie andernfalls den Fehler aus der Tabelle Fehlerursachen den folgenden gängigen FCM-Fehlern zu:

1. Navigieren Sie Journey Optimizer zu > Profile.

2. Suchen Sie nach dem Profil und öffnen Sie es.

3. Wählen Sie die Ereignisse aus.

4. Filtern oder suchen Sie nach Ereignissen mit eventType = "message.feedback".

5. Suchen Sie Feedback-Ereignisse für die Kampagne und Zeitstempel von API-Aufrufen, die Sie untersuchen.

6. Überprüfen Sie die folgenden Schlüsselfelder:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Feld	Mögliche Werte	Bedeutung
   feedbackStatus	sent, error, denylist	Versandergebnis vom Dienstleister
   serviceProvider	fcm	Von FCM behandelter Android-Push-Versand
   errorCode	Provider-Fehlercode oder null	FCM-spezifischer Fehler-Code bei fehlgeschlagenem Versand
   errorMessage	Fehlerbeschreibung oder null	Lesbare Fehlermeldung

7. Wenn feedbackStatus: "error":

   • Überprüfen Sie errorCode und errorMessage und wenden Sie die entsprechende FCM-Auflösung aus Schritt 1 an.

8. Wenn kein Feedback-Ereignis gefunden wird:

   • Die Push-Benachrichtigung wurde möglicherweise nicht versucht, oder Feedback ist möglicherweise noch nicht verfügbar.
   • Überprüfen Sie, ob das Profil im Kampagnenbericht“ ausgeschlossen ​.

Wenn feedbackStatus sent ist: FCM hat die Benachrichtigung akzeptiert. Dies bestätigt nicht, dass das Gerät die Live-Aktivität gerendert hat. Fahren Sie mit den geräteseitigen Prüfungen in Schritt 4 fort.

Verwenden von Assurance auf einem verbundenen Android-Testgerät.

1. Öffnen Sie eine Assurance-Sitzung und lassen Sie sie während des API-Aufrufs aktiv.
2. Führen Sie den API-Aufruf aus, wobei event_type auf start, update oder end eingestellt ist.
3. Überprüfen Sie in Liste Ereignisse“ verfügbare Push-Versandereignisse auf die Anfrage an FCM und deren Antwort.
4. Überprüfen Sie, ob FCM die Anfrage akzeptiert oder abgelehnt hat, und überprüfen Sie alle gemeldeten Fehlerdetails.
5. Verwenden Sie bei abgelehnten Anfragen die FCM-Fehler in Schritt 1, um das Token, die Firebase-Projektanmeldeinformationen und die Payload zu überprüfen. Wenn in der Sitzung keine Anbieterereignisse verfügbar sind, verwenden Sie message.feedback und Kampagnenberichte.

Wenn Adobe einen erfolgreichen Versand anzeigt, das Gerät die Live -Aktivität jedoch nicht anzeigt oder aktualisiert:

• Überprüfen Sie die Android-App-Protokolle auf Fehler bei der Push-Verarbeitung und beim Rendern der Live-Aktivität.
• Vergewissern Sie sich, dass Benachrichtigungen zulässig und hochgestufte Benachrichtigungen mit canPostPromotedNotifications() zulässig sind.
• Stellen Sie sicher, dass POST_NOTIFICATIONS- und POST_PROMOTED_NOTIFICATIONS-Berechtigungen gewährt werden und der durch notification_channel_id identifizierte Kanal vorhanden ist.
• Stellen Sie sicher, dass timestamp neuer als das zuletzt verarbeitete Ereignis ist und dass sich notification_id nicht geändert hat. Überprüfen Sie bei Sendungen auch das Geräteabonnement für topic_name.
• Vergewissern Sie sich, dass die App nicht zwangsweise angehalten wurde.
• Vergewissern Sie sich, dass das Gerät über eine Netzwerkverbindung verfügt.
• Testen Sie auf mehreren Geräten, um gerätespezifische Probleme auszuschließen.
• Stellen Sie sicher, dass auf dem Gerät Android 16.1 (API-Ebene 36.1) oder höher ausgeführt wird und die App targetSdk 36 verwendet.
• Vergewissern Sie sich, dass content_state Schlüssel und Werttypen mit dem Stilanbieter der App übereinstimmen.

Wenn Sie alle Schritte ausgeführt haben und das Problem weiterhin nicht behoben ist, wenden Sie sich an die Adobe-Kundenunterstützung mit:

Erforderliche Informationen:

• Kampagnen-ID und -name
• Profil-Namespace und ID
• notification_id und event_type aus der API-Payload; bei Sendungen auch topic_name und die Zielgruppen-ID angeben
• Zeitstempel von API-Aufrufen
• Screenshots des Kampagnenberichts mit Versandstatistiken, Fehlerursachen und Ausschlussgründen
• Relevante message.feedback, einschließlich FCM-Fehlercodes und -Meldungen
• Assurance-Sitzungsdetails und Screenshots zu relevanten Ereignissen
• Payload und Antwort der API-Anfrage mit Anmeldeinformationen und Geräte-Token kopiert
• Paketname, Firebase-Projekt und Absender-ID sowie Konfigurationsdetails für FCM-Anmeldeinformationen; enthalten keine privaten Schlüssel
• Android-Betriebssystemversion, Gerätemodell, Benachrichtigungsberechtigungsstatus und relevante App-Protokolle

1. Öffnen Sie Ihre API-ausgelöste Marketing Kampagne in Journey Optimizer.

2. Navigieren Sie zum Abschnitt Zielgruppe und überprüfen Sie Folgendes:

   • Für die Kampagne wird eine Audience ausgewählt.
   • Die Zielgruppen-ID entspricht der in Ihrer API-Payload verwendeten.
   • Die Zielgruppe enthält die erwarteten Profile.

3. Navigieren Sie zum Abschnitt Aktionen .

4. Überprüfen Sie die Konfiguration der Live-Aktivität:

   • Die Konfiguration muss für die iOS-App mit der richtigen Bundle-ID festgelegt werden.
   • Der Aktivitätstyp muss mit dem attributes-type in Ihrer API-Payload übereinstimmen. Wenn Ihre Payload beispielsweise "attributes-type": "AirplaneTrackingAttributes" enthält, muss die Kampagne denselben Aktivitätstyp angeben.

Die Struktur der Broadcast-Payload unterscheidet sich von unitären Kampagnen. Vergewissern Sie sich, dass Ihre Payload das richtige Sendeformat verwendet.

Erforderliche Felder für die Übertragung:

{
   "campaignId": "878a11d4-b519-47bd-8313-fecfee19857b",
   "audience": {
      "id": "8c3dbdea-2957-401f-acf0-3966fba1601e"
   },
   "context": {
      "requestPayload": {
         "aps": {
            "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
            "content-available": 1,
            "timestamp": 1771829292,
            "event": "start",
            "attributes-type": "AirplaneTrackingAttributes",
            "content-state": { ... },
            "attributes": { ... }
         }
      }
   }
}

Häufige Payload-Probleme:

Kritische Broadcast-spezifische Felder:

• input-push-channel:

  • Erforderlich für alle Broadcast-Live-Aktivitäten.
  • Fungiert als eindeutige Kennung für diese spezifische Broadcast-Instanz.
  • Alle Profile in der Zielgruppe erhalten Live-Aktivitäten, die mit diesem Kanal verknüpft sind.
  • Muss mit dem channelID in liveActivityData.channelID übereinstimmen (siehe Schritt 3).
  • Muss für das appID im Apple-Entwicklerportal von Ihrem Team erstellt werden.
  • Nur Kanäle, die für das jeweilige appID erstellt wurden, können für die Übertragung der Live-Aktivität in diesem Programm verwendet werden.

• audience.id:

  • Muss auf ein in Adobe Experience Platform erstelltes gültiges Zielgruppensegment verweisen.
  • Alle Profile in dieser Zielgruppe sind für die Live-Aktivität angesprochen.
  • Die Zielgruppe muss aktiviert sein und Profile mit gültigen liveActivityPushNotificationDetails enthalten.

Verwenden Sie immer den neuesten Zeitstempel:

• Das Feld timestamp muss bei jedem API-Aufruf immer die aktuelle Unix-Epochenzeit (in Sekunden) sein.
• Diese Anforderung gilt für alle Ereignistypen: start, update und end.
• Kritisch für Updates/Ende: Die Verwendung veralteter Zeitstempel führt dazu, dass Update- und End-Anfragen fehlschlagen.
• Generieren Sie für jeden Broadcast-API-Aufruf einen neuen Zeitstempel.

Optionale Felder:

• dismissal-date: Unix-Epochenzeit für automatische Abweisung (nur relevant für end Ereignisse)
• alert: Objekt mit title und body zur Benachrichtigung

Vollständige API-Spezifikationen finden Sie in der 🔗 zur Adobe Journey Optimizer Messaging-API .

Stellen Sie sicher, dass die Payload-Felder mit der ActivityAttributes Implementierung Ihrer iOS-App übereinstimmen und dass die input-push-channel mit der channelID in liveActivityData übereinstimmt.

1. Überprüfen Sie Ihre iOS ActivityAttributes-Definition.

Ihre benutzerdefinierte ActivityAttributes muss das LiveActivityAttributes-Protokoll von Adobe implementieren:

struct AirplaneTrackingAttributes: LiveActivityAttributes {
   public struct ContentState: Codable, Hashable {
      var journeyProgress: Int
   }

   // Adobe SDK requirement
   var liveActivityData: LiveActivityData

   // Your custom attributes
   var arrivalAirport: String
   var departureAirport: String
   var arrivalTerminal: String
}

1. Ordnen Sie iOS-Felder der Broadcast-API-Payload zu.

content-state für alle Ereignistypen einschließen. attributes, einschließlich liveActivityData.channelID, nur für Startereignisse einschließen:

{
   "aps": {
      "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
      "event": "start",
      "timestamp": 1771829292,
      "attributes-type": "AirplaneTrackingAttributes",
      "content-state": {
         "journeyProgress": 0
      },
      "attributes": {
         "arrivalAirport": "DEL",
         "departureAirport": "MUM",
         "arrivalTerminal": "T1",
         "liveActivityData": {
            "channelID": "FEt0NgvLEfEAAOqA6AXdIQ=="
         }
      }
   }
}

Kritisch: input-push-channel muss mitchannelID übereinstimmen

• Der input-push-channel am Stamm von aps muss genau mit dem channelID in liveActivityData übereinstimmen.
• Im obigen Beispiel werden beide Werte "FEt0NgvLEfEAAOqA6AXdIQ==".
• Dieser Abgleich verknüpft die Broadcast-Instanz mit den Daten der Live-Aktivität.
• Fehlende Übereinstimmung führt zu fehlgeschlagenen Sendungen.

Wichtige Validierungspunkte:

• Schließen Sie alle ContentState Felder in content-state für alle Ereignistypen ein.
• Schließen Sie alle benutzerdefinierten LiveActivityAttributes nur für Startereignisse in attributes ein.
• Bei Startereignissen muss liveActivityData.channelID mit input-push-channel übereinstimmen.
• Bei Feldnamen wird zwischen Groß- und Kleinschreibung unterschieden und sie müssen genau übereinstimmen.
• Datentypen müssen übereinstimmen (Zeichenfolge, int, bool, verschachtelte Objekte usw.).
• Verwenden Sie für Aktualisierungs-/Endereignisse denselben input-push-channel wie das ursprüngliche Startereignis.

Häufige Fehler:

Überprüfen der API-Ausführung und der Payload-Bereitstellung mithilfe von Assurance:

1. Öffnen Sie Ihre Assurance-Sitzung auf einem Testgerät, das Teil der Zielgruppe ist.

2. Führt den Broadcast-API-Aufruf aus.

3. Suchen Sie in Ereignisliste nach:

   • Ausführungsereignisse der Kampagne.
   • Versandereignisse für Live-Aktivitäten.
   • Fehlerereignisse, die auf Fehler bei der Payload-Validierung hinweisen.

4. Überprüfen Sie Ereignis-Payloads zur Bestätigung:

   • Die Payload wurde korrekt verarbeitet.
   • Die input-push-channel ist vorhanden.
   • Keine Validierungsfehler aufgetreten.
   • Live-Aktivitäten wurden für Zielgruppenmitglieder an APNs gesendet.

1. Öffnen Sie Ihre API-ausgelöste Marketing Kampagne in Journey Optimizer.

2. Navigieren Sie zum Abschnitt Zielgruppe und überprüfen Sie Folgendes:

   • Für die Kampagne wird eine Audience ausgewählt.
   • Die Zielgruppen-ID entspricht der in Ihrer API-Payload verwendeten.
   • Die Zielgruppe enthält die erwarteten Profile.

3. Navigieren Sie zum Abschnitt Aktionen .

4. Vergewissern Sie sich, dass Konfiguration der Live Aktivität auf das richtige Android-Paket abzielt und die entsprechenden FCM-Anmeldeinformationen verwendet. Android verwendet keinen Aktivitätstyp und kein attributes-type.

Android-Sendungen verwenden ein FCM-Thema. Schließen Sie audience.id ein und platzieren Sie das fcm Objekt unter context.requestPayload anstatt unter einem einzelnen Empfänger.

Beispiel für Broadcast-Start-Payload:

{
   "requestId": "your-request-id",
   "campaignId": "your-marketing-campaign-id",
   "audience": {
      "id": "your-audience-id"
   },
   "context": {
      "requestPayload": {
         "fcm": {
            "topic_name": "flight_DL321",
            "notification_id": "flight-DL-321",
            "notification_channel_id": "live_updates_channel",
            "timestamp": 1771829292,
            "priority": "PRIORITY_HIGH",
            "event_type": "start",
            "title": "Flight DL-321",
            "body": "Boarding starts shortly",
            "critical_text": "25 min",
            "content_state": {
               "custom_key_template_type": "progress",
               "custom_key_journey_start": "DEL",
               "custom_key_journey_progress": 10,
               "custom_key_journey_end": "MUM"
            }
         }
      }
   }
}

Ersetzen Sie den Beispiel-Zeitstempel durch die aktuelle Unix-Epochenzeit in Sekunden. Passen Sie die content_state Schlüssel an den Stilanbieter Ihrer App an.

Häufige Payload-Probleme:

Kritische Broadcast-spezifische Felder:

• topic_name: Identifiziert das FCM-Thema, das von den Zielgeräten abonniert wird. Denselben nicht leeren Wert in jede Start-, Update- und End-Anfrage einschließen.
• audience.id: Identifiziert die Zielgruppe der Kampagne in Adobe Experience Platform. Überprüfen der Mitgliedschaft und der Beispielprofile auf gültige pushNotificationDetails.

Zeitstempel und optionale Felder:

• Generieren Sie für jedes Ereignis einen neuen timestamp in Epochensekunden und stellen Sie sicher, dass dieser streng größer als der letzte Wert für dasselbe Thema ist. Ältere oder gleiche Werte werden ignoriert.
• when legt optional die Anzeigedauer der Benachrichtigung in Epochenzeit Sekunden fest. Die Nachrichtenreihenfolge wird nicht gesteuert.
• event_type: "end" gibt dismiss_after optional an, wie viele Sekunden die abgeschlossene Aktivität vor dem Entfernen sichtbar bleibt. Es handelt sich um eine Dauer, nicht um einen Epochenzeitstempel.

Vollständige API-Spezifikationen finden Sie in der 🔗 zur Adobe Journey Optimizer Messaging-API .

1. Vergewissern Sie sich mithilfe von FirebaseMessaging.getInstance().subscribeToTopic(topic), dass das Testgerät das in topic_name angegebene Thema abonniert hat.
2. Vergewissern Sie sich, dass das Abonnement erfolgreich war und dass die App es über die Topic-Subscription-Tracking-API meldet, die von der installierten Adobe Live Activities-Erweiterung unterstützt wird.
3. topic_name und notification_id über Start-, Update- und End-Ereignisse hinweg unverändert beibehalten.
4. Stellen Sie sicher, dass content_state Schlüssel und Werttypen mit dem Stilanbieter der App übereinstimmen.
5. Überprüfen Sie, ob Benachrichtigungsberechtigungen erteilt wurden und ob notification_channel_id mit einem von der App erstellten Kanal übereinstimmt.

Häufige Fehler:

Weitere Felder und Beispiele finden Sie im Beispiel 🔗 Android Broadcast-Payload .

Verwenden Sie Assurance auf einem verbundenen Android-Testgerät, das zur Zielgruppe gehört und das für die Übertragung angemeldet ist.

1. Öffnen Sie Ihre Assurance-Sitzung, bevor Sie den Broadcast-API-Aufruf ausführen.
2. Senden Sie Start-, Aktualisierungs- und End-Anfragen mit denselben topic_name und notification_id sowie steigenden Zeitstempeln.
3. Überprüfen Sie in Liste Ereignisse“ verfügbare SDK- und Versandereignisse auf Fehler bei der Payload-Verarbeitung.
4. Vergewissern Sie sich, dass die Payload die beabsichtigten fcm, topic_name und event_type Werte enthält.
5. Überprüfen Sie die Kampagnenberichte und verfügbaren message.feedback-Ereignisse, um die FCM-Versandergebnisse zu bestätigen. Der Android-serviceProvider ist fcm.
6. Wenn FCM die Nachricht akzeptiert, das Gerät die Aktivität jedoch nicht rendert, überprüfen Sie Themenabonnement, Benachrichtigungsberechtigungen, Kanalkonfiguration und App-Protokolle. Die Anbieterakzeptanz bestätigt nicht das Geräte-Rendering.