Construímos um CRM de E-mail Marketing do Zero para Recuperar o Controle de Dados Pessoais
Um estudo de caso detalhado sobre a criação de um CRM de e-mail marketing personalizado, focando em segurança de dados e conformidade regulatória. O artigo explora os desafios de lidar com dados pessoais, a decisão de construir uma solução própria e as tecnologias utilizadas.
MundiX News·20 de maio de 2026·10 min de leitura·👁 4 views
Olá, Habr! Meu nome é Alexey 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 - e-mail marketing. Mas, como costuma acontecer, o diabo estava nos detalhes, especificamente - nos dados pessoais.
1) Definição do problema: o custo da dependência de plataformas externas
Um cliente veio até nós com a tarefa: precisava de um sistema CRM para e-mail marketing que vivesse 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 e-mail marketing é apenas a ponta do iceberg.
2) Escolha da solução: própria ou pronta?
A primeira questão que a equipe enfrentou: adaptar um serviço em nuvem pronto ou construir sua 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 esse, os requisitos regulatórios (152-FZ, Ordem nº 21 FSTEC, etc.) ditam a arquitetura. Portanto, para não fazer besteira, nos fizemos imediatamente algumas perguntas-chave:
Onde os dados serão armazenados?
Fundamentalmente - eles não devem deixar o perímetro do cliente. Sem histórias de “nuvem” de terceiros.
Quem controlará esse 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 o registro de ações e consentimentos será mantido?
Exigimos um registro completo e comprovável (log) de cada ação: desde o upload de dados até a retirada do consentimento.
Quão profundamente a lógica pode ser configurada?
Precisávamos de lógica personalizada para gerenciar consentimentos, e não apenas uma caixa de seleção “concordo”.
Um serviço pronto é conveniente, não há dúvida. Conectado, configurado e pronto para uso. Mas assim que se trata de controle total sobre os dados, essa conveniência se transforma em abóbora. Ele se choca com a estrutura rígida da plataforma.
Um exemplo simples: serviços populares de e-mail marketing oferecem o 4º nível de proteção de dados pessoais (UZ-4), enquanto os requisitos da legislação em nosso caso ditavam pelo menos 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 os contras, fomos 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 prova de ações
O ponto mais sensível foi o trabalho com dados. Para garantir seu armazenamento e prova de ações, primeiro, colocamos dados de contato, status de consentimento e etiquetas de serviço em um modelo. Para o nosso caso, isso foi otimizado: essa abordagem simplificou as consultas e o processamento, porque o sistema trabalhou 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 do consentimento, com uma marca de tempo, caiu no log (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(). A saída foi uma string de 128 caracteres. Você pode imaginar quais são as chances de escolher 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 ao CRM para que os layouts pudessem ser projetados 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 e-mails marketing para segmentos específicos do público. Essas ferramentas simples, em geral, removeram a rotina do processo, reduziram o risco de erros devido ao fator humano e aceleraram visivelmente 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 em plataformas prontas. E não podíamos usá-los por motivos de segurança. A tarefa de coletar estatísticas sobre a abertura de e-mails foi resolvida da maneira antiga - usando 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 competente 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 processou 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 gerenciou os consentimentos automaticamente: o usuário clicou em “Concordo” - o status foi atualizado no banco de dados, uma entrada apareceu no log. Clicou em “Recusar” - recebeu o status apropriado, e seus dados foram imediatamente excluídos dos e-mails marketing ativos. Sem edições manuais, tudo estritamente de acordo com a letra da 152-FZ.
4) Infraestrutura e razoável suficiência
Um aplicativo não pode fechar essa tarefa. A lógica de trabalhar 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 da 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 redundantes, em nossa opinião. Por exemplo, criptografar todo o banco de dados ou implantar servidores VPN separados para acesso. Tais decisões complicariam seriamente a arquitetura e aumentariam o custo de propriedade do sistema em várias vezes.
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 e adequada ao processo, e não segurança “em papel” para marcar uma caixa.
5) Resultados
NO TOTAL, o que obtivemos na saída:
Prazo: O back-end 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 de consentimentos e seu gerenciamento foram automatizados em 100%. Antes do evento principal, o cliente recebeu uma base totalmente pronta para e-mail marketing e 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 caso é um excelente lembrete: o sistema pode parecer simples em termos de recursos, mas assim que se trata de DP, segurança e auditoria, sua complexidade real aumenta drasticamente. É impossí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 sustenta: a lógica do próprio aplicativo, a infraestrutura construída de forma competente e os 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. Portanto, se você tiver tarefas semelhantes para trabalhar com dados pessoais, sabe a quem recorrer. Teremos prazer em ajudar.
Obrigado por ler! Inscreva-se 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
Olá, Habr! Meu nome é Alexey 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 - e-mail marketing. Mas, como costuma acontecer, o diabo estava nos detalhes, especificamente - nos dados pessoais.
1) Definição do problema: o custo da dependência de plataformas externas
Um cliente veio até nós com a tarefa: precisava de um sistema CRM para e-mail marketing que vivesse 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 e-mail marketing é apenas a ponta do iceberg.
2) Escolha da solução: própria ou pronta?
A primeira questão que a equipe enfrentou: adaptar um serviço em nuvem pronto ou construir sua 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 esse, os requisitos regulatórios (152-FZ, Ordem nº 21 FSTEC, etc.) ditam a arquitetura. Portanto, para não fazer besteira, nos fizemos imediatamente algumas perguntas-chave:
Onde os dados serão armazenados?
Fundamentalmente - eles não devem deixar o perímetro do cliente. Sem histórias de “nuvem” de terceiros.
Quem controlará esse 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 o registro de ações e consentimentos será mantido?
Exigimos um registro completo e comprovável (log) de cada ação: desde o upload de dados até a retirada do consentimento.
Quão profundamente a lógica pode ser configurada?
Precisávamos de lógica personalizada para gerenciar consentimentos, e não apenas uma caixa de seleção “concordo”.
Um serviço pronto é conveniente, não há dúvida. Conectado, configurado e pronto para uso. Mas assim que se trata de controle total sobre os dados, essa conveniência se transforma em abóbora. Ele se choca com a estrutura rígida da plataforma.
Um exemplo simples: serviços populares de e-mail marketing oferecem o 4º nível de proteção de dados pessoais (UZ-4), enquanto os requisitos da legislação em nosso caso ditavam pelo menos 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 os contras, fomos 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 prova de ações
O ponto mais sensível foi o trabalho com dados. Para garantir seu armazenamento e prova de ações, primeiro, colocamos dados de contato, status de consentimento e etiquetas de serviço em um modelo. Para o nosso caso, isso foi otimizado: essa abordagem simplificou as consultas e o processamento, porque o sistema trabalhou 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 do consentimento, com uma marca de tempo, caiu no log (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(). A saída foi uma string de 128 caracteres. Você pode imaginar quais são as chances de escolher 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 ao CRM para que os layouts pudessem ser projetados 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 e-mails marketing para segmentos específicos do público. Essas ferramentas simples, em geral, removeram a rotina do processo, reduziram o risco de erros devido ao fator humano e aceleraram visivelmente 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 em plataformas prontas. E não podíamos usá-los por motivos de segurança. A tarefa de coletar estatísticas sobre a abertura de e-mails foi resolvida da maneira antiga - usando 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 competente 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 processou 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 gerenciou os consentimentos automaticamente: o usuário clicou em “Concordo” - o status foi atualizado no banco de dados, uma entrada apareceu no log. Clicou em “Recusar” - recebeu o status apropriado, e seus dados foram imediatamente excluídos dos e-mails marketing ativos. Sem edições manuais, tudo estritamente de acordo com a letra da 152-FZ.
4) Infraestrutura e razoável suficiência
Um aplicativo não pode fechar essa tarefa. A lógica de trabalhar 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 da 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 redundantes, em nossa opinião. Por exemplo, criptografar todo o banco de dados ou implantar servidores VPN separados para acesso. Tais decisões complicariam seriamente a arquitetura e aumentariam o custo de propriedade do sistema em várias vezes.
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 e adequada ao processo, e não segurança “em papel” para marcar uma caixa.
5) Resultados
NO TOTAL, o que obtivemos na saída:
Prazo: O back-end 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 de consentimentos e seu gerenciamento foram automatizados em 100%. Antes do evento principal, o cliente recebeu uma base totalmente pronta para e-mail marketing e 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 caso é um excelente lembrete: o sistema pode parecer simples em termos de recursos, mas assim que se trata de DP, segurança e auditoria, sua complexidade real aumenta drasticamente. É impossí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 sustenta: a lógica do próprio aplicativo, a infraestrutura construída de forma competente e os 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. Portanto, se você tiver tarefas semelhantes para trabalhar com dados pessoais, sabe a quem recorrer. Teremos prazer em ajudar.
Obrigado por ler! Inscreva-se para ficar por dentro!
