AgnosticData Paper & Docs

AgnosticData nasceu de uma abordagem de Gestão de Produtos chamada PEP (proposta de evolução de produto) do framework de produtos digitais Bolero.Digital. Inicialmente visava-se demonstrar um modelo agnóstico e abstrato para implementação de ferramentas de melhoria de funil como Google Analytics e/ou Facebook (Meta) Pixel.

Na ocasião percebeu-se que precisávamos endereçar as seguintes necessidades de negócio:

1. criar eventos personalizados com padronização de nomenclatura independente da plataforma de ads
2. obter eventos analíticos em tempo real e sem atrasos
3. acelerar a adoção do uso de dados para decisões de negócio eliminando múltiplas implementações de códigos
4. controlar o compartilhamento de informações dos usuários com terceiros e protegê-los

Panorama atual

A análise de dados em tempo real tornou-se um componente crítico para o sucesso das empresas em diversos setores, à medida que o volume de dados gerados e coletados continua a crescer exponencialmente, as organizações buscam soluções eficientes e escaláveis para extrair insights valiosos e tomar decisões informadas em tempo hábil.

No mercado atual (exterior), existem algumas soluções de análise de dados baseado em eventos em tempo real disponíveis, que variam em termos de complexidade, recursos e escalabilidade. Essas soluções também hospedam os dados em seus próprios servidores e possuem suas próprias formas de visualização desses dados. Nossa proposta visa convergir eventos de múltiplos provedores em um único local para a prática de análise de dados e insights em tempo real, combinando-os em uma plataforma leve, rápida e fácil de usar.

Ao adotar uma abordagem agnóstica, de código aberto e oferecer a opção de hospedagem de toda a solução in-house, além da autonomia para escolher as arquiteturas como Kafka ou Pub/Sub, BigQuery ou PostgresSQL ou Oracle (dentre outras), a solução visa atender às crescentes demandas de segurança, privacidade e conformidade, ao mesmo tempo em que proporciona uma maior flexibilidade e controle para as organizações.

Problema 1: Indisponibilidade ou baixo nível de garantia de tempo real

Devido ao vasto volume de dados de eventos recebidos por soluções como Google Analytics ou Meta Pixel e por não ter uma infraestrutura dedicada ao seu negócio exigindo competição de recursos, latência e processamento, a disponibilidade dos dados nessas ferramentas podem ter um atraso de até 24 horas.

Problema 2: Falta de proteção de dados e tracking

As bibliotecas de soluções de eventos, principalmente para marketing, fazem o rastreamento de usuários e não usuários dos seus serviços, utilizando técnicas como "digital fingerprinting" ou "browser fingerprinting" que podem implicar em violação de privacidade, publicidade direcionada e rastreamento intrusivo.

Problema 3: Dependência de armazenamento e visualização

Os eventos são armazenados nos servidores da empresa controladora dos dados, o Google Analytics e Meta Pixel, armazenam os dados em seus próprios servidores e oferecem acesso por meio de suas próprias e limitadas interfaces. A visualização dos dados é limitada aos painéis e relatórios disponíveis desses provedores.

Arquitetura e Tecnologia

Arquitetura em micro componentes permite a flexibilidade de implementação da solução. É composta por bibliotecas de captura de eventos (quando aplicável), o barramento de eventos (Event Bus), a camada de ligação (Linkage Layer) entre eventos personalizados e os destinos, a camada decisão (Open Decisions Layer) e a lógica de destinos (Target Layer ou Storage Layer) para onde os dados devem ser enviados.

Descrição dos componentes principais e as funcionalidades:

• Event bus: Pub/Sub que recebe diretamente os eventos onde um ou mais subscriber(s) são acionados.
• AgnosticData: orquestra as decisões, integrações, distribuição dos dados e armazenamento.
• Open Decision Layer: camada de decisão para restringir ou permitir para onde os dados irão na próxima fase da jornada.
• Linkage Layer: ligação entre os campos dos eventos personalizados e os campos padronizados de terceiros (de/para).
• Target Layer: contém os campos padronizados de terceiros.
• Storage Layer: armazena os eventos para um data warehouse.
• Data Visualization: camada que permite conectar visualizadores ou ferramentas de dashboard nativos a SQL.
• ETL Reverso: acesso para extrair dados estruturados para outras soluções.
• Automator RPA (desenvolvimento): camada de execução de ações programadas de acordo com regras de negócio sobre os dados.
• Payload Creator: Ferramenta web (no-code) para receber uma "tripa de dados" (ex.: csv, JSON) e convertê-la em um evento agnóstico.
• Payload Translator Endpoint: Recebe a tradução do creator e implementa um endpoint que se conecta a infraestrutura do AgnosticData.

É agonóstico porque o envio pode ser realizado sem bibliotecas complexas

Apenas um JSON! Os desenvolvedores não precisam estudar uma nova tecnologia, um novo SDK ou implementar uma lib desconhecida em suas soluções. Recomendamos a implementação dos próprios lançadores de eventos para garantir apenas as informações necessárias do negócio para o desempenho das atividades e com o rigor da proteção de dados (LGPD / GPDR).

Incentivamos produtores a desenvolver suas próprias bibliotecas de forma ilimitada. A seguir o envio de um simples evento baseado em objetos ou JSON.

curl -X POST https://eventbus.customer.com/v1/topics/${TOPIC_NAME} \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d {...contextFields, "content_name":"Minha home page", "content_type": "MY_PAGE_CODE_10"}

Casos de negócios

Antes de começar a se aprofundar na implementação da AgnosticData é importante entender a inteligência e o poder gerado ao negócio com dados em tempo real com casos de negócios reais.

Caso 1: Importância para o Marketing - Desafio para capturar insights de dados de Marketing

Thiago Gomes, Head de Marketing da Lovyca, precisava fazer cálculos para compreender as informações de impressões de páginas e cliques das suas páginas de conversão, porém por mais que seja oferecidos muitos dados pelas soluções atualmente disponíveis ainda é difícil, complexo e demorado apurar e ter confiabilidade.

Com o AgnosticData foi possível correlacionar os dados de impressões e cliques apresentados por terceiros (GA) com o número de visualizações nas páginas e as conversões capturadas, extraídas e enviadas diretamente para seu repositório de dados (DW). Desta forma, Gomes consegue avaliar a efetividade da campanha e se as informações oferecidas pelo provedor são realmente confiáveis.

Thiago, também pôde escolher como destino a sua tabela de KPIs e integrou diretamente os eventos em tempo real aos KPIs de negócio, sem precisar calcular e inserir dados manualmente.

Caso 2: Importância para o Product Manager - Desafio de múltiplas implementações para capturar comportamentos

Como gerente de produtos é difícil capturar o comportamento do usuário e mensurar quais funcionalidades são mais utilizadas. Diante dessas necessidades muitos gerentes de produtos têm que lidar com ferramentas como Google Analytics, Meta Pixel, HotJar, UXCam, MixPanel, Pendo, Amplitude, dentre outras para compor o conjunto de informações necessárias para a tomada de decisão, juntamente com a gestão visual disso tudo. Esse problema provoca desgaste mental com inúmeras trocas de contexto, causando estresse e improdutividade.

O AgnosticData ajuda os gerentes de produtos dando liberdade para criar os próprios eventos e obter automaticamente a documentação sobre seus payloads recém criados para facilitar a tradução de demanda para o time técnico (busines rules translator). Além disso, a solução entrega de forma instantânea os eventos antes mesmo de chegar nessas ferramentas, dando informação em tempo real para a tomada de decisão e a liberdade para construir dashboard de forma autônoma sem depender de profissionais especializados para criar essas visualizações.

Agora, com apenas uma solução é possível solicitar eventos via benchmarking, dado que o gerente produto enxerga um ótimo evento em alguma ferramenta basta criá-lo e liberar no AgnosticData em minutos.

Caso 3: Customer Success - Desafio para enxergar a intenção de compra e a dificuldade de uso

Gabriela, é a Customer Success responsável por garantir que os clientes de sua plataforma estejam satisfeitos com o produto e obtenham o máximo de valor dele. No entanto, enfrentava um desafio significativo: ela não tem acesso a dados detalhados sobre como os usuários estão interagindo com o aplicativo e perdem visibilidade para:

• Identificação de problemas
• Personalização do atendimento
• Monitoramento de engajamento
• Otimização de recursos de suporte

Sem informações detalhadas sobre o comportamento no aplicativo, lutava para identificar a causa do problema e fornecer suporte direcionado. Além disso, não conseguia identificar quais clientes estavam usando o aplicativo de maneira eficaz e quais poderiam estar em risco de cancelar a assinatura de um serviço.

A implementação da ferramenta de eventos em tempo real transformou a experiência dos clientes, melhorando significativamente a satisfação e retenção. Além disso, também ajudou a empresa a identificar áreas de melhoria no aplicativo e a impulsionar o crescimento das receitas com oportunidades de upsell e cross-sell.

Pesquisa, desenvolvimento e referências

As ferramentas de funil compreendem uma jornada de um futuro usuário-cliente. asa Essa jornada começa ainda quando ele tem o status de prospect (alvo) [geralmente um tarefa de marketing], passando para lead [quando executou uma ação esperada ainda fora do produto/aplicativo] até tornar-se usuário ou cliente (customer) [realizar um signup, por exemplo].

Os motivos iniciais para esse setup foram:

1. Melhoria da performance de campanhas. Retroalimentadas para supervisionar as melhores campanhas e otimizá-las (demográfico, geográfico, interesses, etc).
2. Identificar fluxos de conversões ou funil. Na perspectiva do produto é necessário identificar os caminhos e ações executadas para uma conversão [ponto crítico de sucesso].

No primeiro momento foi identificado quais ferramentas iríamos utilizar sendo praticamente uma regra o uso de Google Analytics (GA) e Facebook (Meta). Para entender como poderíamos fazer uso de um política de nomes de eventos padronizados decidimos estudar ambas as plataformas e correlacionar esses eventos caso as informações fossem comuns.

A abordagem geral adotada

1. compreender os eventos (ou parâmetros) de cada plataforma GA e Meta
2. identificar em qual tela, evento, situação devem ocorrer os eventos no seu app/produto
3. compreender o setup na tecnologia utilizada no app/produto (plataforma, linguagem, integrações, o meio)
4. buscar uma documentação oficial passível de compreensão (reference API)
5. identificar os eventos padronizados
6. identificar a possibilidade de personalização

Principais links relacionados aos tópicos abordados

A construção do AgnosticData envolveu a pesquisa e desenvolvimento nas tecnologias disponíveis para encontrar e construir uma solução agnóstica de eventos e dados de forma a padronizar nomenclatura de eventos personalizados e convergir os dados em um único local com o intuito de gerar mais inteligência e permitir aplicar conceitos de escalabilidade (crescer 10x mais).

Mais que criar um lago de dados, o objetivo do AgnosticData, nasceu para criar um data warehouse em tempo real com a capacidade de receber eventos de múltiplas plataformas. A seguir alguns links estudos no processo de pesquisa e desenvolvimento:

Setup na tecnologia

• Eventos Analytics + Firebase
• Eventos da Biblioteca do GA no Flutter
• Eventos Facebook para plataformas Web, iOs e Android (para cada plataforma Web, iOS, Android)
• Esquema de dados dos campos exportados do GA para BigQuery: Campos exportados do GA para o BigQuery
• Modelo de eventos do Algolia: Algolia
• Motivações para envio de eventos no Algolia

Eventos padronizados

• Facebook:

  • Eventos padrão
  • Eventos de conversão
  • Especificação para eventos Padrão do Meta Pixel
  • Parâmetros Facebook
  • Central de ajudas
  • Payload helper Facebook

• Google:

  • Recomendados do Google
  • Automaticamente coletados GA
  • Dados Google Analytics

Eventos personalizados

• Melhores práticas
• Melhores práticas para conversão personalizada

Outras ideias de eventos avaliados

• Ideias de evento da UXCAM
• ServiceNow Event collection
• ServiceNow pushing events

Problemáticas e questões importantes

Você pode se perguntar porque desenvolver uma solução como essa se temos tantas soluções disponíveis para eventos?

É verdade que existem algumas soluções com foco em coleta de eventos, outras com foco em apresentação, mas não temos soluções preocupadas fim a fim com o impacto do negócio (seu lago de dados, vira um pântano). Isso porque somos profissionais de negócio, criadores de produtos, profissionais de marketing, gerente de produtos e estrategistas que nos juntamos a especialista em ETL, engenheiros de dados e especialistas em crescimento acelerado para desenvolver uma solução de classe mundial.

A AgnosticData foi pensada no ciclo de vida dos dados visando conectá-los a automações (macros, low-code, dentre outros) e KPIs de negócio para simplificar o acesso a decisões de negócio. Não é uma solução para apenas a resolução técnica de um problema de implementação, mas para conceder ao negócio habilidades, inteligência e rapidez na integração e disponibilização de informações de negócio em tempo real.

Alguns problemas se repetem na sua jornada de aprendizado sobre os dados, por exemplo:

• Diversos nomes diferentes de eventos para cada plataforma
• Contratar um time dedicado ou alocar recursos caríssimos para estruturar o ciclo de vida dos dados
• Múltiplas chamadas para múltiplos eventos em um única ação ou condição de negócio, afim de atualizar todas as ferramentas
• Excesso e/ou duplicação de chamadas no código para no mínimo duas plataformas de ads e mais ferramentas de suporte ao negócio
• Incapacidade de personalização de parâmetros coletados como campos específicos somente do seu negócio
• Dificuldade para identificar a plataforma do usuário facilmente (iOs, Android, Web)
• Limitação para identificar apropriadamente a versão do seu produto/aplicativo em uso durante o envio do dado
• Limitação e informação em tempo real para identificar o usuário da ação
• Criar seu próprio modelo de coleta como garantir que botões, páginas e similares já implementados e novos herdem e definam eventos padronizados