Uno dei problemi più noti in Marketing Cloud Engagement è il cosiddetto “cache issue” relativo ai content block referenziati.
Anche in Marketing Cloud Next sembra essere presente un meccanismo di caching simile per l’elaborazione dei contenuti durante l’invio delle email.
Ma perché, in primo luogo, è necessario mettere in cache i contenuti?
In Marketing Cloud Next, quando si esegue il rendering di un grande volume di messaggi, sarebbe estremamente inefficiente recuperare lo stesso contenuto dalla Content API ogni singola volta.
Supponiamo, ad esempio, di inviare la stessa email a 100.000 destinatari.
Anche se in quella email viene utilizzato lo stesso content block, recuperare separatamente lo stesso contenuto dalla Content API per ciascuno dei 100.000 destinatari comporterebbe un’enorme quantità di elaborazione superflua.
È quindi ragionevole ipotizzare che venga utilizzato un meccanismo di caching per rendere l’elaborazione più efficiente, permettendo di riutilizzare, all’interno di un certo ambito, un contenuto già recuperato in precedenza.
In Marketing Cloud Engagement, la cache di un content block referenziato può persistere fino a quando il JobID non cambia. Questo comportamento è descritto anche nella documentazione ufficiale di Salesforce Help.
Ho già scritto in passato un articolo su questo problema, presentando alcune soluzioni alternative e approcci possibili.
SFMC Tips #74: How to Update Content Referenced by ContentBlockById
E per quanto riguarda Marketing Cloud Next?
Questa volta ho voluto verificarlo con un test pratico.
Preparazione del contenuto
In questo test ho creato un “footer” come content block e l’ho referenziato all’interno di un’email.
Ho quindi inserito i due pattern seguenti all’interno della stessa email, per poterli confrontare.
- Inserimento in alto tramite AMPscript ContentBlockBy()
- Selezione e inserimento diretto del contenuto dal componente Content Block, in basso
Se a questo punto controlliamo la vista codice, ciascuno dei due appare come segue.
Riferimento dinamico
{{getContentBlock key='MCHG5X7KJXSNCD3EKV3MA2MJOLFY'}}
Inserimento diretto
<!--FRAGMENT:@cms/MCHG5X7KJXSNCD3EKV3MA2MJOLFY-->
Want to update your email preferences? GO HERE.
Questions? Check out the Help Center.
© Nobuyuki Watanabe
Nel caso in cui è stato inserito l’AMPscript con ContentBlockBy(), nella vista codice viene convertito in getContentBlock, il che significa che il content block viene referenziato in modo dinamico.
Al contrario, quando il contenuto viene selezionato direttamente dal componente Content Block, rimane un’informazione che indica un contenuto CMS, come FRAGMENT:@cms/…, ma il contenuto effettivo del Content Block viene espanso subito sotto come HTML.
Il punto chiave è che il comportamento cambia in base a come viene configurato il contenuto.
Invio effettivo dell’email
Per questo test ho preparato un flow che esegue regolarmente, a intervalli di un’ora, un segment flow e invia un’email.
Nella prima email ricevuta, come previsto, lo stesso footer viene visualizzato sia in alto che in basso.
Aggiornamento e ripubblicazione del Content Block
Successivamente ho aperto il content block, modificato il “colore di sfondo” e poi salvato e pubblicato le modifiche.
*Ho già verificato che il semplice salvataggio, senza pubblicazione, non si riflette nel contenuto effettivamente inviato.
A questo punto, aprendo il contenuto dell’email, si può notare che anche il colore di sfondo del blocco inserito direttamente dal componente Content Block è cambiato.
Nota: verificando tramite Preview and Test, si può confermare che la modifica si riflette anche nel blocco in cui è stato inserito l’AMPscript ContentBlockBy(). Inoltre, quando si invia da Preview and Test, l’email viene inviata utilizzando lo stato più recente del content block.
Osservando questa situazione, sembrerebbe che entrambi i blocchi facciano riferimento all’ultima versione del content block. Tuttavia, quando l’email viene effettivamente inviata, emerge una differenza. ↓ ↓ ↓ ↓ ↓
Verifica dell’email effettivamente inviata
Controlliamo ora l’email effettivamente inviata.
Il colore di sfondo del contenuto in “basso”, inserito direttamente dal componente Content Block, non è cambiato.
Durante il controllo precedente in Preview, entrambi i blocchi presentavano uno sfondo “nero”.
Sulla base di questo risultato, possiamo riassumere così le conclusioni di questo test.
ContentBlockBy() inserito tramite AMPscript
- Recupera l’ultimo content block pubblicato al momento dell’invio.
Inserimento diretto dal componente Content Block
- Utilizza il contenuto del content block relativo al momento in cui l’email è stata pubblicata.
In altre parole, si genera una differenza quando viene aggiornato e pubblicato soltanto il content block, senza intervenire sull’email.
*In Marketing Cloud Engagement, anche utilizzando AMPscript, non sempre veniva recuperato l’ultimo content block pubblicato.
Per questo motivo, chi ha esperienza con Marketing Cloud Engagement troverà probabilmente questa una differenza importante da comprendere.
A differenza di Journey Builder in Marketing Cloud Engagement, non è più necessario aprire l’activity email e cliccare nuovamente su “Publish”. In questo senso, il processo risulta molto più semplice.
Tuttavia, quando il contenuto viene inserito direttamente dal componente Content Block, resta comunque il comportamento per cui le modifiche apportate soltanto sul content block non vengono riflesse nel contenuto inviato. Questo aspetto andrà probabilmente tenuto in considerazione nella gestione operativa.
Ho anche valutato la pubblicazione massiva tramite API
Come si può quindi aggiornare un contenuto inserito direttamente dal componente Content Block?
Se si modifica in qualche modo l’email e si salva, l’email passa allo stato Revised.
A quel punto, pubblicandola nuovamente, il nuovo contenuto del content block viene finalmente riflesso nell’email inviata. Questo comportamento è per certi versi simile a quello di Marketing Cloud Engagement.
Tuttavia, quando ho provato a verificare se questo processo potesse essere gestito in massa tramite API, non si è rivelato così semplice.
① Published → Republish As Is
Per prima cosa ho provato a ripubblicare un contenuto già pubblicato, senza apportare alcuna modifica.
POST /services/data/v67.0/connect/cms/contents/publish "errorCode": "INVALID_API_INPUT", "message": "Your content wasn't published. Try again."
Non è stato possibile ripubblicare un contenuto attualmente pubblicato senza modificarlo.
Sarebbe stata la soluzione più semplice, ma purtroppo non ha funzionato.
② Published → Unpublish (→ Republish Later)
Ho quindi provato a “depubblicare” (unpublish) il contenuto.
POST /services/data/v67.0/connect/cms/contents/unpublish "errorCode": "INVALID_API_INPUT", "message": "We can't unpublish the record because one or more records depend on it. The dependent record is either not included in this unpublish request, or the record can't be unpublished at this time"
In questo caso si verifica un errore di dipendenza.
Poiché il content block è referenziato da altri contenuti, non è possibile semplicemente depubblicarlo.
③ Published → Revised (→ Republish Later)
Infine, ho valutato la possibilità di eseguire un qualche tipo di aggiornamento tramite API per portare l’email allo stato Revised.
PUT /services/data/v67.0/connect/cms/contents/variants/{managedContentVariantId}
Con questo metodo, però, il contenuto da aggiornare deve essere incluso nel corpo della richiesta.
In altre parole, non basta eseguire un semplice “aggiornamento fittizio” solo per portare l’email allo stato Revised: è necessario recuperare e mantenere il contenuto esistente e poi effettuare l’aggiornamento.
Questo comporta un certo rischio e un certo impegno.
Per questo motivo, non ho testato ulteriormente questo approccio in questa occasione.
A questo punto, per gestire la situazione in modo affidabile, sembra necessario procedere come segue:
Aprire ogni email singolarmente → Apportare una qualche modifica → Salvare → Pubblicare
Si tratta quindi di un lavoro piuttosto oneroso.
Per inciso, in Marketing Cloud Engagement esistevano casi in cui la creazione di una nuova versione di un journey modificava il JobID, il che poteva contribuire a rinfrescare la cache dei content block referenziati.
In Marketing Cloud Next, invece, anche creando e attivando una nuova versione del flow, questo non sembra influire sul comportamento del content block osservato in questo test. È importante tenere presente anche questo aspetto.
Risultati di questo test
Cosa ne pensate?
Per riassumere i risultati di questo test, abbiamo osservato che il comportamento successivo a un aggiornamento cambia in base a come viene inserito il content block.
La differenza seguente risulta particolarmente rilevante.
Utilizzando ContentBlockBy()
- Quando il content block viene pubblicato, il suo contenuto più recente si riflette negli invii successivi delle email.
Inserendolo direttamente dal componente Content Block
- La semplice pubblicazione del content block non si riflette nelle email già pubblicate.
- È necessario portare l’email stessa allo stato Revised e ripubblicarla.
Naturalmente, non è stato possibile verificare se questo comportamento corrisponda alla specifica finale prevista da Salesforce.
Potrebbe trattarsi di un problema noto e potrebbe cambiare in futuro.
Tuttavia, sulla base dei risultati attuali di questo test, se si desidera che l’ultima versione pubblicata di un content block aggiornato si rifletta anche nelle email già esistenti, l’utilizzo di ContentBlockBy() risulta essere il metodo più appropriato.
Per chi ha esperienza con Marketing Cloud Engagement, questo comportamento di ContentBlockBy() risulta piuttosto intuitivo da comprendere.
- Ripubblicando il content block, il nuovo contenuto viene utilizzato per gli invii successivi.
Fino a quel momento, viene riutilizzato il contenuto esistente, garantendo così anche una maggiore efficienza.
Per chi in passato ha avuto difficoltà con i content block referenziati in Marketing Cloud Engagement, questa è senza dubbio una differenza importante da comprendere.
Concludiamo ora ripassando le funzioni ContentBlockBy utilizzate in questo test.
Le funzioni ContentBlockBy
In Marketing Cloud Next sono disponibili le seguenti funzioni ContentBlockBy.
- ContentBlockById(): specifica un content block utilizzando la Content Key
- ContentBlockByKey(): specifica un content block utilizzando la Content Key
- ContentBlockByName(): specifica un content block utilizzando l’API Reference Name
La Content Key può essere recuperata dal punto seguente.
- Utilizzata con ContentBlockById()
- Utilizzata con ContentBlockByKey()
L’API Reference Name può essere recuperato dal punto seguente.
- Utilizzato con ContentBlockByName()
Quando queste funzioni AMPscript vengono inserite nell’editor visuale, nella vista codice vengono automaticamente convertite nel seguente formato Handlebars.
- ContentBlockById() ⇒ {{getContentBlock key=””}}
- ContentBlockByKey() ⇒ {{getContentBlock key=””}}
- ContentBlockByName() ⇒ {{getContentBlock apiname=””}}
Nota: attualmente, l’unica funzione per contenuti disponibile in Handlebars è getContentBlock key. getContentBlock apiname genera un errore interno, quindi è meglio non utilizzarlo ancora.
Un buon indicatore del fatto che la funzione sia pronta per l’uso sarà la scomparsa del seguente messaggio di avviso. ↓ ↓ ↓ ↓ ↓
Per questa volta è tutto.
Restate sintonizzati per altri consigli su Salesforce Marketing Cloud! 😎
Nobuyuki Watanabe
Tradotto e adattato da SFMC Tips #334 : Marketing Cloud Next: Reference Content Block Cache Issue di Nobuyuki Watanabe (@marketingcloudtips), pubblicato originariamente su Medium. Traduzione autorizzata dall’autore.