Scenari comuni per la risoluzione dei problemi relativi alle attività Live troubleshoot-mobile-live

Puoi utilizzare Assurance per verificare la registrazione del token:

1. In Assurance, dall’elenco Eventi, filtrare o cercare gli eventi eventType = "liveActivity.pushToStart".
2. Seleziona Evento e controlla il payload.
3. Verificare che i valori token, appId e attributeType siano presenti.
4. Conferma che l’evento è stato inviato correttamente.

Puoi anche effettuare il check-in del profilo Adobe Experience Platform.

1. In Adobe Experience Platform, dal tuo Profilo, accedi alla scheda Eventi.
2. Cerca liveActivity.pushToStart eventi.
3. Controlla la marca temporale e il payload dell’evento.

Se non vengono trovati eventi, l’app non sta chiamando correttamente Messaging.registerLiveActivities. Correggi l’integrazione di SDK.

1. Dal tuo Profilo, accedi alla scheda Attributi.

2. Individuare liveActivityPushNotificationDetails.

3. Verifica la configurazione del token:

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

Convalida ogni campo:

Se un campo non è corretto, aggiorna l’app mobile, registrati di nuovo utilizzando Messaging.registerLiveActivities, attendi 5-10 minuti, quindi ricontrolla.

Se manca liveActivityPushNotificationDetails, il token non è ancora stato sincronizzato. Attendi 5-10 minuti dopo aver visto l’evento liveActivity.pushToStart in Assurance, quindi ricontrolla.

Android utilizza il token di registrazione FCM standard per le attività live. Nessun evento liveActivity.pushToStart o token push attività live separato.

1. In Assurance, apri l’elenco Eventi e individua l’evento di registrazione push-token standard.
2. Seleziona l’evento e ispeziona il relativo payload per verificare che sia presente il token di registrazione FCM.
3. Verificare che l’evento di registrazione sia stato inviato correttamente.
4. In Adobe Experience Platform, apri la scheda Attributi del tuo profilo e verifica che il token sia presente in pushNotificationDetails, come descritto nel passaggio 2.

Se manca l’evento di registrazione o il token del profilo, verificare che l’app inoltri il token di registrazione FCM al SDK utilizzando MobileCore.setPushIdentifier(token).

1. Dal tuo profilo, accedi alla scheda Attributi.

2. Individuare pushNotificationDetails. Android utilizza questo oggetto invece di liveActivityPushNotificationDetails e non richiede un campo attributeType.

3. Verifica che la configurazione del token segua questa struttura:

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

Convalida ogni campo:

Se un campo non è corretto, correggi la configurazione dell’app in base alle esigenze, inoltra nuovamente il token FCM utilizzando MobileCore.setPushIdentifier(token), attendi 5-10 minuti, quindi ricontrolla il profilo.

Se manca pushNotificationDetails, il token non è ancora stato sincronizzato. Dopo aver confermato la registrazione del token in Assurance, attendi 5-10 minuti, quindi ricontrolla il profilo.

1. In Journey Optimizer, apri Campaign e passa al menu Azioni.
2. Controlla la configurazione attività Live. La superficie deve essere configurata per l’app iOS con un identificatore bundle che corrisponde a appId nel liveActivityPushNotificationDetails del tuo profilo. Ad esempio, se il tuo profilo ha "appId": "com.example.myapp", la superficie deve avere come destinazione la stessa app.
3. Verifica che il tipo di attività nella configurazione della campagna corrisponda esattamente al attributeType nel liveActivityPushNotificationDetails del tuo profilo. Ad esempio, se il tuo profilo ha "attributeType": "FoodDeliveryLiveActivityAttributes", la campagna deve specificare lo stesso tipo di attività.

Durante l’esecuzione della campagna tramite API, assicurati che il payload segua la struttura corretta.

Payload unitario:

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

Problemi comuni relativi al payload:

Critico: usa sempre una marca temporale nuova

• Imposta timestamp sul tempo attuale (in secondi) dell’epoca Unix nel momento in cui effettui ciascuna chiamata API. Questo vale per tutti i tipi di evento: start, update e end.
• Un timestamp non aggiornato o riutilizzato fa sì che le richieste di aggiornamento e fine non riescano o vengano ignorate dal dispositivo. non riutilizzare i timestamp da richieste o valori memorizzati nella cache precedenti.

Campi facoltativi (tutti i tipi di eventi):

• requestId: identificatore univoco per il tracciamento (consigliato).
• alert: oggetto con title e body per la notifica. Utile per richiamare l’attenzione sugli aggiornamenti.

Informazioni su dismissal-date:

• Facoltativo. Tempo epoca Unix in secondi. Rilevante solo quando event è "end".
• Specifica quando l’attività Live viene rimossa automaticamente dal dispositivo. Se la ometti, l’attività Live rimane visibile fino a quando l’utente non la chiude.
• Deve essere una marca temporale futura, successiva a timestamp.

Assicurati che il payload API corrisponda all’implementazione ActivityAttributes dell’app iOS. Il protocollo LiveActivityAttributes di Adobe SDK estende iOS ActivityAttributes e richiede una proprietà liveActivityData.

Convalida mapping:

1. ActivityAttributes deve implementare il protocollo LiveActivityAttributes di Adobe. Esempio:

   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 }

   Nota che il campo liveActivityData è richiesto da Adobe SDK e deve essere incluso in tutte le implementazioni.

2. Il payload API deve rispecchiare la struttura di 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" } } }

Elenco di controllo convalida:

• Includi tutti i campi ContentState in content-state (obbligatorio per tutti i tipi di evento).

• Includi tutti i campi LiveActivityAttributes in attributes (solo eventi di inizio), inclusi:

  • liveActivityData (obbligatorio; in genere contiene liveActivityID o un identificatore simile)
  • Tutti i campi personalizzati dalla struttura

• Fai corrispondere esattamente i nomi dei campi (distinzione maiuscole/minuscole).

• Tipi di dati corrispondenti (String, Int, Bool, oggetti nidificati).

• Mantieni struttura oggetto nidificata.

Errori comuni:

Per ulteriori esempi, consulta Crea pagina di attività Live.

Verifica dell’esecuzione dell’API e della consegna del payload tramite Assurance:

1. Apri la sessione di Assurance.

2. Esegui la chiamata API per attivare l’attività Live.

3. Nell’Elenco eventi, verificare che:

   • Eventi di esecuzione della campagna.
   • Eventi di consegna di attività live.
   • Eventi di errore di convalida del payload.

4. Esamina i payload degli eventi per verificare:

   • Il payload è stato elaborato correttamente.
   • Non si sono verificati errori di convalida.
   • L’attività live è stata inviata ai numeri APN.

1. In Journey Optimizer, apri Campaign e passa al menu Azioni.
2. Controlla la configurazione attività Live. La superficie deve avere come destinazione l’app Android con un nome di pacchetto che corrisponda a appId nel profilo pushNotificationDetails.
3. Verifica che la superficie utilizzi le credenziali FCM per l’app. La piattaforma token del profilo deve essere "fcm".
4. Verificare che notification_channel_id nel payload corrisponda a un canale di notifica creato dall’app.

Posiziona i campi attività Android Live in context.requestPayload.fcm.

Payload di avvio unitario:

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

Sostituisci la marca temporale di esempio con il tempo dell’epoca Unix corrente in secondi. Le chiavi content_state sono esempi e devono corrispondere al provider di stili dell’app.

Per le trasmissioni, utilizza una campagna di marketing attivata da API con audience.id e inserisci l’oggetto fcm in context.requestPayload. Imposta topic_name sull’argomento FCM a cui si è iscritti dai dispositivi di destinazione. Mantieni l’argomento e notification_id invariati tra gli eventi di inizio, aggiornamento e fine. Consulta gli esempi di payload per la trasmissione di Android.

Problemi comuni relativi al payload:

Controlli timestamp e ciclo di vita:

• Utilizza un nuovo timestamp in pochi secondi per ogni evento di inizio, aggiornamento e fine. Verificare che sia maggiore del valore precedente per lo stesso notification_id (o topic_name per le trasmissioni), anche quando le richieste vengono effettuate nello stesso secondo.
• I timestamp precedenti o uguali vengono ignorati. Non riutilizzare i timestamp memorizzati nella cache.
• Il campo facoltativo when controlla l’ora di visualizzazione della notifica, non l’ordinamento dei messaggi. Mantenerlo ragionevolmente attuale ed esprimerlo in pochi secondi.
• Per aggiornare o terminare un’attività, modificare event_type mantenendo notification_id invariato. Android utilizza lo stesso token di registrazione FCM per tutti e tre gli eventi del ciclo di vita; non è necessario alcun token di aggiornamento separato.

Chiusura evento finale:

Per event_type: "end", imposta facoltativamente dismiss_after sul numero di secondi in cui l’attività Live completata deve rimanere visibile prima della rimozione. Questa è una durata, non una marca temporale dell’epoca.

Il provider di stili dell’app determina il rendering dei valori content_state nella notifica dell’attività live.

1. Conferma che Messaggistica ed estensione Live Activities siano integrati nell’app.
2. Verificare che ogni campo in content_state corrisponda a una chiave gestita dal provider di stili, incluso il tipo di valore previsto.
3. Verificare che title, body e critical_text contengano il testo visualizzato desiderato. critical_text è utilizzato per il chip della barra di stato.
4. Verificare che le autorizzazioni di notifica siano state concesse e che il canale identificato da notification_channel_id esista.

Errori comuni:

Per ulteriori esempi, consulta Creare attività live.

Utilizza Assurance su un dispositivo di prova Android collegato.

1. Apri una sessione di Assurance e conferma che la registrazione del token FCM sia visibile.
2. Esegui la chiamata API per avviare l’attività Live, quindi invia eventi di aggiornamento e fine con gli stessi notification_id e marche temporali crescenti.
3. Esamina gli eventi SDK e i payload disponibili per individuare eventuali errori di elaborazione o di convalida. Verificare che il payload di Android utilizzi fcm e i valori previsti per il ciclo di vita.
4. Nella scheda Eventi del profilo, controlla message.feedback eventi corrispondenti. Verificare che serviceProvider sia fcm e rivedere feedbackStatus, errorCode e errorMessage per gli errori di consegna.
5. Se la consegna ha esito positivo ma l’attività Live non esegue il rendering, esamina i registri dell’app, le mappature dei provider di stili, le autorizzazioni di notifica e la configurazione dei canali sul dispositivo.

Ignora questo passaggio se il report campagna non mostra errori di invio. In caso contrario, impostare una corrispondenza tra l’errore della tabella Motivi errore e gli errori APN comuni seguenti:

1. Passa a Cliente > Profili in Journey Optimizer.

2. Cerca e apri il profilo.

3. Selezionare la scheda Eventi.

4. Filtra o cerca eventi con eventType = "message.feedback".

5. Cerca eventi di feedback corrispondenti al tipo liveActivityID e event della tua attività Live.

6. Esamina i seguenti campi chiave:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Campo	Valori possibili	Che cosa significa
   feedbackStatus	sent, error, denylist	Risultato della consegna dal provider di servizi
   serviceProvider	apns/apnsSandbox	Deve essere un APN per le attività iOS Live
   errorCode	Codice numerico o null	Codice di errore specifico per APNs, se non riuscito
   errorMessage	Descrizione errore o null	Messaggio di errore leggibile

7. Se feedbackStatus: "error":

   • Controllare che errorCode e errorMessage non contengano errori APN specifici.
   • Gli errori APN comuni includono token scaduto, certificato non valido, ID bundle errato.

8. Se non viene trovato alcun evento di feedback:

   • È possibile che la notifica push non sia stata tentata.
   • Verifica se il profilo è stato escluso nel report campagna.

Se feedbackStatus è sent: Journey Optimizer ha passato la notifica ad APNs. Questo non conferma il rendering del dispositivo. Continuare con i controlli lato dispositivo al punto 4.

1. Apri la sessione di Assurance e mantienila attiva durante la chiamata API.

2. Esegui la chiamata API (inizio, aggiornamento o fine).

3. Nell’Elenco eventi, cerca gli eventi di consegna delle attività live.

4. Cerca gli eventi relativi alla consegna push APN.

5. Controllare la presenza dei seguenti indicatori:

   • Invia la richiesta al servizio APN: conferma l’invio del messaggio push ai server di Apple da parte di Adobe
   • Risposta APNs: indica se APNs ha accettato o rifiutato il messaggio push
   • Stato consegna: indicazione di esito positivo o negativo

6. Se vengono rilevati problemi, consulta i seguenti problemi comuni relativi alla consegna di APN:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
   Problema	Sintomo in Assurance	Risoluzione
   Certificato APNs scaduto	Errore di autenticazione	Rinnovare e caricare un nuovo certificato APN
   Ambiente errato (sviluppo e produzione)	Errore di mancata corrispondenza del token	Assicurati che il certificato corrisponda al tipo di build dell’app
   Mancata corrispondenza ID bundle	Identificatore bundle non valido	Verifica che l’ID del bundle di certificati corrisponda all’app
   Token scaduto	Errore InvalidToken da APNs	Registra nuovamente i token di attività live
   Limitazione di velocità	Troppe richieste	Ridurre la frequenza delle chiamate API

Se Adobe mostra una consegna corretta ma il dispositivo non mostra l’attività Live:

• Controlla i registri del dispositivo iOS per verificare la presenza di errori di attività live.
• Verifica che l’app sia in primo piano o in background (non terminata).
• Verificare che il dispositivo disponga della connettività di rete.
• Esegui il test su più dispositivi per escludere problemi specifici del dispositivo.
• Verifica che la versione di iOS sia 16.1 o successiva.

Se hai completato tutti i passaggi e il problema rimane non risolto, contatta l’Assistenza clienti Adobe con:

Informazioni richieste:

• ID e nome della campagna
• Spazio dei nomi e ID del profilo
• liveActivityID dal payload API
• Marca temporale delle chiamate API
• Schermate del rapporto della campagna che mostrano statistiche di invio, motivi di errore e motivi di esclusione
• Eventi di profilo rilevanti (liveActivity.updateToken per problemi di aggiornamento/fine unitari e message.feedback)
• Dettagli della sessione Assurance e schermate dell’evento rilevanti
• Payload e risposta della richiesta API, con credenziali e token del dispositivo eliminati
• Dettagli del certificato APNs (scadenza, ambiente, ID bundle)

Ignora questo passaggio se il report campagna non mostra errori di invio. In caso contrario, verificare che l’errore della tabella Motivi errore corrisponda ai seguenti errori comuni di FCM:

1. Passa a Cliente > Profili in Journey Optimizer.

2. Cerca e apri il profilo.

3. Selezionare la scheda Eventi.

4. Filtra o cerca eventi con eventType = "message.feedback".

5. Individua gli eventi di feedback per la campagna e le marche temporali delle chiamate API che stai esaminando.

6. Esamina i seguenti campi chiave:

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   Campo	Valori possibili	Che cosa significa
   feedbackStatus	sent, error, denylist	Risultato della consegna dal provider di servizi
   serviceProvider	fcm	Consegna push Android gestita da FCM
   errorCode	Codice errore provider o null	Codice di errore specifico per FCM se la consegna non è riuscita
   errorMessage	Descrizione errore o null	Messaggio di errore leggibile

7. Se feedbackStatus: "error":

   • Controllare errorCode e errorMessage e applicare la risoluzione FCM corrispondente dal passaggio 1.

8. Se non viene trovato alcun evento di feedback:

   • La notifica push potrebbe non essere stata tentata o il feedback potrebbe non essere ancora disponibile.
   • Verifica se il profilo è stato escluso nel report campagna.

Se feedbackStatus è sent: FCM ha accettato la notifica. Ciò non conferma che il dispositivo abbia eseguito il rendering dell’attività Live. Continuare con i controlli lato dispositivo al punto 4.

Utilizza Assurance su un dispositivo di prova Android collegato.

1. Apri una sessione di Assurance e mantienila attiva durante la chiamata API.
2. Eseguire la chiamata API con event_type impostato su start, update o end.
3. Nell’elenco Eventi, controlla gli eventi di consegna push disponibili per la richiesta a FCM e la relativa risposta.
4. Verificare se FCM ha accettato o rifiutato la richiesta e controllare i dettagli degli errori segnalati.
5. Per le richieste rifiutate, utilizza gli errori FCM nel passaggio 1 per verificare il token, le credenziali del progetto Firebase e il payload. Se gli eventi del provider non sono disponibili nella sessione, utilizzare message.feedback eventi e report campagna.

Se Adobe mostra una consegna corretta ma il dispositivo non visualizza o aggiorna l’attività Live:

• Ispeziona i registri dell’app Android per individuare eventuali errori di gestione push e rendering delle attività live.
• Verificare che le notifiche siano consentite e che le notifiche promosse siano consentite utilizzando canPostPromotedNotifications().
• Verificare che siano state concesse le autorizzazioni POST_NOTIFICATIONS e POST_PROMOTED_NOTIFICATIONS e che esista il canale identificato da notification_channel_id.
• Verificare che timestamp sia più recente dell’ultimo evento elaborato e che notification_id non sia stato modificato. Per le trasmissioni, verificare anche la sottoscrizione del dispositivo a topic_name.
• Conferma che l’app non venga forzatamente arrestata.
• Verificare che il dispositivo disponga della connettività di rete.
• Esegui il test su più dispositivi per escludere problemi specifici del dispositivo.
• Verificare che il dispositivo esegua Android 16.1 (livello API 36.1) o versione successiva e che l’app utilizzi targetSdk 36.
• Verificare che le chiavi e i tipi di valore di content_state corrispondano al provider di stili dell’app.

Se hai completato tutti i passaggi e il problema rimane non risolto, contatta l’Assistenza clienti Adobe con:

Informazioni richieste:

• ID e nome della campagna
• Spazio dei nomi e ID del profilo
• notification_id e event_type dal payload API; per le trasmissioni, includono anche topic_name e l’ID pubblico
• Marca temporale delle chiamate API
• Schermate del rapporto della campagna che mostrano statistiche di invio, motivi di errore e motivi di esclusione
• Eventi del profilo message.feedback rilevanti, inclusi codici di errore FCM e messaggi
• Dettagli della sessione Assurance e schermate dell’evento rilevanti
• Payload e risposta della richiesta API, con credenziali e token del dispositivo eliminati
• Nome pacchetto Android, ID progetto e mittente Firebase e dettagli di configurazione delle credenziali FCM; non includere chiavi private
• Versione del sistema operativo Android, modello del dispositivo, stato delle autorizzazioni di notifica e registri delle app rilevanti

1. Apri la campagna di marketing con attivazione API in Journey Optimizer.

2. Passa alla sezione Pubblico e verifica:

   • Per la campagna viene selezionato un pubblico.
   • L’ID del pubblico corrisponde a quello utilizzato nel payload API.
   • Il pubblico contiene i profili previsti.

3. Passa alla sezione Azioni.

4. Controlla la configurazione attività in tempo reale:

   • La configurazione deve essere impostata per l’app iOS con l’identificatore del bundle corretto.
   • Il tipo di attività deve corrispondere a attributes-type nel payload API. Ad esempio, se il payload contiene "attributes-type": "AirplaneTrackingAttributes", la campagna deve specificare lo stesso tipo di attività.

La struttura del payload della trasmissione è diversa dalle campagne unitarie. Verifica che il payload segua il formato di trasmissione corretto.

Campi obbligatori per la trasmissione:

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

Problemi comuni relativi al payload:

Campi critici specifici per la trasmissione:

• input-push-channel:

  • Obbligatorio per tutte le attività di trasmissione in diretta.
  • Funge da identificatore univoco per questa istanza di broadcast specifica.
  • Tutti i profili del pubblico ricevono attività live collegate a questo canale.
  • Deve corrispondere a channelID in liveActivityData.channelID (vedere il passaggio 3).
  • Deve essere creato dal team per appID nel portale per sviluppatori di Apple.
  • Solo i canali creati per l’elemento appID specifico possono essere utilizzati per trasmettere le attività Live su tale app.

• audience.id:

  • Deve fare riferimento a un segmento di pubblico valido creato in Adobe Experience Platform.
  • Tutti i profili in questo pubblico sono destinati all’attività Live.
  • Il pubblico deve essere attivato e contenere profili con liveActivityPushNotificationDetails validi.

Usa sempre la marca temporale più recente:

• Il campo timestamp deve essere sempre l’ora Unix corrente (in secondi) per ogni chiamata API.
• Questo requisito si applica a tutti i tipi di evento: start, update e end.
• Critico per aggiornamenti/fine: l’utilizzo di marche temporali non aggiornate causa errori nelle richieste di aggiornamento e fine.
• Genera una nuova marca temporale per ogni chiamata API di trasmissione.

Campi facoltativi:

• dismissal-date: tempo epoca Unix per il licenziamento automatico (pertinente solo per eventi end)
• alert: oggetto con title e body per la notifica

Per informazioni sulle specifiche API complete, consulta la documentazione API di messaggistica Adobe Journey Optimizer.

Assicurati che i campi del payload corrispondano all’implementazione ActivityAttributes dell’app iOS e che input-push-channel corrisponda a channelID in liveActivityData.

1. Rivedi la definizione degli Attributi di attività di iOS.

Lo struct ActivityAttributes personalizzato deve implementare il protocollo LiveActivityAttributes di 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. Mappa i campi di iOS sul payload API della trasmissione.

Includi content-state per tutti i tipi di evento. Includi attributes, incluso liveActivityData.channelID, solo per gli eventi di inizio:

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

Critico: input-push-channel deve corrispondere achannelID

• Il valore input-push-channel nella radice di aps deve corrispondere esattamente a channelID in liveActivityData.
• Nell’esempio precedente, entrambi i valori sono "FEt0NgvLEfEAAOqA6AXdIQ==".
• Questa corrispondenza collega l’istanza di trasmissione ai dati dell’attività Live.
• Una mancata corrispondenza causa errori di consegna.

Punti di convalida chiave:

• Includi tutti i campi ContentState in content-state per tutti i tipi di evento.
• Includi tutti i campi LiveActivityAttributes personalizzati in attributes solo per gli eventi di inizio.
• Per gli eventi di inizio, liveActivityData.channelID deve corrispondere a input-push-channel.
• I nomi dei campi fanno distinzione tra maiuscole e minuscole e devono corrispondere esattamente.
• I tipi di dati devono corrispondere (String, Int, Bool, oggetti nidificati, ecc.).
• Per gli eventi di aggiornamento/fine, utilizzare lo stesso input-push-channel dell’evento iniziale originale.

Errori comuni:

Verifica dell’esecuzione dell’API e della consegna del payload tramite Assurance:

1. Apri la sessione di Assurance su un dispositivo di prova che fa parte del pubblico.

2. Esegui la chiamata API di trasmissione.

3. Nell’Elenco eventi cercare:

   • Eventi di esecuzione della campagna.
   • Eventi di consegna di attività live.
   • Eventi di errore che indicano errori di convalida del payload.

4. Ispeziona i payload degli eventi per confermare:

   • Il payload è stato elaborato correttamente.
   • input-push-channel è presente.
   • Non si sono verificati errori di convalida.
   • Le attività live sono state inviate ai numeri APN per i membri del pubblico.

1. Apri la campagna di marketing attivata da API in Journey Optimizer.

2. Passa alla sezione Pubblico e verifica:

   • Per la campagna viene selezionato un pubblico.
   • L’ID del pubblico corrisponde a quello utilizzato nel payload API.
   • Il pubblico contiene i profili previsti.

3. Passa alla sezione Azioni.

4. Verifica che la configurazione attività live esegua il targeting del pacchetto Android corretto e utilizzi le credenziali FCM corrispondenti. Android non utilizza un tipo di attività o un campo attributes-type.

Le trasmissioni Android utilizzano un argomento FCM. Includere audience.id e inserire l’oggetto fcm in context.requestPayload, anziché in un singolo destinatario.

Esempio di payload di avvio della trasmissione:

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

Sostituisci la marca temporale di esempio con il tempo dell’epoca Unix corrente in secondi. Adattare le chiavi content_state al provider di stili dell’app.

Problemi comuni relativi al payload:

Campi critici specifici per la trasmissione:

• topic_name: identifica l’argomento FCM a cui si è iscritti i dispositivi di destinazione. Includi lo stesso valore non vuoto in ogni richiesta di inizio, aggiornamento e fine.
• audience.id: identifica il pubblico della campagna in Adobe Experience Platform. Verificare l’appartenenza e i profili di esempio per pushNotificationDetails validi.

Timestamp e campi facoltativi:

• Genera un nuovo timestamp in pochi secondi d’epoca per ogni evento e assicurati che sia rigorosamente maggiore dell’ultimo valore per lo stesso argomento. I valori più vecchi o uguali vengono ignorati.
• when imposta facoltativamente il tempo di visualizzazione della notifica in secondi epoca. Non controlla l’ordinamento dei messaggi.
• Per event_type: "end", dismiss_after specifica facoltativamente per quanti secondi l’attività completata rimane visibile prima della rimozione. È una durata, non una marca temporale dell’epoca.

Per informazioni sulle specifiche API complete, consulta la documentazione API di messaggistica Adobe Journey Optimizer.

1. Verificare che il dispositivo di test sia abbonato all’argomento specificato in topic_name, utilizzando FirebaseMessaging.getInstance().subscribeToTopic(topic).
2. Verifica che la sottoscrizione abbia esito positivo e che l’app la segnali tramite l’API di tracciamento delle sottoscrizioni per argomento supportata dall’estensione Adobe Live Activities installata.
3. Mantieni topic_name e notification_id invariati tra gli eventi di inizio, aggiornamento e fine.
4. Verificare che le chiavi e i tipi di valore di content_state corrispondano al provider di stili dell’app.
5. Verificare che le autorizzazioni di notifica siano concesse e che notification_channel_id corrisponda a un canale creato dall’app.

Errori comuni:

Per ulteriori campi ed esempi, consulta l’esempio di payload di trasmissione di Android.

Utilizza Assurance su un dispositivo di test di Android connesso che fa parte del pubblico e si abbona all’argomento della trasmissione.

1. Apri la sessione di Assurance prima di eseguire la chiamata API per la trasmissione.
2. Invia richieste di inizio, aggiornamento e fine con gli stessi topic_name e notification_id e con marche temporali crescenti.
3. Nell’elenco Eventi, controlla gli eventi di SDK e consegna disponibili per individuare eventuali errori di elaborazione del payload.
4. Verificare che il payload contenga l’oggetto fcm, topic_name e i valori event_type previsti.
5. Esamina i rapporti delle campagne e i message.feedback eventi disponibili per confermare i risultati della consegna FCM. Il valore di Android serviceProvider è fcm.
6. Se FCM accetta il messaggio ma il dispositivo non esegue il rendering dell’attività, controlla l’abbonamento all’argomento, le autorizzazioni di notifica, la configurazione del canale e i registri dell’app. L’accettazione del provider non conferma il rendering del dispositivo.