Como Construímos um CRM de E-mail Marketing do Zero para Recuperar o Controle de Dados Pessoais
Um estudo de caso detalhado sobre como uma empresa construiu um CRM de e-mail marketing personalizado para garantir a segurança e o controle total dos dados pessoais de seus clientes. O artigo explora os desafios de usar plataformas externas, a decisão de desenvolver uma solução interna, e os resultados alcançados.
MundiX News·21 de maio de 2026·7 min de leitura·👁 18 views
Olá, Habr! Meu nome é Aleksey Postrigaylo, sou sócio sênior da integradora de TI “Ensign”. Há mais de 20 anos, trabalho com integração de sistemas e gerenciamento de projetos. Hoje, quero compartilhar a história de um projeto que começou com uma tarefa aparentemente rotineira — o envio de e-mails. Mas, como costuma acontecer, o diabo estava nos detalhes, especificamente — nos dados pessoais.
1) Definição do problema: o preço da dependência de plataformas externas
Um cliente nos procurou com a seguinte tarefa: precisava de um sistema CRM para e-mail marketing que funcionasse dentro de nosso perímetro de segurança. Além disso, o sistema deveria funcionar totalmente com dados pessoais (DP): armazená-los, gerenciar consentimentos, personalizar conteúdo e registrar meticulosamente cada ação do usuário (ver Figura 1). Os serviços online populares existentes para essa tarefa não eram mais adequados. Nossos cenários de trabalho foram muito além de sua funcionalidade padrão, onde o envio de e-mails é apenas a ponta do iceberg.
2) Escolha da solução: própria ou pronta?
A primeira pergunta que a equipe enfrentou foi: adaptar um serviço em nuvem pronto ou desenvolver nossa própria solução do zero? À primeira vista, ambas as opções funcionam. Enviar e-mails não é problema, qualquer serviço decente pode fazer isso. No entanto, em projetos como este, os requisitos regulatórios (152-FZ, Ordem nº 21 do FSTEC, etc.) ditam a arquitetura. Portanto, para não cometer erros, nos fizemos imediatamente algumas perguntas-chave:
Onde os dados serão armazenados?
Fundamentalmente — eles não devem sair do perímetro do cliente. Sem histórias de “nuvem” com terceiros.
Quem controlará este perímetro?
Serviços externos não fornecem a flexibilidade necessária. Você depende de seu suporte técnico, atualizações e políticas de segurança.
Como será mantido o registro de ações e consentimentos?
Precisávamos de um registro completo e comprovável (log) de cada ação: desde o upload de dados até a revogação do consentimento.
Quão profundamente a lógica pode ser personalizada?
Precisávamos de lógica personalizada de gerenciamento de consentimento, e não apenas uma caixa de seleção “concordo”.
Um serviço pronto é conveniente, não há dúvida. Conectou, configurou e pronto. Mas assim que se trata do controle total dos dados, essa conveniência se transforma em abóbora. Ela se choca com as estruturas rígidas da plataforma.
Um exemplo simples: serviços populares de envio de e-mails oferecem o 4º nível de proteção de dados pessoais (UZ-4), enquanto os requisitos da legislação em nosso caso ditavam no mínimo o segundo (UZ-2). Confiar tal volume de DP a uma API de terceiros, mesmo a mais protegida, é quase o mesmo que deixar a chave do apartamento sob o tapete. Sempre há um risco. Portanto, depois de pesar os prós e contras, nos movemos em direção ao desenvolvimento de nosso próprio CRM no Django.
3) Tarefas e nossas soluções
Contarei sobre as tarefas que resolvemos e as ferramentas que usamos para isso.
Tarefa: garantir o armazenamento de dados e a comprovação de ações
A parte mais sensível foi o trabalho com dados. Para garantir seu armazenamento e a comprovação de ações, primeiro, colocamos dados de contato, status de consentimento e rótulos de serviço em um único modelo. Para o nosso caso, isso foi otimizado: essa abordagem simplificou as consultas e o processamento, pois o sistema funcionava com um pequeno número de entidades e baixa carga.
Em segundo lugar, para rastrear todas as manipulações com dados pessoais, usamos os mecanismos de registro integrados ao Django. Qualquer ação, seja a importação de um contato ou a confirmação de um consentimento, com uma marca de tempo, caía no registro (ver Figura 2). Isso nos deu a oportunidade de rastrear o ciclo de vida completo do processamento de dados pessoais.
Para cada usuário, geramos um identificador único (UID). Para isso, usamos o algoritmo criptograficamente forte binascii.hexlify(os.urandom(64)).decode(). Na saída, obtivemos uma string de 128 caracteres. Você pode imaginar quais são as chances de selecionar ou adivinhar aleatoriamente uma chave como essa para um banco de dados de 70 mil usuários? Correto, quase zero.
Tarefa: criar e-mails personalizados e visualmente atraentes
Uma tarefa separada é dar ao cliente uma ferramenta para criar e-mails bonitos e pessoais. Para isso, incorporamos um editor de modelos no CRM para que os layouts pudessem ser criados diretamente no sistema, sem pular para serviços de terceiros. Para personalização, usamos placeholders (por exemplo, FIO). Ao enviar, eles foram substituídos automaticamente pelos dados reais do usuário. Também adicionamos um sistema flexível de filtros para que você possa facilmente formar envios para segmentos específicos do público. Essas ferramentas simples, em geral, removeram a rotina do processo, reduziram o risco de erro devido ao fator humano e aceleraram significativamente a preparação das campanhas.
Tarefa: coletar estatísticas sem usar serviços externos
Como escrevemos o serviço do zero, não tínhamos ferramentas de análise sofisticadas como as de plataformas prontas. E não podíamos usá-las por motivos de segurança. A tarefa de coletar estatísticas de abertura de e-mails foi resolvida da maneira antiga — com a ajuda de um pixel de rastreamento. Adicionamos uma imagem invisível de 1x1 pixel a cada e-mail. Quando uma pessoa abria o e-mail, seu cliente de e-mail acessava nosso servidor para essa imagem. Registramos essa solicitação e, assim, anonimamente, sem coletar dados desnecessários, obtivemos as estatísticas necessárias (ver Figura 3).
Tarefa: garantir alta capacidade de entrega de e-mails
A próxima tarefa importante é garantir a alta capacidade de entrega de e-mails. Para que nossas mensagens voassem para a “Caixa de entrada” e não para o spam, “aquecemos” os servidores de e-mail. Este é um procedimento obrigatório para novos domínios. Antes do lançamento principal, o sistema enviou automaticamente e-mails neutros em pequenas porções para toda a base de assinantes. Graças a esse “aquecimento”, o servidor de e-mail do cliente “conheceu” outros servidores e “ganhou” a reputação de um remetente confiável. Após esse “aquecimento”, todos os 70.000 e-mails foram enviados a uma velocidade próxima à meta — 60.000 e-mails por hora.
Aliás, o cálculo correto do tempo de “aquecimento” e a configuração correta da infraestrutura de e-mail (SPF, DKIM, DMARC) não são alguns “esquemas cinzentos”, mas a base das bases e a economia direta de recursos no futuro. Quem estiver interessado nos detalhes técnicos desse processo, pode ler, por exemplo, aqui. E em um dos próximos artigos, contarei como essa abordagem ajuda a economizar em escala.
Tarefa: automatizar o gerenciamento de consentimentos
Reduzimos ao mínimo o trabalho manual com consentimentos. Para isso, desenvolvemos um algoritmo que processava as respostas da página de confirmação de consentimento. Seus resultados exibimos através de um módulo separado no painel administrativo do CRM, para que o acesso ao banco de dados com os status atuais fosse o mais rápido possível. O sistema gerenciava os consentimentos automaticamente: o usuário clicou em “Concordo” — o status foi atualizado no banco de dados, uma entrada apareceu no registro. Clicou em “Recusar” — recebeu o status correspondente, e seus dados foram imediatamente excluídos dos envios ativos. Sem edições manuais, tudo estritamente de acordo com a lei 152-FZ.
4) Infraestrutura e razoável suficiência
Com um aplicativo, essa tarefa não pode ser fechada. A lógica de trabalho com dados foi apenas parte da solução. Não menos importante foi em qual perímetro o sistema vive e como o acesso a ele é organizado.
Para criar uma infraestrutura segura, usamos uma pilha de tecnologias russas: RED OS, hospedagem em um segmento certificado Selectel, antivírus Dr.Web e Secret Net Studio para Linux para controle de acesso.
Ao mesmo tempo, decidimos conscientemente não implementar algumas medidas de proteção, em nossa opinião, redundantes. Por exemplo, a criptografia de todo o banco de dados ou a implantação de servidores VPN separados para acesso. Tais decisões complicariam seriamente a arquitetura e aumentariam o custo de propriedade do sistema.
Avaliamos os riscos, a carga e os cenários de uso e conscientemente escolhemos um nível de proteção suficiente em vez de excessivo. Nosso objetivo era segurança real, adequada ao processo, e não segurança “em papel” para marcar presença.
5) Resultados
NO TOTAL, o que obtivemos na saída:
Prazos: O backend foi escrito em 2 semanas.
Todo o projeto turnkey, sem contar a aprovação do design, levou 3 semanas.
Escala: o sistema atendeu com confiança uma base de 70.000 usuários.
Automação: a coleta e o gerenciamento de consentimentos foram automatizados em 100%. Antes do evento principal, o cliente recebeu uma base totalmente pronta para envio, atualizada, com um clique.
Independência: o cliente recebeu 100% de independência de serviços de e-mail marketing externos e suas políticas.
Quais conclusões tirei para mim?
Este estudo de caso é um excelente lembrete: o sistema pode parecer simples em termos de conjunto de funções, mas assim que se trata de DP, segurança e auditoria, sua complexidade real aumenta drasticamente. Não é possível garantir a conformidade com a lei simplesmente escrevendo um bom código. Este é sempre um trabalho em três níveis, como três baleias, sobre as quais tudo se baseia: a lógica do próprio aplicativo, uma infraestrutura construída de forma competente e processos ajustados no próprio cliente. Remova uma baleia — e toda a estrutura entrará em colapso.
P.S. Este CRM, tendo passado pelo batismo de fogo, acabou se tornando um de nossos produtos de caixa. Então, se você tiver tarefas semelhantes para trabalhar com dados pessoais — você sabe a quem recorrer. Teremos prazer em ajudar.
Obrigado por ler! Assine para ficar por dentro!
Tags:
CRM do zero
Dados pessoais
Gerenciamento de consentimento
Automação de processos
Segurança de dados
Pixel de rastreamento
Infraestrutura interna
Django
Habrs:
Sistemas CRM
Bancos de dados
Segurança da informação
Administração de sistemas
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá, Habr! Meu nome é Aleksey Postrigaylo, sou sócio sênior da integradora de TI “Ensign”. Há mais de 20 anos, trabalho com integração de sistemas e gerenciamento de projetos. Hoje, quero compartilhar a história de um projeto que começou com uma tarefa aparentemente rotineira — o envio de e-mails. Mas, como costuma acontecer, o diabo estava nos detalhes, especificamente — nos dados pessoais.
1) Definição do problema: o preço da dependência de plataformas externas
Um cliente nos procurou com a seguinte tarefa: precisava de um sistema CRM para e-mail marketing que funcionasse dentro de nosso perímetro de segurança. Além disso, o sistema deveria funcionar totalmente com dados pessoais (DP): armazená-los, gerenciar consentimentos, personalizar conteúdo e registrar meticulosamente cada ação do usuário (ver Figura 1). Os serviços online populares existentes para essa tarefa não eram mais adequados. Nossos cenários de trabalho foram muito além de sua funcionalidade padrão, onde o envio de e-mails é apenas a ponta do iceberg.
2) Escolha da solução: própria ou pronta?
A primeira pergunta que a equipe enfrentou foi: adaptar um serviço em nuvem pronto ou desenvolver nossa própria solução do zero? À primeira vista, ambas as opções funcionam. Enviar e-mails não é problema, qualquer serviço decente pode fazer isso. No entanto, em projetos como este, os requisitos regulatórios (152-FZ, Ordem nº 21 do FSTEC, etc.) ditam a arquitetura. Portanto, para não cometer erros, nos fizemos imediatamente algumas perguntas-chave:
Onde os dados serão armazenados?
Fundamentalmente — eles não devem sair do perímetro do cliente. Sem histórias de “nuvem” com terceiros.
Quem controlará este perímetro?
Serviços externos não fornecem a flexibilidade necessária. Você depende de seu suporte técnico, atualizações e políticas de segurança.
Como será mantido o registro de ações e consentimentos?
Precisávamos de um registro completo e comprovável (log) de cada ação: desde o upload de dados até a revogação do consentimento.
Quão profundamente a lógica pode ser personalizada?
Precisávamos de lógica personalizada de gerenciamento de consentimento, e não apenas uma caixa de seleção “concordo”.
Um serviço pronto é conveniente, não há dúvida. Conectou, configurou e pronto. Mas assim que se trata do controle total dos dados, essa conveniência se transforma em abóbora. Ela se choca com as estruturas rígidas da plataforma.
Um exemplo simples: serviços populares de envio de e-mails oferecem o 4º nível de proteção de dados pessoais (UZ-4), enquanto os requisitos da legislação em nosso caso ditavam no mínimo o segundo (UZ-2). Confiar tal volume de DP a uma API de terceiros, mesmo a mais protegida, é quase o mesmo que deixar a chave do apartamento sob o tapete. Sempre há um risco. Portanto, depois de pesar os prós e contras, nos movemos em direção ao desenvolvimento de nosso próprio CRM no Django.
3) Tarefas e nossas soluções
Contarei sobre as tarefas que resolvemos e as ferramentas que usamos para isso.
Tarefa: garantir o armazenamento de dados e a comprovação de ações
A parte mais sensível foi o trabalho com dados. Para garantir seu armazenamento e a comprovação de ações, primeiro, colocamos dados de contato, status de consentimento e rótulos de serviço em um único modelo. Para o nosso caso, isso foi otimizado: essa abordagem simplificou as consultas e o processamento, pois o sistema funcionava com um pequeno número de entidades e baixa carga.
Em segundo lugar, para rastrear todas as manipulações com dados pessoais, usamos os mecanismos de registro integrados ao Django. Qualquer ação, seja a importação de um contato ou a confirmação de um consentimento, com uma marca de tempo, caía no registro (ver Figura 2). Isso nos deu a oportunidade de rastrear o ciclo de vida completo do processamento de dados pessoais.
Para cada usuário, geramos um identificador único (UID). Para isso, usamos o algoritmo criptograficamente forte binascii.hexlify(os.urandom(64)).decode(). Na saída, obtivemos uma string de 128 caracteres. Você pode imaginar quais são as chances de selecionar ou adivinhar aleatoriamente uma chave como essa para um banco de dados de 70 mil usuários? Correto, quase zero.
Tarefa: criar e-mails personalizados e visualmente atraentes
Uma tarefa separada é dar ao cliente uma ferramenta para criar e-mails bonitos e pessoais. Para isso, incorporamos um editor de modelos no CRM para que os layouts pudessem ser criados diretamente no sistema, sem pular para serviços de terceiros. Para personalização, usamos placeholders (por exemplo, FIO). Ao enviar, eles foram substituídos automaticamente pelos dados reais do usuário. Também adicionamos um sistema flexível de filtros para que você possa facilmente formar envios para segmentos específicos do público. Essas ferramentas simples, em geral, removeram a rotina do processo, reduziram o risco de erro devido ao fator humano e aceleraram significativamente a preparação das campanhas.
Tarefa: coletar estatísticas sem usar serviços externos
Como escrevemos o serviço do zero, não tínhamos ferramentas de análise sofisticadas como as de plataformas prontas. E não podíamos usá-las por motivos de segurança. A tarefa de coletar estatísticas de abertura de e-mails foi resolvida da maneira antiga — com a ajuda de um pixel de rastreamento. Adicionamos uma imagem invisível de 1x1 pixel a cada e-mail. Quando uma pessoa abria o e-mail, seu cliente de e-mail acessava nosso servidor para essa imagem. Registramos essa solicitação e, assim, anonimamente, sem coletar dados desnecessários, obtivemos as estatísticas necessárias (ver Figura 3).
Tarefa: garantir alta capacidade de entrega de e-mails
A próxima tarefa importante é garantir a alta capacidade de entrega de e-mails. Para que nossas mensagens voassem para a “Caixa de entrada” e não para o spam, “aquecemos” os servidores de e-mail. Este é um procedimento obrigatório para novos domínios. Antes do lançamento principal, o sistema enviou automaticamente e-mails neutros em pequenas porções para toda a base de assinantes. Graças a esse “aquecimento”, o servidor de e-mail do cliente “conheceu” outros servidores e “ganhou” a reputação de um remetente confiável. Após esse “aquecimento”, todos os 70.000 e-mails foram enviados a uma velocidade próxima à meta — 60.000 e-mails por hora.
Aliás, o cálculo correto do tempo de “aquecimento” e a configuração correta da infraestrutura de e-mail (SPF, DKIM, DMARC) não são alguns “esquemas cinzentos”, mas a base das bases e a economia direta de recursos no futuro. Quem estiver interessado nos detalhes técnicos desse processo, pode ler, por exemplo, aqui. E em um dos próximos artigos, contarei como essa abordagem ajuda a economizar em escala.
Tarefa: automatizar o gerenciamento de consentimentos
Reduzimos ao mínimo o trabalho manual com consentimentos. Para isso, desenvolvemos um algoritmo que processava as respostas da página de confirmação de consentimento. Seus resultados exibimos através de um módulo separado no painel administrativo do CRM, para que o acesso ao banco de dados com os status atuais fosse o mais rápido possível. O sistema gerenciava os consentimentos automaticamente: o usuário clicou em “Concordo” — o status foi atualizado no banco de dados, uma entrada apareceu no registro. Clicou em “Recusar” — recebeu o status correspondente, e seus dados foram imediatamente excluídos dos envios ativos. Sem edições manuais, tudo estritamente de acordo com a lei 152-FZ.
4) Infraestrutura e razoável suficiência
Com um aplicativo, essa tarefa não pode ser fechada. A lógica de trabalho com dados foi apenas parte da solução. Não menos importante foi em qual perímetro o sistema vive e como o acesso a ele é organizado.
Para criar uma infraestrutura segura, usamos uma pilha de tecnologias russas: RED OS, hospedagem em um segmento certificado Selectel, antivírus Dr.Web e Secret Net Studio para Linux para controle de acesso.
Ao mesmo tempo, decidimos conscientemente não implementar algumas medidas de proteção, em nossa opinião, redundantes. Por exemplo, a criptografia de todo o banco de dados ou a implantação de servidores VPN separados para acesso. Tais decisões complicariam seriamente a arquitetura e aumentariam o custo de propriedade do sistema.
Avaliamos os riscos, a carga e os cenários de uso e conscientemente escolhemos um nível de proteção suficiente em vez de excessivo. Nosso objetivo era segurança real, adequada ao processo, e não segurança “em papel” para marcar presença.
5) Resultados
NO TOTAL, o que obtivemos na saída:
Prazos: O backend foi escrito em 2 semanas.
Todo o projeto turnkey, sem contar a aprovação do design, levou 3 semanas.
Escala: o sistema atendeu com confiança uma base de 70.000 usuários.
Automação: a coleta e o gerenciamento de consentimentos foram automatizados em 100%. Antes do evento principal, o cliente recebeu uma base totalmente pronta para envio, atualizada, com um clique.
Independência: o cliente recebeu 100% de independência de serviços de e-mail marketing externos e suas políticas.
Quais conclusões tirei para mim?
Este estudo de caso é um excelente lembrete: o sistema pode parecer simples em termos de conjunto de funções, mas assim que se trata de DP, segurança e auditoria, sua complexidade real aumenta drasticamente. Não é possível garantir a conformidade com a lei simplesmente escrevendo um bom código. Este é sempre um trabalho em três níveis, como três baleias, sobre as quais tudo se baseia: a lógica do próprio aplicativo, uma infraestrutura construída de forma competente e processos ajustados no próprio cliente. Remova uma baleia — e toda a estrutura entrará em colapso.
P.S. Este CRM, tendo passado pelo batismo de fogo, acabou se tornando um de nossos produtos de caixa. Então, se você tiver tarefas semelhantes para trabalhar com dados pessoais — você sabe a quem recorrer. Teremos prazer em ajudar.
Obrigado por ler! Assine para ficar por dentro!
Tags:
CRM do zero
Dados pessoais
Gerenciamento de consentimento
Automação de processos
Segurança de dados
Pixel de rastreamento
Infraestrutura interna
Django
Habrs:
Sistemas CRM
Bancos de dados
Segurança da informação
Administração de sistemas
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
