Meu Mercado: analytics com Firebase e GA4 no app Flutter e os relatórios que transformam uso em decisão

O Meu Mercado chegou a mais uma fase importante do MVP: agora o app online em Flutter já conta com Firebase Analytics integrado ao Google Analytics 4.

Nos posts anteriores, documentei duas etapas do projeto:

• Meu Mercado: construindo uma lista de compras full-stack com React, Express e SQLite

• Meu Mercado Mobile: Flutter para iOS e Android, preparação de publicação e instalação em aparelho real

• Meu Mercado: app Flutter com Firebase e GA4

Agora a evolução deixa de ser apenas técnica e passa a ser também analítica.

O app já estava funcionando em iOS e Android, com login, listas de compras, catálogo, edição de produtos, controle de quantidades e uso real no dia a dia. Mas um app funcionando ainda não responde sozinho às perguntas mais importantes:

• as pessoas conseguem criar conta?

• elas voltam depois do primeiro acesso?

• criam listas?

• adicionam itens?

• usam o catálogo?

• finalizam compras?

• em qual etapa abandonam o fluxo?

• iOS e Android se comportam da mesma forma?

Para responder isso com dados, implementei a camada de analytics.

Por que Firebase Analytics e GA4?

No ecossistema mobile, o caminho natural para mensuração em apps Android e iOS é o Google Analytics for Firebase, integrado ao GA4.

O Firebase coleta os eventos dentro do app. O GA4 organiza esses eventos em relatórios, explorações, funis, comparações por plataforma e análises de comportamento.

Isso permite que um app deixe de ser uma caixa-preta.

Em vez de depender apenas de opinião, print de tela ou relato de usuário, o produto passa a gerar sinais reais de uso:

• eventos de login;

• eventos de criação de lista;

• eventos de catálogo;

• alterações de status;

• itens adicionados;

• quantidades alteradas;

• listas finalizadas;

• separação entre Android e iOS;

• leitura de engajamento por fluxo.

Para a Ad Rock, esse ponto é estratégico. Muitas empresas já medem bem seus sites, mas ainda têm pouca visibilidade sobre seus aplicativos. A instrumentação correta de apps é uma oportunidade clara para unir tecnologia, marketing, produto e análise de dados.

O que foi implementado no app

O app Flutter online do Meu Mercado recebeu Firebase Analytics em Android e iOS.

Foram configurados dois fluxos de dados dentro da mesma propriedade GA4:

• Meu Mercado Android

• Meu Mercado iOS

Essa separação é importante porque permite comparar comportamento por plataforma sem duplicar a lógica de eventos. O evento shopping_list_created, por exemplo, tem o mesmo nome no Android e no iOS. O que muda é o stream de origem.

Na prática, isso dá consistência para a análise:

• mesmo evento;

• mesma regra de negócio;

• mesma taxonomia;

• plataformas comparáveis;

• relatórios mais limpos.

Eventos implementados

A taxonomia de eventos foi pensada para medir produto, não curiosidade.

Os eventos customizados principais são:

app_opened
login_success
logout
sign_up_success
shopping_list_created
shopping_list_status_changed
shopping_list_renamed
item_added_to_list
item_checked
quantity_changed
item_removed_from_list
catalog_item_created
catalog_item_edited
catalog_item_deleted
forgot_password_opened
password_changed

app_opened
login_success
logout
sign_up_success
shopping_list_created
shopping_list_status_changed
shopping_list_renamed
item_added_to_list
item_checked
quantity_changed
item_removed_from_list
catalog_item_created
catalog_item_edited
catalog_item_deleted
forgot_password_opened
password_changed

app_opened
login_success
logout
sign_up_success
shopping_list_created
shopping_list_status_changed
shopping_list_renamed
item_added_to_list
item_checked
quantity_changed
item_removed_from_list
catalog_item_created
catalog_item_edited
catalog_item_deleted
forgot_password_opened
password_changed

Além deles, o GA4 também registra eventos automáticos, como:

first_open
session_start
screen_view
user_engagement

first_open
session_start
screen_view
user_engagement

first_open
session_start
screen_view
user_engagement

Esses eventos automáticos ajudam a entender abertura, sessão, engajamento e visualizações, mas os eventos customizados são os que mais explicam o uso real do produto.

O que cada evento ajuda a entender

app_opened

Mostra que o app foi aberto com sucesso depois do carregamento inicial.

Esse evento ajuda a acompanhar uso recorrente e volume de abertura do app.

sign_up_success

Mostra que uma nova conta foi criada.

É um evento de aquisição/ativação. Se muitas pessoas abrem o app mas poucas criam conta, existe um problema de proposta, tela inicial, confiança ou fricção.

login_success

Mostra que o usuário conseguiu entrar.

Esse evento é essencial para separar usuário novo de usuário recorrente. Também ajuda a identificar se há problemas no fluxo de autenticação.

shopping_list_created

Mostra que uma lista foi criada.

Esse é um dos eventos mais importantes do app, porque indica que o usuário saiu da intenção e começou a usar o produto de fato.

item_added_to_list

Mostra que o usuário adicionou produtos a uma lista.

Esse evento indica profundidade de uso. Criar lista sem adicionar item é um fluxo incompleto. Criar lista e adicionar itens mostra engajamento real.

quantity_changed

Mostra que o usuário ajustou quantidades.

Esse evento ajuda a entender se a experiência de lista está sendo usada de forma prática. Se há muitos ajustes, a função é relevante. Se quase não há, talvez precise de melhoria de UX ou não seja tão central quanto parecia.

item_checked

Mostra que um item foi marcado ou desmarcado como comprado.

Esse evento indica uso no momento da compra. É um sinal forte de que o app está sendo usado dentro do fluxo real do mercado.

shopping_list_status_changed

Mostra mudança de status da lista, como:

draft
active
completed

draft
active
completed

draft
active
completed

Esse evento é fundamental para medir o ciclo da lista:

• rascunho;

• ida ao mercado;

• compra finalizada.

A conversão principal pode ser interpretada como shopping_list_status_changed com status = completed.

catalog_item_created

Mostra que o usuário criou um produto no catálogo.

Esse evento indica personalização. Quando alguém cria produto próprio, o app deixa de ser genérico e passa a representar a rotina daquela pessoa.

catalog_item_edited

Mostra que um produto foi ajustado.

Esse evento ajuda a medir manutenção do catálogo e qualidade da experiência. Se há muita edição, pode ser sinal positivo de personalização ou sinal de que os dados iniciais precisam melhorar.

catalog_item_deleted

Mostra que um produto foi removido.

Ajuda a entender limpeza do catálogo e uso avançado.

Privacidade: o que não foi enviado

Uma decisão importante da implementação foi não enviar dados sensíveis ao GA4.

O app não envia:

• email;

• senha;

• token;

• nome da lista;

• nome do produto;

• texto digitado na busca;

• conteúdo livre do usuário.

O objetivo é medir comportamento, não coletar dados pessoais desnecessários.

Os parâmetros enviados são seguros e agregáveis, como:

status
qty
item_count
category_id
purchased

status
qty
item_count
category_id
purchased

status
qty
item_count
category_id
purchased

Essa é uma regra importante para qualquer projeto sério de analytics: medir bem não significa coletar tudo. Significa coletar o necessário para responder perguntas de produto e negócio.

Relatório 1: eventos por plataforma

O primeiro relatório criado no GA4 foi uma exploração de eventos por plataforma.

Estrutura recomendada:

• Dimensão: Nome do evento

• Dimensão: Nome do stream

• Métrica: Contagem de eventos

• Métrica: Usuários ativos

• Linhas: Nome do evento

• Colunas: Nome do stream

Esse relatório responde:

• quais eventos acontecem mais;

• se Android e iOS estão enviando dados;

• se a instrumentação está consistente;

• se um evento aparece em uma plataforma e não aparece na outra;

• quais ações têm mais volume.

Como analisar

Se login_success aparece nos dois streams, o login está funcionando e sendo medido em Android e iOS.

Se shopping_list_created aparece no iOS, mas não no Android, pode ser uma diferença de uso, teste insuficiente ou falha específica da plataforma.

Se item_added_to_list é muito maior que shopping_list_created, isso é esperado: uma lista pode receber vários itens.

Se catalog_item_created aparece pouco, isso não significa necessariamente problema. Pode indicar que o catálogo inicial já atende a maioria dos usuários.

Esse relatório é a base de saúde da mensuração.

Relatório 2: funil principal do app

O segundo relatório recomendado é o funil principal.

Estrutura:

1. app_opened

2. login_success

3. shopping_list_created

4. item_added_to_list

5. shopping_list_status_changed

Quebra:

• Nome do stream

Esse funil mostra a jornada essencial:

• abriu o app;

• entrou;

• criou lista;

• adicionou item;

• avançou o status da lista.

Como analisar

Se muitas pessoas abrem o app, mas poucas fazem login, o problema está antes da experiência principal. Pode ser cadastro, senha, tela inicial ou confiança.

Se fazem login, mas não criam lista, o problema pode estar no dashboard ou na clareza do botão principal.

Se criam lista, mas não adicionam itens, pode haver atrito na seleção de produtos.

Se adicionam itens, mas não finalizam, talvez a ação de finalizar esteja pouco clara ou a pessoa esteja usando o app apenas como rascunho.

Esse relatório ajuda a transformar uso em backlog.

Relatório 3: conversões do app

Alguns eventos devem ser acompanhados como conversões ou eventos principais.

Sugestão:

• sign_up_success

• shopping_list_created

• shopping_list_status_changed com status = completed

• catalog_item_created

A conversão mais importante é a lista concluída.

Por quê?

Porque esse é o momento em que o app entrega valor completo: a pessoa organizou uma compra e concluiu o processo.

Como analisar

Uma boa leitura não é olhar apenas quantidade absoluta.

É melhor analisar relações:

• contas criadas versus listas criadas;

• listas criadas versus listas concluídas;

• itens adicionados versus listas concluídas;

• uso do catálogo versus conclusão de compra.

Essas relações mostram qualidade de uso, não apenas volume.

Relatório 4: uso do catálogo

O catálogo é uma parte importante do Meu Mercado, porque permite adaptar o app à rotina da pessoa.

Eventos relevantes:

catalog_item_created
catalog_item_edited
catalog_item_deleted
item_added_to_list

catalog_item_created
catalog_item_edited
catalog_item_deleted
item_added_to_list

catalog_item_created
catalog_item_edited
catalog_item_deleted
item_added_to_list

Como analisar

Se muitas pessoas criam produtos no catálogo, isso mostra que o app precisa ser flexível.

Se muitas editam produtos, o cadastro e a curadoria do catálogo inicial podem melhorar.

Se poucas usam o catálogo, talvez ele precise aparecer melhor no fluxo de adicionar produtos.

Se o catálogo é muito usado antes da criação de listas, ele pode virar uma etapa de onboarding ou personalização.

Relatório 5: status das listas

O evento shopping_list_status_changed é especialmente útil quando analisado pelo parâmetro status.

Valores esperados:

draft
active
completed

draft
active
completed

draft
active
completed

Como analisar

Muitas listas em draft podem indicar que as pessoas criam listas como planejamento.

Muitas listas em active mostram uso no mercado.

Muitas listas em completed indicam entrega de valor.

Poucas listas concluídas podem apontar para problema de usabilidade ou para um comportamento diferente do esperado: o usuário talvez use a lista sem se preocupar em finalizar formalmente.

Relatório 6: retenção e retorno

Depois que houver volume, a próxima análise é retenção.

Perguntas importantes:

• o usuário volta no dia seguinte?

• volta na semana seguinte?

• cria mais de uma lista?

• usa o app em ciclos mensais?

• usa o catálogo depois do primeiro acesso?

Para uma lista de compras, retenção não precisa ser diária. O comportamento natural pode ser semanal, quinzenal ou mensal.

Isso é importante: nem todo produto precisa ser usado todos os dias para ser bom.

O analytics precisa respeitar o contexto de uso.

O que os números devem orientar

Analytics não deve ser usado apenas para montar gráficos bonitos.

No Meu Mercado, cada leitura deve ajudar uma decisão:

• melhorar onboarding;

• simplificar cadastro;

• ajustar botões;

• reorganizar catálogo;

• melhorar busca;

• reduzir fricção na criação de lista;

• destacar a ação de finalizar compra;

• decidir o que entra no app offline;

• priorizar melhorias de UX por impacto real.

Essa é a diferença entre instalar analytics e trabalhar com mensuração.

O valor comercial dessa etapa

Essa fase do Meu Mercado mostra uma capacidade importante da Ad Rock: entregar analytics para apps, não apenas para sites.

Na prática, isso envolve:

• configurar Firebase;

• conectar Android e iOS ao GA4;

• definir eventos;

• documentar taxonomia;

• evitar dados sensíveis;

• criar relatórios;

• montar funis;

• interpretar comportamento;

• traduzir dados em ação.

Para empresas que têm aplicativos, isso é muito relevante.

Um app sem analytics depende de percepção.

Um app com analytics bem implementado permite aprender com o uso real.

E um app com análise bem feita pode gerar melhoria contínua de produto, marketing, atendimento e retenção.

Próximo passo: app offline e local

O próximo grande passo do roadmap é criar uma versão 100% offline e local do Meu Mercado.

Essa versão será separada do app online atual.

O app online continua com:

• login;

• API;

• backend;

• banco centralizado;

• Firebase Analytics;

• GA4;

• suporte remoto;

• dados por usuário.

Já a futura versão offline deve nascer com outra proposta:

• sem login;

• sem senha;

• sem cadastro;

• sem token;

• sem API;

• sem Firebase Analytics neste ciclo;

• sem dependência de internet;

• dados salvos no aparelho;

• banco local;

• backup/exportação/importação.

Essa separação é importante porque são produtos com premissas diferentes.

O app online ajuda a validar uso, medir comportamento e evoluir com dados centralizados.

O app offline deve ser pensado para funcionar mesmo sem internet, especialmente no momento da compra dentro do mercado.

O que deve sair da versão offline

Na versão offline, várias partes do app atual deixam de fazer sentido.

Devem ser removidos ou substituídos:

• tela de login;

• tela de cadastro;

• esqueci minha senha;

• alterar senha;

• armazenamento de token;

• validação de sessão expirada;

• chamadas HTTP para API;

• dependência de backend;

• Firebase Analytics;

• arquivos google-services.json e GoogleService-Info.plist;

• eventos GA4;

• fluxo de web administrativa;

• regras de conta por usuário no servidor.

Em vez disso, entram:

• banco SQLite local;

• seed local de categorias e produtos;

• repositórios locais;

• onboarding de primeira abertura;

• tutorial com balões explicando os botões;

• backup manual;

• importação de backup;

• aviso claro sobre dados locais.

Esse será outro ciclo técnico, com outro pacote Android, outro bundle iOS e outra documentação.

Conclusão

O Meu Mercado está deixando de ser apenas um MVP funcional para virar um case completo de produto digital.

Ele já passou por:

• web full-stack;

• app Flutter iOS e Android;

• instalação em dispositivos reais;

• API em produção;

• APK para teste privado;

• Firebase Analytics;

• GA4;

• eventos de produto;

• relatórios por plataforma;

• plano de funis e conversões;

• roadmap offline.

Essa evolução mostra uma visão que a Ad Rock quer levar para o mercado:

não basta criar app.

É preciso criar, medir, entender e melhorar.

Apps bem feitos precisam de produto, tecnologia e análise trabalhando juntos.

E essa é exatamente a direção do Meu Mercado.