Criando um modelo de dados baseado em eventos para analisar dados on-line

Introdução

Se você estiver muito interessado neste tópico, provavelmente é porque você é experiente o suficiente para entender que coletar e analisar eventos é sua autoestrada da informação para entender como seus usuários interagem com a sua aplicação. Mas vamos voltar por um segundo e fazer a pergunta a qual essa ideia se baseia: Porque coletamos eventos em primeiro lugar?

As iterações passadas de profissionais de BI teriam inferido bastante das informações demográficas e psicográficas coletadas sobre seus usuários em vários estágios do processo de compra. É fácil dizer que as pessoas dos Estados Unidos tendem a comprar mais do que em outros países e que as pessoas mais jovens tendem a ter maior propensão a fazer compras on-line.

Contudo dados demográficos e psicográficos não dizem tudo. Estudos mostram que dados comportamentais sobre os usuários são surpreendentemente melhores para prever coisas como compras, atualizações e "churn".

Na Cooladata, seguimos o ditado do nosso fundador, Tomer Ben Moshe:

“Você é definido pelo que faz, não quem você é”.

Essa filosofia não apenas une nossa empresa, mas permeia nosso produto e orienta todas as decisões que tomamos. O Cooladata é um sistema completo e projetado para permitir uma rápida análise e compreensão do comportamento do usuário.

Neste universo do comportamento do usuário, os eventos são os átomos. Quando um usuário realiza algum tipo de ação mensurável em seu website, em seu aplicativo ou em um de seus canais digitais essa ação é registrada como um evento.

Definição Geral

Os dados on-line provenientes do seu site, dispositivos móveis ou IOT são baseados em eventos em que cada evento tem suas próprias propriedades, por exemplo:

Modelagem de dados de evento é o processo de usar lógica de negócios para armazenar dados em nível de evento para produzir dados que são “analisáveis”, que é simples de consultar e entender o comportamento do usuário.

Um modelo de dados baseado em evento normalmente tem 3 níveis hierárquicos principais.

• Usuário

• Sessão

• Evento

Usuário

A entidade usuário conterá atributos específicos sobre o usuário como por exemplo:

• Email

• CEP

• Celular

• e outros atributos

Sessão

A entidade sessão conterá atributos específicos sobre a sessão como por exemplo:

• Browser

• Dispositivo

• Pais (IP)

• Fonte de referência, etc..

Evento

A entidade evento conterá atributos específicos sobre o evento como por exemplo:

• O evento de Login : ID de usuário, landing page, fonte de referência

• O evento adicionar item: Produto , Preço , Cor , Tamanho etc..

• O evento de checkout : Preço Total, Desconto, Opções de envio, etc.

O Desafio

Os modelos de dados tradicionais de BI, como o esquema em estrela ou o floco de neve, contêm tabelas de fatos e dimensões com uma estrutura fixa. Isso é eficiente e fácil de usar para analisar dados, mas funciona somente em dados estruturados e o esquema não muda muito. Um modelo de dados baseado em eventos é baseado em dados estruturados e semi-estruturados, por exemplo:

• URL- contem vários atributos em uma linha c (página , título , campanha etc..)

• DUA - agente do dispositivo do usuário contém muitos atributos sobre a sessão, como dispositivo, navegador, sistema operacional, localização etc.

• Tipo de evento: cada tipo de evento tem um esquema diferente uma vez que é baseado em atributos totalmente diferentes, tornando quase impossível usar modelos tradicionais de dados de BI

A estrutura de dados do evento também tende a mudar com muita frequência. Isso significa que você teria que adicionar campos e tabelas quase diariamente. As estruturas de dados tendem a mudar rapidamente devido à natureza em rápida evolução das empresas hoje (contra 20 anos atrás). Com uma nova funcionalidade no produto, uma nova ferramenta ou uma nova versão, você precisará de um modelo de dados baseado em eventos que seja flexível, escalável e possa incorporar facilmente novos eventos. Modelos rígidos como o "snowflake" ou o esquema estrela simplesmente não são bons para se adaptar à natureza em rápida mudança dos negócios do século XXI. Existem várias maneiras de criar modelos de dados de eventos. Abaixo, listamos os 3 mais populares, bem como nossa própria versão. Antes de começarmos, vamos analisar algumas das considerações mais importantes para um modelo de dados de evento.

Considerações para um modelo de dados de evento:

1. Fácil de usar - Quão fácil é analisar dados usando SQL?

2. Desempenho - Minimize os "joins" e as varreduras completas;

3. Preço - Você deseja usar clusters Redshift mais baratos ou reduzir os custos do BigQuery?

4. Fácil de popular - Quão fácil é carregar dados no modelo? - Carga completa, carga incremental e atualização de dados.

Agora vamos dar uma olhada mais de perto em algumas de suas opções.

Opção 1 - Uma tabela para cada tipo de evento + uma tabela de atributos comum

• Uma tabela de fatos para cada tipo de evento

• Cada tabela de tipo de evento contem campos específicos para o atributo de evento

• Uma tabela com "todos os eventos" para todos os tipos de eventos com campos para atributos comuns:

Prós

• Bom desempenho para consultas comportamentais específicas.

Por exemplo, a análise de funil fará "join" entre as tabelas de tipos de evento, que é muito mais eficiente do que fazer "join" em todos os eventos usando subconsulta para cada tipo de evento.

• Otimizar para analisar o tipo de evento específico

Por exemplo: Analisar o tipo de evento “instalar” na tabela de instalação será muito mais eficiente do que fazer isso em toda a tabela de eventos. Exemplo: A análise do evento "registrar" acessa apenas a tabela de registro.

• Você ainda pode analisar todos os eventos com atributos comuns usando a tabela de fatos "Todos os eventos".

Contras

• Difícil de gerenciar, especialmente em ambiente dinâmico. Sempre que adicionar um tipo de evento, você precisa adicionar uma tabela refletindo o ETL, metadados e monitoramento

• Cada tipo de evento requer uma nova tabela. Mesmo que esse tipo de evento seja raramente usado, você precisará manter uma tabela para cada tipo de evento, mas quando você tem centenas de tipos de eventos isso se torna impossível de gerenciar.

• Por ter uma tabela "todos_eventos" e uma tabela "tipo_evento", você está replicando dados. Isso dá muito mais trabalho e pode facilmente perder a sincronização resultando em problemas de qualidade de dados.

Opção 2 - Uma tabela de eventos comuns + campo json para atributos customizados

• Uma única tabela de evento

• A tabela contém os atributos comuns como campos

• Atributos customizados são armazenados como um campo json

Json:

Prós

• Mais fácil de gerenciar do que uma tabela para cada evento - Novos atributos são adicionados ao campo json. Não é necessário gerenciar muitas tabelas tipo_evento

• Fácil de analisar atributos de eventos comuns como por exemplo, "timestamp" de eventos, id de usuário, de sessão, etc.

• Você pode armazenar dados do usuário e da sessão na tabela de eventos (isso é chamado de "smearing" e ajuda a gerenciar as dimensões que mudam lentamente).

Contras

• Difícil de analisar os atributos personalizados, você precisa extrair o atributo personalizado do campo json em cada consulta impactando o desempenho

• Custoso - Por exemplo, selecionar no Google BigQuery uma pequena quantidade de dados de um objeto JSON maior é mais caro, pois o preço do BigQuery é baseado no tamanho da verificação (bytes processados)

• Difícil mapear os metadados e usar ferramentas de BI para os atributos personalizados, já que os dados podem estar em uma cadeia json aninhada

Opção 3 - Um modelo de dados de tabela aninhada

• Uma única tabela de fatos para todos os eventos

• Atributos comuns na mesma hierarquia

• Atributos personalizados na hierarquia aninhada

• Você pode criar hierarquias para dados de usuários e sessão

Exemplo

Prós

• Elegante e fácil de entender o modo como os dados são armazenados.

• Flexível em atributos para cada hierarquia.

• Bom desempenho para determinadas consultas, como contagem distinta.

• Certas consultas como as de contagem distinta analisam menos dados

• Todo o dado está contido em uma única tabela reduzindo a necessidade de "joins" entre tabelas

Contras

• Os dados aninhados tornam-se difíceis de consultar

• Difícil de carregar dados nas tabelas - especialmente dados incrementais.

• Difícil mapear os metadados e usar ferramentas de BI sobre um modelo de dados aninhados. As colunas que contêm dados aninhados exigem esquemas razoavelmente complexos definidos para considerar possíveis eventos JSON autoexplicativos que possam ocorrer nessas colunas.

• É quase impossível atualizar dados

A Opção da Cooladata:

• Uma única tabela de evento

• Existe uma opção para armazenar tipos de eventos específicos em diferentes tabelas, por exemplo, tipos de eventos populares, como "visualizações de páginas", podem ser armazenados em uma tabela separada e os tipos de eventos restantes podem ser armazenados em uma única tabela.

• A tabela contem os atributos comuns e customizados como campos

• A tabela tem dados de usuário & sessão para cada linha de evento (Smearing)

Prós

• Fácil de entender o modo como os dados são armazenados.

• Ao armazenar tipos de eventos populares em tabelas separadas, você obtém o desempenho de custo ótimo.

• Todo o carregamento dos dados é controlado pela Cooladata.

• Você é capaz de analisar os dados com muita facilidade

• Você tem acesso fácil a mudanças históricas (dimensão de alteração lenta).

• You have easy access to historical changes (slowly changing dimension).\

Contras

• Para um ótimo desempenho você precisa usar o CQL (Cooladat SQL)

• O gerenciamento de dados é via Cooladata

Recursos adicionais do Cooladata

Esquema físico

Nós particionamos os dados por tempo e propriedade como geografia do tipo de evento, etc. para obter o máximo desempenho e otimizar o acesso aos dados.

Armazenamos os dados em um banco de dados analítico colunar esparso, obtendo flexibilidade e desempenho.

Camada semântica/ Metadados

Criamos automaticamente a camada semântica e os metadados a partir de dados on-line, bem como dados tradicionais

Camada de acesso a dados otimizada (Parser)

Nosso "parser" inteligente traduz instruções SQL simples para poder acessar partições relevantes

Extensões de série temporal comportamental (CQL)

Estendemos o SQL com mais funções, permitindo a análise de séries temporais sobre dados granulares

Nossa tecnologia exclusiva fornece esses recursos:

• Combine dados transações e on-line em um fluxo coerente.

• Flexibilidade de um esquema base de documento no modelo de dados.

• Análises de séries temporais e dimensionais abrangentes em um esquema.

• Capacidade de usar ferramentas comuns de visualização no modelo de dados.

• Unificação ad hoc de dados Online e tradicionais

• Otimize o custo dos dados por meio do particionamento inteligente.

• Rastreamento completo de mudanças de dados históricos (dimensões que mudam lentamente).

Sobre a Cooladata

O Cooladata é um data warehouse completo, baseado em nuvem e totalmente gerenciado, otimizado para análise comportamental e projetado para empresas com produtos digitais.

Ele auxilia as equipes de dados a unificar todos os seus dados em um único local, de forma que cada equipe em suas empresas possam obter as respostas necessárias, em segundos, não em horas ou dias.

Ele auxilia pequenas equipes de dados a fazer grandes coisas fornecendo-lhes todo o poder de um data warehouse sem as dores de cabeça e o custo de construir e manter um.

A Cooladata é apoiada pela 83 North / Greylock Israel, pela Carmel Ventures e pela Salesforce Ventures.

www.cooladata.com