XDM ExperienceEvent classe
XDM ExperienceEvent é uma classe padrão do Experience Data Model (XDM). Use essa classe para criar um instantâneo com carimbo de data e hora do sistema quando um evento específico ocorrer ou quando um determinado conjunto de condições for atingido.
Um Evento de experiência é um registro fatual do que ocorreu, incluindo o momento e a identidade do indivíduo envolvido. Eventos podem ser explícitos (ações humanas diretamente observáveis) ou implícitos (gerados sem uma ação humana direta) e são registrados sem agregação ou interpretação. Para obter mais informações de alto nível sobre o uso dessa classe no ecossistema da Platform, consulte a visão geral do XDM.
A própria classe XDM ExperienceEvent fornece vários campos relacionados a séries temporais para um esquema. Dois destes campos (_id e timestamp) são obrigatórios para todos os esquemas baseados nesta classe, enquanto o restante é opcional. Os valores de alguns campos são preenchidos automaticamente quando os dados são assimilados.
_id(Obrigatório)
_id identifica exclusivamente eventos individuais que são assimilados na Adobe Experience Platform. Este campo é usado para rastrear a exclusividade de um evento individual, impedir a duplicação de dados e pesquisar esse evento nos serviços downstream.Quando eventos duplicados são detectados, os aplicativos e serviços da Platform podem lidar com a duplicação de forma diferente. Por exemplo, eventos duplicados no Serviço de perfil são descartados se o evento com o mesmo
_id já existir no armazenamento Perfil.Em alguns casos,
_id pode ser um Identificador exclusivo universal (UUID) ou Identificador exclusivo global (GUID).Se estiver transmitindo dados de uma conexão de origem ou assimilando diretamente de um arquivo do Parquet, você deve gerar esse valor concatenando uma determinada combinação de campos que tornam o evento único. Os exemplos de eventos que podem ser concatenados incluem ID primária, carimbo de data e hora, tipo de evento e assim por diante. O valor concatenado deve ser uma cadeia de caracteres formatada
uri-reference, o que significa que todos os caracteres de dois pontos devem ser removidos. Posteriormente, o valor concatenado deve ser transformado em hash usando SHA-256 ou outro algoritmo de sua escolha.É importante distinguir que este campo não representa uma identidade relacionada a uma pessoa individual, mas o próprio registro de dados. Os dados de identidade relacionados a uma pessoa devem ser relegados a campos de identidade fornecidos por grupos de campos compatíveis.
eventMergeIdeventTypeOs valores padrão para esta propriedade são fornecidos na seção do apêndice, incluindo descrições do caso de uso pretendido. Esse campo é um enum extensível, o que significa que você também pode usar suas próprias cadeias de caracteres de tipo de evento para categorizar os eventos que você está rastreando.
eventType limita você a usar apenas um único evento por ocorrência em seu aplicativo e, portanto, você deve usar campos calculados para informar ao sistema qual evento é mais importante. Para obter mais informações, consulte a seção sobre práticas recomendadas para campos calculados.producedByAlguns valores sugeridos para esta propriedade são fornecidos na seção do apêndice. Esse campo é um enum extensível, o que significa que você também pode usar suas próprias cadeias de caracteres para representar diferentes produtores de evento.
identityMapConsulte a seção sobre mapas de identidade nas noções básicas da composição de esquema para obter mais informações sobre o caso de uso.
timestamp(Obrigatório)
Práticas recomendadas para modelagem de eventos
As seções a seguir abordam as práticas recomendadas para criar esquemas do Experience Data Model (XDM) com base em eventos no Adobe Experience Platform.
Carimbos de data e hora timestamps
O campo raiz timestamp de um esquema de evento pode only representar a observação do próprio evento e deve ocorrer no passado. Entretanto, o evento must ocorrerá a partir de 1970. Se os casos de uso de segmentação exigirem o uso de carimbos de data e hora que podem ocorrer no futuro, esses valores deverão ser restritos em outro lugar no esquema do Evento de experiência.
Por exemplo, se uma empresa no setor de viagem e hospitalidade estiver modelando um evento de reserva de voo, o campo timestamp no nível da classe representa o horário em que o evento de reserva foi observado. Outros carimbos de data e hora relacionados ao evento, como a data de início da reserva de viagem, devem ser capturados em campos separados fornecidos por grupos de campos padrão ou personalizados.
Ao manter o carimbo de data e hora em nível de classe separado de outros valores de data e hora relacionados nos esquemas de evento, você pode implementar casos de uso de segmentação flexível, preservando uma conta com carimbo de data e hora de jornadas do cliente no aplicativo de experiência.
Uso de campos calculados calculated
Certas interações em seus aplicativos de experiência podem resultar em vários eventos relacionados que tecnicamente compartilham o mesmo carimbo de data e hora de evento e, portanto, podem ser representados como um único registro de evento. Por exemplo, se um cliente exibir um produto em seu site, isso poderá resultar em um registro de evento com dois valores possíveis de eventType: um evento de "exibição de produto" (commerce.productViews) ou um evento genérico de "exibição de página" (web.webpagedetails.pageViews). Nesses casos, você pode usar campos calculados para capturar os atributos mais importantes quando vários eventos são capturados em uma única ocorrência.
Use o Preparo de dados do Adobe Experience Platform para mapear, transformar e validar dados de e para o XDM. Usando as funções de mapeamento disponíveis fornecidas pelo serviço, você pode chamar operadores lógicos para priorizar, transformar e/ou consolidar dados de registros de vários eventos ao serem assimilados no Experience Platform. No exemplo acima, você poderia designar eventType como um campo calculado que priorizaria uma "exibição de produto" sobre uma "exibição de página" sempre que ambas ocorressem.
Se você estiver assimilando dados manualmente na Platform por meio da interface do usuário, consulte o manual em campos calculados para obter etapas específicas sobre como criar campos calculados.
Se você estiver transmitindo dados para a Platform usando uma conexão de origem, será possível configurar a origem para utilizar campos calculados. Consulte a documentação da sua origem específica para obter instruções sobre como implementar campos calculados ao configurar a conexão.
Grupos de campos de esquema compatíveis field-groups
O Adobe fornece vários grupos de campos padrão para uso com a classe XDM ExperienceEvent. Veja a seguir uma lista de alguns grupos de campos comumente usados para a classe:
- Extensão completa do Adobe Analytics ExperienceEvent
- Transferências de saldo
- Detalhes de marketing da campanha
- Ações do cartão
- Detalhes do canal
- Detalhes do Commerce
- Detalhes do depósito
- Detalhes de troca do dispositivo
- Reserva para o jantar
- Detalhes da ID do Usuário Final
- Detalhes do ambiente
- Reserva de voo
- Consentimento IAB TCF 2.0
- Reserva de hospedagem
- Detalhes de interação do MediaAnalytics
- Detalhes da solicitação de orçamento
- Detalhes da reserva
- Detalhes da Web
Apêndice
A seção a seguir contém informações adicionais sobre a classe XDM ExperienceEvent.
Valores aceitos para eventType eventType
A tabela a seguir descreve os valores aceitos para eventType, juntamente com suas definições:
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 é enviado quando o buffering começa. Não há um tipo de evento bufferResume específico; considera-se que o buffering foi retomado quando um evento play é enviado após um evento bufferStart.media.chapterCompletemedia.chapterSkipmedia.chapterStartmedia.downloadedmedia.errormedia.pauseStartpauseStart ocorreu. Esse evento é acionado quando um usuário inicia uma pausa na reprodução de mídia. Não há um tipo de evento de retomada. Um currículo é inferido quando você envia um evento de reprodução após um pauseStart.media.pingmedia.ping é usado para indicar o status de reprodução em andamento. Para o conteúdo principal, esse evento deve ser enviado a cada 10 segundos durante a reprodução, começando 10 segundos após o início da reprodução. Para conteúdo de anúncio, ele deve ser enviado a cada segundo durante o rastreamento do anúncio. Os eventos de ping não devem incluir o mapa de parâmetros no corpo da solicitação.media.playmedia.play é enviado quando o player faz a transição para o estado playing a partir de outro estado, como buffering, paused (quando retomado pelo usuário) ou error (quando recuperado), incluindo cenários como reprodução automática. Este evento é disparado pelo retorno de chamada on('Playing') do player.media.sessionCompletemedia.sessionEndmedia.sessionEnd notifica o back-end do Media Analytics para fechar imediatamente uma sessão quando um usuário abandona a visualização e é improvável que retorne. Se esse evento não for enviado, a sessão expirará após 10 minutos de inatividade ou 30 minutos sem movimento do indicador de reprodução. Quaisquer chamadas de mídia subsequentes com essa ID de sessão serão ignoradas.media.sessionStartmedia.sessionStart é enviado com a chamada de iniciação de sessão. Ao receber uma resposta, a ID da sessão é extraída do cabeçalho Localização e usada para todas as chamadas de evento subsequentes para o servidor de coleta.media.statesUpdatestatesUpdate ocorreu. Os recursos de rastreamento do estado do player podem ser anexados a um fluxo de áudio ou vídeo. Os estados padrão são: fullscreen, mute, closedCaptioning, pictureInPicture e inFocus.opportunityEvent.addToOpportunityopportunityEvent.opportunityUpdatedopportunityEvent.removeFromOpportunitypersonalization.requestdecisioning.propositionFetch.pushTracking.applicationOpenedpushTracking.customActionweb.formFilledOutweb.webinteraction.linkClicksweb.webpagedetails.pageViewslocation.entrylocation.exitValores sugeridos para producedBy producedBy
A tabela a seguir descreve alguns valores aceitos para producedBy:
selfsystemsalesRefcustomerRep