Uso degli eventi

Un evento è uno dei tre elementi della configurazione di Interact nell'ambiente di progettazione che interagisce direttamente con l'API di Interact. Quando si codifica il touchpoint per l'uso con l'API di Interact, utilizzare il metodo postEvent per fare riferimento agli eventi. Il nome dell'evento utilizzato nell'API di Interact deve corrispondere al nome dell'evento come configurato nell'ambiente di progettazione. Questo nome non fa distinzione tra maiuscole e minuscole.

Un evento attiva una o più delle seguenti azioni predefinite:

Attiva nuova segmentazione: l'ambiente runtime esegue di nuovo tutti i diagrammi di flusso interattivi per il livello di destinatari corrente associato al canale interattivo, utilizzando i dati correnti nella sessione del visitatore.

Quando si progetta l'interazione, tenere presene che se non si specifica un determinato diagramma di flusso, la risegmentazione esegue di nuovo tutti i diagrammi di flusso interattivi associati a questo canale interattivo con il livello di destinatari corrente e che tutte le richieste di offerte rimangono in attesa fino al termine di tutti i diagrammi di flusso. L'eccessiva risegmentazione all'interno di una singola visita può avere impatto sulle prestazioni del touchpoint in un modo visibile al cliente.

Posizionare il cliente in nuovi segmenti dopo aver aggiunto una quantità significativa di nuovi dati all'oggetto sessione runtime. Questi nuovi dati possono provenire da richieste dell'API di Interact (ad esempio, modifica dei destinatari) o da azioni del cliente (ad esempio, aggiunta di nuovi elementi a un elenco preferenze o un carrello).

Registra contatto offerta: l'ambiente runtime contrassegna le offerte consigliate affinché il servizio database registri le offerte nella cronologia dei contatti.

Per integrazioni Web, la procedura migliore consiste nella registrazione del contatto dell'offerta nella stessa chiamata in cui si richiedono offerte per ridurre al minimo il numero di richieste tra il touchpoint e il server runtime.

Se il touchpoint non restituisce i codici trattamento per le offerte che sono state presentate al visitatore, l'ambiente runtime registra l'ultimo elenco di offerte consigliate.

Registra accettazione offerta: l'ambiente runtime contrassegna l'offerta selezionata affinché il servizio database registri l'offerta nella cronologia di risposta.

Registra rifiuto offerta: l'ambiente runtime contrassegna l'offerta selezionata affinché il servizio database registri l'offerta nella cronologia di risposta.

Se si crea un evento con più azioni di registrazione dell'offerta, tenere presente che l'API di Interact esegue la stessa azione per l'offerta associata. Pertanto, non creare un evento che registra sia l'accettazione che il rifiuto dell'offerta perché sono azioni in conflitto l'una con l'altra. Tuttavia, creare un singolo evento per registrare il contatto e l'accettazione dell'offerta oppure il contatto e il rifiuto dell'offerta può essere utile.

Per impostazione predefinita, l'ambiente runtime può tenere traccia di due tipi di risposta, accettazione e rifiuto dell'offerta. È possibile modificare i tipi di risposta che gli eventi Registra accettazione offerta e Registra rifiuto offerta registrano, utilizzando le proprietà di configurazione accept e reject.

L'API di Interact può anche utilizzare eventi per attivare azioni definite utilizzando parametri di evento nell'API. Questi eventi includono la registrazione in una tabella personalizzata, il rilevamento di più tipi di risposta e la specifica di un determinato diagramma di flusso da eseguire. È possibile che sia necessario creare alcuni eventi senza una reazione del sistema definita o diversi eventi con la stessa reazione di sistema definita, ad esempio Registra contatto, da utilizzare con parametri di evento riservati.

È possibile creare diversi eventi con l'azione Registra accettazione offerta, uno per ogni tipo di risposta che si desidera registrare, o un singolo evento con l'azione Registra accettazione offerta utilizzato per ogni chiamata di postEvent per registrare tipi di risposta separati.

Ad esempio, creare un evento con l'azione Registra accettazione offerta per ciascun tipo di risposta. Definire le seguenti risposte personalizzate nella tabella UA_UsrResponseType [come Nome (codice)]: Esplora (EXP), Considera (CON) e Commit (CMT). Creare, quindi, tre eventi e denominarli LogAccept_Explore, LogAccept_Consider e LogAccept_Commit. Tutti e tre gli eventi sono esattamente gli stessi (azione Registra accettazione offerta), ma sono diversi in modo che la persona che utilizza l'API di Interact possa distinguerli.

Altrimenti, creare un singolo evento con l'azione Registra accettazione offerta utilizzato per tutti i tipi di risposta personalizzati. Ad esempio, denominarlo LogCustomResponse.

Quando si utilizza l'API di Interact, non esiste una differenza funzionale tra gli eventi, ma le convenzioni di denominazione possono rendere più chiaro il codice. Inoltre, se si assegna a una risposta personalizzata un nome diverso, il report Riepilogo attività eventi canale visualizza informazioni più accurate.

Per ulteriori informazioni sui parametri riservati e il metodo postEvent, vedere la Interact Administrator's Guide.

Eventi definiti dal sistema

La scheda Eventi contiene la categoria predefinita, Definito dal sistema. Non è possibile modificare, aggiungere o eliminare eventi in questa categoria. Questa categoria contiene eventi che corrispondono all'API di Interact. È possibile monitorare la frequenza con la quale tutti questi eventi si verificano nel touchpoint con il report Riepilogo attività eventi canale.

Questi eventi comprendono:

Fine sessione: consente di contrassegnare la fine di una sessione interattiva di un visitatore.

Ottieni offerta: consente di richiedere un elenco di offerte consigliate per un visitatore.

Richiama profilo: consente di richiedere i dati del profilo di un visitatore memorizzati nella sessione; include dati temporanei nonché dati letti da una tabella profili.

Imposta destinatari: consente di modificare il livello di destinatari di un visitatore all'interno della relativa sessione interattiva.

Imposta debug: consente di ignorare il livello di registrazione corrente per la sessione interattiva di un visitatore.

Avvia sessione: consente di contrassegnare l'inizio della sessione interattiva di un visitatore.