Scénarios de dépannage des activités en direct courantes troubleshoot-mobile-live

Vous pouvez utiliser Assurance pour vérifier l’enregistrement des jetons :

1. Dans Assurance, à partir de la liste Événements, filtrez ou recherchez des événements eventType = "liveActivity.pushToStart".
2. Sélectionnez l’événement Event et examinez la payload.
3. Vérifiez que les valeurs token, appId et attributeType sont présentes.
4. Vérifiez que l’événement a bien été envoyé.

Vous pouvez également archiver le profil Adobe Experience Platform.

1. Dans Adobe Experience Platform, à partir de votre Profil, accédez à l’onglet Événements.
2. Recherchez des événements liveActivity.pushToStart.
3. Vérifiez la date et l’heure de l’événement ainsi que la payload.

Si aucun événement n’est trouvé, l’application n’appelle pas Messaging.registerLiveActivities correctement. Correction de l’intégration de SDK.

1. À partir de votre Profil, accédez à l’onglet Attributs.

2. Localisez liveActivityPushNotificationDetails.

3. Vérifiez la configuration du jeton :

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

Valider chaque champ :

Si un champ est incorrect, mettez à jour l’application mobile, réenregistrez-la à l’aide de l’Messaging.registerLiveActivities, patientez entre 5 et 10 minutes, puis vérifiez à nouveau.

Si liveActivityPushNotificationDetails est manquant, le jeton n’a pas encore été synchronisé. Patientez 5 à 10 minutes après avoir affiché l’événement liveActivity.pushToStart dans Assurance, puis revérifiez.

Android utilise le jeton d’enregistrement FCM standard pour les activités dynamiques. Il n’existe aucun événement liveActivity.pushToStart ou jeton push d’activité dynamique distinct.

1. Dans Assurance, ouvrez la liste Événements et recherchez l’événement d’enregistrement de jeton push standard.
2. Sélectionnez l’événement et examinez sa payload pour vérifier que le jeton d’enregistrement FCM est présent.
3. Vérifiez que l’événement d’enregistrement a bien été envoyé.
4. Dans Adobe Experience Platform, ouvrez l’onglet Attributs de votre profil et vérifiez que le jeton est présent dans pushNotificationDetails, comme décrit à l’étape 2.

Si l’événement d’enregistrement ou le jeton de profil est manquant, vérifiez que l’application transfère le jeton d’enregistrement FCM vers SDK à l’aide de MobileCore.setPushIdentifier(token).

1. À partir de votre profil, accédez à l’onglet Attributs.

2. Localisez pushNotificationDetails. Android utilise cet objet au lieu de liveActivityPushNotificationDetails et ne nécessite pas de champ attributeType.

3. Vérifiez que la configuration du jeton suit cette structure :

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

Valider chaque champ :

Si un champ est incorrect, corrigez la configuration d’application selon les besoins, transférez à nouveau le jeton FCM à l’aide de MobileCore.setPushIdentifier(token), patientez 5 à 10 minutes, puis vérifiez à nouveau le profil.

Si pushNotificationDetails est manquant, le jeton n’a pas encore été synchronisé. Après avoir confirmé l’enregistrement du jeton dans Assurance, patientez 5 à 10 minutes, puis vérifiez à nouveau le profil.

1. Dans Journey Optimizer, ouvrez votre Campagne et accédez au menu Actions.
2. Vérifiez la configuration de l’activité dynamique. La surface doit être configurée pour l’application iOS avec un identifiant de lot correspondant à l’appId dans le liveActivityPushNotificationDetails de votre profil. Par exemple, si votre profil a "appId": "com.example.myapp", la surface doit cibler cette même application.
3. Vérifiez que le type d’activité dans votre configuration de campagne correspond exactement au attributeType dans le liveActivityPushNotificationDetails de votre profil. Par exemple, si votre profil a "attributeType": "FoodDeliveryLiveActivityAttributes", la campagne doit spécifier le même type d’activité.

Lors de l’exécution de la campagne par le biais de l’API, assurez-vous que la payload suit la structure correcte.

Payload unitaire :

{
   "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": { ... }
            }
         }
      }
   }]
}

Problèmes courants de payload :

Critique : utilisez toujours un nouvel horodatage

• Définissez timestamp sur l’heure Unix actuelle (en secondes) au moment où vous effectuez chaque appel API. Cela s’applique à tous les types d’événements : start, update et end.
• Un horodatage obsolète ou réutilisé entraîne l’échec ou l’ignorance des requêtes de mise à jour et de fin par l’appareil. Ne réutilisez pas les horodatages des requêtes précédentes ou les valeurs mises en cache.

Champs facultatifs (tous les types d’événements) :

• requestId : identifiant unique pour le tracking (recommandé).
• alert : objet avec title et body pour la notification. Utile pour attirer l’attention sur les mises à jour.

À propos de dismissal-date:

• Facultatif. Heure Unix epoch en secondes. Pertinent uniquement lorsque event est "end".
• Indique à quel moment l’activité Live est automatiquement supprimée de l’appareil. Si vous l’omettez, l’activité Live reste visible jusqu’à ce que l’utilisateur la ferme.
• Doit être un horodatage ultérieur, postérieur à timestamp.

Assurez-vous que la payload de l’API correspond à la mise en œuvre ActivityAttributes de l’application iOS. Le protocole LiveActivityAttributes d’Adobe SDK étend la ActivityAttributes d’iOS et nécessite une propriété liveActivityData.

Validez le mappage :

1. Votre ActivityAttributes doit mettre en œuvre le protocole LiveActivityAttributes d’Adobe. Exemple :

   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 }

   Notez que le champ liveActivityData est requis par Adobe SDK et doit être inclus dans toutes les implémentations.

2. La payload de l’API doit refléter la structure d’iOS :

   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" } } }

Liste de contrôle de validation :

• Incluez tous les champs ContentState dans content-state (obligatoire pour tous les types d’événements).

• Incluez tous les champs LiveActivityAttributes dans attributes (événements de début uniquement), notamment :

  • liveActivityData (obligatoire ; contient généralement un identifiant liveActivityID ou similaire)
  • Tous les champs personnalisés de votre structure

• Faire correspondre exactement les noms des champs (respect de la casse).

• Faire correspondre les types de données (chaîne, entier, booléen, objets imbriqués).

• Conserver la structure de l’objet imbriqué.

Erreurs courantes :

Pour consulter d’autres exemples, consultez la page Créer une activité en direct.

Vérifiez l’exécution de l’API et la diffusion de la payload à l’aide d’Assurance :

1. Ouvrez votre session Assurance.

2. Exécutez l’appel API pour déclencher l’activité Live .

3. Dans la Liste des événements, vérifiez les éléments suivants :

   • Événements d’exécution de campagne.
   • Événements de diffusion d’activité en direct.
   • Événements d’erreur de validation de la payload.

4. Examinez les payloads d’événement pour vérifier les éléments suivants :

   • La payload a été traitée correctement.
   • Aucune erreur de validation ne s’est produite.
   • L’activité en direct a été envoyée aux APNs.

1. Dans Journey Optimizer, ouvrez votre Campagne et accédez au menu Actions.
2. Vérifiez la configuration de l’activité dynamique. La surface doit cibler l’application Android avec un nom de package correspondant au appId dans le pushNotificationDetails du profil.
3. Vérifiez que la surface utilise les informations d’identification FCM pour cette application. La plateforme de jeton du profil doit être "fcm".
4. Vérifiez que la notification_channel_id dans la payload correspond à un canal de notification créé par l’application.

Placez les champs d’activité Android Live sous context.requestPayload.fcm.

Payload de début unitaire :

{
   "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"
                  }
               }
            }
         }
      }
   ]
}

Remplacez l’exemple d’horodatage par l’heure Unix actuelle en secondes. Les clés content_state sont des exemples et doivent correspondre au fournisseur de style de votre application.

Pour les diffusions, utilisez une campagne marketing déclenchée par API avec audience.id et placez l’objet fcm sous context.requestPayload. Définissez topic_name sur la rubrique FCM à laquelle les appareils cibles sont abonnés. Conservez la rubrique et le notification_id inchangés pour les événements de début, de mise à jour et de fin. Consultez les exemples de payload de diffusion ​.

Problèmes courants de payload :

Vérifications d’horodatage et de cycle de vie :

• Utilisez une nouvelle timestamp en quelques secondes pour chaque événement de début, de mise à jour et de fin. Assurez-vous qu’elle est supérieure à la valeur précédente pour la même notification_id (ou topic_name pour les diffusions), même lorsque les demandes sont effectuées dans la même seconde.
• Les dates et heures antérieures ou égales sont ignorées. Ne réutilisez pas les horodatages mis en cache.
• Le champ facultatif when contrôle l’heure d’affichage de la notification, et non l’ordre des messages. Conservez-le à jour et exprimez-le en quelques secondes.
• Pour mettre à jour ou terminer une activité, modifiez les event_type tout en conservant les notification_id inchangées. Android utilise le même jeton d’enregistrement FCM pour les trois événements de cycle de vie ; aucun jeton de mise à jour distinct n’est requis.

Rejet de l’événement de fin :

Par event_type: "end", vous pouvez éventuellement définir la dismiss_after sur le nombre de secondes pendant lesquelles l’activité Live terminée doit rester visible avant la suppression. Il s’agit d’une durée, et non d’une date et heure Unix.

Le fournisseur de style de l’application détermine le rendu des valeurs content_state dans la notification d’activité dynamique.

1. Vérifiez que la messagerie et l’extension Activités en direct sont intégrées dans l’application.
2. Vérifiez que chaque champ de content_state correspond à une clé gérée par le fournisseur de style, y compris son type de valeur attendu.
3. Vérifiez que title, body et critical_text contiennent le texte d’affichage prévu. critical_text est utilisé pour la puce de la barre d’état.
4. Vérifiez que les autorisations de notification sont accordées et que le canal identifié par notification_channel_id existe.

Erreurs courantes :

Pour consulter d’autres exemples, voir Création d’activités dynamiques.

Utilisez Assurance sur un appareil de test Android connecté.

1. Ouvrez une session Assurance et vérifiez que l’enregistrement du jeton FCM est visible.
2. Exécutez l’appel API pour démarrer l’activité Live, puis envoyez les événements de mise à jour et de fin avec la même notification_id et des horodatages croissants.
3. Consultez les événements et payloads SDK disponibles pour le traitement ou la validation des erreurs. Vérifiez que la payload Android utilise fcm et les valeurs de cycle de vie prévues.
4. Dans l’onglet Événements du profil, inspectez les événements message.feedback correspondants. Vérifiez que serviceProvider est fcm et passez en revue les feedbackStatus, errorCode et errorMessage en cas d’échec de la diffusion.
5. Si la diffusion réussit, mais que l’activité Live n’est pas rendue, examinez les journaux d’application, les mappages de fournisseur de style, les autorisations de notification et la configuration des canaux sur l’appareil.

Ignorer cette étape si le rapport de campagne n’affiche aucune erreur d’envoi. Sinon, faites correspondre l’erreur du tableau Raisons de l’erreur aux erreurs APNs courantes suivantes :

1. Accédez à Client > Profils dans Journey Optimizer.

2. Recherchez et ouvrez le profil.

3. Sélectionnez l’onglet Événements.

4. Filtrez ou recherchez des événements avec eventType = "message.feedback".

5. Recherchez des événements de retour correspondant au type de liveActivityID et de event de votre activité Live.

6. Examinez les champs clés suivants :

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Champ	Valeurs possibles	Signification
   feedbackStatus	sent, error, denylist	Résultat de diffusion du prestataire
   serviceProvider	apns/apnsSandbox	Doit être un APN pour les activités iOS Live
   errorCode	Code numérique ou null	Code d’erreur spécifique à APNS en cas d’échec
   errorMessage	Description ou null de l’erreur	Message d’erreur lisible par l’utilisateur

7. If feedbackStatus: "error":

   • Vérifiez les errorCode et les errorMessage pour détecter les erreurs APNs spécifiques.
   • Les erreurs APNs courantes incluent un jeton expiré, un certificat non valide, un ID de lot incorrect.

8. Si aucun événement de retour n’est trouvé :

   • Il se peut que la notification push n’ait pas été tentée.
   • Vérifiez si le profil a été exclu du ​ rapport de campagne ​.

Si feedbackStatus est sent : Journey Optimizer a remis la notification aux APNs. Cela ne confirme pas le rendu de l’appareil. Poursuivez les vérifications côté appareil à l’étape 4.

1. Ouvrez votre session Assurance et maintenez-la active pendant l’appel API.

2. Exécutez l’appel API (début, mise à jour ou fin).

3. Dans la Liste des événements, recherchez les événements de diffusion d’activité en direct .

4. Recherchez des événements liés à la diffusion des notifications push APNS.

5. Recherchez les indicateurs suivants :

   • Requête push aux APNs : confirme qu’Adobe a envoyé la notification push aux serveurs Apple.
   • Réponse APNs : indique si APNs a accepté ou rejeté la notification push.
   • Statut de la diffusion : indication de succès ou d’échec

6. Si des problèmes sont détectés, reportez-vous aux problèmes de diffusion APNS courants suivants :

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
   Problème	Symptôme dans Assurance	Résolution
   Certificat APNS expiré	Erreur d’authentification	Renouveler et charger un nouveau certificat APNS
   Mauvais environnement (développement ou production)	Erreur de correspondance de jeton	S’assurer que le certificat correspond au type de build de l’application
   Incompatibilité de l’ID de lot	Identifiant de lot non valide	Vérifier que l’ID de groupe de certificats correspond à l’application
   Jeton expiré	Erreur InvalidToken depuis APNS	Réenregistrer les jetons d’activité actifs
   Limitation de débit	Trop de requêtes	Réduire la fréquence des appels API

Si Adobe affiche une diffusion réussie mais que l’appareil n’affiche pas l’activité Live :

• Recherchez des erreurs d’activité en direct dans les journaux des appareils iOS.
• Vérifiez que l’application est au premier plan ou en arrière-plan (non terminée).
• Vérifiez que l’appareil dispose d’une connectivité réseau.
• Testez plusieurs appareils pour exclure les problèmes spécifiques à l’appareil.
• Vérifiez qu’iOS version 16.1 ou ultérieure.

Si vous avez terminé toutes les étapes et que le problème n’est pas résolu, contactez l’assistance clientèle d’Adobe à l’adresse suivante :

Informations requises :

• Identifiant et nom de campagne
• Espace de noms et ID du profil
• liveActivityID à partir de la payload de l’API
• Horodatages des appels API
• Captures d’écran des rapports de campagne présentant les statistiques d’envoi, les raisons d’erreur et les raisons d’exclusion
• Événements de profil pertinents (liveActivity.updateToken pour les problèmes et message.feedback de mise à jour/de fin unitaires)
• Détails de la session Assurance et captures d’écran d’événement pertinentes
• Payload et réponse de requête API, avec les informations d’identification et les jetons d’appareil supprimés
• Détails du certificat APNS (expiration, environnement, ID de lot)

Ignorer cette étape si le rapport de campagne n’affiche aucune erreur d’envoi. Sinon, faites correspondre l’erreur du tableau Raisons de l’erreur aux erreurs FCM courantes suivantes :

1. Accédez à Client > Profils dans Journey Optimizer.

2. Recherchez et ouvrez le profil.

3. Sélectionnez l’onglet Événements.

4. Filtrez ou recherchez des événements avec eventType = "message.feedback".

5. Recherchez les événements de retour pour la campagne et les horodatages d’appel API que vous recherchez.

6. Examinez les champs clés suivants :

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Champ	Valeurs possibles	Signification
   feedbackStatus	sent, error, denylist	Résultat de diffusion du prestataire
   serviceProvider	fcm	Diffusion de notifications push Android gérée par FCM
   errorCode	Code d’erreur ou null du fournisseur	Code d’erreur spécifique à FCM en cas d’échec de la diffusion
   errorMessage	Description ou null de l’erreur	Message d’erreur lisible par l’utilisateur

7. If feedbackStatus: "error":

   • Inspectez errorCode et errorMessage et appliquez la résolution FCM correspondante à partir de l’étape 1.

8. Si aucun événement de retour n’est trouvé :

   • Il se peut que la notification push n’ait pas été tentée ou que les commentaires ne soient pas encore disponibles.
   • Vérifiez si le profil a été exclu du ​ rapport de campagne ​.

Si feedbackStatus est sent : FCM a accepté la notification. Cela ne confirme pas que l’appareil a rendu l’activité En direct . Poursuivez les vérifications côté appareil à l’étape 4.

Utilisez Assurance sur un appareil de test Android connecté.

1. Ouvrez une session Assurance et maintenez-la active pendant l’appel API.
2. Exécutez l’appel API avec event_type défini sur start, update ou end.
3. Dans la liste Événements, examinez les événements de diffusion push disponibles pour la requête à FCM et sa réponse.
4. Vérifiez si FCM a accepté ou rejeté la demande et examinez tous les détails d’erreur signalés.
5. Pour les requêtes rejetées, utilisez les erreurs FCM de l’étape 1 pour vérifier le jeton, les informations d’identification du projet Firebase et la payload. Si les événements du fournisseur ne sont pas disponibles dans la session, utilisez les événements message.feedback et les rapports de campagne.

Si Adobe affiche une diffusion réussie mais que l’appareil n’affiche pas ou ne met pas à jour l’activité Live :

• Inspectez les journaux de l’application Android pour détecter les erreurs de gestion des notifications push et de rendu des activités dynamiques.
• Vérifiez que les notifications sont autorisées et que les notifications promues sont autorisées à l’aide de canPostPromotedNotifications().
• Vérifiez que les autorisations POST_NOTIFICATIONS et POST_PROMOTED_NOTIFICATIONS sont accordées et que le canal identifié par notification_channel_id existe.
• Assurez-vous que timestamp est plus récent que le dernier événement traité et que notification_id n’a pas changé. Pour les diffusions, vérifiez également l’abonnement de l’appareil à topic_name.
• Vérifiez que l’application n’est pas arrêtée de force.
• Vérifiez que l’appareil dispose d’une connectivité réseau.
• Testez plusieurs appareils pour exclure les problèmes spécifiques à l’appareil.
• Vérifiez que l’appareil exécute Android 16.1 (niveau API 36.1) ou une version ultérieure et que l’application utilise targetSdk 36.
• Vérifiez que les clés content_state et les types valeur correspondent au fournisseur de style de l’application.

Si vous avez terminé toutes les étapes et que le problème n’est pas résolu, contactez l’assistance clientèle d’Adobe à l’adresse suivante :

Informations requises :

• Identifiant et nom de campagne
• Espace de noms et ID du profil
• notification_id et event_type de la payload de l’API ; pour les diffusions, incluez également les topic_name et l’ID d’audience
• Horodatages des appels API
• Captures d’écran des rapports de campagne présentant les statistiques d’envoi, les raisons d’erreur et les raisons d’exclusion
• Événements de message.feedback de profil pertinents, y compris les codes d’erreur FCM et les messages
• Détails de la session Assurance et captures d’écran d’événement pertinentes
• Payload et réponse de requête API, avec les informations d’identification et les jetons d’appareil supprimés
• Nom du package Android, projet Firebase, ID de l’expéditeur et détails de configuration des informations d’identification FCM ; n’incluez pas de clés privées
• Version du système d’exploitation Android, modèle d’appareil, statut d’autorisation des notifications et journaux d’application pertinents

1. Ouvrez votre campagne marketing déclenchée par API dans Journey Optimizer.

2. Accédez à la section Audience et vérifiez les éléments suivants :

   • Une audience est sélectionnée pour la campagne.
   • L’ID d’audience correspond à celui utilisé dans votre payload d’API.
   • L’audience contient les profils attendus.

3. Accédez à la section Actions.

4. Vérifiez la Configuration de l’activité dynamique :

   • La configuration doit être définie pour l’application iOS avec l’identifiant de lot approprié.
   • Le type d’activité doit correspondre à la attributes-type de votre payload API. Par exemple, si votre payload contient des "attributes-type": "AirplaneTrackingAttributes", la campagne doit spécifier le même type d’activité.

La structure de la payload de diffusion diffère des campagnes unitaires. Vérifiez que la payload respecte le format de diffusion approprié.

Champs obligatoires pour la diffusion :

{
   "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": { ... }
         }
      }
   }
}

Problèmes courants de payload :

Champs critiques spécifiques à la diffusion :

• input-push-channel:

  • Obligatoire pour toutes les activités de diffusion en direct.
  • Sert d’identifiant unique pour cette instance de diffusion spécifique.
  • Tous les profils de l’audience reçoivent des activités en direct liées à ce canal.
  • Doit correspondre à la channelID dans liveActivityData.channelID (voir étape 3).
  • Doit être créé pour le appID dans le portail Apple Developer Portal par votre équipe.
  • Seuls les canaux créés pour l’appID spécifique peuvent être utilisés pour la diffusion d’activités en direct sur cette application.

• audience.id:

  • Un segment d’audience valide créé dans Adobe Experience Platform doit être référencé.
  • Tous les profils de cette audience sont ciblés pour l’activité En direct .
  • L’audience doit être activée et contenir des profils avec des liveActivityPushNotificationDetails valides.

Utilisez toujours la dernière date et heure :

• Le champ timestamp doit toujours correspondre à l’heure Unix actuelle (en secondes) pour chaque appel API.
• Cette exigence s’applique à tous les types d’événements : start, update et end.
• Critique pour les mises à jour/fin : l’utilisation d’horodatages obsolètes entraîne l’échec des demandes de mise à jour et de fin.
• Générez un nouvel horodatage pour chaque appel API de diffusion.

Champs facultatifs :

• dismissal-date : époque Unix pour le rejet automatique (pertinent uniquement pour les événements end)
• alert : objet avec title et body pour la notification

Consultez la documentation de l’API de messagerie Adobe Journey Optimizer 🔗 pour obtenir des spécifications d’API complètes.

Assurez-vous que les champs de payload correspondent à l’implémentation ActivityAttributes de votre application iOS et que le input-push-channel correspond au channelID dans liveActivityData.

1. Vérifiez votre définition d’Attributs d’activité iOS.

Votre structure de ActivityAttributes personnalisée doit implémenter le protocole LiveActivityAttributes d’Adobe :

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. Mappez les champs iOS à la payload de l’API de diffusion.

Incluez des content-state pour tous les types d’événements. Incluez les attributes, y compris les liveActivityData.channelID, pour les événements de début uniquement :

{
   "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=="
         }
      }
   }
}

Critique : input-push-channel doit correspondre àchannelID

• La valeur input-push-channel à la racine de aps doit correspondre exactement à la channelID dans liveActivityData.
• Dans l’exemple ci-dessus, les deux valeurs sont "FEt0NgvLEfEAAOqA6AXdIQ==".
• Cette correspondance associe l’instance de diffusion aux données d’activité en direct.
• Une incohérence entraîne des échecs de diffusion.

Points clés de validation :

• Incluez tous les champs ContentState dans content-state pour tous les types d’événements.
• Incluez tous les champs de LiveActivityAttributes personnalisés dans attributes pour les événements de début uniquement.
• Pour les événements de début, les liveActivityData.channelID doivent correspondre aux input-push-channel.
• Les noms des champs sont sensibles à la casse et doivent correspondre exactement.
• Les types de données doivent correspondre (chaîne, entier, booléen, objets imbriqués, etc.).
• Pour les événements de mise à jour/fin, utilisez le même input-push-channel que l’événement de début d’origine.

Erreurs courantes :

Vérifiez l’exécution de l’API et la diffusion de la payload à l’aide d’Assurance :

1. Ouvrez votre session Assurance sur un appareil de test qui fait partie de l’audience.

2. Exécutez l’appel API de diffusion.

3. Dans la Liste des événements, recherchez :

   • Événements d’exécution de campagne.
   • Événements de diffusion d’activité en direct.
   • Événements d’erreur indiquant les échecs de validation de la payload.

4. Inspectez les payloads d’événement pour confirmer :

   • La payload a été traitée correctement.
   • Le input-push-channel est présent.
   • Aucune erreur de validation ne s’est produite.
   • Des activités en direct ont été envoyées aux APNs pour les membres de l’audience.

1. Ouvrez votre campagne marketing déclenchée par API dans Journey Optimizer.

2. Accédez à la section Audience et vérifiez les éléments suivants :

   • Une audience est sélectionnée pour la campagne.
   • L’ID d’audience correspond à celui utilisé dans votre payload d’API.
   • L’audience contient les profils attendus.

3. Accédez à la section Actions.

4. Vérifiez que la Configuration de l’activité dynamique cible le package Android correct et utilise les informations d’identification FCM correspondantes. Android n’utilise ni type d’activité ni champ attributes-type.

Les diffusions Android utilisent une rubrique FCM . Incluez audience.id et placez l’objet fcm sous context.requestPayload, plutôt que sous un destinataire individuel.

Exemple de payload de début de diffusion :

{
   "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"
            }
         }
      }
   }
}

Remplacez l’exemple d’horodatage par l’heure Unix actuelle en secondes. Adaptez les clés content_state au fournisseur de style de votre application.

Problèmes courants de payload :

Champs critiques spécifiques à la diffusion :

• topic_name: identifie la rubrique FCM à laquelle les équipements cibles sont abonnés. Incluez la même valeur non vide dans chaque requête de début, de mise à jour et de fin.
• audience.id: identifie l’audience de la campagne dans Adobe Experience Platform. Vérifiez son appartenance et ses profils types pour obtenir des pushNotificationDetails valides.

Horodatage et champs facultatifs :

• Générez une nouvelle timestamp en secondes epoch pour chaque événement et assurez-vous qu’elle est strictement supérieure à la dernière valeur pour le même sujet. Les valeurs antérieures ou égales sont ignorées.
• when permet éventuellement de définir l’heure affichée par la notification en secondes epoch. Il ne contrôle pas l’ordre des messages.
• Par event_type: "end", dismiss_after spécifie éventuellement le nombre de secondes pendant lesquelles l’activité terminée reste visible avant la suppression. Il s’agit d’une durée, et non d’un horodatage d’époque.

Consultez la documentation de l’API de messagerie Adobe Journey Optimizer 🔗 pour obtenir des spécifications d’API complètes.

1. Vérifiez que l’appareil de test s’abonne à la rubrique exacte spécifiée dans topic_name, à l’aide de FirebaseMessaging.getInstance().subscribeToTopic(topic).
2. Vérifiez que l’abonnement a réussi et que l’application le signale par le biais de l’API de suivi d’abonnement aux rubriques prise en charge par son extension Adobe Live Activities installée.
3. Conservez les topic_name et notification_id inchangés pour les événements de début, de mise à jour et de fin.
4. Vérifiez que les clés content_state et les types valeur correspondent au fournisseur de style de l’application.
5. Vérifiez que les autorisations de notification sont accordées et qu’notification_channel_id correspond à un canal créé par l’application.

Erreurs courantes :

Voir l’exemple de payload de diffusion Android 🔗 pour des champs et des exemples supplémentaires.

Utilisez Assurance sur un appareil de test Android connecté, qui fait partie de l’audience et est abonné à la rubrique de diffusion.

1. Ouvrez votre session Assurance avant d’exécuter l’appel API de diffusion.
2. Envoyez des requêtes de début, de mise à jour et de fin avec les mêmes topic_name et notification_id et avec des horodatages croissants.
3. Dans la liste Événements, recherchez les erreurs de traitement de la payload dans les événements SDK et de diffusion disponibles.
4. Vérifiez que la payload contient les valeurs d’objet, de topic_name et de event_type fcm prévues.
5. Consultez les rapports de campagne et les événements message.feedback disponibles pour confirmer les résultats de la diffusion FCM. La valeur de la serviceProvider Android est fcm.
6. Si FCM accepte le message mais que l’appareil n’effectue pas le rendu de l’activité, inspectez l’abonnement à la rubrique, les autorisations de notification, la configuration du canal et les journaux d’application. L’acceptation du fournisseur ne confirme pas le rendu de l’appareil.