Medir o aplicativo e a assinatura com Firebase sem perder a pessoa entre plataformas

O clube de assinatura vive num aplicativo. Os 2.900 assinantes acompanham no app os cuidados das plantas e a entrega do mês, e é lá que a maioria cancela. O site em Next.js e a Shopify já estão medidos; o app da Verde Vivo não manda dados para lugar nenhum, e o cancelamento de 4,1 por cento ao mês só existe na planilha do financeiro.

Sem medir o app, a empresa sabe quantos cancelam e não sabe quem. Não sabe se quem cancela abriu o app uma vez ou vinte, se veio de anúncio ou de indicação, se é o mesmo cliente que compra vasos na loja. A R$ 79 por mês, cada ponto percentual de cancelamento a menos vale 29 assinaturas mantidas, e a decisão de onde agir precisa de dado.

O Firebase é a porta de entrada do GA4 para aplicativos, e a arquitetura decidida no capítulo 4 já reservou espaço para os fluxos de Android e iOS na mesma propriedade do site. Este capítulo instala o SDK, define o que o app registra, liga a pessoa do app à pessoa do site e trata o iOS com o que a Apple permite em 2026.

A arquitetura tem três peças. O projeto Firebase (o contêiner de serviços do Google para apps, onde o SDK se registra) guarda o app Android e o app iOS. A propriedade GA4 recebe um fluxo por plataforma, vinculado a esse projeto. Quando os fluxos do app ficam na mesma propriedade dos fluxos web, a identidade de relatório pode reunir a pessoa que assinou no site e abre o app no celular.

O SDK do Firebase coleta três camadas de evento. A automática registra sem código a primeira abertura (first_open) e o início de sessão (session_start). A recomendada segue a mesma referência do site, com compra, cadastro e login. A personalizada é o que o clube precisa e ninguém publicou: plano de cuidado criado, lembrete ativado, entrega avaliada.

A jornada no app começa antes do app: instalação na loja, primeira abertura, onboarding e ativação. first_open marca o começo do que o GA4 vê. Ativação é a decisão do negócio, e a Verde Vivo escolheu "primeiro plano de cuidado criado", porque é o momento em que o assinante passa a ter motivo para voltar. Tudo entre first_open e a ativação é o funil de onboarding.

Identidade entre plataformas é o que faz o app valer o esforço. No site, o GA4 conhece a pessoa pelo Client ID; no app, pelo App Instance ID, o identificador que o SDK cria na instalação. Só o User-ID, enviado no login das duas superfícies, liga os dois. Sem ele, o assinante que comprou no site e abre o app aparece como duas pessoas, e a retenção por coorte do capítulo 17 nasce quebrada.

A identidade de relatório decide como o GA4 usa esse elo. Blended tenta User-ID, depois identificador do dispositivo, depois modelagem; Observed usa User-ID e dispositivo; Device-based, só o dispositivo. O clube só se lê inteiro em Blended ou Observed, e as duas sujeitam relatórios a limiares de dados quando há poucos usuários logados.

Eventos que nascem no servidor precisam encontrar a pessoa certa. Para o site, o SDK JavaScript do GA4 ganhou a função getGoogleAnalyticsClientId, que devolve o Client ID da sessão para o backend enviar eventos com o mesmo identificador. Para o app, o caminho é o User-ID, e a Data Manager API roteia eventos de app pelo Firebase App ID, ainda sob allowlist.

Monetização tem três formas, e a Verde Vivo usa uma. Compra no app e assinatura pela loja de aplicativos passam pelo Google Play ou pela App Store, e o Firebase registra a compra; em julho de 2026 um terceiro relatou que o SDK aceita registrar compra no app manualmente por logEvent, informação sem confirmação na página oficial. Receita publicitária entra pela integração do AdMob com o SDK, sem mudança em 2026.

A assinatura do clube é cobrada no site, fora das lojas de aplicativo, então a renovação e o cancelamento são eventos que o servidor de cobrança envia, com o User-ID e o valor de R$ 79. É a única forma de o GA4 ver o cancelamento no mesmo lugar em que vê o uso do app, e é o que permite perguntar quem cancela.

iOS impõe limites próprios, e a primeira coisa a fazer é pedir a permissão de rastreamento pelo diálogo do sistema antes de qualquer atribuição. Com a permissão negada, a atribuição de instalação não passa pelo identificador do aparelho, e o GA4 depende de dois mecanismos que a Apple e o Google construíram para esse cenário.

SKAdNetwork (o mecanismo da Apple que devolve ao anunciante um sinal agregado de instalação, sem identificar a pessoa) chega ao GA4 por postbacks enviados via Measurement Protocol. O Analytics modela o first_open a partir desses sinais, exige um esquema de valor de conversão configurado na propriedade e o SDK do Firebase, e promete modelar mais eventos pós-instalação. AdAttributionKit, o sucessor que a Apple recomenda desde a WWDC de 2024, não é citado na página do Analytics; os dois coexistem.

On-device conversion measurement (medição de conversão no aparelho, para campanhas de app no iOS) é o segundo mecanismo. Exige SDK 11.14.0 ou superior, de junho de 2025, tem uma variante por dados próprios e outra por eventos, e a variante por eventos está em beta aberta. Fica inativo no Espaço Econômico Europeu, no Reino Unido e na Suíça, o que não afeta o clube, cujos assinantes estão no Brasil.

Diagnóstico por versão é a rotina que o app exige e o site não. Cada publicação nas lojas pode quebrar um evento, e a dimensão de versão do app separa o antes do depois. O SDK também muda: as versões 12.15.0 a 12.19.2 do SDK da Apple saíram entre junho e setembro de 2026, quase todas com limpezas internas, mas a 12.18.0 corrigiu uma condição de corrida no session_start, e um app preso numa versão antiga carrega o defeito.

Armadilha comum: criar uma propriedade separada para o app "para não misturar" e mandar o User-ID só no site. O resultado é um relatório de app cheio de pessoas novas que já eram clientes, uma retenção que não bate com a planilha de assinantes e nenhuma forma de saber se o assinante que cancelou tinha comprado na loja. Fluxo separado, propriedade única, User-ID nas duas pontas.

Na Verde Vivo, Caio criou os dois fluxos na propriedade existente, instalou o SDK 12.19.2 no iOS e o equivalente no Android, e colocou o User-ID no login do app com o mesmo valor que o site usa. O servidor de cobrança passou a enviar renovação e cancelamento com o User-ID e o valor de R$ 79. O esquema de valor de conversão do SKAdNetwork foi configurado com a ativação como evento principal.

Dois meses depois, o cancelamento de 4,1 por cento ao mês ganhou rosto. Os 2.900 assinantes se dividiram em 1.680 no iOS e 1.220 no Android, com identidade unificada em 91 por cento das contas. Quem criou o plano de cuidado na primeira semana cancelou 2,3 por cento ao mês; quem nunca criou, 8,7 por cento. Entre os assinantes vindos de anúncio de app, 38 por cento não chegaram à ativação em 30 dias.

O que mudou foi o lugar da decisão. O cancelamento deixou de ser um número do financeiro e virou um funil de onboarding com uma etapa que fica para trás: a criação do plano de cuidado. A equipe do clube reescreveu a primeira tela do app para levar à criação do plano, e o teste dessa hipótese ganhou uma métrica e um prazo.

Abra o relatório de eventos do fluxo iOS e filtre pela versão atual do app: first_open, session_start e o seu evento de ativação precisam aparecer com a versão nova em até 48 horas depois da publicação na loja. Se um deles faltar, a publicação quebrou a medição. A próxima trilha leva esses eventos-chave ao Google Ads, e o primeiro passo é decidir quais deles podem virar conversão.