Quais são os componentes dos dados de eventos?

Publicados: 2022-05-12

Esta é a quarta parte da série de cinco partes sobre Dados do Cliente. Aqui estão as partes um, dois e três.

Os Dados do Cliente compreendem os Dados do Evento e os Dados da Entidade — você já sabe disso se já passou pela primeira parte (O que são dados do cliente?).

Neste guia, você aprenderá sobre os componentes de dados de eventos, a convenção de nomenclatura preferida para definir eventos, as categorias de dados de entidade e os dois tipos principais de entidades.

Dados do evento

Como você provavelmente comprou coisas online, vamos começar com um exemplo de comércio eletrônico.

Ao interagir com um aplicativo de comércio eletrônico (web ou celular), você normalmente compra um produto adicionando-o ao carrinho, procedendo à finalização da compra e concluindo o pagamento — esses são eventos que você realiza quando passa pelo processo de compra de um item no a aplicação.

A jornada do comprador, no entanto, não é tão simples e existem vários outros eventos que podem ocorrer como:

Um produto é visualizado
O carrinho é visualizado
Um produto é removido do carrinho
Um cupom é aplicado
Um endereço é escolhido
Um método de pagamento é escolhido
Um pedido é concluído

E assim por diante.

Eventos comuns como Adicionar ao carrinho, Prosseguir para o checkout e Efetuar pagamento vêm à mente imediatamente, mas para entender o comportamento do usuário, também é necessário rastrear outros eventos como os mencionados acima.

Decidir quais eventos rastrear e nomear os eventos usando uma convenção de nomenclatura adequada são as duas primeiras etapas no processo de coleta de dados de eventos.

Quais são os próximos dois passos?

Que bom que você perguntou!

Cada evento é acompanhado por propriedades de evento (ou atributos de evento ) que fornecem mais contexto sobre um evento. Decidir quais propriedades associar a um evento e nomear essas propriedades são as próximas duas etapas no processo de coleta de dados do evento.

O que há em um nome?

Quando se trata de dados, tudo.

Uma convenção de nomenclatura ou taxonomia adequada é o que faz com que os dados bons se destaquem dos dados ruins e permite que as partes interessadas entendam o que estão vendo. Não manter uma taxonomia padronizada, por outro lado, é uma das principais causas dos conjuntos de dados serem distorcidos ou inchados com redundância.

Além disso, ao trabalhar com dados do cliente, não manter a uniformidade de maiúsculas e minúsculas ao nomear eventos e propriedades de eventos é um dos maiores erros que você pode cometer, que pode ter ramificações de longo prazo. Uma boa convenção de nomenclatura deve sempre ser acompanhada por diretrizes rígidas de maiúsculas e minúsculas.

Aqui está o porquê:

Adicionar ao carrinho, add_to_cart, productAdded, add to cart, Added to cart, Product Added são formas diferentes de definir o mesmo evento.

Embora nada disso esteja errado em si, e não existam regras definidas quando se trata de nomear eventos e propriedades, existem práticas recomendadas que devem ser consideradas.

A convenção de nomenclatura objeto-ação praticamente se tornou o padrão da indústria e por boas razões - ela descreve claramente a ação que já ocorreu. Produto adicionado definitivamente significa que um objeto (produto) é seguido por uma ação (adicionado).

Saiba mais sobre como configurar uma taxonomia consistente para seus eventos .

Componentes dos dados do evento

Há dois componentes principais de um evento — uma entidade (uma ou mais) e propriedades do evento.

Associar dados de entidade como user_id a um evento fornece informações sobre o usuário que executou o evento.

Na ausência de um identificador exclusivo como user_id , os dados do evento permanecerão anônimos e não haverá como saber quem executou esse evento. Da mesma forma, no contexto de B2B SaaS, onde um usuário pode potencialmente fazer parte de várias organizações, organization_id precisa estar associado a eventos para saber onde os eventos ocorrem.

Além das entidades, existem outras informações que podem ser coletadas para fins de análise e segmentação quando os eventos ocorrem.

Voltando ao exemplo do e-commerce, quando um produto é comprado, além de saber quem fez a compra, no mínimo, você também precisa saber qual produto foi comprado a que preço e quando .

Essas informações adicionais são reunidas na forma de propriedades do evento .

Na primeira parte desta série, foi mencionado que os dados de eventos compreendem três elementos principais:

A ação ou o evento que ocorreu
O carimbo de data/hora ou a data e hora precisas em que o evento ocorreu
O estado ou todas as outras propriedades associadas ao evento (conhecidas como propriedades do evento)

Vejamos o evento Product Added (o nome em Proper Case de acordo com a estrutura de ação de objeto para o evento Add to Cart ) e suponha que ele foi realizado por um usuário em 1º de janeiro de 2020, às 10h UTC. Os dados coletados quando o evento ocorreu incluem o seguinte:

A ação: Produto Adicionado
O carimbo de data/hora: 1577872800 (carimbo de data/hora Unix para ABZ 7.99 ( O estado: 0123 ABZ 7,99 ( De acordo com este exemplo, as propriedades associadas ao evento Product Added são user_id, product_id, price e amount , cada uma das quais fornece mais informações sobre o evento. O carimbo de data/hora está associado ao evento para saber quando ocorreu.
Também é útil especificar um nome para o carimbo de data/hora que é essencialmente uma propriedade de evento. Não é obrigatório fazer isso, pois a prática padrão é associar o timestamp como timestamp a cada evento ao enviar dados para ferramentas de terceiros; no entanto, especificar um nome distinto para a propriedade que armazena o registro de data e hora pode ser útil a longo prazo quando você precisar trabalhar com dados de eventos históricos.

A taxonomia recomendada para carimbos de data/hora é o nome do evento seguido por “at”: product_added_at para o evento Product Added.
Você já deve ter notado que snake_case está sendo usado para definir propriedades de eventos, o que facilita a distinção entre nomes de eventos e propriedades de eventos. Dito isso, lembre-se de que não há regras predefinidas aqui e você deve escolher o que funcionar melhor para você e sua equipe.
Aqui está uma visão final das propriedades associadas ao evento Produto Adicionado e os tipos de dados de cada uma dessas propriedades:
Especificar o tipo de dados para cada propriedade garante a consistência dos dados e facilita o processo de instrumentação.

Nota lateral: É bom ter em mente que Agora deve ficar claro que a coleta de dados de eventos compreende as seguintes etapas:
Decidindo quais eventos rastrear
Nomear esses eventos usando uma convenção de nomenclatura adequada
Decidindo quais propriedades associar a cada evento
Nomeando essas propriedades usando uma convenção de nomenclatura adequada
A próxima (e última) parte desta série cobre o processo de decidir quais eventos rastrear e quais dados coletar.
No entanto, você deve ter uma boa ideia do que esperar ao analisar os dados do evento (seja em um plano de rastreamento antes da instrumentação ou dentro de um destino de dados, como sua ferramenta de análise de produto).

Alguns eventos comuns e suas propriedades
Antes de prosseguir, dê uma olhada em alguns eventos e propriedades comuns que são rastreados pela maioria dos produtos de tecnologia.
Tipos de entidade
É hora de examinar detalhadamente as diferentes entidades e suas propriedades. Se ainda não o fez, consulte este guia para entender como os dados da entidade se relacionam com os dados do evento.
Na primeira parte desta série, foi mencionado que os dados compartilhados pelos usuários se enquadram nos dados da entidade. Embora isso seja verdade, nem todos os dados da entidade são compartilhados pelos próprios usuários – os dados da entidade também podem ser gerados.

Os dados da entidade compreendem as propriedades associadas à entidade—se User for a entidade, todas as informações sobre um usuário são reunidas na forma de propriedades do usuário.
User_id é gerado para cada usuário por padrão para identificar usuários (e atua como um identificador para eventos).
Dito isto, por enquanto, esqueça os eventos e pense nas diferentes informações que se relacionam exclusivamente aos usuários e informam sobre suas características.
Tipos de dados da entidade
Os dados da entidade podem ser categorizados nos seguintes buckets (também mencionados na parte 3 desta série):
Informações de identificação pessoal , como Dados demográficos , como Persona como Preferências como Dados específicos do produto , como Os dados em cada bucket se enquadram nas propriedades do usuário. Em outras palavras, as propriedades do usuário armazenam vários detalhes e características sobre os usuários, permitindo que você os identifique e saiba mais sobre eles.
Embora a maioria das informações venha diretamente do usuário, certas propriedades do usuário são geradas automaticamente ao longo do tempo como resultado do uso do produto.
Mas os dados de eventos também não são gerados devido ao uso do produto?
Com certeza, as propriedades do usuário são detalhes adicionais relacionados a um evento reunido quando o evento ocorre. Vamos dar uma olhada no evento Signed Up e suas propriedades:
Como você pode ver, todas as propriedades associadas a este evento fornecem detalhes sobre os usuários — detalhes que são compartilhados pelos próprios usuários ( first_name, last_name, email, phone, country ) ou detalhes que são gerados automaticamente ( sign_up_at, user_id ).
É útil ter em mente o seguinte:
Alguns eventos como Signed Up ou A maioria das propriedades do usuário que excluem carimbos de data e hora e identificadores estão sujeitas a alterações. Um usuário pode alterar seu nome, e-mail, telefone, local, setor, função, etc. Mas o momento da inscrição (signed_up_at) ou o identificador exclusivo (user_id) não podem ser alterados pelo usuário.
Propriedades do usuário x propriedades da organização
Com aplicativos de consumo, tempo gasto, produtos comprados, músicas tocadas ou vídeos assistidos são propriedades associadas ao usuário armazenadas como propriedades do usuário, cujos valores são constantemente atualizados com o aumento do uso.
No contexto de B2B SaaS, Usuário e Organização são as principais entidades, e os eventos coletados estão vinculados a um usuário ou uma organização (ou ambos).
Pode haver outras entidades de grupo, como equipe ou projeto, com determinados dados vinculados a eles, como é o caso da maioria das ferramentas de produtividade - o processo de coleta de dados da organização também é aplicável nesses casos.
Vamos dar uma olhada em algumas propriedades de usuário comuns relevantes para produtos B2B SaaS:
Quando um usuário faz parte de uma organização , muitas informações importantes são vinculadas à organização e não ao usuário.
Algumas propriedades comuns da organização (também chamadas de propriedades de grupo ) são as seguintes:
É importante ter em mente que o organization_id também atua como um identificador e deve ser associado a eventos para saber em qual organização um determinado evento ocorreu.
Manter as seguintes declarações em mente pode ajudar a diferenciar entre propriedades do usuário e propriedades da organização:
Cada informação que ajuda a definir grupos de usuários – de onde eles vêm, quem são, qual é seu objetivo ou o que eles fazem dentro de um produto – é armazenada como propriedade do usuário .
Cada informação que ajuda a segmentar contas ou organizações — o tipo de conta, a receita que ela gera, os produtos ou recursos que usa, os recursos que consome ou o número de usuários que fazem parte dela — é armazenada como propriedade da organização ( ou propriedade do grupo).
Uma vez que você pode diferenciar entre os itens acima, fica fácil trazer novas entidades (como equipes ou projetos) para o mix.
Próximos passos
Agora você deve ter uma compreensão clara de como definir eventos e suas propriedades associadas, bem como especificar as propriedades de cada entidade (usuário e organização).
Para começar a definir eventos e organizar seus dados hoje, comece com uma conta gratuita do Amplitude.