A partire da questo articolo, inizieremo a testare Salesforce Personalization.
Salesforce Personalization è una soluzione che utilizza informazioni sui clienti, dati comportamentali e informazioni sui prodotti provenienti da Data 360 per selezionare contenuti personalizzati e raccomandazioni di prodotto per ciascun cliente.
Oltre alla personalizzazione delle email in combinazione con Marketing Cloud Next, può essere utilizzata anche su più canali non email, tra cui siti web e app mobili.
Per questo scopo, ho creato un sito e-commerce outdoor fittizio chiamato “TrailNest” usando Marketing Cloud Engagement CloudPages.
Questo sito contiene i seguenti sei tipi di pagine.
- Home
- Category
- Product Detail
- Cart
- Checkout
- Order Confirmation
Gli utenti possono navigare tra i prodotti, aggiungerli al carrello e poi effettuare un ordine al Checkout inserendo le seguenti informazioni.
- First Name
- Last Name
- Customer ID
- Email Address
- Country
Il sito è configurato in modo che l’utente inserisca Customer ID e Email Address, esegua Confirm Customer, e quindi confermi l’ordine.
Andando avanti, utilizzeremo questo Customer ID per associare utenti anonimi a clienti conosciuti e testare la identity resolution di Salesforce Personalization e la Personalization in tempo reale.
Inoltre, al momento dell’acquisto, conserviamo non solo l’ordine completo ma anche le singole righe di prodotto, in modo da poter in seguito utilizzare lo storico degli acquisti nelle Recommendations.
Creare TrailNest
Se disponi di CloudPages e desideri creare lo stesso sito, esegui prima il seguente script in Automation Studio per creare la Data Extension che servirà come master dei prodotti.
<script runat="server">
Platform.Load("Core", "1");
var dataExtensionConfig = {
"CustomerKey": "TrailNest_Product_Master",
"Name": "TrailNest_Product_Master",
"Fields": [
{
"Name": "ProductId",
"FieldType": "Text",
"MaxLength": 50,
"IsPrimaryKey": true,
"IsRequired": true
},
{
"Name": "ProductName",
"FieldType": "Text",
"MaxLength": 150,
"IsRequired": true
},
{
"Name": "CategoryId",
"FieldType": "Text",
"MaxLength": 50,
"IsRequired": true
},
{
"Name": "CategoryName",
"FieldType": "Text",
"MaxLength": 100,
"IsRequired": true
},
{
"Name": "Activity",
"FieldType": "Text",
"MaxLength": 100
},
{
"Name": "ExperienceLevel",
"FieldType": "Text",
"MaxLength": 50
},
{
"Name": "Description",
"FieldType": "Text",
"MaxLength": 1000
},
{
"Name": "Price",
"FieldType": "Decimal",
"MaxLength": 18,
"Scale": 0,
"IsRequired": true
},
{
"Name": "ImageUrl",
"FieldType": "Text",
"MaxLength": 500
},
{
"Name": "ProductSlug",
"FieldType": "Text",
"MaxLength": 150
},
{
"Name": "ProductUrl",
"FieldType": "Text",
"MaxLength": 500
},
{
"Name": "InventoryCount",
"FieldType": "Number"
},
{
"Name": "IsFeatured",
"FieldType": "Boolean"
},
{
"Name": "IsActive",
"FieldType": "Boolean"
}
]
};
var createdDataExtension = DataExtension.Add(dataExtensionConfig);
Write("TrailNest_Product_Master created.");
</script>
Dopo aver creato la Data Extension, importa il file CSV seguente con i qualificatori di testo attivati.
Verranno registrati trenta record di prodotto nella Data Extension. Su pagine come Product Detail, le informazioni sul prodotto vengono visualizzate dinamicamente utilizzando parametri Query String.
Successivamente, incolla il seguente HTML sopra il contenuto esistente nella vista codice delle CloudPages e pubblicalo. Questo completa il sito TrailNest.
In questo articolo, utilizzeremo il sito TrailNest per iniziare a lavorare con Sitemap Builder.
Creare un Website Connector
Ora procederemo partendo dal presupposto che Data 360 sia già stato implementato.
Il Sitemap Builder utilizzato in questo caso può generare automaticamente uno Schema Data 360 basato su impostazioni come Page Type, Event e Resolver.
Pertanto, piuttosto che creare manualmente il JSON dello Schema da zero, creeremo prima un Website Connector, e poi creeremo il Sitemap e lo Schema in Sitemap Builder.
Crea prima solo il Website Connector
→ Carica l’SDK in TrailNest
→ Crea Page Type / Event in Sitemap Builder
→ Genera lo Schema
→ Carica quello Schema nel Website Connector
Nella tab Schema di Sitemap Builder, puoi verificare lo Schema Data 360 generato automaticamente in base al Sitemap configurato.
1. In [Setup], cerca Websites, seleziona Websites & Mobile Apps, e crea un nuovo Website Connector.
2. In questo caso, ho creato la Website Connection con le seguenti impostazioni. Modifica i valori in base al tuo ambiente.
- Connection Name: TrailNest Website
- Alias: nes
- Connection Type: A Custom Website
- Website Base URL: l’URL pubblicato delle CloudPages mostrato di seguito
https://mcxkknz3m0zj3jqsxn4hm3dp3q-4.pub.sfmc-content.com/f0sn3uhu0p0
※ Alias è stato introdotto nella release di nuove funzionalità di agosto 2026.
- Quando si distribuisce lo stesso Data Kit Package su più Website o Mobile Connections, i nomi possono potenzialmente duplicarsi tra i vari connettori. Impostando un Alias univoco, è possibile evitare queste collisioni di nomi.
- Il vantaggio principale è che, ad esempio, con “nes” utilizzato in questo caso, nes verrà aggiunto all’inizio dei nomi dei data stream e dei DLO, rendendo molto più semplici le ricerche in Data Explorer e in altre aree. Può essere utile scegliere il nome dell’Alias tenendo presente questa logica.
Ottenere l’URL dell’SDK Salesforce Interactions
3. Quando crei il Website Connector, nella parte inferiore dello schermo viene mostrata una Integration Guide. Sotto Add the Script to your source code, viene mostrato l’URL CDN dell’SDK Salesforce Interactions dedicato a quel Website Connector.
- L’SDK Salesforce Interactions è un Web SDK utilizzato per catturare il comportamento degli utenti e le informazioni di Profile su un sito web.
- Dopo aver inizializzato l’SDK e ottenuto il Consent appropriato, è possibile inviare a Data 360 le Interactions e le informazioni di Profile generate sulla pagina Web.
4. Quando lo implementi formalmente su un sito web reale, specifica questo URL nell’attributo src di un tag <script> e aggiungilo all’interno di <head>.
<script src="https://cdn.c360a.salesforce.com/beacon/c360a/XXXXXXXX/scripts/c360a.min.js"></script>
Tuttavia, in questa fase, non implementeremo ancora il processo di inizializzazione dell’SDK in CloudPages.
- Il Sitemap Builder che utilizzeremo da qui in avanti fornisce una funzionalità Inject che carica temporaneamente il Web SDK ottenuto nella pagina Web attualmente aperta.
- Per prima cosa, utilizzeremo questa funzionalità Inject per creare e testare il Sitemap, verificare il Sitemap e lo Schema generati, e poi determinare il codice finale da inserire nel sito web reale.
- Questo ci permette anche di evitare duplicazioni tra il metodo init() configurato lato CloudPages e il processo di inizializzazione generato da Sitemap Builder.
Cos’è un Sitemap?
In Salesforce Personalization, un Sitemap è una configurazione che descrive a Salesforce la struttura del sito web, le informazioni sulla pagina e il comportamento dell’utente.
Quando si sente il termine Sitemap su un sito web generico, si potrebbe pensare a qualcosa destinato ai motori di ricerca, ma un Sitemap di Salesforce Personalization è diverso.
In un Sitemap di Salesforce Personalization, ad esempio, si definiscono elementi come i seguenti.
- Se questa pagina è Home
- Se questa pagina è Product Detail
- Quali sono l’ID prodotto e il prezzo attualmente visualizzati
- Quali aree sono utilizzate come aree di visualizzazione per la Personalization
- Se l’utente ha cliccato su Add to Cart
- Se l’utente ha raggiunto la pagina di completamento acquisto
- Se è stato inserito il Customer ID o l’Email Address
In altre parole, un Sitemap è un insieme di regole che permette a Salesforce Personalization di capire “quale pagina l’utente sta attualmente visualizzando, quale prodotto sta guardando, e quali azioni ha eseguito.”
Ad esempio, la pagina di dettaglio prodotto di TrailNest contiene le seguenti informazioni nell’HTML.
<main
id="trailnest-app"
data-page-type="product_detail"
data-product-id="TN-BP-003"
data-product-name="Trail Pro 35L"
data-product-price="139000">
Nel Sitemap, è possibile utilizzare elementi DOM, URL, valori JavaScript e così via per trasmettere a Salesforce informazioni come le seguenti.
Page Type = Product Detail Product ID = TN-BP-003 Product Name = Trail Pro 35L Price = 139000
Il DOM (Document Object Model) è un meccanismo che permette al browser di gestire l’HTML di una pagina Web come un modello strutturato.
Ad esempio, elementi HTML come nomi di prodotto, ID prodotto, bottoni e immagini possono essere recuperati e manipolati da JavaScript o da un Sitemap.
- HTML = Il progetto (blueprint) della pagina
- DOM = La struttura dei componenti manipolabili creata dal browser dopo aver letto quel progetto
Inoltre, un Sitemap fa più che semplicemente classificare le pagine.
Ad esempio, su una pagina di dettaglio prodotto, può rilevare quando viene cliccato il seguente bottone:
- Add to Cart
Può anche definire Content Zone come:
- home_hero
- home_recs
- product_detail_recs_row_1
Queste potranno essere utilizzate in seguito come posizioni per la visualizzazione di Hero Banner o Recommendations.
Pertanto, nell’implementazione Web, il Sitemap svolge un ruolo simile a un progetto che collega il sito web a Salesforce.
Cos’è Sitemap Builder?
Il Sitemap Builder utilizzato in questo caso è una nuova funzionalità introdotta in Spring ’26. È un’estensione Chrome che supporta la creazione di Sitemap e Schema.
Invece di scrivere solo il JavaScript del Sitemap direttamente da zero come prima, è possibile configurare Page Types, Resolvers, Profile Attributes, Events e altro ancora dall’interfaccia utente.
Salesforce descrive inoltre Sitemap Builder come uno strumento low-code / no-code pensato per ridurre la dipendenza dalla conoscenza di JavaScript e rendere più semplice l’implementazione di Personalization anche per i non sviluppatori.
Installare Sitemap Builder
- Installa Sitemap Builder dal Chrome Web Store.
2. Dopo l’installazione, apri la pagina Home di TrailNest in Chrome e, mentre la pagina è aperta, avvia Sitemap Builder dall’elenco delle estensioni di Chrome.
- Sitemap Builder viene utilizzato in associazione con la pagina Web di destinazione al momento dell’avvio, quindi avvialo mentre il sito web per cui vuoi configurare il Sitemap è aperto.
- Una volta aperto Sitemap Builder, consiglio di cliccare immediatamente sul bottone di espansione nell’angolo in alto a destra. Questo evita che Sitemap Builder si chiuda anche se ti spostassi su un’altra scheda del browser, rendendo il lavoro più efficiente.
Iniettare il Web SDK
Prima di creare un Sitemap utilizzando Sitemap Builder, carica l’SDK Salesforce Interactions ottenuto dal Website Connector in TrailNest.
3. Apri la tab Inject nella parte superiore di Sitemap Builder.
Per CloudPages di test come quelle utilizzate in questo caso, è anche possibile incorporare in anticipo l’SDK Salesforce Interactions. Tuttavia, su un sito web reale, potrebbe non essere sempre possibile aggiungere liberamente l’SDK già dalla fase di test.
Per questo motivo, utilizzeremo prima la funzionalità Inject di Sitemap Builder. Inject è una funzionalità che applica temporaneamente l’SDK Salesforce Interactions e il Sitemap in corso di creazione alla pagina Web attualmente aperta, in modo da poter effettuare sviluppo e verifiche operative direttamente in Sitemap Builder.
4. Nel campo Web SDK URL, inserisci l’URL dello script copiato in precedenza dal Website Connector.
https://cdn.c360a.salesforce.com/beacon/c360a/db4dce08-43c3-406c-b901-1d0fc6a9e009/scripts/c360a.min.js
5. Dopo aver inserito l’URL dello script, clicca su Inject lasciando inalterate le seguenti impostazioni.
- Use SDK-embedded sitemap: OFF
- Browser Overrides: lascia il valore predefinito
6. Quando il caricamento avviene correttamente, nella parte superiore dello schermo viene mostrato SDK Loaded ✓.
Questo permette di utilizzare il Web SDK da Sitemap Builder sul sito TrailNest attuale e testare il comportamento del Sitemap.
Nota: L’SDK caricato tramite Inject serve per lo sviluppo e il test con Sitemap Builder. A questo punto, non significa che l’SDK Salesforce Interactions sia stato formalmente implementato sul sito web.
Nella schermata era presente un’impostazione chiamata Use SDK-embedded sitemap, ma poiché in questo caso vogliamo testare il Sitemap che stiamo creando in Sitemap Builder, la lasceremo su OFF.
- Se questa impostazione viene attivata (ON), è possibile effettuare il test utilizzando il Sitemap già incorporato nell’SDK, invece del Sitemap attualmente in fase di creazione in Sitemap Builder.
- Questo può essere utile, ad esempio, per verificare il Sitemap dopo averlo caricato nel Website Connector.
Scegliere come creare il Sitemap in Sitemap Builder
7. Successivamente, passa alla tab Configure.
Quando si configura Sitemap Builder per la prima volta, vengono mostrate più opzioni su come creare il Sitemap.
Nella schermata utilizzata in questo caso, vengono mostrate le seguenti opzioni.
- Start from Scratch
- Import Sitemap Builder Config
- Retail Quick Start
Import Sitemap Builder Config permette di caricare un file di configurazione di Sitemap Builder esportato in precedenza e riprendere il lavoro.
8. Se si utilizza Retail Quick Start in questo caso, Page Types, Resolvers, Events, Listeners e altri elementi per un sito e-commerce vengono preparati in anticipo, permettendo di iniziare rapidamente a creare un Sitemap per un tipico sito Retail.
Tuttavia, TrailNest utilizzato in questo caso ha una configurazione particolare in cui Home, Category, Product Detail e altre pagine vengono commutate tramite parametri Query String su un’unica CloudPage. Inoltre, poiché questo articolo intende configurare Sitemap Builder verificando i suoi meccanismi uno alla volta, selezioneremo Start from Scratch in questo caso.
Retail Quick Start è un template che permette di iniziare a creare un Sitemap basandosi su transizioni di pagina e Interactions comuni sui siti Retail / EC, come Product Listing Page, Product Detail Page e Cart. Tuttavia, poiché è pensato per siti e-commerce molto standard, è improbabile che possa essere applicato completamente così com’è.
Nota: Se si passa da “Start From Scratch” a “Retail Quick Start” (o viceversa) e si clicca sul bottone di avvio, tutto il contenuto configurato finora verrà cancellato e non potrà essere recuperato, quindi fai attenzione.
Spiegazione di ciascuna tab in Sitemap Builder
La schermata Configure fornisce più tab per la creazione di un Sitemap. Il ruolo di ciascuna tab può essere riassunto come segue.
Settings
Qui si configurano le impostazioni comuni per l’intero Sitemap. Si configurano elementi come Data Space, Logging Level e il comportamento al cambio di URL per i siti SPA.
Consent Management
Questo collega il Consent del sito web al Sitemap e configura se l’SDK Salesforce Interactions è autorizzato ad avviare il Tracking.
Page Types
Questo classifica le pagine del sito web per tipo. Ad esempio, più pagine prodotto possono essere gestite tutte insieme come Product Detail.
Resolvers
Questo viene utilizzato per ottenere i valori richiesti dalla pagina Web, come ID prodotto, nome prodotto, prezzo, Customer ID, Email Address e informazioni sull’ordine.
Profile Attributes
Questo viene utilizzato per includere negli Events le informazioni di Profile necessarie per identificare l’utente, come Email Address e Customer ID.
Events
Questo definisce le azioni che gli utenti eseguono sul sito web, come Product View, Add to Cart e Purchase.
Schema
Questo permette di verificare lo Schema Data 360 generato automaticamente in base alle impostazioni configurate per Page Types, Resolvers, Profile Attributes, Events e altro.
Configurare Settings
Quando si clicca su Start From Scratch, si apre prima la tab Settings.
Settings si applica all’intero Sitemap, non solo a uno specifico Page Type.
Per TrailNest in questo caso, i valori predefiniti sono adeguati.
- Personalization Dataspace: default
- Logging Level: Debug
- Single Page Application Support: Off
Personalization Dataspace
- Personalization Dataspace è un’impostazione che specifica lo Data Space in cui vengono utilizzati gli asset di Salesforce Personalization come Personalization Points e Recommenders.
- Poiché in questo caso utilizzeremo il Data Space predefinito, lo lasceremo su default.
Logging Level
- Logging Level configura il livello di dettaglio dei log prodotti dall’SDK Salesforce Interactions.
- Poiché ci troviamo attualmente nella fase di costruzione e test del Sitemap, utilizzeremo Debug in modo che eventuali problemi siano più facili da verificare.
- L’SDK Salesforce Interactions include un Logger che produce informazioni di debug nella Console del browser.
Single Page Application Support
- Single Page Application Support è un’impostazione per i siti SPA (Single Page Application).
- Una SPA è un’applicazione Web che modifica solo l’URL e il contenuto della schermata senza ricaricare l’intera pagina.
TrailNest in questo caso utilizza parametri Query String come:
- ?view=product
- ?view=cart
- ?view=checkout
Tuttavia, ogni volta che si clicca su un link, la CloudPage stessa viene ricaricata. Pertanto non si tratta di una SPA, quindi lasceremo questa impostazione su OFF.
Configurare Consent Management
Successivamente, apri la tab Consent Management.
L’SDK Salesforce Interactions non salva né invia i dati comportamentali catturati finché non è stato ottenuto il Tracking Consent appropriato.
Quando viene fornito un Opt In valido, il Tracking inizia, e se il Consent cambia successivamente, lo stato può essere aggiornato utilizzando updateConsents().
Nella sezione Consent Management di Sitemap Builder, è possibile configurare come viene gestito il Consent utilizzando le seguenti opzioni.
- Opt In (un meccanismo che tratta sempre l’utente come opted in)
- Opt Out (un meccanismo che tratta sempre l’utente come opted out)
- Advanced Setup (per i casi in cui esiste un Consent Banner, e così via)
In questo caso, vogliamo poter verificare il comportamento del Sitemap e degli Events, quindi configureremo Opt In e procederemo. In altre parole, su questo sito di test, “il visitatore viene trattato come se avesse fornito il consenso al Tracking dall’inizio.”
Nota: L’Opt In utilizzato in questo caso è una configurazione per verificare il funzionamento in un ambiente di test. Su un sito web reale, implementa la gestione del Consent in base al Cookie Banner o alla Consent Management Platform utilizzata, alla privacy policy, ai requisiti legali e così via.
Se un sito web reale ha un Consent Banner, è possibile utilizzare Advanced Setup per specificare un Opt-In Element che consente il Tracking e un Opt-Out Element che lo rifiuta (ad esempio, bottoni “Accetta” e “Rifiuta”).
Sitemap Builder genera codice che rileva i click sugli elementi specificati e determina il Consent.
Tuttavia, con una Consent Management Platform (CMP) reale, il Consent precedentemente selezionato dall’utente potrebbe essere memorizzato nei Cookie o nel Local Storage, e il Consent Banner potrebbe non essere mostrato quando l’utente ritorna sul sito. Inoltre, il Consent Banner stesso potrebbe essere generato dinamicamente dopo il caricamento della pagina.
Pertanto, su un sito in produzione, oltre al rilevamento dei click tramite Element Picker, è necessario considerare anche un’implementazione che recuperi lo stato attuale del Consent memorizzato nella CMP al caricamento della pagina e lo passi all’SDK Salesforce Interactions.
Nel Web Tracking Consent Banner standard fornito da Marketing Cloud Next, la selezione dell’utente viene memorizzata nel Cookie sfmc_consent, quindi lo stato precedente del Consent può essere utilizzato anche nelle visite successive.
Relazione tra init() e Consent
A questo punto, aggiungerò qualche spiegazione in più sull’inizializzazione dell’SDK Salesforce Interactions.
Per utilizzare l’SDK Salesforce Interactions, è necessaria l’inizializzazione tramite il metodo init().
L’inizializzazione è il processo preparatorio che porta l’SDK caricato in uno stato effettivamente utilizzabile.
In init(), vengono preparate principalmente le impostazioni necessarie affinché l’SDK inizi a raccogliere dati, come la gestione dell’Identity e lo stato del Consent.
Nell’attuale API Salesforce, consents è un’impostazione obbligatoria passata a init(). init() restituisce una Promise, e una volta completata correttamente l’inizializzazione, l’SDK diventa disponibile per l’uso.
Una Promise è un meccanismo JavaScript che significa “restituisci il risultato più avanti, quando l’elaborazione sarà completata.”
L’elaborazione da eseguire dopo il completamento di init() può essere scritta in then(), mentre l’elaborazione per gli errori che si verificano durante l’inizializzazione può essere scritta in catch().
Ad esempio, se il Consent dell’utente non è ancora stato determinato, è possibile inizializzare l’API passando un array vuoto come segue.
window.getSalesforceInteractions().init({
consents: []
});
In questo caso, l’SDK stesso viene inizializzato, ma il Tracking non inizia finché non viene configurato l’Opt In.
Tuttavia, in questo caso, piuttosto che implementare questo codice direttamente e in modo permanente in CloudPages, configureremo il Consent in Sitemap Builder Consent Management e utilizzeremo il processo di inizializzazione nel Sitemap generato alla fine.
Se si osserva la Preview nella schermata Consent Management, è possibile verificare il contenuto di consents passato a init(), ad esempio nella forma seguente.
{
consents: new Promise(resolve => {
resolve([{
provider: "Consent Provider",
purpose: SI.ConsentPurpose.Tracking,
status: SI.ConsentStatus.OptIn
}]);
}),
personalization: {
dataspace: "default"
}
}
In altre parole, Sitemap Builder Consent Management non è semplicemente un’impostazione dell’interfaccia utente. È anche collegato alla configurazione del Consent passata durante l’inizializzazione dell’SDK Salesforce Interactions.
Pertanto, piuttosto che scrivere separatamente un init() inizialmente e fissarlo lato CloudPages, procederemo in questo caso utilizzando Sitemap Builder come base di configurazione.
Informazioni sul Personalization Module
L’obiettivo finale in questo caso non è semplicemente memorizzare i dati comportamentali in Data 360.
Utilizzando Salesforce Personalization, procederemo finché non riusciremo effettivamente a eseguire quanto segue su TrailNest.
- Hero Banner
- Recommendation
- Web Personalization
- Experimentation
Quando si visualizzano i risultati della Personalization sul Web, viene utilizzato anche il Personalization Module dell’SDK Salesforce Interactions.
Nell’implementazione attuale di Salesforce:
- SalesforceInteractions.Personalization.Config.initialize()
viene eseguito all’inizio del Sitemap, e il Personalization Module viene inizializzato prima di SalesforceInteractions.init().
Concettualmente, il flusso finale sarà:
Caricare l’SDK Salesforce Interactions
↓
Inizializzare il Personalization Module
↓
Inizializzare l’SDK Salesforce Interactions
↓
Inizializzare il Sitemap
↓
Integrare con Data 360 / Salesforce Personalization
Tuttavia, a questo punto, non abbiamo ancora creato gli elementi seguenti necessari per visualizzare Web Personalization.
- Profile Data Graph
- Item Data Graph
- Personalization Point
- Experience Template
Pertanto, riprenderemo la configurazione specifica del Personalization Module in seguito, quando implementeremo gli Hero Banner e le Recommendations.
Conclusione
Con questo, la preparazione tramite Website Connector, SDK Injection, Settings e Consent Management è completa.
Per riassumere a grandi linee le impostazioni che seguiranno:
- Page Types
→ “Quale pagina?” - Resolvers
→ “Cosa c’è nella pagina?” - Profile Attributes
→ “Chi è il visitatore?” - Events
→ “Cosa ha fatto?”
Sono questi gli elementi che configureremo successivamente.
Nel prossimo articolo, configureremo i sei tipi di pagine di TrailNest — Home, Category, Product Detail, Cart, Checkout e Order Confirmation — come Page Types in Sitemap Builder.
Questo è tutto per questo articolo.
Restate collegati per altri consigli su Salesforce Marketing Cloud! 😎
Nobuyuki Watanabe
Tradotto e adattato da SFMC Tips #354 : Personalization: Getting Started with Sitemap Builder di Nobuyuki Watanabe (@marketingcloudtips), pubblicato originariamente su Medium. Traduzione autorizzata dall’autore.