Status
queued, delivered, retry_wait, dead_letter ou suppressed.
Parceiros
O que o parceiro recebe
Click macroID nativo + Bridgee ID
Install matchdecisão neutra e versionada
Eligibilityconsent + contrato + idempotência
Postbackdelivered, retry ou suppressed
Regras por canal
| Canal | Entrada | Saída | Observação |
|---|---|---|---|
| gclid/gbraid/referrer | fluxo aprovado Google | deduplicar atribuição nativa Firebase | |
| Meta | fbclid ou payload aprovado | adapter contratado | fbclid isolado não garante postback de app |
| TikTok | ttclid/payload aprovado | adapter contratado | validar onboarding e Events Manager |
| DSP | macro → partner_click_id | URL assinada configurável | schema, auth e janela por parceiro |
Elegibilidade e entrega
one_resolved_paid_partner native_partner_evidence tenant_integration_enabled consent_and_region_allowed event_allowed_by_contract idempotency_key_not_delivered = eligible_postback
O redirect e o first-open nunca dependem da rede. A decisão cria um item em outbox; workers entregam com retry/backoff e dead-letter auditável.
O que aparece para o parceiro
| Evento | Padrão Bridgee | Conteúdo mínimo |
|---|---|---|
| install | Core | app, OS, timestamp, ID aprovado, consentimento, idempotência |
| reinstall/reopen | por contrato | somente quando política do parceiro permitir |
| purchase | não coletado pelo SDK Bridgee | usar Firebase/GA4 ou integração própria do cliente |
| quality summary | interno/opt-in | agregado; não substituir evento de conversão |
Como acompanhar postbacks
Diagnóstico
response status/code, tentativa, próximo retry e reason codes; payload sensível é redigido.
Reconciliação
Comparar idempotency key, janela, evento e total diário com o painel do parceiro.
Por que confiar nos resultados
- decisão baseada em evidência, não prioridade de canal;
- IDs opacos e preservados sem alteração de caixa;
- conflitos suprimem postback em vez de escolher vencedor arbitrário;
- contratos versionados e fixtures compartilháveis;
- outbox replay-safe e payload hash em auditoria;
- score separado da atribuição e sempre acompanhado de cobertura.
Checklist técnico
Registrar app, contas e ambientes
Sandbox/teste antes de produção.
Definir macros e credenciais
Segredos somente no cofre do servidor.
Mapear eventos e consentimento
Nenhum evento é presumido por semelhança de nome.
Executar fixtures
success, duplicate, expired, conflict, retry e revoked consent.
Ativar por feature flag
Monitorar divergência e manter rollback por tenant.