O GDPR, que entrou em vigor em maio deste ano, afetou seriamente o mercado de marketing na Internet. Seus participantes desejam formar o público mais preciso para a exibição de anúncios, mas agora para isso é necessário obter o consentimento explícito do usuário, caso contrário, mesmo um pequeno recurso de nicho pode sofrer multas de vários milhões. Alguns recursos foram fechados, mas muitos estão sendo convertidos para atender a novos requisitos. E nosso projeto de um serviço de gerenciamento de campanhas publicitárias para um cliente dos EUA é um ótimo exemplo disso.
Sobre o serviço
Nosso cliente, uma empresa americana de Los Angeles, concentra-se em marketing na indústria da música. Seu serviço oferece suporte a campanhas publicitárias complexas para equipes de vários tamanhos - de gangues ao virar da esquina às estrelas do cenário mundial.
Em essência, o atendimento ao cliente é uma startup que desenvolve uma plataforma de marketing especializada que conseguiu coletar investimentos de gravadoras, pois leva em consideração as especificidades do comportamento do público em um determinado setor. A plataforma permite que você segmente anúncios analisando o comportamento dos usuários que antes demonstraram interesse em uma equipe específica. Os principais usuários do recurso são músicos e trabalhadores da indústria (gerentes, funcionários de gravadoras, organizadores de shows e muitos outros).
No momento em que nosso projeto começou, o serviço já estava funcionando e conseguiu conquistar uma certa posição no mercado. No entanto, foi um protótipo que testou a hipótese básica de um negócio, principalmente porque parte da funcionalidade foi implementada por meio de serviços de parceiros. Nós nos conectamos ao desenvolvimento para criar uma arquitetura completa, e o GDPR foi o próprio ímpeto que lançou todas as transformações. Nossa tarefa não era apenas atualizar o serviço existente, mas reconstruí-lo com a nova legislação, atualizar e trazer uma interface de usuário mais uniforme.
Implementação
Todo o projeto foi dividido em várias etapas.
Na primeira etapa, reescrevemos do zero a parte que já havia trabalhado no PHP - encurtador de link e serviço de autorização.
O encurtador de link faz parte da funcionalidade disponível gratuitamente para todos os usuários registrados e é usado para atrair clientes para os serviços pagos da empresa. O serviço permite que você traga um link longo para um formulário curto para publicá-lo nas redes sociais. Ao mesmo tempo, você pode personalizar o link definindo, por exemplo, a segmentação geográfica: dependendo do país de origem do usuário, ele pode exibir diferentes páginas de destino.
Atualizando o back-end, usamos OpenJDK 1.8, Kotlin e Spring boot / data / web - a estrutura padrão para um projeto que não espera grandes cargas. A propósito, foi nesse projeto que experimentamos o Kotlin "em batalha" pela primeira vez e, devido à sua sintaxe, nos permitiu acelerar significativamente o desenvolvimento. Definitivamente, vamos usá-lo em outros projetos.
O banco de dados do serviço de autorização e o encurtador implementado no primeiro estágio são construídos com base no PostgreSQL - o modelo de armazenamento de dados relacionais foi bem adequado para resolver esses problemas.
Na segunda etapa, assumimos o gerenciamento de campanhas publicitárias. Essa funcionalidade na plataforma do cliente também existia anteriormente, mas através do serviço do parceiro, pelo qual você tinha que pagar. Agora, a plataforma do cliente cresceu a ponto de ser necessário cuidar de sua infraestrutura. O serviço próprio, diferentemente de terceiros, é muito mais fácil de desenvolver na direção certa, fazendo rapidamente as alterações necessárias.
Nesta parte do projeto, implementamos apenas a API externa para o gerente da campanha. Mas, no terceiro estágio, desenvolvemos este módulo - finalizamos a API e fizemos uma interface de usuário completa para o gerente de campanha.
Paralelamente, desenvolvemos um pequeno DMP (plataforma de gerenciamento de dados) proprietário que gerencia a coleta de dados dos visitantes. Os dados do DMP são armazenados no MongoDB, porque decidimos deixar as bases para o futuro dimensionamento horizontal desse banco de dados. Agora, o DMP atende até 2 mil solicitações por segundo (em picos), enquanto nos concentramos em armazenar cerca de um terabyte de dados. Esse volume poderia ter sido salvo no PostgreSQL, mas, a longo prazo, seria necessário usar grandes esforços para dimensionar.
O mesmo MongoDB é usado no banco de dados do gerenciador de campanhas (Campaign DB) - aqui o modelo de um banco de dados orientado a documentos nos abordou bem. As campanhas vão como entidades únicas e podem ser expandidas.
Todos os caches funcionam no Redis.
Front-end: Angular 5, TypeScript, HTML5, Sass, Node.js, npm, CLI angular.
Durante a última etapa do projeto, concluímos a integração dos sistemas dos clientes e dos serviços de um parceiro importante, abrindo o acesso a uma enorme base de músicos para a empresa, o que garantirá um aumento no número de usuários.
Houve algumas dificuldades no projeto. O cliente queria salvar os dados do usuário e os registros acumulados durante a operação do serviço, enquanto alterava levemente o modelo. Paralelamente à alteração da arquitetura, transferimos registros e alteramos seus princípios - de nome de usuário para email como login, o que nos trouxe muitas noites sem dormir devido a restrições no número de usuários com o mesmo endereço de email. O modelo de direitos no sistema mudou. Anteriormente, o serviço funcionava de acordo com um modelo de dois níveis, mas implementamos um modelo de direitos sem restrições (incluindo a capacidade de emitir direitos limitados).
Ao mesmo tempo, a funcionalidade foi expandida. Por exemplo, em um dos estágios, o armazenamento múltiplo apareceu, com a ajuda dos visitantes finais que clicam em links curtos para uma composição específica, é possível configurar páginas com uma lista de serviços em que essas composições estão disponíveis para compra ou escuta legal.
Vale a pena dizer separadamente sobre o RGPD
O principal mercado de nosso cliente são os EUA, mas cerca de 10% do tráfego que a empresa não queria perder veio da Europa. Desde que o novo regulamento entrou em vigor (25 de maio de 2018), sua segmentação foi simplesmente desativada. Após consultar os advogados, construímos o serviço de forma que não contradisse o RGPD e, a partir de 16 de agosto, começamos a segmentar novamente.
Honestamente, estudamos as complexidades dos regulamentos ao longo do grupo de duas semanas. A dificuldade nesse estágio foi que, com a imprecisão geral da redação, até o momento não há práticas de aplicação da lei - casos reais que poderiam mostrar como fazer certo e o que está errado. No entanto, agora (após nossa própria pesquisa e consulta com advogados) estamos confiantes na arquitetura implementada da solução.
A lógica do serviço implicava adicionar um usuário que segue um link curto para um público específico, para que mais tarde ele pudesse exibir anúncios. Em termos de GDPR, isso não pode ser feito sem o consentimento explícito do usuário. E implementamos uma solicitação de consentimento - quando você clica no link na parte inferior da página, um prato aparece com uma pergunta e dois botões. A solicitação é aberta para usuários cujo IP pertence à Europa e sua resposta é armazenada na forma de cookies, para que os visitantes não precisem pressionar botões o tempo todo.
Se não houver consentimento do usuário (ou seja, cookies), simplesmente não mostramos um pixel, ou seja, nas estatísticas gerais do serviço, o fato da visita será contado, mas os dados do usuário não serão coletados e levados em consideração.
O GDPR impõe restrições arquitetônicas - os dados pessoais devem não apenas ser coletados corretamente, mas também armazenados com segurança. No nosso caso, essas restrições se aplicam ao DMP implementado (apesar de armazenar dados anônimos com identificadores anônimos que apenas permitem a hipótese de anonimizar) e ao banco de dados do serviço de autorização. Em nossa arquitetura, essas bases são claramente alocadas em blocos separados. De acordo com os regulamentos, o acesso de terceiros a esses módulos "sensíveis" é naturalmente limitado.
Somente o serviço correspondente tem acesso ao banco de dados de autorização. Todos os outros serviços não sabem nada sobre os dados pessoais do usuário da plataforma - eles precisam apenas de validação do serviço de autorização.
O banco de dados DMP também inclui apenas o serviço de mesmo nome. Ao mesmo tempo, apenas agregados de dados do público são retornados do banco de dados, mas não os dados em si. Esses agregados formam a base das análises que os usuários do serviço da indústria da música recebem em suas contas pessoais.
Também temos um procedimento obrigatório para carregar e excluir dados do usuário. Havia uma pergunta sobre como verificar se o usuário está realmente solicitando seus dados de maneira legítima. E usamos o cookie armazenado pelo usuário como um fator de verificação.
O projeto foi concluído recentemente, por isso é muito cedo para falar sobre quaisquer resultados numéricos.
Autor do artigo: Nikolay Eremin
PS Publicamos nossos artigos em vários sites do Runet. Assine nossas páginas no
canal VK ,
FB ou
Telegram para descobrir todas as nossas publicações e outras notícias do Maxilect.