Registar uma aplicação começa a recolher dados?

Não. O registo cria o ID público da propriedade da aplicação e nada mais. Os eventos aparecem quando a aplicação tem o SDK instalado, o inicia com a decisão de consentimento do utilizador, envia eventos e os entrega.

Quando é que os eventos saem do dispositivo?

Cerca de 5 segundos depois de serem registados, tanto no iOS como no Android, sem nenhuma chamada da aplicação; também quando a aplicação passa para segundo plano (sem garantia: o sistema pode suspendê-la antes) e, após o arranque seguinte, o que ainda estiver em fila. Enquanto a aplicação está em execução, os pedidos que falham são repetidos automaticamente; uma aplicação suspensa ou fechada não envia nada até voltar a ser executada. Antes do SDK de iOS 1.3.0 e do webmasterid_flutter 0.4.0, o iOS só enviava quando a aplicação chamava flush() ou passava para segundo plano; atualizar ativa a entrega automática.

Preciso de um site para usar a análise de aplicações?

Não. Depois do pagamento, abra Aplicações iOS ou Aplicações Android no painel e registe a aplicação. Os relatórios de aplicações não dependem de um site.

A WebmasterID substitui o AppsFlyer ou o Adjust?

Não. São parceiros de medição móvel: atribuem instalações a redes de anúncios e campanhas. Os SDK da WebmasterID não enviam fonte, campanha nem referenciador, e a WebmasterID não se liga a redes de anúncios, ao SKAdNetwork, ao AdServices nem ao Install Referrer.

Os dados são anónimos?

Não. Os ID de instalação e as chaves de conta são guardados como hashes com chave, o que os torna pseudónimos, não anónimos. Com o consentimento restrito, os eventos levam apenas um ID de sessão: uma identificação reduzida, que continua a não ser anonimato.

Usa o IDFA ou pede App Tracking Transparency?

Não. O servidor recusa identificadores publicitários e de dispositivo, e a WebmasterID não pede ATT. Uma resposta ao ATT não é consentimento para análise: a aplicação transmite a sua própria decisão de análise ao SDK.

Posso ver a atividade no site e na aplicação da mesma pessoa?

Não. Os sites e as aplicações aparecem lado a lado num espaço de trabalho, mas os identificadores são convertidos em hash por site e por aplicação, por isso um visitante e um utilizador da aplicação nunca são associados, nem o mesmo utilizador entre uma aplicação iOS e uma Android.

Que compras contam como receita?

Apenas as compras verificadas com a Apple ou a Google: transações de produção com receita, em bruto antes de reembolsos e por moeda. As compras de sandbox e de teste nunca contam. Os eventos de pagamento que a aplicação comunica aparecem como afirmações da própria aplicação, separados da receita.

É compatível com o RevenueCat?

Não. A verificação de compras funciona com o StoreKit 2 no iOS e o Google Play Billing no Android. O RevenueCat e outras frameworks de compras não são suportados.

É compatível com React Native ou Unity?

Não. Há SDK nativos para iOS (Swift) e Android (Kotlin ou Java) e um plugin para Flutter para aplicações iOS e Android. React Native, Unity e .NET não são suportados.

A análise de aplicações está incluída no Pro (US$ 499 por mês) e no Agency (US$ 1199 por mês), e nos planos Business acordados à medida. Os pacotes dos SDK são de transferência pública; enviar eventos e consultar os relatórios requer um plano ativo. Não existe plano gratuito para novas contas.

Análise de aplicações móveis que respeita a privacidade

Análise de aplicações móveis para iOS, Android e Flutter

Instale um SDK público, transmita a decisão de consentimento de cada utilizador e envie eventos. A WebmasterID mostra eventos, sessões, instalações, retenção e conversões das suas aplicações iOS e Android no mesmo espaço de trabalho dos seus sites, e os relatórios dizem o que não conseguem responder.

Ver preços Guia de instalação (em inglês)

Plataformas

SDK nativos para iOS e Android, e um plugin para Flutter

Instalam-se a partir do canal público de pacotes de cada plataforma: sem repositório privado, sem token de acesso e sem credenciais a acrescentar ao seu servidor de compilação.

iOS
Swift Package Manager. SDK da WebmasterID para iOS 1.3.0, para iOS 15.0 ou posterior, a partir de um pacote Swift público no GitHub.
Android
Gradle, com Kotlin ou Java. SDK da WebmasterID para Android 0.3.0, para a API 24 ou posterior, a partir do repositório Maven público em webmasterid.com/sdk/maven.
Flutter
pub.dev: webmasterid_flutter 0.4.0, para Flutter 3.47.0 ou posterior, em aplicações iOS e Android. Funciona sobre os SDK nativos.

React Native, Unity e .NET não são suportados. O plugin para Flutter cobre aplicações iOS e Android, não o Flutter para web ou para computador.

O que pode medir

Cinco relatórios construídos com os eventos que a sua aplicação envia

Cada relatório conta pelo momento em que a WebmasterID recebeu o evento, não pelo relógio do dispositivo, e as métricas principais têm a sua definição na página.

Visão geral
Eventos, sessões, instalações ativas, instalações observadas pela primeira vez e utilizadores identificados, com eventos por dia, os principais eventos e o estado da recolha: quando chegou o último evento.
Eventos
Cada nome de evento com as suas contagens e sessões, os principais ecrãs e países, e os 50 eventos mais recentes com identificadores pseudónimos abreviados.
Conversões
Os eventos de funil que a sua aplicação comunica, numa tabela; as compras verificadas com a Apple ou a Google, noutra. As duas nunca são somadas.
Retenção (beta)
Coortes dos dias 1, 7 e 30 por instalação, no seu fuso horário de relatórios. Um dia que ainda não passou aparece como ainda não observável, nunca como 0 %.
Atribuição
O que se sabe sobre a origem da atividade da aplicação e o que não se sabe. Os SDK não enviam fonte, campanha nem referenciador, por isso a origem das instalações aparece como desconhecida, nunca como orgânica.

Um vocabulário fixo de 14 eventos, para que os relatórios de cada aplicação signifiquem o mesmo: app_open, session_start, screen_view, cta_tap, search_performed, filter_applied, signup, login, checkout_started, booking_started, payment_started, booking_completed, cancellation, refund_requested.

Os eventos registam o ecrã em que aconteceram, quando existe. Não são suportados nomes de evento nem propriedades personalizados, e a versão da aplicação, a versão do sistema e o estado do consentimento são verificados quando o evento chega, mas não são guardados, por isso não há desagregação por eles.

Sites e aplicações

Os seus sites e aplicações num só espaço de trabalho, lado a lado

As equipas com um site e uma aplicação veem os dois num só sítio e com um só plano. Os relatórios continuam separados: a WebmasterID não junta um visitante do site e um utilizador da aplicação numa mesma pessoa.

Partilhado
Uma conta, um espaço de trabalho e um plano. Um painel com as secções Websites e Aplicações na barra lateral. O intervalo de datas mantém-se ao passar de uma para a outra, com um só fuso horário de relatórios.
Separado
Não há um relatório combinado de site e aplicação, nem um percurso desde uma visita ao site até à aplicação, nem correspondência de uma pessoa entre dispositivos: a chave de conta é guardada como um hash diferente em cada aplicação, por isso o mesmo utilizador conta uma vez na aplicação iOS e outra na aplicação Android.

Instalação

Da instalação ao primeiro evento

Registar uma aplicação não recolhe nada. Os eventos aparecem quando o SDK está instalado, é iniciado com a decisão de consentimento do utilizador, envia eventos e os entrega.

Antes de começar

Um plano Pro, Agency ou Business ativo no espaço de trabalho; a função Proprietário, Administrador ou Editor para registar uma aplicação; iOS 15.0 ou posterior compilado com o Xcode 26.0 ou posterior, Android API 24 ou posterior com Gradle, ou Flutter 3.47.0 ou posterior; e um local na sua aplicação onde o utilizador decide sobre a análise, cuja resposta a aplicação transmite ao SDK. Não é preciso conta no GitHub, token de acesso nem repositório privado.

1. Escolha um planoCrie uma conta e escolha Pro ou Agency no pagamento. A análise de aplicações está incluída em ambos.
2. Registe a aplicaçãoEm Aplicações iOS ou Aplicações Android, no painel. Recebe um ID público da propriedade: pode ser incluído na aplicação, não é um segredo e, sozinho, não recolhe nada.
3. Adicione o SDKA partir do Swift Package Manager, do repositório Maven da WebmasterID ou do pub.dev.
4. Inicie-o com uma decisão de consentimentoInicialize o SDK com o ID da propriedade e transmita-lhe a decisão do utilizador. Até haver uma decisão, nada é colocado em fila nem enviado.
5. Envie eventosVisualizações de ecrã, toques e os passos de funil que lhe interessam. No Flutter, os observadores de ciclo de vida e de navegação do plugin registam app_open e screen_view por si.
6. Entregue-osO SDK fá-lo sozinho, no iOS e no Android: cerca de 5 segundos depois de um evento, quando a aplicação passa para segundo plano e, após o arranque seguinte, com o que tiver ficado pendente. flush() fica apenas para um momento que a aplicação escolha.
7. Confirme o primeiro eventoEm Aplicações → Visão geral das aplicações, o estado da recolha mostra o último evento recebido. Se nada chegar, os passos de verificação do guia e os diagnósticos do SDK explicam porquê.

Consentimento e identidade

Consentimento e identidade, em linguagem simples

A WebmasterID regista o que a sua aplicação envia, com a decisão que a aplicação lhe transmite. Se é preciso consentimento e com que base legal é uma decisão sua; o SDK não torna uma aplicação conforme por si só.

Sem decisão, sem dados
Até a sua aplicação transmitir a decisão do utilizador, o SDK não coloca nada em fila nem envia nada.
Permitido
Os eventos levam um ID de sessão, um ID de instalação e, se a aplicação chamar identify(), uma chave de conta. Os ID de instalação e as chaves de conta são guardados como hashes com chave: pseudónimos, não anónimos.
Restrito
Os eventos levam apenas um ID de sessão: nem ID de instalação nem chave de conta. É uma identificação reduzida, não anonimato: o ID de sessão, as horas exatas e o país mantêm-se.
Desativado
Nada é enviado.
Sem identificadores publicitários
O servidor recusa o IDFA, o IDFV, o ID de publicidade do Android e outros identificadores de dispositivo. O App Tracking Transparency não é pedido, e uma resposta ao ATT não é consentimento para análise.
Sem endereço IP guardado
O país é obtido na periferia da rede quando o evento chega. Não é guardado nenhum endereço IP nem agente do utilizador.

O guia de instalação (em inglês) detalha os estados de consentimento, os identificadores e o que os SDK enviam, para os detalhes de privacidade da App Store e a secção de segurança dos dados do Google Play.

Conversões

Conversões comunicadas e compras verificadas são factos diferentes

A sua aplicação pode comunicar um pagamento iniciado. Só a Apple ou a Google podem confirmar uma compra. O relatório de conversões guarda os dois em tabelas separadas e nunca os soma.

Conversões comunicadas pela aplicação
Os eventos de funil que a sua aplicação envia, contados como afirmações da própria aplicação: signup, login, checkout_started, booking_started, payment_started, booking_completed, cancellation e refund_requested.
Compras verificadas pela loja
No iOS, transações do StoreKit 2 assinadas pela Apple, verificadas com os certificados da Apple, e notificações do servidor da App Store. No Android, tokens de compra do Google Play verificados junto da Google e notificações em tempo real para programadores. Cada uma precisa de uma ligação à loja configurada na página da aplicação no painel. Apenas transações de produção com receita, em bruto antes de reembolsos e por moeda. As compras de sandbox e de teste nunca contam.

Em que ponto está a verificação de compras

A entrega das notificações da App Store está verificada em produção. A parte do Google Play já está em produção, mas ainda não foi comprovada de ponta a ponta com uma compra de teste, e ainda nenhuma compra passou pela sandbox de qualquer das lojas até à verificação. O RevenueCat e outras frameworks de compras não são suportados.

É para si?

Para que serve e para que não foi feita

Adequada para
Equipas que já medem um site com a WebmasterID e publicam uma aplicação iOS ou Android. Aplicações cujos momentos-chave cabem nos 14 eventos: ecrãs, toques, pesquisa, filtros, registo e início de sessão, e os passos de reserva, pagamento e compra. Equipas que querem uma análise de aplicações pseudónima, com consentimento e sem identificadores publicitários. Agências que gerem sites e aplicações de vários clientes (o plano Agency acrescenta espaços de trabalho e membros da equipa).
Não foi feita para
Atribuição de instalações: postbacks de redes de anúncios, SKAdNetwork, Apple AdServices, o Install Referrer do Google Play, campanhas de ligações diretas, custo ou ROAS; a WebmasterID não é um parceiro de medição móvel (MMP). Nomes ou propriedades de evento personalizados, nem um percurso único que siga uma pessoa do site para a aplicação ou entre dispositivos. Transferências da App Store ou do Google Play: uma instalação observada pela primeira vez é o primeiro evento de um ID de instalação, não uma transferência. Relatórios de falhas, gravação de sessões, notificações push ou testes A/B. Aplicações React Native, Unity ou .NET. Dados de aplicações no Explorador de eventos, nas exportações ou nas ferramentas MCP e do agente, que trabalham com dados web.

Preços

Incluída no Pro e no Agency

Os pacotes dos SDK são de transferência pública. Enviar eventos e consultar os relatórios de aplicações requer um plano ativo. Não existe plano gratuito para novas contas.

O Pro custa US$ 499 por mês e o Agency US$ 1199 por mês; o Business é acordado à medida. Os três incluem a análise de aplicações. Faturação mensal em USD; pode cancelar a qualquer momento.

Perguntas frequentes

Registar uma aplicação começa a recolher dados?: Não. O registo cria o ID público da propriedade da aplicação e nada mais. Os eventos aparecem quando a aplicação tem o SDK instalado, o inicia com a decisão de consentimento do utilizador, envia eventos e os entrega.
Quando é que os eventos saem do dispositivo?: Cerca de 5 segundos depois de serem registados, tanto no iOS como no Android, sem nenhuma chamada da aplicação; também quando a aplicação passa para segundo plano (sem garantia: o sistema pode suspendê-la antes) e, após o arranque seguinte, o que ainda estiver em fila. Enquanto a aplicação está em execução, os pedidos que falham são repetidos automaticamente; uma aplicação suspensa ou fechada não envia nada até voltar a ser executada. Antes do SDK de iOS 1.3.0 e do webmasterid_flutter 0.4.0, o iOS só enviava quando a aplicação chamava flush() ou passava para segundo plano; atualizar ativa a entrega automática.
Preciso de um site para usar a análise de aplicações?: Não. Depois do pagamento, abra Aplicações iOS ou Aplicações Android no painel e registe a aplicação. Os relatórios de aplicações não dependem de um site.
A WebmasterID substitui o AppsFlyer ou o Adjust?: Não. São parceiros de medição móvel: atribuem instalações a redes de anúncios e campanhas. Os SDK da WebmasterID não enviam fonte, campanha nem referenciador, e a WebmasterID não se liga a redes de anúncios, ao SKAdNetwork, ao AdServices nem ao Install Referrer.
Os dados são anónimos?: Não. Os ID de instalação e as chaves de conta são guardados como hashes com chave, o que os torna pseudónimos, não anónimos. Com o consentimento restrito, os eventos levam apenas um ID de sessão: uma identificação reduzida, que continua a não ser anonimato.
Usa o IDFA ou pede App Tracking Transparency?: Não. O servidor recusa identificadores publicitários e de dispositivo, e a WebmasterID não pede ATT. Uma resposta ao ATT não é consentimento para análise: a aplicação transmite a sua própria decisão de análise ao SDK.
Posso ver a atividade no site e na aplicação da mesma pessoa?: Não. Os sites e as aplicações aparecem lado a lado num espaço de trabalho, mas os identificadores são convertidos em hash por site e por aplicação, por isso um visitante e um utilizador da aplicação nunca são associados, nem o mesmo utilizador entre uma aplicação iOS e uma Android.
Que compras contam como receita?: Apenas as compras verificadas com a Apple ou a Google: transações de produção com receita, em bruto antes de reembolsos e por moeda. As compras de sandbox e de teste nunca contam. Os eventos de pagamento que a aplicação comunica aparecem como afirmações da própria aplicação, separados da receita.
É compatível com o RevenueCat?: Não. A verificação de compras funciona com o StoreKit 2 no iOS e o Google Play Billing no Android. O RevenueCat e outras frameworks de compras não são suportados.
É compatível com React Native ou Unity?: Não. Há SDK nativos para iOS (Swift) e Android (Kotlin ou Java) e um plugin para Flutter para aplicações iOS e Android. React Native, Unity e .NET não são suportados.
Quanto custa?: A análise de aplicações está incluída no Pro (US$ 499 por mês) e no Agency (US$ 1199 por mês), e nos planos Business acordados à medida. Os pacotes dos SDK são de transferência pública; enviar eventos e consultar os relatórios requer um plano ativo. Não existe plano gratuito para novas contas.

Relacionado