Como construímos uma arquitetura de dados para acompanhar um curso online latino-americano com GA4, Google Sheets, Apps Script, GitHub e Looker Studio

Acompanhar um curso online distribuído em vários países e idiomas parece, à primeira vista, um problema de dashboard.

Na prática, o dashboard é apenas a última camada.

No projeto do Curso PBL 2026 do Solve for Tomorrow Latam um cliente do portal Porvir.org, o desafio foi construir uma arquitetura capaz de acompanhar uma jornada que começa antes do curso, passa pela inscrição, distribuição de conteúdos via WhatsApp, consumo de páginas, vídeos e materiais, avança por módulos e termina nos formulários de conclusão.

O projeto atende uma operação latino-americana, com experiências em português e espanhol, e precisava responder perguntas que ferramentas isoladas não conseguiriam responder de maneira confiável.

Quantas pessoas se inscreveram?

De quais países vieram?

Quantas efetivamente começaram a consumir o curso?

Quais conteúdos foram acessados?

Qual foi a profundidade de leitura?

Houve interação com os vídeos?

Quantas pessoas avançaram da Parte 1 para a Parte 2?

Quantas concluíram cada módulo?

Qual é a diferença entre inscritos, cliques, usuários, sessões, visualizações e respostas?

E, principalmente, como automatizar tudo isso sem transformar uma planilha ou um dashboard em uma coleção de métricas metodologicamente incompatíveis?

A solução evoluiu para uma stack formada por Mailchimp, Google Analytics 4, Google Tag Manager, Bitly, Google Forms, Google Sheets, Google Apps Script, Google Cloud, GA4 Data API, GitHub, GitHub Actions e Looker Studio.

Este artigo apresenta a arquitetura técnica e o histórico dessa implementação. O objetivo não é apresentar ainda os resultados finais da ação. O curso continua em andamento e, depois de seu encerramento, os resultados consolidados serão objeto de um segundo conteúdo no formato de case.

O problema inicial: inscrições não eram suficientes

A primeira etapa do projeto começou de forma relativamente simples.

O Curso PBL 2026 possuía duas jornadas de inscrição, uma em português e outra em espanhol. As landing pages estavam hospedadas no Mailchimp e precisávamos acompanhar o volume de inscritos, sua evolução e sua distribuição geográfica.

Rapidamente ficou evidente que apenas contabilizar inscrições não seria suficiente.

Uma pessoa inscrita não é necessariamente uma pessoa que iniciou o curso.

Uma pessoa que abriu um link também não é necessariamente uma pessoa que consumiu um conteúdo.

Uma visualização não representa um usuário único.

Uma sessão não representa conclusão.

Um clique no Bitly não representa uma pessoa.

E a soma dos usuários de várias páginas não representa necessariamente o total de usuários de um módulo.

Essas distinções se tornaram fundamentais para a arquitetura.

O projeto deixou de ser apenas um relatório de inscrições e passou a ser um sistema de acompanhamento da jornada educacional.

Fase 1: automatizando as inscrições PT e ES

Na primeira fase, o Mailchimp funcionava como principal fonte operacional.

As inscrições em português e espanhol precisavam ser consolidadas diariamente sem depender de exportações manuais.

A integração foi construída utilizando a Mailchimp Marketing API, Google Apps Script e Google Sheets.

O Apps Script consulta a audiência e os segmentos correspondentes às inscrições PT e ES, normaliza os registros e atualiza diferentes camadas da planilha.

A estrutura foi organizada para produzir, entre outras informações:

• situação atual das inscrições;

• histórico diário;

• inscrições por país;

• inscrições brasileiras por estado.

Um ponto importante foi evitar que diferentes abas executassem consultas independentes e potencialmente inconsistentes ao Mailchimp.

A rotina passou a trabalhar com um snapshot estável da audiência. A mesma fotografia dos dados é utilizada para derivar os diferentes outputs daquela execução.

Isso reduz discrepâncias internas entre indicadores gerados em momentos ligeiramente diferentes.

Google Sheets como camada operacional, não como banco improvisado

O Google Sheets tem um papel importante no projeto, mas com limites bem definidos.

Ele funciona como uma camada operacional e de integração entre sistemas.

Não é utilizado como substituto indiscriminado de um banco de dados.

Na Fase 1, uma planilha concentra a consolidação das inscrições.

Na Fase 2, outra planilha técnica foi criada para organizar configurações, resultados das coletas, históricos e tabelas destinadas ao Looker Studio.

Entre as estruturas utilizadas estão configurações de módulos, conteúdos, calendário, métricas do Bitly, formulários, consumo do GA4, agregações por parte, módulo e curso, além de logs de execução.

Essa separação é importante porque dados de configuração e dados analíticos possuem funções diferentes.

Uma URL de conteúdo, por exemplo, pertence à configuração.

O número de usuários daquele conteúdo em determinado dia pertence à camada analítica.

Misturar os dois conceitos em uma única tabela dificultaria manutenção, testes e auditoria.

Da inscrição para o consumo real do curso

A segunda fase aumentou significativamente a complexidade do projeto.

O curso é organizado em cinco módulos. Cada módulo acontece durante duas semanas e é dividido em duas partes.

A distribuição dos conteúdos ocorre principalmente por WhatsApp, seguindo um calendário de mensagens.

O participante recebe materiais como páginas de leitura, vídeos, recursos complementares e PDFs. Ao final de cada módulo existe um formulário.

Isso criou uma hierarquia analítica que passou a orientar toda a implementação:

Curso > Módulo > Parte > Conteúdo

Essa hierarquia parece simples, mas resolve um dos maiores problemas desse tipo de relatório: a deduplicação de usuários.

Por que não podemos simplesmente somar usuários

Imagine que um módulo tenha três conteúdos.

Um participante acessa os três.

Nas análises individuais, ele será contabilizado como usuário de cada conteúdo.

Se somarmos:

Conteúdo A: 100 usuários

Conteúdo B: 80 usuários

Conteúdo C: 60 usuários

não podemos concluir que o módulo teve 240 usuários.

Parte desses usuários pode ser exatamente a mesma pessoa navegando pelos três conteúdos.

Por isso, a arquitetura não calcula usuários de módulo somando usuários de páginas.

O mesmo princípio vale para as partes.

Usuários da Parte 1 + usuários da Parte 2 não representam necessariamente usuários únicos do módulo.

E também vale para o curso.

Usuários do M1 + M2 + M3 + M4 + M5 não representam automaticamente usuários únicos do curso.

Esse foi um dos princípios metodológicos mais importantes de todo o projeto.

Google Tag Manager e GA4 como camada comportamental

O Google Analytics 4 passou a ser a principal fonte para observar o comportamento após a inscrição.

A implementação utiliza o Google Tag Manager para estruturar e validar eventos relevantes da experiência.

O GA4 registra métricas como:

• usuários;

• sessões;

• visualizações;

• tempo de engajamento;

• profundidade de rolagem;

• interação com vídeos;

• acesso aos conteúdos.

Também trabalhamos com UTMs para preservar o contexto de distribuição.

A estrutura utiliza parâmetros como:

utm_source

utm_medium

utm_campaign

utm_term

utm_content

utm_id

O utm_content identifica a mensagem da jornada, enquanto o utm_id ajuda a identificar o ativo ou conteúdo relacionado.

Isso permite relacionar a distribuição do curso com os conteúdos posteriormente consumidos.

O cuidado com a persistência das UTMs

Durante a implementação apareceu um problema técnico importante.

A atribuição de sessão do GA4 pode persistir enquanto o usuário navega por outras páginas.

Isso significa que filtrar somente uma determinada sessionManualAdContent, por exemplo, pode incluir páginas que não representam o conteúdo original daquela mensagem.

Em outras palavras, uma UTM correta não é suficiente para identificar sozinha o consumo de um conteúdo.

A solução foi combinar a atribuição com o conjunto oficial de URLs configuradas para cada módulo.

Assim, a consulta não pergunta apenas:

"Esta sessão veio desta campanha?"

Ela também verifica:

"Esta interação ocorreu em uma das páginas que realmente pertencem a este conjunto de conteúdos?"

Essa restrição reduz falsos positivos causados pela continuidade da navegação.

A configuração dos conteúdos virou parte da arquitetura

Os conteúdos monitorados são cadastrados em uma camada de configuração.

Cada registro pode conter informações como:

• módulo;

• idioma;

• parte;

• número da mensagem;

• tipo de conteúdo;

• formato;

• plataforma;

• fonte de dados;

• métrica principal;

• parâmetros UTM;

• URL de destino;

• Bitlink;

• status do conteúdo.

Isso evita espalhar regras diretamente pelo código.

Se determinado conteúdo pertence ao M1 PT, Parte 1 e corresponde à mensagem m1_msg2, essa informação está na configuração.

A aplicação pode então utilizar essa configuração para construir suas consultas e agregações.

É uma abordagem muito mais sustentável do que codificar dezenas de URLs e condições manualmente em cada função.

GA4 Data API para sair da dependência de exportações

Conforme a Fase 2 evoluiu, depender de exportações manuais do GA4 deixou de fazer sentido.

Foi criado um projeto específico no Google Cloud e habilitada a Google Analytics Data API.

Uma service account recebeu somente as permissões necessárias para leitura da propriedade analítica e atualização da planilha técnica.

A partir daí, a aplicação passou a consultar programaticamente o GA4.

Isso permitiu automatizar consultas por:

• conteúdo;

• parte;

• módulo;

• idioma;

• curso.

O processamento não depende mais de alguém abrir o Analytics, aplicar filtros, exportar um CSV e copiar os dados para uma planilha.

Usuários únicos precisam ser calculados no nível correto

A Data API foi particularmente importante para resolver a deduplicação.

Para obter usuários únicos de um módulo, fazemos uma consulta consolidada contendo o conjunto de páginas oficiais daquele módulo.

O GA4 então calcula totalUsers sobre aquele universo.

Isso é diferente de executar uma consulta para cada página e posteriormente somar os resultados.

O mesmo princípio foi aplicado às partes.

Assim, existem datasets diferentes para diferentes níveis analíticos.

Uma tabela pode responder:

Quantos usuários consumiram este conteúdo?

Outra:

Quantos usuários únicos consumiram esta parte?

Outra:

Quantos usuários únicos consumiram este módulo?

E outra:

Quantos usuários consumiram o curso?

Cada pergunta possui uma granularidade própria.

O tempo de consumo também exigiu uma decisão metodológica

Outra questão foi definir o que significaria "tempo médio".

O GA4 oferece métricas diferentes que podem parecer semelhantes.

Para conteúdos específicos, optamos por trabalhar principalmente com o tempo de engajamento e derivar uma métrica de tempo médio engajado por usuário.

Conceitualmente:

userEngagementDuration / totalUsers

Também podemos analisar o tempo em relação às sessões, mas são perguntas diferentes.

Isso evita apresentar averageSessionDuration como se representasse necessariamente o tempo dedicado a determinado conteúdo.

No relatório, o nome da métrica precisa explicar o que realmente está sendo calculado.

Scroll como proxy de profundidade, não de leitura

Para conteúdos textuais, monitoramos marcos de rolagem.

A estrutura utiliza níveis como:

25%

50%

75%

90%

Isso ajuda a entender a profundidade da navegação.

Mas existe uma distinção metodológica importante.

Scroll de 90% não significa que o usuário leu 90% do texto.

Significa que ele atingiu aproximadamente aquele ponto da página.

É um sinal comportamental útil, principalmente quando combinado com usuários e tempo de engajamento, mas não deve ser convertido em uma afirmação sobre assimilação do conteúdo.

Vídeos exigiram uma camada própria de instrumentação

O consumo de vídeo também precisou ser tratado separadamente.

O GTM passou a enviar eventos de interação com parâmetros como ação, título, percentual, tempo atual, duração, URL e provedor do vídeo.

Entretanto, existe outra regra importante no projeto:

não reconstruir retroativamente dados que não estavam disponíveis de forma confiável.

Se determinado parâmetro detalhado passou a existir após uma nova configuração, ele deve ser utilizado prospectivamente.

Dados históricos sem aquela dimensão não são convertidos artificialmente em zero.

No período anterior, uma interação genérica com vídeo pode continuar sendo uma métrica válida, enquanto play, progresso ou conclusão detalhada ficam indisponíveis.

Essa diferença entre zero e não disponível é pequena visualmente, mas enorme analiticamente.

PDFs mostraram outra limitação de atribuição

Downloads de PDF trouxeram um problema semelhante.

O GA4 possuía eventos de file_download, mas nem sempre existia atribuição suficientemente confiável para relacionar historicamente o download a uma peça específica da jornada.

Nesse cenário, optamos por não transformar ausência de atribuição confiável em "zero downloads".

Zero significa que medimos corretamente e nenhum evento aconteceu.

Nulo significa que aquela métrica não pode ser determinada de maneira confiável naquele contexto.

Essa distinção foi preservada na camada técnica e precisa ser respeitada também no Looker Studio.

Bitly: cliques não são usuários

O Bitly entrou na arquitetura como fonte de distribuição.

Os links utilizados nas mensagens podem gerar métricas de clique, mas cliques são eventos, não indivíduos.

Uma pessoa pode clicar várias vezes.

Também encontramos casos em que o mesmo Bitlink é compartilhado entre português e espanhol.

Se o link não possui informação suficiente para determinar o idioma, não fazemos uma divisão artificial.

O registro é tratado como compartilhado.

Isso evita um erro bastante comum em dashboards: dividir um número entre segmentos apenas porque a visualização exige uma categoria.

A ausência de granularidade não pode ser corrigida inventando granularidade.

Google Forms como sinal de conclusão

Cada módulo possui um formulário em português e outro em espanhol.

As respostas são consolidadas automaticamente e utilizadas como indicador operacional de conclusão.

Isso permitiu construir duas taxas diferentes.

Conclusão sobre inscritos

respostas / inscritos da Fase 1

Responde:

"Qual percentual da base original chegou à conclusão deste módulo?"

Conclusão sobre cursistas

respostas / usuários únicos que consumiram o módulo

Responde:

"Entre as pessoas que efetivamente chegaram ao módulo, qual percentual concluiu?"

As duas métricas são importantes e não devem ser confundidas.

Conectando a Fase 1 à Fase 2

Uma evolução importante da arquitetura foi evitar que a Fase 2 mantivesse uma segunda cópia manual do número de inscritos.

A própria base técnica da Fase 1 passou a ser a fonte dos denominadores utilizados na Fase 2.

Assim, os indicadores de consumo e conclusão não dependem de números hardcoded no código ou no dashboard.

Se a consolidação da Fase 1 mudar, a camada seguinte recebe o valor atualizado.

Esse tipo de decisão reduz divergências entre relatórios que deveriam representar a mesma população.

Google Apps Script e Node.js com responsabilidades diferentes

O projeto evoluiu para uma arquitetura híbrida.

O Google Apps Script continua sendo extremamente útil para operações próximas ao ecossistema Google, especialmente Sheets, Forms e rotinas operacionais.

Ao mesmo tempo, parte da coleta e transformação foi estruturada em Node.js.

Essa divisão permitiu tratar a aplicação como software de verdade, com módulos, testes automatizados, schemas e versionamento.

Em vez de manter toda a inteligência presa ao editor do Apps Script, o código passou a possuir um repositório próprio.

GitHub como fonte de verdade técnica

Um ponto importante do projeto foi separar a fonte de verdade operacional da fonte de verdade técnica.

O Google Sheets é a camada operacional dos dados.

O GitHub é a fonte de verdade do código, arquitetura, testes, schemas e decisões técnicas.

O repositório mantém documentação sobre:

• arquitetura da Fase 2;

• integração com GA4 Data API;

• modelo de dados;

• schema da planilha técnica;

• modelo do Looker Studio;

• decisões metodológicas;

• regras de coleta;

• limitações conhecidas.

Isso permite reconstruir por que determinada decisão foi tomada meses depois.

Em projetos analíticos, documentação não é apenas um complemento.

Ela faz parte da governança dos dados.

Testes automatizados também fazem sentido em Analytics

Uma mudança relevante foi aplicar práticas comuns de engenharia de software a uma implementação de Analytics.

As funções críticas passaram a possuir testes automatizados.

A abordagem utilizada foi escrever testes antes das alterações relevantes, principalmente em pontos que poderiam gerar corrupção silenciosa dos dados.

Foram testados comportamentos como:

• normalização;

• deduplicação;

• construção das consultas;

• cálculo dos denominadores;

• geração das taxas;

• idempotência;

• transformação das linhas;

• regras de calendário;

• escrita em Sheets;

• conversão de intervalos A1.

Esse último caso é um bom exemplo.

Quando a tabela técnica ultrapassou a coluna Z, uma função que assumia intervalos de uma única letra deixou de ser suficiente.

O teste passou a validar:

1 = A

26 = Z

27 = AA

Esse tipo de detalhe pode parecer trivial até que uma rotina automática escreva dados na coluna errada.

Idempotência: rodar duas vezes não pode duplicar o relatório

Rotinas automáticas precisam ser idempotentes sempre que possível.

Se a mesma janela analítica for processada novamente, o sistema não deve simplesmente anexar uma segunda cópia dos mesmos registros.

As tabelas possuem chaves lógicas.

Em conteúdos, por exemplo, podemos trabalhar com uma combinação como:

data + conteudo_id

Em módulos:

data + modulo_id

O processo pode atualizar ou substituir a fotografia correspondente sem gerar duplicação arbitrária.

Isso é particularmente importante porque o GA4 possui processamento tardio.

GA4 não é uma fonte completamente fechada no mesmo dia

Eventos recentes podem sofrer processamento posterior.

Um relatório consultado hoje pode apresentar números ligeiramente diferentes quando a mesma data é consultada amanhã.

Por isso, a arquitetura diferencia:

data

e

coletado_em

data representa o dia analítico.

coletado_em representa quando aquela fotografia foi coletada.

Essa distinção permite auditoria e ajuda a explicar alterações causadas pelo processamento tardio do GA4.

Automação diária e GitHub Actions

Depois da homologação das rotinas, o fluxo foi preparado para execução automatizada.

O processo diário coleta e atualiza a camada técnica utilizada pelo relatório.

O GitHub Actions entra como parte dessa automação e governança do projeto, permitindo executar workflows controlados a partir do código versionado.

Credenciais não são armazenadas diretamente no repositório.

Arquivos locais sensíveis, configurações de autenticação e chaves são excluídos do versionamento, e os workflows utilizam mecanismos apropriados para secrets e variáveis de ambiente.

Essa separação é essencial.

Automatizar um relatório não pode significar publicar credenciais junto com o código.

Uma rotina diária é suficiente para esse contexto

O dashboard não foi projetado para ser realtime.

A natureza do curso não exige atualização a cada minuto.

Além disso, dados recentes do GA4 podem ainda estar em processamento.

A rotina consolidada trabalha com uma janela analítica fechada e atualiza as tabelas técnicas uma vez ao dia.

Isso produz um equilíbrio melhor entre atualidade, estabilidade e custo operacional.

O relatório mostra quando os dados foram atualizados, permitindo que quem o consulta entenda que está observando a última fotografia processada.

Looker Studio como camada de visualização

Somente depois que as regras de coleta, granularidade e deduplicação estavam definidas o Looker Studio passou a ser tratado como a camada final.

Essa ordem é importante.

Um dashboard não deveria decidir a metodologia dos dados.

Ele deveria visualizar uma metodologia previamente definida.

A estrutura da Fase 2 foi organizada para acompanhar:

Curso

Módulo

Parte

Conteúdo

As páginas incluem visões gerais, comparação PT e ES, evolução dos módulos, Parte 1 x Parte 2, conteúdos individuais, profundidade de leitura, interação com vídeo, jornada, retenção, conteúdos de maior consumo e síntese do curso.

O dashboard também precisa saber quando não mostrar dados

Módulos futuros não são publicados com zeros artificiais.

Enquanto um módulo ainda não começou, a base não cria linhas apenas para preencher o gráfico.

Isso segue outro princípio da arquitetura:

ausência de dados não significa zero.

Quando M2, M3, M4 ou M5 ainda não possuem janela operacional válida, o relatório pode apresentar a estrutura preparada para aquela etapa, mas não inventa resultados.

À medida que o calendário avança, os novos módulos entram no fluxo.

O relatório muda de significado conforme o curso avança

Esse é um aspecto interessante de uma arquitetura longitudinal.

Na primeira semana, praticamente toda a análise está concentrada no M1.

Quando o M2 começa, temos:

M1 consolidando seu ciclo;

M2 iniciando;

primeira oportunidade real de observar progressão entre módulos.

Depois:

M1 fechado;

M2 fechado ou consolidando;

M3 em andamento.

Ao final, a mesma arquitetura permitirá estudar a jornada completa entre os cinco módulos.

Por isso, retenção não deveria ser calculada artificialmente quando existe apenas um módulo.

A estrutura pode estar pronta, mas a análise precisa esperar a existência do fenômeno que pretende medir.

Uma camada metodológica também foi necessária

Conforme o relatório cresceu, percebemos que apenas entregar os gráficos criaria outro problema.

Quem recebe um dashboard pode naturalmente tentar fazer operações que parecem intuitivas, mas são metodologicamente erradas.

Por exemplo:

somar usuários das páginas;

somar usuários das partes;

interpretar clique como pessoa;

interpretar scroll como leitura;

interpretar interação com vídeo como conclusão;

interpretar valor nulo como zero;

comparar um módulo encerrado com outro que ainda não começou.

Por isso, o próprio relatório passou a apontar para um Guia de Leitura e Metodologia.

A documentação explica como cada métrica deve ser interpretada e quais operações não devem ser feitas.

Essa camada reduz ambiguidades e transforma o dashboard em um produto de dados mais governado.

A arquitetura final

De maneira simplificada, a arquitetura pode ser representada assim:

Camada 1: aquisição

Landing pages + Mailchimp

↓

Inscrições PT e ES

↓

Países e estados

Camada 2: distribuição

WhatsApp e demais canais

↓

UTMs + Bitly

↓

Cliques e contexto das mensagens

Camada 3: comportamento

Google Tag Manager

↓

Google Analytics 4

↓

GA4 Data API

↓

Usuários + sessões + visualizações + engajamento + scroll + vídeo + conteúdos

Camada 4: conclusão

Google Forms

↓

Respostas por módulo e idioma

↓

Taxas de conclusão

Camada 5: processamento

Google Apps Script + Node.js

↓

Google Sheets

↓

Tabelas consolidadas por conteúdo, parte, módulo e curso

Camada 6: engenharia e governança

GitHub

↓

Testes automatizados + documentação + versionamento

↓

GitHub Actions + execução automatizada

Camada 7: visualização

Looker Studio

↓

Inscrição > consumo > progressão > conclusão

O que aprendemos até aqui

O principal aprendizado desse projeto é que automação de relatórios não começa pela automação.

Começa pela definição correta das entidades e das perguntas.

Antes de escrever código, foi necessário definir o que é:

• inscrição;

• cursista;

• clique;

• sessão;

• visualização;

• conteúdo;

• parte;

• módulo;

• conclusão.

Depois foi necessário definir em qual sistema cada conceito poderia ser medido com maior confiabilidade.

Só então fazia sentido automatizar.

O segundo aprendizado é que Analytics e engenharia de software estão cada vez mais próximos.

Quando uma operação depende de APIs, autenticação, processamento recorrente, schemas, deduplicação, testes, logs, versionamento e pipelines, já não estamos falando apenas de configurar algumas tags no GA4.

Estamos construindo um pequeno sistema de dados.

Do dashboard para um produto de dados

A evolução mais importante talvez tenha sido justamente essa mudança de perspectiva.

O objetivo inicial poderia ter terminado em uma planilha com inscrições e alguns gráficos.

Em vez disso, construímos uma arquitetura que separa:

coleta

configuração

processamento

armazenamento operacional

governança

visualização

Isso permite que cada camada evolua sem obrigar a reconstrução completa das demais.

Se um conteúdo novo entra no curso, ele pode ser cadastrado na configuração.

Se uma nova métrica passa a estar disponível, ela pode ser adicionada prospectivamente.

Se um módulo começa, sua janela passa a ser processada.

Se o GA4 reprocessa uma data recente, a fotografia pode ser atualizada.

E o Looker Studio continua sendo apenas o consumidor final dessas camadas.

O projeto ainda não terminou

Este artigo documenta a arquitetura enquanto o Curso PBL 2026 ainda está em andamento.

Por isso, deliberadamente não estou transformando os números intermediários em um case de resultado.

Neste momento, o mais relevante é mostrar como a infraestrutura foi construída para acompanhar uma operação educacional latino-americana em português e espanhol com consistência metodológica e automação.

Quando os cinco módulos forem concluídos, teremos uma base muito mais rica.

Será possível analisar a jornada completa entre inscrição, início do consumo, evolução entre módulos, conteúdos de maior adesão, diferenças entre idiomas, retenção e conclusão.

Essa segunda etapa será publicada posteriormente como um case completo do projeto.

Até lá, a arquitetura continua fazendo exatamente o que foi projetada para fazer:

acompanhar o curso enquanto ele acontece, sem confundir disponibilidade de dados com certeza analítica.

Quer ver a implementação em código?

A arquitetura apresentada neste artigo também ganhou uma camada própria de engenharia, com GA4 Data API, Node.js, testes automatizados, idempotência, GitHub Actions, gerenciamento de credenciais e integração com Google Sheets.

No artigo Como construímos uma arquitetura de dados para acompanhar um curso online latino-americano com GA4, Google Sheets, Apps Script, GitHub e Looker Studio, mostro como essas decisões foram implementadas em código e por que regras de Analytics também podem e devem ser testadas.

Stack técnica do projeto

A stack utilizada nesta implementação inclui:

• Mailchimp Marketing API;

• Google Analytics 4;

• Google Analytics Data API;

• Google Tag Manager;

• Google Cloud;

• Google Sheets;

• Google Apps Script;

• Google Forms;

• Bitly;

• Node.js;

• GitHub;

• GitHub Actions;

• Looker Studio.

Mais importante do que a quantidade de ferramentas é a responsabilidade atribuída a cada uma delas.

A arquitetura não tenta transformar uma única plataforma em solução para tudo.

Cada fonte responde pela parte da jornada que consegue observar com maior confiabilidade.

É essa separação que permite transformar várias ferramentas independentes em um sistema coerente de mensuração.