Data Engineering

Desvendando o comportamento dos usuários: Como construimos produtos de maneira Data-Driven

Descubra como utilizamos a Snowplow, uma poderosa ferramenta de trackeamento de sites e aplicações, para entender o comportamento dos usuários aqui na Afya.

Você já se perguntou como os usuários interagem com o seu produto? Quais são as suas preferências, necessidades, dores e desejos? Como você pode melhorar a experiência do usuário e aumentar a sua retenção e conversão?

Essas são perguntas que todo time de produto ou negócio precisa responder para criar soluções que atendam às expectativas dos seus clientes. E para isso, é preciso ter dados. Muitos dados!

Mas não basta apenas coletar dados. É preciso transformá-los em insights. Insights que possam orientar as decisões estratégicas e as ações táticas do seu time através de uma análise de comportamento dos usuários de forma clara e precisa.

E é aí que entra a Snowplow, uma solução PaaS (Platform-as-service) que nós utilizamos aqui na Afya para mapear os dados comportamentais dos nossos usuários e como eles interagem com nossos sites e aplicações. Neste artigo, vamos explicar o que é o Snowplow, como capturamos os trackings e a arquitetura de dados implementada.

Mas o que é Snowplow?

Snowplow é uma plataforma cujo o objetivo é mapeamento de dados comportamentais de usuários em aplicações web ou navegação em sites web, feita para dar poder aos times de produtos. Lançado em 2012, o Snowplow começou como um projeto de código aberto para libertar os profissionais de dados das limitações das soluções proprietárias, que agem como “caixas-pretas” sem oferecer muita transparência ou controle sobre seus dados, como por exemplo a ferramenta que hoje é mais utilizada por várias empresas que é o Google Analytics. A plataforma opera com total conformidade às leis de privacidade de dados como o GDPR e o CCPA.

O Snowplow começou a ser utilizado aqui em 2019 pela antiga PEBMED, empresa que foi adquirida e integrada à Afya em 2020, sendo que uma das características mais importantes era a flexibilidade de personalizar seu pipeline de acordo com as suas necessidades e a liberdade de ser utilizado em qualquer nuvem, no nosso caso AWS.

Imagine que você quer saber o que os usuários fazem no seu produto digital. Você pode criar eventos para cada ação que eles realizam, como clicar em um botão, preencher um formulário ou assistir a um vídeo. Esses eventos são enviados para o Snowplow através de uma API, e depois o Snowplow cuida de organizar, limpar, validar e até enriquecer esses eventos, para então enviá-lo para um Data Warehouse, no nosso caso AWS Redshift.

Construção de produtos Data-Driven

Aqui na Afya temos vários produtos digitais como Iclinic, Medical Harbour, Glic dentre outros já citamos neste post. Neste tópico vamos focar no Whitebook, que é o produto que faz o maior uso do Snowplow na Afya. O Whitebook é um aplicativo de referência médica sendo um dos mais baixados nas principais lojas de aplicativos.

Porém antes de falarmos do ciclo de vida, queria reforçar que este processo só funciona quando existe comprometimento mútuo entre os times de Produtos, Tecnologia e Dados, que devem trabalhar em conjunto para definir objetivos, hipóteses, métricas, experimentos e ações. Cada time tem um papel fundamental nesse processo, contribuindo com suas habilidades, conhecimentos e perspectivas.

O que vejo aqui no Whitebook que faz funcionar essa abordagem Data-Driven, algo até então que não havia visto em outras empresas que passei, é que cada time sabe da importância dos outros dois times, e a construção deixa de ser cada um por si no seu departamento com cobranças distintas, e se torna uma corrida de revezamento no qual foco, as metas e os resultados são compartilhados entre todos.

Com isso em mente, criamos em conjunto um fluxo de trabalho para implementação de eventos que entro em mais detalhes abaixo:

1. Concepção de novos eventos

Quando o time de Produtos está em uma fase de ideação, no qual ainda não tem uma visão clara do que será desenvolvido ou qual hipótese será testada, os time de análise de dados e o time de tecnologia já são envolvidos. Ter esse contexto inicial é o diferencial que temos, afinal estar junto nessas discussões é o que servirá como base para saber quais (Dados) e como (Tecnologia) as informação serão coletas. O tipo de informação coletada varia muito de caso a caso, porém todos possuem um objetivo comum: Tomar decisões assertivas para o negócio.

Para cada cenários temos um fluxo de trabalho muito bem mapeado pelo time de ProductOps, como na figura abaixo:

Sendo: P — Produto, D — Desenvolvimento, A — Análise de Dados e E — Engenharia de Dados.

2. Implementação dos eventos

Um vez definidas as informações que serão capturadas, o time de desenvolvimento verifica se já existem schemas prontos para estes trackings dentro do Snowplow, ou será necessário criar ou adaptar um novo, que nesse caso será feito pelo time de engenharia de dados.

Para verificar os schemas que existem e quais as suas versões, nós utilizamos o Snowplow BDP, que é uma ferramenta que nos consegue dar estas informações de forma visual. Na página do Snowplow é possível verificar quais são os conceitos de eventos e entidades, que são os tipos de schemas que podemos ter.

Ao abrirmos algum schema, temos um JSON que não só nos informa quais serão os dados esperados, como já aplica conceitos muito atuais de Governança de Dados, como Contrato de Dados. Esses contratos definirão algo que chamamos de Good Data e Bad Data. Abaixo temos um exemplo deste JSON.

{
  "description": "Event describing an user login. Default value for data-time
                  is: Timezone UTC, format YY-MM-DDTHH:MM:SS.mmmZ",
  "properties": {
    "time": {
      "type": "string",
      "format": "date-time",
      "description": "Date and time when the login occurred, ISO formatted"
    }
  },
  "additionalProperties": false,
  "type": "object",
  "required": [
    "time"
  ],
  "self": {
    "vendor": "Whitebook",
    "name": "login",
    "format": "jsonschema",
    "version": "2-0-1"
  },
  "$schema": "http://<API>/schema/jsonschema/2-0-0#"
}

3. Captura, enriquecimento e disponibilização

Como citado anteriormente, os eventos são capturados através de chamadas de API que são inseridos dentro dos códigos de páginas web e aplicações. Esses requests também podem vir de aplicações terceiras, que enviam os eventos via webhook. Abaixo temos uma visão geral da arquitetura da solução.

Iglu Server

O Iglu Server é um repositório de esquemas que define a estrutura dos eventos que você deseja rastrear. Ele garante que todos os eventos sejam validados contra o esquema definido antes de serem processados. Lembra dos schemas que cadastramos no Snowplow BDP?

Stream Collector:

O Stream Collector é o responsável por receber os eventos de várias fontes, serializar estes eventos e então encaminhá-los para uma plataforma de processamento real-time. No nossa arquitetura são EC2 que ficam exposta através de um Elastic Load Balancer e então encaminham estes dados para o Kinesis.

Stream Enrichment

Depois que os eventos brutos são coletados, eles são enviados para o Stream Enrichment. Este componente valida, limpa e enriquece cada evento com informações adicionais (como dados geográficos, dados do usuário, etc.) antes de enviá-los para o próximo estágio.

Nesse etapa o Kinesis valida o evento recebido conforme cadastramos no Snowplow BDP, se inválido então é enviado para um bucket S3 de Bad Data, se atendeu as regras definidas será um Good Data e então será encaminhado para um cluster Spark no EMR que fará o enriquecimento destes eventos.

S3 Loader

Finalmente, o S3 Loader carrega os eventos enriquecidos em um bucket S3. Aqui, os dados estão prontos para serem analisados e usados para insights de negócios, pois já estarão disponíveis no Data Lake.

Existe também um processo chamado Shredder, que é executados várias vezes ao dia e é responsável por fazer o COPY destes arquivos para o nosso AWS Redshift.

Todo esse fluxo, deste a captura até a carga no Redshift é o PaaS no qual o Snowplow é responsável por administrar e dar suporte.

4. Validação e Observabilidade

Esta é a etapa onde fica a maior responsabilidade do time de engenharia de dados do Whitebook garantindo que tudo esteja ocorrendo conforme é esperado.

Como citando anteriormente, engenharia é o guardião dos Schemas, logo, somos responsáveis por validar junto com o time de tecnologia se os eventos estão chegando no data lake como esperado, além de tirar dúvidas relacionadas aos schemas. Para fazer essa validação, uma das principais ferramentas que utilizamos é o Kibana.

Porém existem casos no qual precisamos entender melhor o comportamento dos Bad Datas, para esses casos utilizamos o AWS Athena.

Já para observabilidade temos alguns dashboards construídos no Grafana com alertas integrados ao Slack. Nós monitoramos basicamente as EC2, o Kinesis, o Redshift e a qualidade dos dados. Por exemplo, um dos nossos principais alertas é relacionado a porcentagem de eventos que vão para a fila de Bad Data.

Uma vez esses dados no nosso Data Warehouse, o time de análise de dados que está mais próximo ao time de produtos consegue gerar insights, modelos e dashboards para que o time possa cada vez mais entregar valor aos nossos clientes, que são a parte mais importante deste fluxo.

Agradeço a sua atenção e espero que este artigo tenha contribuído para o seu conhecimento sobre o tema. Caso tenham alguma sugestão, crítica ou elogio, peço que entrem em contato comigo pelo LinkedIn.

Agora se você deseja fazer parte do maior ecossistema médico do país, com as mais avançadas tecnologias de dados e em um ambiente propício à inovação, vem pra Afya!