[v7]{class="badge informative" title="Applicabile anche a Campaign Classic v7"} [v8]{class="badge positive" title="Applicabile a Campaign v8"}

Modifiche del canale di notifica push push-upgrade

Puoi utilizzare Campaign per inviare notifiche push su dispositivi iOS e Android. Per eseguire questa operazione, Campaign si basa sui servizi di abbonamento alle app mobili.

Alcune modifiche importanti al servizio Android Firebase Cloud Messaging (FCM) sono state rilasciate nel 2024 e potrebbero influire sull’implementazione di Adobe Campaign. Per supportare questa modifica, potrebbe essere necessario aggiornare la configurazione dei servizi di abbonamento per i messaggi push di Android.

Inoltre, Adobe consiglia vivamente di passare alla connessione basata su token ai numeri APN anziché a una connessione basata su certificati, che è più sicura e scalabile.

Servizio Google Android Firebase Cloud Messaging (FCM) fcm-push-upgrade

Cosa è cambiato? fcm-changes

Nell'ambito del continuo impegno di Google per migliorare i propri servizi, le API FCM legacy cesseranno il 22 luglio 2024. Ulteriori informazioni sul protocollo HTTP Firebase Cloud Messaging sono disponibili nella documentazione di Google Firebase.

Adobe Campaign Classic v7 e Adobe Campaign v8 supportano già le API più recenti per l’invio di messaggi di notifica push. Tuttavia, alcune implementazioni precedenti si basano ancora sulle API legacy. Queste implementazioni devono essere aggiornate.

Sei interessato? fcm-impact

Se l’implementazione corrente supporta i servizi di abbonamento che si connettono a FCM utilizzando le API legacy, sei interessato. Per evitare distrazioni di servizio, è necessario passare alle API più recenti. In tal caso, i team di Adobi ti contatteranno.

Per verificare se sei interessato, puoi filtrare i Servizi e abbonamenti in base al filtro seguente:

  • Se uno dei servizi di notifica push attivi utilizza l'API HTTP (legacy), la configurazione sarà direttamente interessata da questa modifica. È necessario rivedere le configurazioni correnti e passare alle API più recenti come descritto di seguito.

  • Se la configurazione utilizza esclusivamente l'API HTTP v1 per le notifiche push di Android, significa che la conformità è già garantita e non sarà necessaria alcuna ulteriore azione da parte tua.

Come si esegue l’aggiornamento? fcm-transition-procedure

Prerequisiti fcm-transition-prerequisites

  • Per Campaign Classic v7, il supporto di HTTP v1 è stato aggiunto nella versione 20.3.1. Se l'ambiente è in esecuzione su una versione precedente, un prerequisito per la transizione a HTTP v1 è aggiornare l'ambiente alla build Campaign Classic più recente. Per Campaign v8, HTTP v1 è supportato da tutte le versioni e non è necessario alcun aggiornamento.

  • Il file JSON dell'account del servizio Android Firebase Admin SDK è necessario per spostare l'app mobile su HTTP v1. Scopri come ottenere questo file nella documentazione di Google Firebase.

  • Per le distribuzioni ibride, in hosting e Managed Services, oltre alla procedura di transizione riportata di seguito, contatta l’Adobe per aggiornare il server di esecuzione in tempo reale (RT). Il server Mid-Sourcing non è interessato.

  • In qualità di utente on-premise di Campaign Classic v7, devi aggiornare sia il server di esecuzione Marketing che il server di esecuzione in tempo reale. Il server Mid-Sourcing non è interessato.

Procedura di transizione fcm-transition-steps

Per spostare l’ambiente in HTTP v1, effettua le seguenti operazioni:

  1. Sfoglia l'elenco di Servizi e abbonamenti.

  2. Elenca tutte le applicazioni mobili che utilizzano la versione API HTTP (legacy).

  3. Per ciascuna di queste applicazioni mobili, impostare la versione API su HTTP v1.

  4. Fai clic sul collegamento Load project json file to extract project details… per caricare direttamente il file di chiave JSON.

    È inoltre possibile immettere manualmente i seguenti dettagli:

    • Project Id
    • Private Key
    • Client Email

  5. Fare clic su Test the connection per verificare che la configurazione sia corretta e che il server di marketing abbia accesso a FCM. Per le distribuzioni Mid-Sourcing, il pulsante Test connection non è in grado di verificare se il server ha accesso al servizio Android Firebase Cloud Messaging (FCM).

  6. Se necessario, puoi arricchire il contenuto di un messaggio push con alcuni Application variables. Questi sono completamente personalizzabili e fanno parte del payload del messaggio inviato al dispositivo mobile.

  7. Fai clic su Finish, quindi su Save.

    Di seguito sono riportati i nomi del payload FCM per personalizzare ulteriormente la notifica push. Queste opzioni sono dettagliate qui.

    table 0-row-3 1-row-3 2-row-3 1-align-center 2-align-center 3-align-center 5-align-center 6-align-center 7-align-center 9-align-center 10-align-center 11-align-center
    Tipo di messaggio Elemento del messaggio configurabile (nome del payload FCM) Opzioni configurabili (nome payload FCM)
    messaggio dati N/D validate_only
    messaggio di notifica titolo, corpo, android_channel_id, icona, suono, tag, colore, click_action, immagine, ticker, fisso, visibilità, notification_priority, notification_count validate_only
  8. Al termine della transizione HTTP v1, devi aggiornare i modelli di consegna per le notifiche push di Android per aumentare il numero di messaggi batch. A questo scopo, sfoglia le proprietà del modello di consegna Android e, nella scheda Consegna, imposta la quantità batch messaggi su 256. Applica questa modifica a tutti i modelli di consegna utilizzati per le consegne Android e a tutte le consegne Android esistenti.

NOTE
Una volta applicate queste modifiche a tutti i server, tutte le nuove consegne di notifiche push ai dispositivi Android utilizzano l’API HTTP v1. Le consegne push esistenti in un nuovo tentativo, in corso e in uso utilizzano ancora l’API HTTP (legacy).

Qual è l’impatto sulle app Android? fcm-apps

Non sono richieste modifiche specifiche al codice delle applicazioni Android Mobile e il comportamento di notifica non deve cambiare.

Tuttavia, con HTTP v1, puoi personalizzare ulteriormente la notifica push con HTTPV1 additional options.

Puoi eseguire le seguenti azioni:

  • Utilizza il campo Ticker per impostare il testo del ticker della notifica.
  • Utilizza il campo Image per impostare l'URL dell'immagine da visualizzare nella notifica.
  • Utilizzare il campo Notification Count per impostare il numero di nuove informazioni non lette da visualizzare direttamente sull'icona dell'applicazione.
  • Impostare l'opzione Sticky su false in modo che la notifica venga automaticamente chiusa quando l'utente fa clic su di essa. Se impostato su true, la notifica viene comunque visualizzata anche quando l’utente fa clic su di essa.
  • Imposta il livello Notification Priority della notifica su predefinito, minimo, basso o alto.
  • Imposta il livello Visibility della notifica su public, private o secret.

Per ulteriori informazioni su HTTP v1 additional options e su come compilare questi campi, consulta la documentazione FCM.

Servizio Apple iOS Push Notification (APNs) apns-push-upgrade

Cosa è cambiato? ios-changes

Come consigliato da Apple, è necessario proteggere le comunicazioni con il servizio APN (Apple Push Notification Service) utilizzando token di autenticazione senza stato.

L’autenticazione basata su token offre un modo senza stato di comunicare con i numeri APN. La comunicazione senza stato è più veloce della comunicazione basata su certificato perché non richiede che APN ricerchi il certificato o altre informazioni correlate al server provider. L’utilizzo dell’autenticazione basata su token presenta altri vantaggi:

  • È possibile utilizzare lo stesso token da più server provider.

  • Puoi utilizzare un token per distribuire le notifiche per tutte le app della tua azienda.

Per ulteriori informazioni sulle connessioni basate su token ai numeri APN, consulta la documentazione per gli sviluppatori di Apple.

Adobe Campaign Classic v7 e Adobe Campaign v8 supportano connessioni sia basate su token che basate su certificati. Se l’implementazione si basa su una connessione basata su certificato, Adobe consiglia vivamente di aggiornarla a una connessione basata su token.

Sei interessato? ios-impact

L’implementazione corrente è interessata se si basa su richieste basate su certificati per la connessione ad APN. Si consiglia di passare a una connessione basata su token.

Per verificare se sei interessato, puoi filtrare i Servizi e abbonamenti in base al filtro seguente:

  • Se uno dei servizi di notifica push attivi utilizza la modalità di autenticazione basata su certificato (.p12), le implementazioni correnti devono essere riviste e spostate in una modalità di autenticazione basata su token (.p8) come descritto di seguito.

  • Se la configurazione utilizza esclusivamente la modalità di autenticazione basata su token per le notifiche push di iOS, l'implementazione è già aggiornata e non sarà necessaria alcuna ulteriore azione da parte tua.

Come si esegue l’aggiornamento? ios-transition-procedure

Prerequisiti ios-transition-prerequisites

  • Per Campaign Classic v7, il supporto della modalità di autenticazione basata su token è stato aggiunto nella versione 20.2. Se l'ambiente è in esecuzione su una versione precedente, un prerequisito per questa modifica è aggiornare l'ambiente alla build Campaign Classic più recente. Per Campaign v8, la modalità Autenticazione basata su token è supportata da tutte le versioni e non è necessario alcun aggiornamento.

  • Per generare i token utilizzati dal server è necessaria una chiave di firma del token di autenticazione APNs. Richiedi questa chiave al tuo account sviluppatore Apple, come descritto nella documentazione per sviluppatori Apple.

  • Per le distribuzioni ibride, in hosting e Managed Services, oltre alla procedura di transizione riportata di seguito, contatta l’Adobe per aggiornare il server di esecuzione in tempo reale (RT). Il server Mid-Sourcing non è interessato.

  • In qualità di utente on-premise di Campaign Classic v7, devi aggiornare sia il server di esecuzione Marketing che il server di esecuzione in tempo reale. Il server Mid-Sourcing non è interessato.

Procedura di transizione ios-transition-steps

Per spostare le app mobili iOS nella modalità di autenticazione basata su token, effettua le seguenti operazioni:

  1. Sfoglia l'elenco di Servizi e abbonamenti.

  2. Elenca tutte le applicazioni mobili che utilizzano la modalità Autenticazione basata su certificato (.p12).

  3. Modifica ciascuna di queste app mobili e passa alla scheda Certificato/Chiave privata.

  4. Dal menu a discesa Modalità di autenticazione, selezionare Modalità di autenticazione basata su token (.p8).

  5. Compila le impostazioni di connessione APNs Key Id, Team Id e Bundle Id, quindi seleziona il certificato p8 facendo clic su Enter the private key….

  6. Fare clic su Test the connection per verificare che la configurazione sia corretta e che il server abbia accesso ai nomi APN. Si noti che per le distribuzioni Mid-Sourcing, il pulsante Test connection non è in grado di verificare se il server ha accesso ad APN.

  7. Fare clic su Next per avviare la configurazione dell'applicazione di produzione e seguire gli stessi passaggi descritti in precedenza.

  8. Fai clic su Finish, quindi su Save.

L’applicazione iOS viene ora spostata nella modalità di autenticazione basata su token.

recommendation-more-help
c14bd44c-7b5f-474a-888d-1c2baee5a247