Implementação

Arquitetura

Um produto, três camadas independentes

Core

Bridgee Attribution

Link e Blink preservam a origem; o SDK resolve a instalação; o canal chega ao Firebase/GA4.

Qualidade

Traffic Intelligence

CTIT, replay, profundidade da jornada e trust score com componentes e reason codes.

Físico

Physical Intelligence

Câmeras e sensores geram contagens, ocupação, permanência e coortes agregadas.

Fluxo animado

Do clique ao canal no GA4

Acompanhe as etapas de atribuição do clique à entrega no GA4.

1. CliqueBlink preserva IDs e UTMs permitidos.

2. InstalaçãoSDK executa o match.

3. DecisãoMétodo, confiança e reason codes.

4. Firebase/GA4Canal entregue sem duplicidade.

Start here

Checklist de implementação

Criar tenant e ambiente de teste

Defina domínios, destinos, janelas, consentimento e contatos técnicos.

Configurar CNAME e Blink

Use HTTPS, allowlist de parâmetros e uma URL de teste por plataforma.

Instalar o SDK

Android, iOS ou React Native; execute o first-open somente conforme o ciclo documentado.

Validar a decisão

Confira match method, confidence, decision version, reason codes e idempotência.

Validar Firebase/GA4

Garanta uma única entrega de atribuição e preserve a atribuição nativa do Google.

Onboarding técnico

Credenciais e informações necessárias

Cada cliente recebe um Tenant ID e uma Tenant Key exclusivos para autenticar as chamadas de reconciliação. Para emissão, informe empresa, aplicativo nas lojas, responsáveis técnicos e os domínios escolhidos para o Blink.

Emissão individual

Credenciais são separadas por tenant e ambiente. Produção e teste não compartilham segredo.

Entrega segura

Chaves são enviadas por canal autenticado, nunca em ticket público, analytics ou código de exemplo.

Rotação

Planeje owner, expiração, revogação e rotação sem interromper o aplicativo.

Canal registrado na documentação legada: bridgee@caaqui.com. Antes de produção, confirme SLA e canal operacional no onboarding vigente.

Blink Server

Domínios, CNAME, TLS e validação

O desenho documentado usa subdomínios sob controle do cliente: um para iOS e outro para Android. Prefira nomes curtos e reconhecíveis, como ios.suaempresa.com.br e android.suaempresa.com.br.

Tipo	Host de exemplo	Destino documentado	TTL	Plataforma
CNAME	`ios.suaempresa.com.br`	`blink.bridgee.ai`	300	iOS
CNAME	`android.suaempresa.com.br`	`blink.bridgee.ai`	300	Android

confirme o endpoint final recebido no onboarding antes de alterar DNS;
valide propagação com dig ou nslookup;
o fluxo legado prevê provisionamento TLS pela Bridgee após confirmação dos hosts;
teste HTTPS, redirect, parâmetros allowlisted e destino de cada plataforma;
não publique links de campanha antes da validação de roteamento e certificado.

SDKs e exemplos

Implementações oficiais do Bridgee

Os SDKs e aplicativos de exemplo abaixo são públicos e mantidos na organização oficial bridgee-ai. Os links abrem o GitHub em uma nova aba.

Plataforma	SDK oficial	Aplicativo de exemplo
Android / Kotlin	bridgee-android-sdk ↗	bridgee-android-example ↗
iOS / Swift	bridgee-ios-sdk ↗	bridgee-ios-example ↗
React Native	bridgee-react-native-sdk ↗	bridgee-react-native-example ↗

Para produção, confirme no onboarding a release homologada, compatibilidade, checksum do artefato e credenciais do ambiente. Fale com contato@bridgee.ai.

O ciclo de firstOpen e a API pública devem seguir a release homologada para o projeto; valide o aplicativo de exemplo antes de promover a integração.

Primeiro acesso

Do SDK ao Firebase/GA4

No primeiro ciclo elegível, o SDK inicializa o identificador técnico aprovado, chama o serviço de reconciliação e recebe os metadados de aquisição. Depois, a origem resolvida é disponibilizada ao Firebase/GA4 conforme o contrato da versão.

inicializar o SDK uma única vez no ciclo documentado;
usar credenciais do tenant e ambiente corretos;
tratar sucesso, ausência de match, timeout e repetição com idempotência;
validar source, medium, campaign, método e confiança;
preservar atribuição nativa e impedir entrega duplicada;
confirmar no DebugView/teste e depois no relatório de aquisição.

Contrato neutro

Identificadores aceitos

Parceiro	Evidência	Regra
Google	`gclid`, `gbraid`, `market_referrer_gclid`	Preservar fluxo nativo e impedir duplicidade.
Meta	`fbclid` ou payload aprovado	Manter opaco; postback exige contrato aprovado.
TikTok	`ttclid` ou payload aprovado	Roteamento configurado por tenant.
DSP	macro em `partner_click_id`	Não existe macro universal.
Bridgee	`bridgee_click_id`, `bridgee_install_id`	Correlação pseudônima; nunca identidade de pessoa.

SDK

Resposta de match versionada

{
  "utm_source": "tiktok",
  "utm_medium": "paid_social",
  "utm_campaign": "launch",
  "attribution": {
    "resolved_partner": "tiktok",
    "evidence_type": "ttclid",
    "match_method": "deterministic",
    "match_confidence": 1.0,
    "partner_conflict": false,
    "decision_version": "partner-routing/1.0.0"
  }
}

IDs são case-sensitive e opacos. Nunca escolher um canal por prioridade comercial; conflitos são auditados e suprimem postback.

Qualidade

Web, app e ausência de GTM

Web + GTM

Checkpoint consentido com tempo ativo, profundidade, sequência e chave idempotente. O navegador não calcula score.

App + BigQuery

Authorized view dos eventos nativos do Firebase. Não recolhe purchase.

App sem acesso

Push server-to-server, checkpoints do SDK ou status comportamental unavailable.

Contrato session-quality/1.0.0: evidência bruta allowlisted → validação e deduplicação no servidor → features explicáveis → antifraude e Trust Score versionados. Revogação de analytics_storage interrompe a coleta e apaga o estado local.

Privacidade e operação

Gates antes de produção

consentimento e finalidade por região;
sem IP bruto, PII ou segredos no analytics;
retenção e deleção por tenant;
contract tests Android, iOS, React Native e API;
shadow scoring antes de afetar decisões;
rollback por feature flag.