Como Singular oferece análises de ROI de aplicativos extremamente rápidas

Os profissionais de marketing de aplicativos Mobile precisam de acesso a dados cada vez mais detalhados para medir com precisão o ROI dos aplicativos — o que inevitavelmente exige o processamento de enormes volumes de dados em tempo real. Isso pode reduzir drasticamente a velocidade de consulta ao banco de dados, criando gargalos para os profissionais de marketing e impedindo-os de otimizar com a rapidez e frequência desejadas. Podemos chamar isso de o paradoxo do marketing mobile moderno: uma necessidade crescente de velocidade em meio a uma avalanche de dados cada vez maior.

Em Singular, o problema surgiu antes da nossa mais recente oferta de análise para profissionais de marketing, Publisher ROI. O Publisher ROI permite que os profissionais de marketing exponham rapidamente uma divisão do inventário de uma rede de anúncios’s por publicador e determinem os sites e aplicativos individuais que geram o melhor desempenho.

Os testes iniciais da funcionalidade mostraram que as consultas de clientes a dados de nível de publicador exigiam um aumento enorme de poder de computação — na ordem de 50-100X dos dados normalmente ingeridos e processados para consultas em Singular. Conforme observamos o aumento dos tempos de consulta durante os testes, ficou claro que atingimos um marco importante: superamos as capacidades das nossas tecnologias de banco de dados.

Para lançar nossa mais recente inovação e continuar oferecendo aos profissionais de marketing de aplicativos mobile acesso rápido e flexível a dados de marketing cada vez mais detalhados, precisaríamos introduzir um novo pipeline de dados e um novo armazenamento de dados — um que fosse capaz de permitir consultas ad-hoc em bilhões de linhas com desempenho inferior a um segundo.

Neste post, vamos descrever como reconstruímos certos componentes das nossas tecnologias de banco de dados e aumentamos drasticamente a velocidade das consultas dos nossos clientes’ — em alguns casos por um fator de 150X.

Mas antes de nos aprofundarmos em como aceleramos as consultas de nossos clientes, vale a pena contextualizar as necessidades em constante evolução dos profissionais de marketing de aplicativos mobile e a enorme dimensão dos desafios de dados que enfrentamos ao fornecer a eles uma plataforma de análise tão flexível quanto Singular.

Desde os primórdios do Singular, acompanhamos de perto os tipos de consultas que nossos clientes executavam na Singular. Tentávamos identificar padrões para criar sistemas que antecipassem as dimensões que um profissional de marketing poderia usar em suas consultas. Mas logo descobrimos que havia uma enorme diversidade nos relatórios e consultas que os clientes utilizavam, com inúmeras combinações de diferentes dimensões e métricas.

Pense nisso em termos de linhas em uma tabela. Digamos que você anuncie em uma rede de anúncios que veicula seus anúncios em 100 publishers diferentes. Você pode verificar o ROI geral da rede — com Singular, isso representa apenas uma linha de dados. Para então exibir uma análise detalhada do desempenho de cada publisher individualmente, a fim de segmentar os publishers de alto desempenho daqueles com baixo desempenho, você precisaria renderizar 100 linhas de dados. Agora, imagine que você esteja executando 4 campanhas em vários países e queira verificar se determinados publishers estão tendo um desempenho particularmente bom em certas regiões geográficas — agora você está olhando para 400 linhas. Quer detalhar os dados por iOS e Android? — são 800 linhas.

Esse tipo de complexidade nos levou à nossa primeira conclusão sobre a arquitetura de banco de dados que poderia atender às nossas necessidades. Como o uso do Singular é muito diverso, com inúmeras combinações de dimensões de consulta, precisávamos dar suporte a consultas ad-hoc, ou seja, consultas que não podem ser determinadas antes do momento em que são emitidas. Como a maioria dos engenheiros de dados sabe, bancos de dados realmente otimizados para consultas ad-hoc geralmente não são bons em atualizar dados após a ingestão. Portanto, precisávamos ingerir os dados em nosso banco de dados em seu formato final.

Ingestão de dados na Singular

Na Singular, executamos cerca de 10.000 de coleta de dados de marketing por dia. Cada tarefa de coleta é responsável por coletar dados de um cliente específico de um de seus fornecedores de marketing terceirizados, referentes a um período de 1 a 30 dias. Nosso pipeline de ingestão se destaca pelo volume de dados que cada tarefa coleta (estatísticas detalhadas do Facebook para 30 dias representam um volume enorme) e também porque coletamos dados de fornecedores que tendem a atualizá-los retroativamente com frequência, o que exige Singular substitua constantemente as estatísticas antigas por dados atualizados.

Anteriormente, nosso pipeline de ingestão carregava dados no MySQL e executava várias lógicas de ingestão, consultando os dados e realizando atualizações. Após a disponibilização dos dados, as consultas acionadas pelo nosso painel de controle e API também acessavam o MySQL.

Isso estava funcionando bem para nós — até introduzirmos a coleta e consulta em nível de editor. Com o grande aumento no volume de dados, o carregamento para o MySQL ficou mais lento, criando gargalos em nosso pipeline. Além disso, executar consultas analíticas nesse volume de dados era simplesmente muito lento.

Projetando um novo pipeline de ingestão

Para suportar um número infinito de tarefas, com um volume de dados ingeridos cada vez maior, nosso objetivo era construir um pipeline com escalabilidade horizontal (ao contrário do MySQL). A escolha do Amazon Simple Storage Service, ou "S3", para suportar essas dependências foi óbvia. Já utilizávamos o S3 para fazer backup dos nossos dados antes de inseri-los no MySQL. Além disso, ele é escalável horizontalmente, não requer operações e oferece alta velocidade de download/upload quando utilizado dentro da Amazon Web Services.

Assim, nossa nova arquitetura de ingestão utiliza o S3, com apenas os metadados armazenados no MySQL. Em vez de consultar e atualizar o MySQL, cada componente do nosso pipeline recebe um arquivo S3 como entrada e repassa outro arquivo S3 contendo os dados recebidos juntamente com as novas informações geradas pelo componente.

Ao final do nosso pipeline, os dados são enviados para um bucket do S3, contendo as estatísticas mais recentes por cliente, fonte de marketing e data. Isso permite a execução de tarefas de coleta de dados em paralelo e torna esse bucket a fonte de verdade para o nosso sistema.

Em direção a um novo armazenamento de dados

Com nossos dados em sua forma final, prontos para serem consultados no S3, nossa escolha de armazenamento de dados foi extremamente flexível. Tínhamos construído previamente uma pequena camada de abstração entre nossa API e o MySQL, que podia ser adaptada para suportar qualquer linguagem de consulta ou esquema. Assim, ao avaliar novos bancos de dados, sabíamos de antemão que a decisão não era definitiva, já que os custos de migração eram muito baixos. No fim, selecionamos o Druid, um armazenamento de dados de código aberto desenvolvido especificamente para a necessidade de consultas agregadas sobre dados de análise de marketing.

Após a implementação, ficamos muito satisfeitos com os resultados: com o Druid, consultas que antes 60 segundos passaram a ser executadas em 1 a 2 segundos, enquanto consultas que antes levavam 30 segundos passaram a ser executadas em menos de um segundo. Em alguns casos, observamos melhorias no tempo de consulta ao banco de dados de até 150 vezes em comparação com o sistema antigo.

Todos esses desenvolvimentos nos levam ao início deste ano, quando começamos a ativar o ROI em nível de editor para clientes selecionados em um teste beta fechado do recurso. O beta serviria como o teste de estresse definitivo para nossa nova arquitetura.

Granularidade e velocidade são a chave para a vitória

Para relembrar o ROI em nível de editor e por que ele é tão inovador, aqui vai um breve resumo do setor. As redes de anúncios normalmente compram inventário composto por espaços publicitários em centenas, às vezes milhares, de sites e aplicativos. Esses sites e aplicativos, conhecidos individualmente como "editores", são onde os anúncios dos anunciantes são exibidos.

Nos últimos anos, os profissionais de marketing de aplicativos mobile têm exigido maior visibilidade do desempenho em nível de editor para identificar os nichos de tráfego mais valiosos. As redes responderam fornecendo IDs de editor nos dados de desempenho que disponibilizam aos profissionais de marketing. Estes, por sua vez, usam esses IDs de editor ou site para otimizar suas estratégias, aumentando o investimento em editores de alto desempenho e diminuindo o investimento ou "bloqueando" aqueles com baixo desempenho.

Historicamente, porém, a otimização de publishers em múltiplas redes tem sido um processo árduo e propenso a erros, exigindo que os profissionais de marketing alternem entre vários painéis e atualizem manualmente planilhas do Excel complexas. O processo é particularmente problemático para aqueles que desejam analisar o desempenho dos publishers não apenas pelas taxas de cliques ou pelo número bruto de instalações, mas sim pela qualidade real desses usuários, medida pelo ROI (retorno sobre o investimento).

Singular automatiza o processo de coleta de todos os seus dados de marketing em um só lugar, antes de limpar e combinar os dados com a receita e os eventos obtidos por meio de links de rastreamento, a fim de expor o ROI do aplicativo e outras métricas de negócios de funil completo.

Mas, como mostramos aqui, depois de ingeridos, enriquecidos e combinados, tornar os dados em nível de editor rápidos e flexíveis é um desafio completamente diferente. É exatamente por isso que investimos tanto em nosso novo pipeline e armazenamento de dados. Os profissionais de marketing de aplicativos Mobile precisam tanto de granularidade quanto de velocidade — e temos orgulho de dizer que os resultados falam por si.

Com a implementação do ROI em nível de editor para nossos clientes de teste beta, que agora estão utilizando nosso novo sistema baseado em Druid, os clientes relataram tempos de carregamento extremamente rápidos, mesmo com o aumento massivo no volume de dados.

E as melhorias de desempenho não são limitadas à consulta em nível de publicador. Com Singular, consultas intensivas em dados — para expor Campanha, País, Criativo e Nível de Usuário desempenho — está agora mais rápido do que nunca graças a esses avanços em nossas novas tecnologias de banco de dados.