XDM ExperienceEvent clase
XDM ExperienceEvent es una clase estándar de modelo de datos de experiencia (XDM). Utilice esta clase para crear una instantánea con marca de tiempo del sistema cuando se produzca un evento específico o cuando se haya alcanzado un conjunto determinado de condiciones.
Un Evento de experiencia es un registro de hechos de lo que ocurrió, incluido el momento y la identidad de la persona involucrada. Los eventos pueden ser explícitos (acciones humanas directamente observables) o implícitos (planteados sin una acción humana directa) y se registran sin agregación ni interpretación. Para obtener más información de alto nivel sobre el uso de esta clase en el ecosistema de Platform, consulte la descripción general de XDM.
La propia clase XDM ExperienceEvent proporciona varios campos relacionados con series temporales a un esquema. Dos de estos campos (_id y timestamp) son obligatorios para todos los esquemas basados en esta clase, mientras que el resto son opcionales. Los valores de algunos de los campos se rellenan automáticamente cuando se incorporan datos.
_id(obligatorio)
_id identifica de forma exclusiva los eventos individuales que se incorporan a Adobe Experience Platform. Este campo se utiliza para realizar un seguimiento de la exclusividad de un evento individual, evitar la duplicación de datos y buscar ese evento en los servicios descendentes.Cuando se detectan eventos duplicados, las aplicaciones y los servicios de Platform pueden administrar la duplicación de forma diferente. Por ejemplo, los eventos duplicados en el servicio de perfiles se pierden si el evento con el mismo
_id ya existe en el almacén de perfiles.En algunos casos,
_id puede ser un Identificador único universal (UUID) o un Identificador único global (GUID).Si está transmitiendo datos desde una conexión de origen o ingiriendo directamente desde un archivo de Parquet, debe generar este valor concatenando una cierta combinación de campos que hagan que el evento sea único. Algunos ejemplos de eventos que se pueden concatenar son el ID principal, la marca de tiempo, el tipo de evento, etc. El valor concatenado debe ser una cadena con formato
uri-reference, lo que significa que se deben eliminar los caracteres de dos puntos. Después, el valor concatenado debe tener un cifrado hash con SHA-256 u otro algoritmo de su elección.Es importante distinguir que este campo no representa una identidad relacionada con una persona individual, sino más bien el registro de datos en sí. Los datos de identidad relacionados con una persona deben relegarse a campos de identidad proporcionados por grupos de campos compatibles.
eventMergeIdeventTypeLos valores estándar para esta propiedad se proporcionan en la sección del apéndice, con descripciones de su caso de uso previsto. Este campo es una enumeración ampliable, lo que significa que también puede utilizar sus propias cadenas de tipo de evento para categorizar los eventos que está rastreando.
eventType le limita a utilizar un solo evento por visita en la aplicación y, por lo tanto, debe utilizar campos calculados para que el sistema sepa qué evento es el más importante. Para obtener más información, consulte la sección sobre prácticas recomendadas para campos calculados.producedByAlgunos valores sugeridos para esta propiedad se proporcionan en la sección del apéndice. Este campo es una enumeración extensible, lo que significa que también puede utilizar sus propias cadenas para representar a diferentes productores de eventos.
identityMapConsulte la sección sobre mapas de identidad en los conceptos básicos de la composición de esquemas para obtener más información sobre su caso de uso.
timestamp(obligatorio)
Prácticas recomendadas para el modelado de eventos
Las siguientes secciones tratan sobre las prácticas recomendadas para diseñar esquemas XDM (Experience Data Model) basados en eventos en Adobe Experience Platform.
Marcas de hora timestamps
El campo raíz timestamp de un esquema de evento puede solamente representar la observación del propio evento y debe ocurrir en el pasado. Sin embargo, el evento debe tener lugar a partir de 1970. Si los casos de uso de la segmentación requieren el uso de marcas de tiempo que puedan producirse en el futuro, estos valores deben restringirse en cualquier parte del esquema de Experience Event.
Por ejemplo, si un negocio del sector de viajes y hospitalidad está modelando un evento de reserva de vuelo, el campo de nivel de clase timestamp representa el momento en el que se observó el evento de reserva. Otras marcas de tiempo relacionadas con el evento, como la fecha de inicio de la reserva de viaje, deben capturarse en campos independientes proporcionados por grupos de campos estándar o personalizados.
Al mantener la marca de tiempo en el nivel de clase separada de otros valores de fecha y hora relacionados en los esquemas de evento, puede implementar casos de uso de segmentación flexible, al tiempo que conserva una cuenta con marca de tiempo de los recorridos del cliente en la aplicación de experiencia.
Uso de campos calculados calculated
Ciertas interacciones en las aplicaciones de experiencia pueden dar como resultado varios eventos relacionados que técnicamente comparten la misma marca de tiempo de evento y, por lo tanto, se pueden representar como un único registro de evento. Por ejemplo, si un cliente ve un producto en su sitio web, esto puede generar un registro de evento que tenga dos valores eventType potenciales: un evento de "vista de producto" (commerce.productViews) o un evento de "vista de página" genérico (web.webpagedetails.pageViews). En estos casos, puede utilizar campos calculados para capturar los atributos más importantes cuando se capturan varios eventos en una sola visita.
Use Preparación de datos de Adobe Experience Platform para asignar, transformar y validar datos desde y hacia XDM. Con las funciones de asignación disponibles que proporciona el servicio, puede invocar a los operadores lógicos para priorizar, transformar o consolidar datos de registros de varios eventos cuando se incorporen en Experience Platform. En el ejemplo anterior, puede designar eventType como un campo calculado que daría prioridad a una "vista de producto" sobre una "vista de página" siempre que se produzcan ambos.
Si está ingiriendo datos manualmente en Platform a través de la interfaz de usuario, consulte la guía de campos calculados para ver los pasos específicos sobre cómo crear campos calculados.
Si está transmitiendo datos a Platform mediante una conexión de origen, puede configurar el origen para que utilice campos calculados en su lugar. Consulte la documentación de su origen en particular para obtener instrucciones sobre cómo implementar campos calculados al configurar la conexión.
Grupos de campos de esquema compatibles field-groups
El Adobe proporciona varios grupos de campos estándar para su uso con la clase XDM ExperienceEvent. A continuación se muestra una lista de algunos grupos de campos utilizados comúnmente para la clase:
- Extensión completa de Adobe Analytics ExperienceEvent
- Transferencias de saldo
- Detalles de marketing de campaña
- Acciones de tarjeta
- Detalles de canal
- Detalles de Commerce
- Detalles de depósito
- Detalles de intercambio de dispositivos
- Reserva de restaurante
- Detalles del identificador de usuario final
- Detalles del entorno
- Reserva de vuelo
- Consentimiento de IAB TCF 2.0
- Reserva de alojamiento
- Detalles de interacción de MediaAnalytics
- Detalles de solicitud de presupuesto
- Detalles de la reserva
- Detalles web
Apéndice
La siguiente sección contiene información adicional sobre la clase XDM ExperienceEvent.
Valores aceptados para eventType eventType
En la tabla siguiente se describen los valores aceptados de eventType, junto con sus definiciones:
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 se envía cuando comienza el almacenamiento en búfer. No hay ningún tipo de evento bufferResume específico; se considera que el almacenamiento en búfer se reanudó cuando se envía un evento play después de un evento bufferStart.media.chapterCompletemedia.chapterSkipmedia.chapterStartmedia.downloadedmedia.errormedia.pauseStartpauseStart. Este evento se activa cuando un usuario inicia una pausa en la reproducción de contenido. No hay ningún tipo de evento de reanudación. Se infiere una reanudación cuando envía un evento de reproducción después de pauseStart.media.pingmedia.ping se usa para indicar el estado de reproducción en curso. Para el contenido principal, este evento debe enviarse cada 10 segundos durante la reproducción, empezando 10 segundos después del inicio de la reproducción. Para el contenido de publicidad, debe enviarse cada segundo durante el seguimiento de la publicidad. Los eventos ping no deben incluir el mapa de parámetros en el cuerpo de la solicitud.media.playmedia.play se envía cuando el reproductor pasa al estado playing desde otro estado, como buffering, paused (cuando el usuario lo reanuda) o error (cuando se recupera), incluidos escenarios como la reproducción automática. Este evento se activa mediante la llamada de retorno on('Playing') del reproductor.media.sessionCompletemedia.sessionEndmedia.sessionEnd notifica al backend de Media Analytics que cierre inmediatamente una sesión cuando un usuario abandone la visualización y es poco probable que vuelva. Si no se envía este evento, la sesión se cerrará tras 10 minutos de inactividad o 30 minutos sin movimiento del cabezal de reproducción. Se ignorarán todas las llamadas de medios subsiguientes con ese ID de sesión.media.sessionStartmedia.sessionStart se envía con la llamada de inicio de sesión. Al recibir una respuesta, el ID de sesión se extrae del encabezado Ubicación y se utiliza para todas las llamadas de evento subsiguientes al servidor de recopilación.media.statesUpdatestatesUpdate. Las funcionalidades de seguimiento de estado del reproductor se pueden adjuntar a un flujo de audio o vídeo. Los estados estándar son: fullscreen, mute, closedCaptioning, pictureInPicture y inFocus.opportunityEvent.addToOpportunityopportunityEvent.opportunityUpdatedopportunityEvent.removeFromOpportunitypersonalization.requestdecisioning.propositionFetch.pushTracking.applicationOpenedpushTracking.customActionweb.formFilledOutweb.webinteraction.linkClicksweb.webpagedetails.pageViewslocation.entrylocation.exitValores sugeridos para producedBy producedBy
En la tabla siguiente se describen algunos valores aceptados para producedBy:
selfsystemsalesRefcustomerRep