XDM ExperienceEvent classe
XDM ExperienceEvent è una classe XDM (Experience Data Model) standard. Utilizzare questa classe per creare uno snapshot con marca temporale del sistema quando si verifica un evento specifico o viene raggiunto un determinato set di condizioni.
Un evento esperienza è una registrazione fattuale di ciò che si è verificato, incluso il momento e l’identità dell’individuo coinvolto. Gli eventi possono essere espliciti (azioni umane direttamente osservabili) o impliciti (generati senza un'azione umana diretta) e sono registrati senza aggregazione o interpretazione. Per ulteriori informazioni di alto livello sull'utilizzo di questa classe nell'ecosistema Platform, fare riferimento alla panoramica XDM.
La classe XDM ExperienceEvent fornisce a uno schema diversi campi correlati a serie temporali. Due di questi campi (_id e timestamp) sono obbligatori per tutti gli schemi basati su questa classe, mentre gli altri sono facoltativi. I valori di alcuni campi vengono compilati automaticamente al momento dell’acquisizione dei dati.
_id(Obbligatorio)
_id identifica in modo univoco i singoli eventi acquisiti in Adobe Experience Platform. Questo campo viene utilizzato per tenere traccia dell’univocità di un singolo evento, evitare la duplicazione di dati e cercare tale evento nei servizi a valle.Se vengono rilevati eventi duplicati, le applicazioni e i servizi Platform potrebbero gestire la duplicazione in modo diverso. Ad esempio, gli eventi duplicati nel servizio Profilo vengono eliminati se l'evento con lo stesso
_id esiste già nell'archivio Profili.In alcuni casi,
_id può essere un Identificatore univoco universale (UUID) o Identificatore univoco globale (GUID).Se si esegue il flusso di dati da una connessione di origine o si acquisiscono dati direttamente da un file Parquet, è necessario generare questo valore concatenando una determinata combinazione di campi che rendono l'evento univoco. Esempi di eventi che possono essere concatenati includono ID primario, marca temporale, tipo di evento e così via. Il valore concatenato deve essere una stringa formattata
uri-reference, il che significa che è necessario rimuovere i due punti. Successivamente, il valore concatenato deve essere sottoposto a hashing utilizzando SHA-256 o un altro algoritmo a tua scelta.È importante distinguere che questo campo non rappresenta un'identità correlata a una singola persona, ma il record dei dati stessi. I dati di identità relativi a una persona devono essere relegati a campi di identità forniti da gruppi di campi compatibili.
eventMergeIdeventTypeI valori standard per questa proprietà sono forniti nella sezione dell'appendice, incluse le descrizioni del caso d'uso previsto. Questo campo è un enum estensibile, il che significa che puoi utilizzare anche stringhe di tipo evento personalizzate per categorizzare gli eventi che stai tracciando.
eventType ti limita a utilizzare un solo evento per hit nell'applicazione, pertanto devi utilizzare i campi calcolati per comunicare al sistema quale evento è più importante. Per ulteriori informazioni, consulta la sezione sulle best practice per i campi calcolati.producedByAlcuni valori suggeriti per questa proprietà sono forniti nella sezione dell'appendice. Questo campo è un enum estensibile, il che significa che puoi utilizzare anche stringhe personalizzate per rappresentare diversi produttori di eventi.
identityMapPer ulteriori informazioni sul caso d'uso, consulta la sezione sulle mappe di identità nelle nozioni di base sulla composizione dello schema.
timestamp(Obbligatorio)
Best practice per la modellazione degli eventi
Le sezioni seguenti descrivono le best practice per la progettazione di schemi Experience Data Model (XDM) basati su eventi in Adobe Experience Platform.
Marca temporale timestamps
Il campo timestamp radice di uno schema evento può only rappresentare l'osservazione dell'evento stesso e deve verificarsi nel passato. Tuttavia, l'evento must si svolge dal 1970 in poi. Se i casi di utilizzo della segmentazione richiedono l’uso di marche temporali che possono verificarsi in futuro, questi valori devono essere vincolati altrove nello schema Evento esperienza.
Ad esempio, se un'azienda del settore viaggi e ospitalità sta modellando un evento di prenotazione di un volo, il campo timestamp a livello di classe rappresenta il momento in cui è stato osservato l'evento di prenotazione. Altre marche temporali correlate all’evento, come la data di inizio della prenotazione del viaggio, devono essere acquisite in campi separati forniti da gruppi di campi standard o personalizzati.
Mantenendo la marca temporale a livello di classe separata da altri valori di data e ora correlati negli schemi evento, puoi implementare casi di utilizzo di segmentazione flessibili, mantenendo al contempo un account con marca temporale dei percorsi di clienti nell’applicazione Experience.
Utilizzo dei campi calcolati calculated
Alcune interazioni nelle applicazioni di esperienza possono causare più eventi correlati che tecnicamente condividono la stessa marca temporale dell’evento e possono quindi essere rappresentati come un singolo record di evento. Ad esempio, se un cliente visualizza un prodotto sul sito Web, può verificarsi un record evento con due potenziali valori eventType: un evento "visualizzazione prodotto" (commerce.productViews) o un evento "visualizzazione pagina" generico (web.webpagedetails.pageViews). In questi casi, puoi utilizzare i campi calcolati per acquisire gli attributi più importanti quando più eventi vengono acquisiti in un singolo hit.
Utilizza Preparazione dati di Adobe Experience Platform per mappare, trasformare e convalidare i dati da e verso XDM. Utilizzando le funzioni di mappatura disponibili fornite dal servizio, è possibile richiamare operatori logici per assegnare priorità, trasformare e/o consolidare dati da record con più eventi al momento dell'acquisizione in Experience Platform. Nell'esempio precedente, è possibile designare eventType come campo calcolato che assegnerebbe la priorità a una "visualizzazione prodotto" rispetto a una "visualizzazione pagina" ogni volta che si verificano entrambe.
Se acquisisci manualmente i dati in Platform tramite l’interfaccia utente, consulta la guida sui campi calcolati per i passaggi specifici sulla creazione dei campi calcolati.
Se trasferisci dati a Platform utilizzando una connessione di origine, puoi configurare l’origine per utilizzare i campi calcolati. Per istruzioni su come implementare i campi calcolati durante la configurazione della connessione, consulta la documentazione per l'origine specifica.
Gruppi di campi di schema compatibili field-groups
L'Adobe fornisce diversi gruppi di campi standard da utilizzare con la classe XDM ExperienceEvent. Di seguito è riportato un elenco di alcuni gruppi di campi comunemente utilizzati per la classe:
- Estensione completa Adobe Analytics ExperienceEvent
- Trasferimenti saldo
- Dettagli marketing campagna
- Azioni scheda
- Dettagli canale
- Dettagli Commerce
- Dettagli versamento
- Dettagli permuta dispositivo
- Prenotazione ristorante
- Dettagli ID utente finale
- Dettagli ambiente
- Prenotazione del volo
- Consenso IAB TCF 2.0
- Prenotazione alloggio
- Dettagli interazione MediaAnalytics
- Dettagli richiesta preventivo
- Dettagli prenotazione
- Dettagli Web
Appendice
La sezione seguente contiene informazioni aggiuntive sulla classe XDM ExperienceEvent.
Valori accettati per eventType eventType
La tabella seguente illustra i valori accettati per eventType e le relative definizioni:
advertising.clicksadvertising.completesadvertising.conversionsadvertising.federatedadvertising.firstQuartilesadvertising.impressionsadvertising.midpointsadvertising.startsadvertising.thirdQuartilesadvertising.timePlayedapplication.closeapplication.launchclickdecisioning.propositionInteract.commerce.backofficeCreditMemoIssuedcommerce.backofficeOrderCancelledcommerce.backofficeOrderItemsShippedcommerce.backofficeOrderPlacedcommerce.backofficeShipmentCompletedcommerce.checkoutscommerce.productListAddscommerce.productListOpenscommerce.productListRemovalscommerce.productListReopenscommerce.productListViewscommerce.productViewscommerce.purchasescommerce.saveForLatersdecisioning.propositionDisplaydecisioning.propositionDismissdecisioning.propositionFetchdecisioning.propositionInteractdecisioning.propositionSenddecisioning.propositionTriggerdelivery.feedbackdirectMarketing.emailBounceddirectMarketing.emailBouncedSoftdirectMarketing.emailClickeddirectMarketing.emailDelivereddirectMarketing.emailOpeneddirectMarketing.emailSentdirectMarketing.emailUnsubscribeddisplaydecisioning.propositionDisplay.inappmessageTracking.dismissinappmessageTracking.displayinappmessageTracking.interactleadOperation.callWebhookleadOperation.changeCampaignStreamleadOperation.changeEngagementCampaignCadenceleadOperation.convertLeadleadOperation.interestingMomentleadOperation.mergeLeadsleadOperation.newLeadleadOperation.scoreChangedleadOperation.statusInCampaignProgressionChangedlistOperation.addToListlistOperation.removeFromListmedia.adBreakCompletemedia.adBreakStartmedia.adCompletemedia.adSkipmedia.adStartmedia.bitrateChangemedia.bufferStartmedia.bufferStart viene inviato all'inizio del buffering. Non esiste un tipo di evento bufferResume specifico; il buffering viene considerato ripreso quando un evento play viene inviato dopo un evento bufferStart.media.chapterCompletemedia.chapterSkipmedia.chapterStartmedia.downloadedmedia.errormedia.pauseStartpauseStart. Questo evento viene attivato quando un utente avvia una pausa nella riproduzione di contenuti multimediali. Non esiste un tipo di evento di ripresa. La ripresa viene dedotta quando si invia un evento di riproduzione dopo pauseStart.media.pingmedia.ping viene utilizzato per indicare lo stato di riproduzione in corso. Per il contenuto principale, questo evento deve essere inviato ogni 10 secondi durante la riproduzione, a partire da 10 secondi dopo l’inizio della riproduzione. Per il contenuto degli annunci, deve essere inviato ogni secondo durante il tracciamento degli annunci. Gli eventi ping non devono includere la mappa dei parametri nel corpo della richiesta.media.playmedia.play viene inviato quando il lettore passa allo stato playing da un altro stato, ad esempio buffering, paused (quando viene ripreso dall'utente) o error (quando viene ripristinato), inclusi scenari come la riproduzione automatica. Questo evento viene attivato dal callback on('Playing') del lettore.media.sessionCompletemedia.sessionEndmedia.sessionEnd notifica al backend di Media Analytics la chiusura immediata di una sessione quando un utente abbandona la visualizzazione ed è improbabile che ritorni. Se questo evento non viene inviato, la sessione si interrompe dopo 10 minuti di inattività o 30 minuti senza movimento dell’indicatore di riproduzione. Eventuali chiamate multimediali successive con tale ID sessione verranno ignorate.media.sessionStartmedia.sessionStart viene inviato con la chiamata di avvio della sessione. Dopo aver ricevuto una risposta, l’ID sessione viene estratto dall’intestazione Posizione e utilizzato per tutte le chiamate evento successive al server di raccolta.media.statesUpdatestatesUpdate. Le funzionalità di tracciamento dello stato del lettore possono essere collegate a un flusso audio o video. Gli stati standard sono: fullscreen, mute, closedCaptioning, pictureInPicture e inFocus.opportunityEvent.addToOpportunityopportunityEvent.opportunityUpdatedopportunityEvent.removeFromOpportunitypersonalization.requestdecisioning.propositionFetch.pushTracking.applicationOpenedpushTracking.customActionweb.formFilledOutweb.webinteraction.linkClicksweb.webpagedetails.pageViewslocation.entrylocation.exitValori consigliati per producedBy producedBy
Nella tabella seguente sono illustrati alcuni valori accettati per producedBy:
selfsystemsalesRefcustomerRep