Anexo comum aos documentos legais · Última atualização: 14 de agosto de 2026 · Versão 1.3
Este Anexo é parte integrante dos Termos de Uso, da Política de Privacidade e do DPA do Sonar.
Ele é a fonte da verdade sobre para onde o Sonar envia dados de conversão. Onde aqueles três documentos falarem em "destino de conversão", a lista é a da seção 2 deste Anexo. Nenhum dos três repete a lista — para não haver duas versões dela.
Destino de conversão é a plataforma de anúncio, de terceiro, para a qual o Sonar envia os eventos de conversão a mando do Cliente: uma visita, um início de checkout, uma compra.
O Sonar não escolhe destino. Ele executa o envio para os destinos que o Cliente ligou, com a conta de anúncio que o próprio Cliente cadastrou.
| Destino | Quem opera / onde | O que recebe | Situação em 14/08/2026 |
|---|---|---|---|
| Meta (Conversions API) | Meta Platforms, Inc. — Estados Unidos | Eventos de conversão do Cliente: nome do evento, data/hora, identificador do evento, URL de origem, dados da transação e dados do visitante (seção 4) | Ativo. É o destino em produção hoje |
| Google (Data Manager API) | Google — fora do Brasil | Conversões do Cliente: identificador de clique de anúncio, dados da transação e dados do visitante (seção 4) | Disponível desde 14/08/2026. O caminho de envio existe e funciona. Entra desligado em todo projeto: só recebe dado depois que o Cliente liga a conta de anúncio e o produto do funil (seção 3) |
O Google nasce desligado em todo projeto, e quem liga é o Cliente. São dois interruptores independentes: um da conta de anúncio e um por produto do funil. Enquanto qualquer um dos dois estiver desligado, nada é enviado.
Antes de ligar, o Sonar opera em modo sombra: monta a conversão inteira e guarda sem enviar. Serve para o Cliente conferir o número antes de ligar. Guardar e enviar continuam sendo etapas distintas.
A autorização é por Cliente, por OAuth: ele autoriza com a própria conta Google, na tela do Google. O Sonar nunca vê nem guarda a senha — guarda um token de atualização cifrado, e o Cliente pode revogar o acesso quando quiser.
Próximos destinos avaliados, e nenhum deles está construído nem contratado: TikTok, Kwai, Shopify e WhatsApp. Só entram nesta tabela quando existirem de fato, e a entrada segue a seção 6.
3.1. Cada destino é ativado por decisão do Cliente, projeto a projeto. Nunca por padrão, nunca em bloco, nunca por atualização do Sonar.
3.2. Ligar um destino exige que o Cliente cadastre a credencial ou a conta de anúncio dele naquele destino. Sem isso o envio não acontece — não há credencial genérica do Sonar servindo de vala comum.
3.3. O Cliente pode desligar um destino a qualquer momento, pelo painel. O desligamento vale para os envios seguintes; não desfaz o que já foi enviado — o dado já entregue está com o destino, e é com ele que o Cliente precisa tratar a exclusão.
3.4. É essa decisão, projeto a projeto, que sustenta juridicamente o item 5: o consentimento que o Cliente coletou dos Titulares dele precisa cobrir os destinos que ele ligou, e ninguém liga um destino por ele.
Hash aqui é SHA-256: o dado vira uma sequência de letras e números e não pode ser lido de volta diretamente.
Isto muda por destino, e não é detalhe. Cada plataforma exige um formato. O que o Meta manda hashear, o Google recebe em claro — e o contrário faria o envio ser aceito e descartado em silêncio.
Leia a tabela com as colunas separadas: a do meio é o que o Google aceita; a da direita é o que o Sonar envia hoje. Não são a mesma coisa — há campo que o Google aceitaria e que o Sonar não manda.
| Dado | Meta (CAPI) — o que o Sonar envia hoje | Google (Data Manager) — o que o Google aceita | Google — o que o Sonar envia hoje |
|---|---|---|---|
| Hasheado | Hasheado. Nos domínios gmail/googlemail, o Google exige remover os pontos e o +sufixo antes do hash | Sim, hasheado (SHA-256) | |
| Telefone | Hasheado, só dígitos, com o código do país, sem o + | Hasheado, no formato E.164 com o + | Sim, hasheado (SHA-256) |
| Nome e sobrenome | Hasheado | Hasheado | Não · ver a nota abaixo da tabela |
| Cidade | Hasheado | EM CLARO | Não · ver a nota abaixo da tabela |
| Estado | Hasheado | EM CLARO | Não · ver a nota abaixo da tabela |
| CEP | Hasheado | EM CLARO | Não · o Sonar não tem esse campo no registro de venda |
| País | Hasheado | EM CLARO (region_code) | Não · ver a nota abaixo da tabela |
Identificador do cookie _sonar_id | Hasheado (vai como external_id) | Não se aplica — o Google não tem campo equivalente | Não se aplica |
Cookies do Facebook fbp e fbc | EM CLARO — é o formato que o Meta exige | Não se aplica | Não se aplica |
Identificador de clique de anúncio (gclid, gbraid, wbraid) | Não se aplica | EM CLARO — o identificador tem campo próprio, sem hash | Sim, em claro, como veio na URL |
| Endereço IP | EM CLARO | EM CLARO | Sim, em claro · novo em 14/08/2026 |
| User agent (navegador) | EM CLARO | EM CLARO | Sim, em claro · novo em 14/08/2026 |
Contexto do clique do Google · endereço da página de entrada, referenciador e parâmetros gad_* da URL | Não se aplica | EM CLARO. O Google usa para casar a conversão com a navegação | Sim, em claro · novo em 14/08/2026 |
| Dados da transação (valor, moeda, identificador do pedido, data/hora) | Em claro — não são dado pessoal por si | Em claro | Sim, em claro |
Por que nome, sobrenome, país, estado e cidade não vão ao Google. O Google só casa uma conversão por endereço quando recebe quatro campos juntos: nome, sobrenome, país e CEP. Endereço pela metade é aceito e descartado em silêncio do lado dele. O Sonar não tem CEP no registro da venda, então o bloco de endereço inteiro fica de fora — e cidade e estado, que só existem dentro desse bloco, saem junto. O que identifica o comprador no envio ao Google é o e-mail, o telefone e o identificador de clique.
Correção de uma imprecisão dos documentos anteriores. Até a versão 1.1, o DPA e a Política davam a entender que toda informação pessoal ia hasheada ao Meta. Não é verdade, e nunca foi: o endereço IP, o user agent e os cookies fbp/fbc sempre foram enviados em claro — o Meta exige assim, e sem eles a correspondência do evento cai. Isto está corrigido aqui e nos três documentos. Não é uma mudança de produto; é o texto passando a descrever o que o código sempre fez (lib/meta/capi.ts, função buildUserData).
Hash não é anonimização. O destino consegue casar o hash com quem ele já conhece — é exatamente para isso que o hash é enviado. Tratamos o dado hasheado como dado pessoal pseudonimizado, não como dado anônimo.
A lista do que vai ao Google quando o Cliente liga o destino, e ela é inteira: o identificador de clique (gclid, gbraid ou wbraid); o identificador da transação, o valor, a moeda e a data/hora da venda; o e-mail e o telefone do comprador com hash SHA-256; e, em claro, o endereço IP, o user agent e o contexto do clique.
O que NÃO vai: nome, sobrenome, país, estado, cidade e CEP.
Onde estão os fatos de cada coluna: a coluna do Meta foi lida no código do Sonar (lib/meta/capi.ts). A coluna "o que o Google aceita" veio da documentação oficial de formatação da Data Manager API, registrada no levantamento interno do Sonar sobre a Google Ads API, seção 4, com a fonte. A coluna "o que o Sonar envia hoje" foi lida no código que monta o envio (lib/google/), campo a campo. Nada aqui foi deduzido por analogia entre as duas plataformas — foi analogia que criou o problema que esta tabela resolve.
5.1. Quando a base legal do Cliente (Controlador) for o consentimento, ele precisa cobrir o compartilhamento com cada destino que o Cliente ligou — não com "plataformas de anúncio" em geral, e não com um destino específico nomeado no contrato.
5.2. A lista da seção 2 e a coluna "Situação" existem para que o Cliente saiba exatamente o que precisa constar no aviso do site dele.
5.3. Ligar um destino novo pode exigir do Cliente atualizar o aviso e o consentimento no site dele. Essa avaliação é do Cliente, como Controlador. O Sonar avisa que o destino existe (seção 6); não decide pelo Cliente.
5.4. O campo de consentimento do Google (Consent Mode v2) é opcional na API e diz respeito a tráfego do Espaço Econômico Europeu e do Reino Unido. Para tráfego brasileiro não há campo obrigatório a preencher. Isso não substitui a base legal do Cliente — a exigência da LGPD continua inteira.
6.1. Incluir um destino novo é uma alteração de sub-operador e aciona a cláusula 5.3 do DPA: o Sonar informa o Controlador, que pode se opor por motivo legítimo ligado à proteção de dados.
6.2. O destino novo entra desligado para todos os projetos (seção 3).
6.3. A data de entrada de um destino e qualquer mudança na coluna "Situação" são registradas na tabela da seção 2 e na versão deste Anexo.
6.4. Mudança de formato de envio (o que vai hasheado, o que vai em claro) é atualizada na seção 4 antes de o envio mudar, não depois.
7.1. A regra geral continua sendo a das cláusulas 8 do DPA e 8.4 da Política: no banco de dados, o dado que identifica um Titular é apagado aos 30 dias.
7.2. A exceção, e é uma só: o identificador de clique do Google (gclid, gbraid, wbraid) precisa ser guardado por 95 dias.
Por quê, sem rodeio: o Google aceita receber a conversão de um clique que aconteceu há até 90 dias. Boleto pago com atraso, Pix esquecido e recuperação de carrinho caem exatamente nessa janela. Guardado por 30 dias, o identificador morre antes da venda acontecer, e a venda nunca poderá ser enviada — nem depois. Os 95 dias são os 90 do Google mais uma folga de 5 para a rotina de expurgo rodar.
O que é guardado nessa exceção: o identificador de clique, o projeto, a data e o contexto técnico do clique — o endereço da página de entrada, o user agent e o endereço IP. Esses três acompanham o identificador porque a plataforma de anúncio os exige junto para reconhecer a conversão; separados, o identificador sozinho não é aceito.
Não entram nessa exceção o e-mail e o telefone, que seguem o prazo próprio deles (seção 8.4 da Política).
O endereço da página de entrada é gravado como veio. Se o Cliente construir URLs com dado pessoal na query string, esse dado entra aqui junto — é o Cliente, como Controlador, quem decide o que põe na própria URL.
7.3. Situação em 14/08/2026. O Sonar guarda o identificador de clique do Google desde 13/08/2026, em todo projeto, e o prazo de 95 dias continua o mesmo. O que mudou em 14/08/2026 é o envio: o Cliente já pode ligar o destino Google e passar a enviar. Guardar e enviar continuam sendo coisas distintas — o Sonar guarda em todo projeto e só envia nos projetos em que o Cliente ligou.
Isto vale para todos os destinos da seção 2.
O destino é escolhido pelo Cliente — é ele quem cadastra a conta de anúncio e liga o envio — e o Sonar só executa o envio.
Mas o destino também trata os dados para finalidades próprias, definidas por ele: otimização de campanha, modelagem e políticas da plataforma. Nessas finalidades ele não segue instrução do Sonar nem do Cliente.
Por isso cada destino aparece nas duas tabelas dos documentos: na de sub-operadores e na de transferência internacional (arts. 33 a 36). E por isso o que já foi entregue a um destino é tratado com ele, não com o Sonar (seções 3.3 e 7).
Orion Digital Ltda · CNPJ 67.736.996/0001-79 · Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA · CEP 65.605-515