Dynamic Yield propone due metodi per aggiornare il feed dei dati utente con le informazioni che puoi sfruttare per creare segmenti di pubblico in base a condizioni di targeting specificate: l'API per i dati utente, come descritto in questo articolo, o un file CSV caricato. L'API è la scelta migliore per l'attivazione dei dati in tempo reale, con un carico ridotto rispetto al caricamento del file, e funziona bene per l'aggiornamento di un numero limitato di utenti.
L'API per i dati utente consente di aggiornare i dati utente su richiesta, anche tramite aggiornamenti parziali.
Con l'API per i dati utente, è possibile utilizzare i dati raccolti al di fuori di Dynamic Yield per la segmentazione e il targeting, in tempo reale e con un carico ridotto rispetto al feed basato su file. Inoltre, è possibile eseguire aggiornamenti, visualizzare i risultati e monitorare le operazioni senza bisogno dell'assistenza del tuo account manager.
Flusso di onboarding dei dati utente
Il processo di onboarding include i seguenti passaggi:
- Passaggio 1 - preparazione: dovrai decidere quali attributi (colonne) trasferire all'API.
- Passaggio 2 - crea lo schema JSON: imposta lo schema che determina dove e come vengono archiviate le informazioni in Dynamic Yield.
- Passaggio 3 - configura il feed: crea un nuovo feed, testalo e carica i tuoi dati utente.
Segui queste istruzioni se stai configurando l'onboarding dei dati utente per la prima volta. Se stai eseguendo la migrazione dal caricamento CSV all'API, consulta la sezione Account esistenti: passaggio da CSV ad API.
Passaggio 1: preparazione
- Decidi quali attributi (colonne) trasferire nell'API (includendo attributi come nome, tipo e così via). Nota: per motivi di privacy, non includere attributi considerati PII (ad esempio nome, data di nascita, indirizzo e così via).
Suggerimento professionale:
tutti gli attributi utente vanno trasferiti ad ogni chiamata API. È possibile semplificare il processo raggruppando le colonne in feed di dati utente in base ai casi d'uso, per esempio, sulla base d questi parametrii:
- frequenza: raggruppa i campi da aggiornare con la stessa frequenza (elimina gli aggiornamenti inutili);
- disponibilità degli attributi: tutti gli attributi aggiornati nel feed disponibili per ogni chiamata API, quindi, suddividi le caratteristiche che cambiano di rado da quanto si modifica spesso;
- numero di utenti da aggiornare: per un numero limitato di aggiornamenti agli utenti, l'API è la più modalità più adatta. Se è necessario eseguire un aggiornamento completo, sfrutta il metodo del caricamento di un'API o di un file CSV.
- Genera una chiave API (se non l'hai già fatto).
Passaggio 2: crea lo schema JSON
Lo schema è una tabella che determina dove e come vengono archiviate le informazioni in Dynamic Yield. Queste informazioni vengono fornite nella sintassi JSON e copiate nella console Dynamic Yield.
Abbiamo creato uno strumento per semplificare la creazione e la modifica dello schema JSON:
- accedi allo strumento per la creazione di schemi,
- scopri di più sul Creatore di schemi di dati utente,
.
Obiettivo
Lo scopo dello schema è:- definire la tabella in cui sono archiviati i dati, in modo che i valori possano essere convalidati quando vengono inviati tramite l'API o il CSV.
- Definisci il modo in cui la console di Dynamic Yield mostra la condizione (quando definisce un pubblico in base a criteri).
Limitazione delle dimensioni
Lo schema di definizione JSON non può superare 64 KB.Settori
Ogni settore viene memorizzato come oggetto all'interno dell'array dei campi. Lo schema JSON deve includere almeno 1 oggetto nell'array dei campi con i seguenti parametri, come mostrato nell'esempio seguente:"fields": [
{
"name": "purchase_count",→ il nome del campo inviato all'API o della colonna nel file CSV
"display": "Purchase Count", → il nome della condizione, che appare in DY admin
"type": [
"null", → l'oggetto ammette valori nulli o meno
"int" → la natura del campo da trasferire
],
"uiType": "number" → la natura del campo che appare in DY admin
}
]
Valori aggiuntivi nel layout
Se vuoi creare valori di visualizzazione nella console Dynamic Yield oltre a quelli impostati nello schema:
- devi creare un oggetto dell'interfaccia utente che ne contenga la definizione (ad esempio, mappa “true” a “t”).
- Parallelamente all'array "field", aggiungi un oggetto "uiTypes".
- Mappa l'oggetto dell'interfaccia utente utilizzando l'oggetto campo esistente.
- Verifica che ogni oggetto dell'interfaccia utente nelle matrici di campi sia definito.
Esempio di come può apparire:
Codice dell'esempio:
"fields": [
{
"name": "has_offer",
"display": "Has Offer",
"type": [
"null",
"boolean"
],
"uiType": "ref",
"uiTypeRef": "UIhas_offer"
}
],
"uiTypes": {
"UIhas_offer": {
"uiType": "select",
"validation": {
"values": [
{
"name": "Yes",
"value": "true"
},
{
"name": "No",
"value": "false"
}
]
}
}
puoi:
- aggiungere o rimuovere valori, purché non siano in uso in condizioni di pubblico
- modificare i nomi visualizzati dei campi,
- aggiungere nuovi campi:
- elementi da aggiungere solo alla fine dello schema esistente.
- I campi devono ammettere valori nulli (non obbligatori; devono essere del tipo “null”).
- Deve includere "default": parametri null;
non puoi:
- eliminare campi.
Suggerimento professionale: prova, piuttosto, a cambiare un campo non obbligatorio e smetti di aggiornarlo; - modificare l'ordine dei campi,
- modificare i tipi di campo,
- rimuovere “null” dal tipo di campo, come farà il campo obbligatorio.
Nota: quando salverai lo schema modificato, i cambiamenti verrannno applicati immediatamente. Assicurati di aggiornare le tue chiamate API di conseguenza.
{
"fields": [
{
"//": "Esempio di campo con valori - riferimento per uiType con i valori possibili",
"name": "VIPPersona",
"display": "VIP Persona",
"type": [
"null",
"int"
],
"uiType": "ref",
"uiTypeRef": "UIMetalVIP"
},
{
"//": "Esempio di numero - non è necessario inserire un riferimento in uiType",
"name": "CustomerScore",
"display": "Customer Score",
"type": [
"null",
"int"
],
"default": null,
"uiType": "number"
},
{
"//": "Esempio di stringa - non è necessario inserire un riferimento in uiType",
"display": "Account Manager",
"name": "AccountManager",
"type": [
"null",
"string"
],
"uiType": "input"
},
{
"//": "Esempio booleano - non è necessario inserire un riferimento in uiType",
"name": "IsSubscribedTo",
"display": "Is Subscribed To Emails",
"type": [
"null",
"boolean"
],
"uiType": "ref",
"uiTypeRef": "UIIsSubscribed"
},
{
"//": "Esempio di data - non è necessario inserire un riferimento in uiType",
"name": "AnniversaryGiftExpires",
"display": "Anniversary Gift Expires",
"type": [
"null",
"long"
],
"uiType": "date"
},
{
"//": "Esempio di matrice di enumerazioni - valori che si possono selezionare da un elenco a discesa, di cui si può inserire un riferimento in uiType con i valori possibili",
"name": "VIPPersona",
"display": "VIP Persona",
"type": [
"null",
{
"type": "array",
"items": "int"
}
],
"uiType": "ref",
"uiTypeRef": "UIMetalVIP"
},
{
"//": "Esempio di array di stringhe - non è necessario inserire un riferimento in uiType",
"name": "nicknames",
"display": "Nicknames",
"type": [
"null",
{
"type": "array",
"items": "string"
}
],
"uiType": "input"
}
],
"uiTypes": {
"UIMetalVIP": {
"//": "Esempio di rappresentazione di valori di visualizzazione diversi nella console Dynamic Yield",
"uiType": "select",
"validation": {
"values": [
{
"name": "VIP Gold",
"value": 0,
"source": "goldVIP"
},
{
"name": "Other",
"value": 1,
"source": "otherVip"
},
{
"name": "VIP Silver",
"value": 4,
"source": "vipSilver"
}
]
}
},
"UIIsSubscribed": {
"//": "Valori admin: booleani",
"uiType": "select",
"validation": {
"values": [
{
"name": "No",
"value": "false"
},
{
"name": "Yes",
"value": "true"
}
]
}
}
}
}
Usa il nostro Generatore di schemi di dati utente per creare o modificare gli schemi.
Passaggio 3: configura il feed
Crea un nuovo feed
- Vai a Asset › Feed di dati e crea un nuovo feed di dati utente.
- Per la Fonte del feed, seleziona la Sincronizzazione tramite API.
- Entra nello schema per il feed.
- Definisci il tipo CUID. L'impostazione predefinita è e-mail, quindi dovrai modificare questo valore solo se volessi utilizzare un tipo di ID diverso.
- Clicca su Salva in bozza.
Testare il feed
Nota: questo è un passaggio importante, perché dopo l'attivazione, lo schema può cambiare solo entro certe limitazioni. In questo modo, il sistema non eseguirà il commit dei dati utente di prova e le campagne non saranno ancora pubblicate.
- Chiama l'API codificata nel passaggio precedente.
- La chiamata API restituirà un ID transazione in un campo denominato dy_trace_id. Utilizzando questo ID, vai al registro API e cerca lo stato della chiamata API.
- Nel registro, verifica che lo stato della richiesta API sia corretto (202). Quindi, controlla che non esistano errori per gli oggetti nidificati: lo stato della chiamata API restituito non li dovrà includere.
Quando il sistema chiama l'API, verrà restituito uno stato. Questo stato indica che la chiamata è stata ricevuta. Nel log è possibile visualizzare i dettagli di eventuali errori per ogni azione, relativi agli specifici oggetti inclusi.
Onboarding dei dati utente
- Attiva il feed (sviluppatore).
- Chiama le API in base al tuo flusso aziendale.
- Monitora il feed (utente aziendale e sviluppatore). Consulta la sezione Registri e avvisi API in Experience per ulteriori informazioni. I log dell'API per i dati utente si comporteranno allo stesso modo.
Account esistenti: passaggio da CSV ad API
Se hai già impostato l'onboarding dei dati utente tramite il metodo di caricamento CSV e vuoi trasferire all'API dei dati utente:
- apri il feed di dati utente.
- Modifica le impostazioni del feed a Sincronizza via API. Nota che i cambiamenti nello schema non sono supportati al momento.
- Chiama le API in base al tuo flusso aziendale.
- Monitora il feed (utente aziendale e sviluppatore). Usa:
- Alert: puoi fornire informazioni sui problemi relativi alla chiamata API e agli oggetti inclusi;
- Log: consulta la sezione log delle API Experience per avere maggiori informazioni. I log dell'API per i dati utente si comportano allo stesso modo.
- Attiva la funzione
Nota: gli attributi utente esistenti verranno mantenuti quando si passano ad API.
Importante: una volta passati alla sincronizzazione API, non è possibile tornare indietro al metodo CSV senza l'assistenza del supporto tecnico, quindi, assicurati che sia ciò che vuoi fare.
Creazione di chiamate API
Per ulteriori informazioni, consulta la sezione dedicata ai riferimenti API sul sito del nostro sviluppatore.
Creazione di segmenti di pubblico in base ai dati degli utenti
Quando si imposta l'onboarding dei dati, è possibile utilizzare immediatamente il comando Audience Explorer per esplorare questi importanti segmenti e analizzare le relative prestazioni rispetto all'intera base di utenti online, integrandoli con dati comportamentali degli utenti acquisiti tramite Dynamic Yield. Visualizzerai la nuova condizione sotto le Proprietà utente utilizzando il nome del feed dati utenti, da abbinare a qualsiasi altra condizione di Dynamic Yield disponibile nel tuo account e utilizzata per creare e salvare segmenti micro-targetizzabili (segmenti di pubblico) che si possono incorporare nelle tue esperienze di personalizzazione del sito Dynamic Yield e nei consigli.
Nota: quando crei un segmento di pubblico con condizioni che si basano sui dati mappati come array di stringhe (Text Array), gli operatori disponibili sono "is", "is not", "contains", e "does not contain", dove "is" soddisfa uno dei valori nell'array corrispondente al valore elencato, mentre "contains" soddisfa uno dei valori qualsiasi nella matrice che contiene il valore elencato.
Prerequisiti e limitazioni
- Il feed incentrato sulle API non si può modificare nel metodo CSV.
- Ogni sito deve avere una chiave API univoca.
- Limite di richieste API:
- puoi aggiornare fino a 100 utenti in 1 chiamata API
- fino a 100 chiamate API in 1 secondo, per un totale di 600.000 aggiornamenti al minuto