App + Web no GA4: uma propriedade, duas realidades
App+Web no GA4 na mesma propriedade só funciona com taxonomia comum, identidade consciente e expectativa realista sobre sessões cross-platform. Unificar streams sem contrato de eventos cria dashboard único e mentiroso. Às vezes a decisão correta é separar propriedades e reconciliar no warehouse — com critério, não por dogma.
O que “App+Web” promete e o que entrega?
A promessa: uma propriedade, múltiplos data streams (iOS, Android, Web), relatórios cross-platform e audiences compartilhadas. A entrega real depende de nomes de eventos alinhados, user_id quando houver login, e times que não inventam parâmetros diferentes por plataforma.
Sem isso, você soma page_view com screen_view sem mapa, compara “sessões” que não são comparáveis e otimiza mídia no escuro. Unidade cosmética não é unidade analítica.
Streams, Firebase e governança
Apps tipicamente entram via Firebase/GA4 SDK; web via gtag/GTM. Cada stream tem configuration própria (measurement, debug, consent). Governança: um catálogo de eventos de negócio (login, sign_up, purchase, tutorial_complete) com os mesmos nomes e parâmetros core em todas as plataformas.
Diferenças legítimas existem (screen_view vs page_view). Crie um modelo canônico no warehouse: event_name_raw → event_name_business.
- Catálogo único de eventos de negócio
- Dicionário de parâmetros obrigatórios
- Owners por plataforma (app iOS/Android/web)
- Ambientes debug separados de produção
- Política de user_id e reset no logout
Identidade: device, user_id e Blended
Sem login, o GA4 une pouco entre app e web. Com user_id consistente (mesmo ID estável do backend), a união melhora — ainda sujeita a modelos e limiares. Não prometa “jornada 100% unificada” para stakeholders só porque a propriedade é única.
Reporting identity (blended, observed, etc., conforme opções da conta) muda números. Congelar a escolha e educar o time evita “o relatório mudou sozinho”.
| Abordagem | Quando faz sentido | Vantagem | Custo/risco |
|---|---|---|---|
| Uma propriedade App+Web | Produto único, login comum, time único | Audiences e UI centralizados | Taxonomia desalinhada polui tudo |
| Propriedades separadas + warehouse | Times/processos distintos, compliance | Isolamento e clareza | Mais ETL e disciplina de join |
| Roll-up / subproperties (se disponível) | Org complexa | Flexibilidade organizacional | Setup e licenciamento a validar |
| Só app ou só web “oficial” | Um canal domina receita | Foco | Cegueira cross-platform |
Eventos comuns vs específicos de plataforma
Comuns: sign_up, login, purchase, refund, generate_lead (se existir no app). Específicos: os_update, notification_open, first_open. Não force web a emitir first_open. No funil executivo, mostre métricas canônicas; no diagnóstico, preserve o raw.
Parâmetros de item/receita devem seguir o mesmo schema — senão ROAS app vs web vira discussão de definição.
Sessão cross-platform: expectativa saudável
Usuário vê anúncio no mobile web, instala app, compra logado. A reconstrução completa exige user_id + possivelmente sinais de mídia (Google Ads app campaigns etc.). GA4 ajuda, mas o warehouse com timestamps e IDs continua sendo o lugar do “caso completo” para análise séria.
Quando separar propriedades?
Separe se os roadmaps de evento divergem sem governança, se há marcas/regiões com regras distintas, ou se um stream experimental polui produção. Unir no BI depois é preferível a um GA4 monolítico sem dono.
O critério é operacional: quem quebra, quem corrige, quem confia no número. Se a resposta for “ninguém”, a propriedade única está cara demais.
Mídia e attribution em App+Web
Campanhas app (ACI/ACE etc.) e campanhas web têm stacks de atribuição diferentes. Não compare CPA app vs web sem alinhar janelas e definições de conversão. Importe conversões com cuidado e documente o que cada plataforma otimiza.
Audiences GA4 cross-stream são poderosas para remarketing — se o volume e a identidade permitirem. Valide tamanho por stream.
Como a DataScroll decide o desenho?
Workshop de taxonomia, mapa de identidade (quando há login), escolha propriedade única vs separada, e pipeline de validação por stream. O entregável é número confiável para produto e mídia — não o checkbox “App+Web ativado”.
Checklist prático
- Catálogo de eventos de negócio cross-platform
- Streams iOS/Android/Web documentados
- Política de user_id (emissão, logout, suporte)
- Decisão explícita: propriedade única vs separada
- Schema de receita/itens alinhado
- Reporting identity documentada para o time
- QA por stream no DebugView / DebugView app
- Mapa de conversões de mídia app vs web
Erros comuns
- Unir propriedades sem alinhar nomes de eventos
- Prometer jornada 100% unificada sem login
- Misturar screen_view e page_view sem modelo canônico
- Deixar stream de staging apontar para produção
- Comparar CPA app vs web com definições diferentes
- Mudar reporting identity sem comunicar
- Ignorar donos por plataforma e deixar o catálogo apodrecer
App e site falando idiomas diferentes?
A DataScroll unifica taxonomia App+Web (ou separa com critério) para jornadas cross-platform serem legíveis.