Contactos e consentimento
Uma lista que podes defender, não apenas uma lista que tens
Qualquer pessoa pode ter dez mil endereços de e-mail. A pergunta que importa — aquela que um regulador, um fornecedor e a tua própria consciência fazem, cada um com palavras ligeiramente diferentes — é de onde veio cada um deles e com que base podes escrever-lhe. O ClickSomo transforma isso num facto armazenado em vez de algo que terias de reconstruir.
A identidade é o endereço de e-mail
Um contacto por endereço por projeto, imposto pela base de dados e não pela esperança. Os endereços são normalizados quando são escritos, nunca quando são lidos — normalizar na leitura torna a restrição uma decoração que deixa Anna@ e anna@ entrar ambos.
Os números de telefone são armazenados em E.164 quando existem, mas um número de telefone é um atributo, não uma identidade. Não há grafo de resolução de identidades, nem protocolo de fusão, nem registo de auditoria de fusões, porque cada contacto aqui chega por um canal que já tem um endereço: uma importação, um formulário, uma subscrição, ou o teu próprio código.
O nome é armazenado por inteiro
display_name é mantido exatamente como foi dado e nunca é dividido em partes. Dividir nomes é uma fábrica de erros — "van der Berg", "Kim Min-jun", nomes únicos, títulos, e todas as convenções de ordem que não são anglo-saxónicas — e uma divisão errada aparece numa etiqueta de fusão como "Caro van,", o que é pior do que nenhuma personalização.
As partes estruturadas existem apenas para fontes que já as fornecem separadas. Nada as deriva. E um nome que alguém escreveu nunca é substituído por um CSV posterior que por acaso observou algo diferente, porque a regra da última escrita vence deixa ganhar a importação mais descuidada.
- 1IdentidadeE-mail, normalizado. Único dentro do projeto.
- 2NomeGuardado por inteiro.
first_nameé derivado no momento da renderização, nunca armazenado. - 3AtributosO que quiseres, em JSON. Teus, e interpoláveis como
attrs.*. - 4Etiquetas e listasAs etiquetas são de primeira classe e vivem num único armazém; as listas são pertenças explícitas.
- 5ConsentimentoUma linha por canal, com uma base legal e a sua evidência.
- 6EventosUm registo só de anexação de tudo o que esta pessoa fez. A tabela de que o produto depende.
- ×NuncaNenhuma palavra-passe, nenhum hash, nenhuma sessão, nenhuma chave de API. Uma coluna que autentica alguém seria um incidente, não uma funcionalidade.
Delimitado ao tenant e ao projeto, ambos
O registo de consentimentos
A ausência não é permissão
Uma linha por contacto por canal — e-mail, SMS, carta, push — cada uma com um estado, uma base legal, uma fonte, a evidência, os carimbos temporais e a jurisdição. A um contacto sem linha de base para um canal não se pode enviar nada nesse canal. Não "está sinalizado". Não se pode.
consent
Alguém pediu ativamente. Um envio de formulário com a evidência guardada, uma dupla adesão, uma caixa de seleção que a própria pessoa marcou. Esta é a base mais forte e é a única que um formulário pode produzir.
legitimate_interest
O melhor que uma importação de CSV pode alcançar. Uma folha de cálculo não consegue lembrar-se de alguém ter concordado com algo, por isso nunca lhe é permitido afirmar que sim — e voltar a carregar o mesmo ficheiro não a melhora.
contract
Escreves-lhe por causa de algo em que ambos são parte. O aviso de serviço, a notificação de renovação, aquilo de que a pessoa ficaria chateada por não receber.
Antes de uma campanha ser enviada, vês a mistura de bases do seu público: quantas destas pessoas pediram, quantas estás a alcançar por interesse legítimo e quantas lá estão por causa de um contrato. É um número que impediu mais envios errados do que qualquer faixa de aviso já escrita.
Porque é que isto é mais rigoroso do que o necessário para ti: na verdade não se trata de ti. A reputação do envio em massa é um recurso partilhado, e uma lista descuidada envenena o poço para todos os que enviam pela mesma infraestrutura. As taxas de reclamação e de devolução por tenant são vigiadas, e uma conta cujas taxas ultrapassem o limiar é limitada aqui — antes que um fornecedor o faça a todos de uma vez.
Atrás de cada linha da lista, alguém disse sim.
Quatro formas de entrada
Cada via de entrada na tua lista és tu, a agir sobre os teus próprios dados
Não existe nenhum canal de ingestão com token de serviço nem nenhum produto irmão a escrever silenciosamente nos teus contactos. Se queres alguém numa lista, foi um destes quatro que o colocou lá.
Importação de CSV
Mapeado coluna a coluna, normalizado na escrita, com verificação MX para que domínios mortos ou mal escritos sejam apanhados antes de devolverem um bounce definitivo, e entregue com uma base que defines explicitamente. A importação recebe um id, e cada contacto que criou aponta de volta para ele.
Um formulário ClickSomo
Renderizado a partir do mesmo documento que tudo o resto, com validação, um honeypot e um limite de taxa. Um envio é a única via que pode legitimamente produzir consent, porque é a única em que a pessoa está presente.
Uma página que construíste no dash-b
O designer do dashboard publica páginas; um formulário numa delas envia para aqui com as tuas próprias credenciais. A mesma validação, o mesmo tratamento de consentimento, sem uma segunda integração para manter.
A API pública
POST /v1/contacts com o teu próprio token, semântica de upsert, chave de idempotência respeitada. A tua aplicação já sabe quem se inscreveu; este é o caminho mais curto desse facto até um funil.
Segmentos são um predicado, compilado
Um segmento é uma árvore de predicados armazenada sobre campos de contacto, atributos, tags, pertença a listas e comportamento, compilada para SQL e guardada em cache com uma contagem. Os operadores são os habituais — equals, not equals, in, not in, starts with, ends with, contains, is set, is not set — combinados com and, or e not até à profundidade de que precisares.
Previsualiza-o antes de o usares. O endpoint devolve contactos reais, por isso "quem está realmente aqui dentro" é uma pergunta que respondes olhando, e não enviando e descobrindo depois.
Os segmentos fazem depois dupla função: como audiência de uma campanha, como condição num ramo de funil e como gatilho por direito próprio — segment_enter inicia uma execução no momento em que alguém se torna elegível.
- 1Tag
tags contains "regular" - 2Atributo
attrs.total_orders >= 3— o teu campo, o teu nome para ele. - 3ComportamentoNenhum evento
order.paidnos últimos 90 dias. - 4ConsentimentoUma base de e-mail utilizável. Contactos sem uma não entram na contagem, porque de qualquer forma não podiam receber envios.
- iPré-visualização412 contactos, listados. Recontados no envio, porque um segmento é uma pergunta e não uma fotografia.
Compilado para SQLContagem em cache, resposta em tempo real
Supressão, e quando é verificada
As supressões são por projeto e globais: bounces definitivos, reclamações, cancelamentos de subscrição, entradas manuais e endereços de função. São verificadas no momento do envio, e depois novamente dentro do próprio serviço de envio.
Essa segunda verificação é que faz o trabalho. Um funil com uma espera de três dias tem uma janela de três dias em que alguém pode cancelar a subscrição, e um sistema que verificou a supressão quando a mensagem foi colocada em fila enviar-lhe-á na mesma. Verificar no envio é a diferença entre honrar um cancelamento e apenas registá-lo.
A eliminação funciona da mesma forma: um pedido de eliminação remove o contacto e o seu histórico de mensagens aqui, e chega a todos os serviços irmãos que tinham uma cópia através do mesmo canal interno que o resto da família usa. Há um único lugar onde pedir e uma única coisa que acontece.