# Privacidade (LGPD) e integridade das conversões

Este guia descreve o que o CDP Edge faz com dados pessoais e o que fica a cargo de quem instala.
Ele **não substitui** a análise jurídica do controlador dos dados (o seu cliente): política de
privacidade, base legal de cada finalidade e banner de cookies continuam sendo responsabilidade dele.

## 1. Consentimento

O SDK envia em todo evento um sinal `consent`:

| Situação no navegador | `consent.ads` / `consent.analytics` |
|---|---|
| Usuário aceitou (`cdpTrack.updateConsent({ ads: true, analytics: true })`) | `granted` |
| Usuário recusou (`updateConsent({ ads: false })`) | `denied` |
| Usuário ainda não escolheu | `pending` |

O Worker aplica assim:

| Sinal | Meta CAPI / TikTok (`ads`) | GA4 (`analytics`) | Lead no D1 |
|---|---|---|---|
| `granted` | envia | envia | grava |
| `denied` | **não envia** | **não envia** | grava |
| `pending` ou ausente | envia (padrão) — **não envia** com `REQUIRE_CONSENT=1` | idem | grava |

- A recusa explícita **sempre** é respeitada, em qualquer configuração.
- `REQUIRE_CONSENT=1` liga o modo estrito: só envia às plataformas com `granted`. Recomendado quando o
  site tem banner de cookies integrado ao `updateConsent`. Sem banner, o modo estrito zera o envio.
- O lead continua gravado no D1: é o registro do contato que o próprio titular enviou ao seu cliente.
- Compras vindas dos webhooks de checkout não passam pelo navegador e não carregam sinal de consentimento.

```bash
wrangler secret put REQUIRE_CONSENT   # valor: 1
```

## 2. Purchase vindo do navegador

`/track` é público. Para impedir compras falsas no Pixel e contagem dupla com o webhook:

| `BROWSER_PURCHASE` | Comportamento |
|---|---|
| `auto` (padrão) | bloqueia o `Purchase` do navegador **quando há webhook de checkout configurado** (`WEBHOOK_SECRET_HOTMART`, `_KIWIFY` ou `_TICTO`). A compra vem do webhook, que é autenticado. |
| `on` | sempre envia (checkout próprio sem webhook) |
| `off` | nunca envia |

Bloqueado, o evento não vai às plataformas e é gravado no D1 como `PurchaseBrowser`, separado das compras
do webhook. Eventos `Purchase` de tráfego identificado como bot são descartados.

```bash
wrangler secret put BROWSER_PURCHASE  # auto | on | off
```

## 3. Direitos do titular (art. 18)

Exclusão dos dados de uma pessoa, a pedido dela:

```bash
curl -X POST -H "Authorization: Bearer $ADMIN_API_TOKEN" -H "Content-Type: application/json" \
     -d '{"email":"pessoa@exemplo.com","phone":"11999998888"}' \
     https://SEU-WORKER/admin/privacy/delete
```

Remove leads, perfil, eventos, sequências de nurture, histórico de mensagens, fingerprints, sinais de
fraude e webhooks ligados ao e-mail/telefone, e apaga os payloads de falha (`api_failures`) que contêm o
hash do titular. A resposta traz o número de linhas por tabela. A operação é irreversível.

Fora do alcance desta rota: dados já enviados às plataformas (Meta, Google, TikTok…) — peça a exclusão
pelos canais de cada uma — e logs no R2 (`AUDIT_LOGS`), que guardam só o `userId` pseudônimo. Use regras
de ciclo de vida do bucket R2 para expirá-los.

## 4. Retenção

Defina o prazo e o cron semanal anonimiza os dados pessoais mais antigos que ele:

```bash
wrangler secret put DATA_RETENTION_DAYS   # ex.: 365 (mínimo 30)
```

- `leads`: apaga e-mail, telefone, nome, IP e payload bruto (as métricas de evento, valor e UTM ficam).
- `user_profiles`: apaga e-mail e telefone.
- `webhook_events` e `api_failures`: apagam o payload bruto.
- `nurture_sequences`, `fraud_signals`, `edge_fingerprints`: linhas antigas são excluídas.

Vazio = desligado (comportamento anterior). Aplicar agora, sem esperar o cron:

```bash
curl -X POST -H "Authorization: Bearer $ADMIN_API_TOKEN" -H "Content-Type: application/json" \
     -d '{"days":365}' https://SEU-WORKER/admin/privacy/purge
```

A anonimização é irreversível. Confira o prazo com o seu cliente antes de ligar.

## 5. O que fica guardado

| Onde | Dados pessoais | Observação |
|---|---|---|
| D1 `leads` | e-mail, telefone, nome, cidade, IP, payload | em texto: necessário para o hash enviado às plataformas |
| D1 `user_profiles` | e-mail, telefone, cidade, cookies de clique | perfil unificado |
| Plataformas de anúncio | e-mail, telefone, nome etc. **em SHA-256**; IP e User-Agent sem hash | exigência das APIs de conversão |
| R2 `AUDIT_LOGS` | `userId` pseudônimo, UTM, geo | sem e-mail/telefone |