Show Menu
TÓPICOS×

Eventos acionadores

Processamento de eventos no JavaScript

Arquivo JavaScript

O pipeline usa uma função JavaScript para processar cada mensagem. Essa função é definida pelo usuário.
Está configurado na opção NmsPipeline_Config sob o atributo "JSConnector". Esse javascript é chamado toda vez que um evento é recebido. É executado pelo processo pipelined.
O arquivo JS de amostra é cus:triggers.js.

Função JavaScript

O Javascript pipelined deve ser iniciado com uma função específica.
Essa função é chamada uma vez para cada evento:
function processPipelineMessage(xmlTrigger) {}

Deveria voltar como
<undefined/>

Reinicie o pipelined após editar o JS.

Acionar formato de dados

Os dados trigger são passados à função JS. Está no formato XML.
  • O atributo @triggerId contém o nome do trigger.
  • O elemento enriquecimentos no formato JSON contém os dados gerados pelo Analytics e está anexado ao acionador.
  • @offset é o "ponteiro" para a mensagem. Indica a ordem da mensagem na fila.
  • **@partitio**n é um container de mensagens na fila. O deslocamento é relativo a uma partição.
    Há cerca de 15 partições na fila.
Exemplo:
<trigger offset="1500435" partition="4" triggerId="LogoUpload_1_Visits_from_specific_Channel_or_ppp">
 <enrichments>{"analyticsHitSummary":{"dimensions":{" eVar01":{"type":"string","data":["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],"name":" eVar01","source":"session summary"}, "timeGMT":{"type":"int","data":[1469164186,1469164195],"name":"timeGMT","source":"session summary"}},"products":{}}}</enrichments>
 <aliases/>
 </trigger>

Formato dos dados de enriquecimento

É um exemplo específico de várias implementações possíveis.
O conteúdo é definido no Analytics para cada acionador. Está no formato JSON. Por exemplo, em um acionador LogoUpload_uploading_Visits:
  • eVar01 pode conter a ID do consumidor, utilizada para reconciliar com recipients do Campaign. Está no formato String.
    Deve ser reconciliado para localizar a ID do consumidor, que é a chave primária.
  • timeGMT pode conter a hora do acionador no lado do Analytics. Está no formato UTC Epoch (segundos desde 01/01/1970 UTC).
Exemplo:
{
 "analyticsHitSummary": {
 "dimensions": {
 "eVar01": {
 "type": "string",
 "data": ["PI4INE1ETDF6UK35GO13X7HO2ITLJHVH"],
 "name": " eVar01",
 "source": "session summary"
 },
 "timeGMT": {
 "type": "int",
 "data": [1469164186, 1469164195],
 "name": "timeGMT",
 "source": "session summary"
 }
 },
 "products": {}
 }
 }

Ordem de processamento dos eventos

Os eventos são processados um de cada vez, por ordem de deslocamento. Cada thread do pipelined processa uma partição diferente.
O "deslocamento" do último evento recuperado é armazenado no banco de dados. Portanto, se o processo for interrompido, será reiniciado a partir da última mensagem. Esses dados são armazenados no schema incorporado xtk:pipelineOffset.
Esse ponteiro é específico para cada instância e para cada consumidor. Portanto, quando muitas instâncias acessam o mesmo pipeline com consumidores diferentes, cada um recebe todas as mensagens na mesma ordem.
O parâmetro "consumidor" da opção de pipeline identifica a instância de chamada.
Atualmente, não há como ter filas diferentes para ambientes separados, como "preparo" ou "dev".

Registro e tratamento de erros

Registros como logInfo() são direcionados ao log de pipelined. Erros como logError() são gravados no log de pipelined e fazem com que o evento seja colocado em uma fila de tentativas. Verifique o log de pipeline. Mensagens com erro são repetidas várias vezes na duração definida nas opções de pipelined.
Para fins de depuração e monitoramento, os dados completos do acionador são gravados na tabela do acionador. Eles ficam no campo "dados" no formato XML. Como alternativa, um logInfo() contendo os dados do acionador tem a mesma finalidade.

Análise dos dados

Este exemplo de código JS analisa a eVar01 nos enriquecimentos.
function processPipelineMessage(xmlTrigger)
 {
 (…)
 var shopper_id = ""
 if (xmlTrigger.enrichments.length() > 0)
 {
 if (xmlTrigger.enrichments.toString().match(/eVar01/) != undefined)
 {
 var enrichments = JSON.parse(xmlTrigger.enrichments.toString())
 shopper_id = enrichments.analyticsHitSummary.dimensions. eVar01.data[0]
 }
 }
 (…)
 }

Tenha cuidado ao analisar para evitar erros. Como esse código é usado para todos os acionadores, a maioria dos dados não é exigida. Portanto, pode ser deixado em branco quando não estiver presente.

Armazenar o acionador

É um exemplo específico de várias implementações possíveis.
Este exemplo de código JS salva o acionador no banco de dados.
function processPipelineMessage(xmlTrigger)
 {
 (…)
 var event = 
 <pipelineEvent
 xtkschema = "cus:pipelineEvent"
 _operation = "insert"
 created = {timeNow}
 lastModified = {timeNow}
 triggerType = {triggerType}
 timeGMT = {timeGMT}
 shopper_id = {shopper_id}
 data = {xmlTrigger.toXMLString()}
 />
 xtk.session.Write(event)
 return <undef/>; 
 }

Restrições

O desempenho deste código deve ser ideal, pois ele é executado em altas frequências. Existem possíveis efeitos negativos para outras atividades de marketing. Especialmente com o processamento de mais de um milhão de eventos acionadores por hora no servidor de marketing. Ou se não estiver ajustado corretamente.
O contexto deste Javascript é limitado. Nem todas as funções da API estão disponíveis. Por exemplo, getOption() ou getCurrentdate() não funcionam.
Para permitir um processamento mais rápido, vários threads desse script são executados ao mesmo tempo. O código deve ser seguro para thread.

Armazenar os eventos

É um exemplo específico de várias implementações possíveis.

Schema do evento pipeline

Eventos são armazenados em uma tabela de banco de dados. Ele é usado pelas campanhas de marketing para clientes do público-alvo e enriquece emails usando acionadores. Embora cada acionador possa ter uma estrutura de dados distinta, todos os acionadores podem ser mantidos em uma única tabela. O campo triggerType identifica o acionador a partir do qual os dados são originados.
Este é um exemplo de código de schema para esta tabela:
Atributo
Tipo
Rótulo
Descrição
pipelineEventId
Longo
Chave primária
A chave primária interna do acionador.
dados
Memorando
Dados do acionador
O conteúdo completo dos dados do acionador em formato XML. Para fins de depuração e auditoria.
triggerType
String 50
TriggerType
O nome do acionador. Identifica o comportamento do cliente no site.
shopper_id
String 32
shopper_id
O identificador interno do comprador. Definido pelo workflow de reconciliação. Se for zero, significa que o cliente é desconhecido no Campaign.
shopper_key
Longo
shopper_key
O identificador externo do comprador foi capturado pelo Analytics.
criado
Data e hora
Criado
A hora em que o evento foi criado no Campaign.
lastModified
Data e hora
Última modificação
A última vez que o evento foi modificado na Adobe.
timeGMT
Data e hora
Carimbo de data e hora
A hora em que o evento foi gerado no Analytics.

Exibição de eventos

Os eventos podem ser exibidos com um formulário simples baseado no schema de eventos.
O nó do evento pipeline não está incorporado e precisa ser adicionado, assim como o formulário relacionado precisa ser criado no Campaign. Essas operações são restritas unicamente a usuários especialistas. Para obter mais informações, consulte as seções: Hierarquia de navegação e Edição de formulários .

Processamento de eventos

Workflow de reconciliação

A reconciliação é o processo que faz a correspondência do cliente do Analytics ao banco de dados do Campaign. Por exemplo, os critérios de correspondência podem ser o shopper_id.
Por motivos de desempenho, a correspondência deve ser feita no modo de lote por um workflow. A frequência deve ser definida como 15 minutos para otimizar a carga de trabalho. Como consequência, o atraso entre uma recepção de evento e seu processamento por um workflow de marketing é de até 15 minutos.

Opções de reconciliação de unidade em JavaScript

Em teoria, é possível executar o query de reconciliação para cada acionador no JavaScript. Ele tem um impacto maior no desempenho e oferece resultados mais rápidos. Pode ser necessário para casos específicos de utilização quando for necessária reatividade.
Pode ser difícil fazer isso se nenhum índice estiver definido em shopper_id. Se os critérios estiverem em um servidor de banco de dados separado do servidor de marketing, será usado um link de banco de dados com desempenho inadequado.

Limpar workflow

Os acionadores são processados dentro de uma hora, portanto não há razão para mantê-los por um longo tempo. O volume pode ser de aproximadamente 1 milhão de acionadores por hora. Isso explica por que um workflow de limpeza deve ser implementado. A limpeza exclui todos os acionadores com mais de três dias e é executada uma vez por dia.

Workflow de campanha

O workflow de campanha do acionador geralmente é semelhante a outras campanhas recorrentes já usadas. Por exemplo, pode iniciar com um query nos acionadores que procuram eventos específicos durante o último dia. Esse público-alvo é usado para enviar o email. Enriquecimentos ou dados podem vir do acionador. Pode ser usado com segurança pelo Marketing, pois não requer configuração.