Última atualização: 14 de agosto de 2026 · Versão 1.4
Este Acordo de Tratamento de Dados Pessoais ("DPA") é parte integrante e inseparável dos Termos de Uso do Sonar e rege o tratamento de dados pessoais realizado pelo Sonar em nome do Cliente, em conformidade com a Lei nº 13.709/2018 (LGPD).
Partes:
• Controlador: o Cliente, pessoa física ou jurídica que contrata o Sonar e determina as finalidades e os meios do tratamento dos dados de seus Titulares.
• Operador: Orion Digital Ltda, CNPJ 67.736.996/0001-79, sede na Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA, CEP 65.605-515 ("Sonar"), que trata os dados pessoais exclusivamente em nome e segundo as instruções do Controlador.
Anexo obrigatório: o documento Destinos de conversão é parte integrante deste DPA e é a fonte da verdade sobre para onde o Sonar envia os dados dos Titulares. Onde este DPA falar em "destino de conversão", a lista é a daquele anexo.
Em caso de conflito entre este DPA e os Termos de Uso quanto à proteção de dados, prevalece este DPA.
1.1. Este DPA disciplina o tratamento, pelo Sonar (Operador), dos dados pessoais dos Titulares finais (visitantes e compradores dos sites do Controlador), coletados por meio do Serviço.
1.2. As partes reconhecem que, quanto a esses dados, o Cliente é o Controlador e o Sonar é o Operador. O Sonar tratará os dados apenas para prestar o Serviço e conforme as instruções documentadas do Controlador (art. 39).
1.3. Os Termos de Uso, a contratação do plano e a configuração do painel constituem as instruções documentadas iniciais do Controlador. Instruções adicionais devem ser formalizadas por escrito.
2.1. Natureza e finalidade: rastreamento server-side, atribuição e deduplicação de eventos, e envio de eventos de conversão aos destinos de conversão ativados pelo Controlador, além de registro de vendas via webhook. Os destinos existentes, o que cada um recebe e em que país fica cada um estão no anexo Destinos de conversão, seção 2.
2.2. Duração: enquanto vigente a contratação, observados os prazos de retenção da cláusula 8.
2.3. Categorias de Titulares: visitantes dos sites do Controlador e compradores/leads gerados por esses sites.
2.4. Categorias de dados pessoais tratados:
_sonar_id (400 dias), fbp, fbc; o script espelha o _sonar_id, o fbc, as UTMs, os identificadores de clique do Google e o cache técnico de checkout no localStorage do navegador (mesmo prazo do cookie correspondente), só para continuidade entre páginas quando o cookie falha;fbclid (Meta), gclid, gbraid, wbraid e gad_source (Google). São parâmetros que a plataforma de anúncio acrescenta ao endereço do site quando o Titular clica no anúncio, e servem para ligar a venda ao clique que a originou;Situação em 14/08/2026 dos identificadores do Google: o Sonar captura e guarda gclid, gbraid, wbraid e gad_source em todo projeto, por 95 dias (cláusula 8.2). Desde 14/08/2026 eles também podem ser enviados ao Google — mas só nos projetos em que o Controlador ligou o destino, que nasce desligado. Guardar e enviar continuam sendo etapas distintas. Ver a seção 7 do anexo de destinos.
2.5. Dados sensíveis (art. 11): o Serviço não se destina ao tratamento de dados sensíveis. Se o produto ou serviço anunciado pelo Controlador revelar dado sensível (ex.: dado de saúde), é responsabilidade do Controlador dispor de base legal específica (art. 11) e das salvaguardas exigidas.
O Sonar obriga-se a:
3.1. Tratar os dados somente conforme as instruções documentadas do Controlador, e não para finalidades próprias (art. 39). Caso uma instrução viole a LGPD, o Sonar informará o Controlador.
3.2. Garantir que as pessoas autorizadas a tratar os dados estejam sujeitas a dever de confidencialidade.
3.3. Implementar e manter as medidas de segurança técnicas e administrativas da cláusula 6 (arts. 46 a 49).
3.4. Auxiliar o Controlador, na medida do razoável e considerando a natureza do tratamento, a: (a) responder aos pedidos de exercício de direitos dos Titulares (art. 18); (b) cumprir os deveres de segurança, comunicação de incidentes, relatório de impacto (art. 38) e consulta prévia.
3.5. Disponibilizar ao Controlador as informações necessárias para demonstrar o cumprimento das obrigações deste DPA, nos termos da cláusula 9.
3.6. Manter registro das operações de tratamento que realiza como Operador (art. 37).
3.7. Não realizar uso compartilhado dos dados fora do previsto neste DPA.
3.8. Não ativar destino de conversão por conta própria. Nenhum destino é ligado por padrão, em bloco, ou por atualização do Serviço. O envio a um destino só começa depois que o Controlador o ativa naquele projeto, na forma da cláusula 4.6 e da seção 3 do anexo de destinos.
O Controlador declara e obriga-se a:
4.1. Possuir base legal válida (art. 7º e, se aplicável, art. 11) para o tratamento e para o envio dos dados aos destinos de conversão que ativar.
4.2. Cumprir os deveres de transparência perante os Titulares (art. 9º) e, quando a base for consentimento, coletar e gerenciar esse consentimento em seu site — inclusive o aviso/banner de cookies e o consentimento para o compartilhamento com cada destino de conversão que o Controlador tiver ativado, conforme a lista do anexo Destinos de conversão.
Consequência prática de ligar um destino novo: o consentimento que o Controlador já coletou pode não cobrir o destino recém-ativado. Avaliar isso — e, se for o caso, atualizar o aviso no site — é dever do Controlador. O Sonar informa que o destino passou a existir (cláusula 5.5); não decide pelo Controlador.
4.3. Fornecer instruções lícitas; responder, como ponto de contato primário, aos Titulares; e configurar o Serviço de acordo com sua base legal.
4.4. Não inserir no Serviço dados sensíveis ou de menores sem amparo legal.
4.5. Responder pelos danos decorrentes do descumprimento de suas obrigações como Controlador, observados os arts. 42 a 44 da LGPD.
4.6. Decidir quais destinos de conversão são ativados, projeto a projeto. A ativação é do Controlador, com a conta de anúncio dele, e vale como instrução documentada (cláusula 1.3) para o envio àquele destino. O Controlador pode desativar um destino a qualquer momento; a desativação vale para os envios seguintes e não desfaz o que já foi entregue ao destino.
5.1. O Controlador autoriza o Sonar a contratar sub-operadores para a prestação do Serviço. Sub-operadores atuais:
| Sub-operador | Função | Localização |
|---|---|---|
| Supabase | Banco de dados e hospedagem de dados | AWS us-east-1 · Virgínia, Estados Unidos |
| Vercel | Hospedagem da aplicação | Região definida na conta Vercel · não declarada em vercel.json |
| Cloudflare · rede | Proxy first-party (Worker) e certificados. Só repassa o tráfego | Rede global |
| Cloudflare · armazenamento (R2) | Guarda o arquivo dos eventos de navegação (bucket sonar-arquivo): identificador do cookie, nome e data/hora do evento, país | Leste da América do Norte (Estados Unidos) |
| Meta Platforms, Inc. | Destino de conversão — recebe os eventos (CAPI). Ativo | Estados Unidos |
| Destino de conversão — recebe as conversões (Data Manager API). Disponível desde 14/08/2026. Nasce desligado em todo projeto: só recebe dado depois que o Controlador liga | Fora do Brasil |
O Google nasce desligado em todo projeto, e quem liga é o Controlador. O caminho de envio existe desde 14/08/2026, e 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, para o Controlador conferir o número.
A autorização é do próprio Controlador, por OAuth: ele autoriza com a conta Google dele, na tela do Google. O Sonar não vê nem guarda a senha — guarda um token de atualização cifrado, e o Controlador pode revogar o acesso quando quiser. Ver a seção 2 do anexo de destinos.
A Cloudflare mudou de papel em 08/08/2026, e o Controlador precisa saber. Até essa data ela era só caminho de rede: o dado passava e não ficava. Desde então ela também armazena uma cópia diária dos eventos de navegação dos Titulares, nos Estados Unidos. O que essa cópia contém e por quanto tempo ela fica está na cláusula 8.4.
Observação sobre os destinos de conversão (vale para TODOS eles, não só para o Meta). Funcionalmente, o destino é escolhido pelo Controlador — é ele quem cadastra a conta de anúncio e liga o envio — e o Sonar só executa. Mas o destino também trata os dados para finalidades próprias, que ele mesmo define e que não seguem instrução do Sonar nem do Controlador. Por isso cada destino aparece nas duas tabelas: aqui, entre os sub-operadores, e na 7.2, entre as transferências internacionais (cláusula 7). Ver a seção 8 do anexo de destinos.
5.2. O Sonar impõe aos sub-operadores obrigações de proteção compatíveis com as deste DPA.
5.3. O Sonar informará o Controlador sobre alterações relevantes de sub-operadores, facultando ao Controlador opor-se por motivo legítimo relacionado à proteção de dados; a oposição não sanável pode ensejar rescisão.
5.4. O Sonar responde perante o Controlador pelos atos de seus sub-operadores nos mesmos limites de suas próprias obrigações.
5.5. Destino de conversão novo é alteração de sub-operador. Incluir um destino no anexo Destinos de conversão aciona a cláusula 5.3: o Sonar informa o Controlador e ele pode se opor. O destino novo entra desligado em todos os projetos (cláusulas 3.8 e 4.6), de modo que o aviso chega antes de qualquer dado ser enviado.
O Sonar mantém, no mínimo:
6.1. Isolamento entre contas por Row Level Security (RLS) em todas as tabelas; leitura restrita ao usuário autenticado.
6.2. Cifragem de tokens de API (pgcrypto) e de tokens de webhook (cifrados e comparados por hash).
Sobre o hash da informação pessoal enviada aos destinos: o Sonar aplica SHA-256 à informação pessoal antes do envio, no formato que cada destino exige — e o formato varia por destino. A tabela campo a campo, com o que vai hasheado e o que vai em claro em cada um, está na seção 4 do anexo Destinos de conversão, que é a fonte da verdade.
O Controlador precisa saber de três coisas, e nenhuma delas é confortável:
1. Nem tudo vai hasheado, e nunca foi. O endereço IP, o user agent e os cookies fbp/fbc são enviados em claro ao Meta — é o formato que o Meta exige. Versões anteriores deste DPA davam a entender o contrário. Corrigido.
2. O Google aceita CEP, cidade, estado, país, nome e sobrenome — e o Sonar NÃO envia nenhum deles. São coisas diferentes, e o Anexo separa as duas em colunas. O Google só casa a conversão por endereço quando recebe nome, sobrenome, país e CEP juntos; 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 dele, saem junto. O que identifica o comprador no envio ao Google é o e-mail, o telefone e o identificador de clique. Onde o Google aceita em claro, hashear faria o envio ser aceito e descartado em silêncio — por isso a promessa de hash é por destino, e não uma regra única.
3. Desde 14/08/2026, o endereço IP e o user agent também vão em claro ao Google, junto com o contexto do clique (endereço da página de entrada, referenciador e os parâmetros gad_* da URL). O Google usa esses campos para casar a conversão com a navegação. Isso vale só nos projetos em que o Controlador ligou o destino.
6.3. Restrição de credenciais privilegiadas (service_role) ao servidor; ausência de segredos expostos ao navegador.
6.4. Limitação de taxa nos endpoints públicos e filtragem de tráfego automatizado.
6.5. Liberação manual de contas e controle de acesso por papéis (dono, editor, leitor) e por escopo de projeto.
6.6. Minimização e retenção limitada (cláusula 8).
7.1. O Controlador precisa saber disto antes de assinar: os dados dos Titulares são ARMAZENADOS FORA DO BRASIL. Não é transferência pontual · é onde o serviço inteiro roda. O banco de dados do Sonar fica em AWS us-east-1, Norte da Virgínia, Estados Unidos (Supabase). Ali estão os visitantes, os eventos, as vendas e o e-mail e telefone dos compradores do Controlador.
São dois lugares, não um. Desde 08/08/2026 existe também o arquivo de eventos na Cloudflare (R2), igualmente nos Estados Unidos, com uma cópia reduzida dos eventos de navegação · cláusula 8.4.
E há os destinos de conversão, que ficam fora do Brasil e recebem dado a mando do Controlador — cada um deles é uma transferência internacional própria.
7.2. Onde cada dado fica:
| Sub-operador | Papel | Guarda o dado? | Onde |
|---|---|---|---|
| Supabase | Banco de dados · é onde o dado do Titular mora | Sim | AWS us-east-1, Virgínia, EUA |
| Vercel | Executa a aplicação; o dado passa para ser processado | Não persistente | Região definida na conta Vercel · não declarada em vercel.json |
| Cloudflare · rede | Proxy first-party, repassa IP e geo do visitante | Não | Rede global |
| Cloudflare · R2 (arquivo) | Guarda o arquivo diário dos eventos de navegação | Sim | Bucket sonar-arquivo, Leste da América do Norte, EUA |
| Meta Platforms | Destino de conversão — recebe os eventos, a mando do Controlador. Ativo | Sim, do lado dele | EUA |
| Destino de conversão — recebe as conversões, a mando do Controlador. Disponível desde 14/08/2026; desligado até o Controlador ligar | Sim, do lado dele, depois que o Controlador liga | Fora do Brasil |
7.3. Tais transferências observam o art. 33 da LGPD, nas hipóteses legais aplicáveis a cada destinatário. O instrumento de garantia de cada fornecedor e de cada destino é, hoje, o termo padrão que ele próprio pratica · ver o aviso abaixo.
Antes do envio a um destino de conversão, o Sonar minimiza o dado transmitido e aplica hash à informação pessoal no formato que aquele destino exige. O que vai hasheado e o que vai em claro, campo a campo e destino a destino, está na seção 4 do anexo Destinos de conversão — inclusive o que não é hasheado hoje (IP, user agent, fbp e fbc ao Meta; IP, user agent e o contexto do clique ao Google, desde 14/08/2026) e o que o Google aceitaria em claro e o Sonar não envia (nome, sobrenome, país, estado, cidade e CEP).
Hash não é anonimização. O destino consegue casar o dado hasheado com quem ele já conhece — é para isso que o hash é enviado. Tratamos o dado hasheado como dado pessoal pseudonimizado.
Um fato que o Controlador precisa saber antes de assinar: hoje o Sonar não tem cláusulas-padrão da ANPD assinadas com os fornecedores de infraestrutura nem com os destinos de conversão. O que existe são os termos padrão que cada um deles pratica. O que é fato verificado são as regiões e os fluxos da cláusula 7.2.
Consequência para o Controlador: como ele é o Controlador dos dados dos Titulares dele, a transferência internacional é dele também. O dever de informar isso aos próprios Titulares, na política de privacidade do site dele, é do Controlador — não do Sonar. Isso vale para cada destino que ele ligar.
7.4. A Stripe está fora deste DPA, e o Controlador precisa saber por quê. A cobrança da assinatura do Sonar é processada pela Stripe, fora do Brasil. Essa transferência envolve os dados do Controlador enquanto Cliente do Sonar (quem paga a assinatura) · não os dados dos Titulares finais deste DPA. Nenhum dado de visitante ou comprador do site do Controlador é enviado à Stripe. O regramento dessa transferência está na seção 6 da Política de Privacidade.
8.1. O critério da retenção. No banco de dados, o dado que identifica um Titular é guardado por 30 dias. Depois disso o Sonar mantém, no banco, apenas contagens agregadas por dia, que não identificam ninguém, para que o histórico do painel do Controlador não se perca.
O prazo é o mesmo em todos os planos. Retenção aqui é regra de proteção de dados, não item de pacote comercial.
A exceção, e ela é nova (08/08/2026): o arquivo de eventos. Antes de apagar o dia do banco, o Sonar grava uma cópia reduzida dos eventos num arquivo fora do banco, na Cloudflare (R2). Essa cópia guarda o identificador do cookie e o país do Titular, e hoje não é apagada. Ver a cláusula 8.4, alínea (c).
Os prazos da cláusula 8.2 foram verificados no código.
8.2. Uma rotina automática executa a cada 2 horas e aplica os prazos:
| Dado | Prazo |
|---|---|
Registro do visitante (visitors) · cookie, IP, user agent, UTMs, geo, e-mail, telefone, nome | Excluído aos 30 dias, a linha inteira |
Evento de navegação individual (events_log), exceto compra | 30 dias, em todos os planos |
JSON técnico do evento (payload_meta/response_meta) | Removido aos 14 dias |
Webhook bruto da venda (raw_webhook), nome, IP, user agent da venda | Removidos aos 14 dias |
E-mail e telefone da venda (purchases) | Anonimizados aos 180 dias (a venda é mantida sem PII) |
Identificador de clique do Google (gclid, gbraid, wbraid) e o contexto técnico do clique · em produção desde 13/08/2026 | 95 dias · ver a exceção abaixo |
A exceção nomeada dos 95 dias, e por que ela não muda o prazo geral. 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 dentro dessa janela. Guardado por 30 dias, o identificador de clique morre antes de a venda acontecer, e essa venda nunca poderá ser enviada — nem depois. Os 95 dias são os 90 do Google mais 5 de folga para a rotina de expurgo rodar.
O que fica 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.
O endereço da página de entrada é gravado como veio. Se o Controlador construir URLs com dado pessoal na query string, esse dado entra aqui junto — é o Controlador quem decide o que põe na própria URL.
Situação em 14/08/2026: o Sonar guarda o identificador de clique do Google desde 13/08/2026, e o prazo de 95 dias não muda. O que mudou é o envio: desde 14/08/2026 o Controlador pode ligar o destino Google e passar a enviar. Guardar e enviar continuam sendo etapas distintas. Detalhes na seção 7 do anexo Destinos de conversão.
8.3. Disjuntor de volume. Além dos prazos acima, cada projeto tem teto de 1.000.000 de eventos; acima disso, os mais antigos saem antes do prazo. É uma proteção de infraestrutura, não uma política de privacidade.
8.4. Dados mantidos sem prazo definido:
purchases) · valor, moeda, produto, status, identificador da transação e atribuição, sem e-mail e sem telefone a partir dos 180 dias.sonar-arquivo da Cloudflare, nos Estados Unidos. O corte só apaga um dia depois que o arquivo daquele dia foi gravado, baixado de volta e conferido.
Para que serve: reconstruir as contagens do painel do Controlador se um erro de agregação for descoberto depois que o dado individual já saiu.
O que vai no arquivo · dez campos, e esta é a lista inteira: identificador interno da linha, projeto, identificador do evento, nome do evento, data e hora, identificador do cookie do Titular (_sonar_id), status do envio, país, e duas marcas técnicas (tráfego de teste e robô).
O que NÃO vai: IP, e-mail, telefone, nome, UTMs, cidade, estado e o JSON técnico do evento. Esses saem no prazo da cláusula 8.2 e não têm cópia.
Prazo: não há. Não existe rotina que apague esse arquivo, nem regra de ciclo de vida configurada no R2. Enquanto isso não existir, a cópia fica por tempo indeterminado. Não escrevemos aqui um prazo que o sistema não cumpre. Decisão pendente do Sonar; quando o prazo existir e estiver em execução, este DPA será atualizado com o número real e o Controlador será informado na forma da cláusula 5.3.
O identificador do cookie é, em regra, dado pessoal (identificador online) · este DPA trata essa cópia como dado pessoal, não como estatística anônima.
Duas observações sobre o corte por tempo de events_log: (1) a régua foi ligada em 08/08/2026 e a data de ativação está registrada no banco: 30 dias, igual nos cinco planos. Hoje ela apaga zero linha · a única conta com tráfego é a conta da própria Orion Digital, marcada como isenta dos limites. Nas contas de Controlador, o corte passa a apagar quando houver histórico mais velho que 30 dias, e só em dia que já tenha arquivo conferido (alínea (c) acima). O outro limite que existe é o teto de 1.000.000 de eventos. (2) Para o resumo agregado não há expurgo agendado · existe rotina escrita com prazo padrão de 3 anos, não ativada. Quando for ativada, este DPA será atualizado.
8.5. Ao término da prestação, o Sonar elimina ou devolve os dados pessoais, a critério do Controlador, salvo obrigação legal de conservação. Os dados sujeitos aos prazos automáticos acima seguirão seu ciclo de eliminação.
O que já foi enviado a um destino de conversão não volta. O Sonar não tem como apagar dado que está dentro do Meta, do Google ou de qualquer outro destino: aquele dado foi entregue a mando do Controlador, e é com o destino que ele precisa tratar a exclusão. A eliminação prevista nesta cláusula alcança o que está com o Sonar.
O arquivo da alínea 8.4(c) não tem eliminação automática. Não existe rotina que o apague. Enquanto ela não existir, eliminar o arquivo de um Controlador que encerrou o contrato depende de ação manual do Sonar, mediante pedido por ajuda@sonartrack.pro.
8.6. Como a devolução funciona na prática. Descrevemos o mecanismo real, e não uma promessa genérica:
9.1. O Sonar disponibilizará ao Controlador, mediante solicitação razoável e não mais que 1 (uma) vez a cada 12 (doze) meses, informações necessárias para demonstrar o cumprimento deste DPA. A frequência não se aplica quando a solicitação decorrer de incidente de segurança comprovado ou de determinação de autoridade competente · nesses casos, o Sonar atende sem limite de frequência.
9.2. Auditorias presenciais, quando cabíveis, observarão aviso prévio razoável, horário comercial, dever de confidencialidade e não poderão comprometer a segurança de outros clientes nem o segredo de negócio do Sonar.
10.1. Ao tomar ciência de incidente de segurança que possa acarretar risco ou dano relevante aos Titulares, o Sonar notificará o Controlador sem demora injustificada, fornecendo as informações disponíveis para que o Controlador cumpra seus deveres de comunicação à ANPD e aos Titulares.
10.2. O dever de comunicar a ANPD e os Titulares cabe ao Controlador (art. 48). O Sonar prestará a cooperação razoável.
11.1. Cada parte responde por suas obrigações na forma da LGPD. O Operador responde solidariamente quando descumprir as obrigações da lei ou não seguir as instruções lícitas do Controlador (art. 42, §1º, I).
11.2. Aplicam-se as limitações de responsabilidade dos Termos de Uso, ressalvado o que a lei considere inafastável.
Este DPA vigora enquanto o Sonar tratar dados pessoais em nome do Controlador e sobrevive à rescisão dos Termos no que for necessário à eliminação/devolução dos dados e ao cumprimento de obrigações legais.
Encarregado (DPO) do Sonar: Felipe Emanoel Silva · oriondigittal@gmail.com
Operador: Orion Digital Ltda, CNPJ 67.736.996/0001-79, Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA, CEP 65.605-515. Contato de suporte: ajuda@sonartrack.pro.
Orion Digital Ltda · CNPJ 67.736.996/0001-79 · Av. Alexandre Costa, 3886, Vila Lobão, Caxias/MA · CEP 65.605-515