Source: https://bridgeeme.com/pt/docs/parceiros.html

Documentação / Parceiros

# Parceiros

Integração

## O que o parceiro recebe

Click macroID nativo + Bridgee ID

Install matchdecisão neutra e versionada

Eligibilityconsent + contrato + idempotência

Postbackdelivered, retry ou suppressed 

Registro

## Regras por canal

| Canal | Entrada | Saída | Observação | 
| --- | --- | --- | --- |

| Google | 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 | 

Postback

## 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.

Eventos

## 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 | 

Auditoria

## Como acompanhar postbacks

### Status

queued, delivered, retry_wait, dead_letter ou suppressed.

### 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.

Confiança

## 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.

Onboarding parceiro

## 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.