O Ad Exchange como parte do lance em tempo real (RTB) é uma das soluções da AdTech que está transformando o mercado de publicidade on-line. Sua principal função é ancorar um grande número de SSPs e DSPs que não possuem integração direta entre si, além de revender uma variedade de tráfego de publicidade entre eles.
Graças a um pedido para o mercado dos EUA, mergulhamos de cabeça nas especificidades da criação da plataforma Ad Exchange. E neste artigo, apresentamos algumas idéias e resultados.
Declaração do problema
Lances em tempo real (RTB) fornecem a venda de espaço publicitário em sites em tempo real para exibir anúncios relevantes ao público-alvo.
Em resumo, o diagrama do processo é o seguinte:
- o usuário final solicita uma página da web ou aplicativo móvel onde é reservado um local para um banner (o código da plataforma para a venda de inventário de publicidade está incorporado - SSP, Supply Side Platform);
- Para garantir o preço máximo de venda do inventário, o SSP organiza propostas entre os vários DSPs (Demand Side Platform) por meio do Ad Exchange, cujo objetivo é comprar o inventário o mais barato possível;
- após o anúncio do vencedor do leilão, o DSP vencedor envia um código de faixa SSP, que é exibido ao usuário;
- outro lado do processo é o DMP, um sistema de terceiros que fornece ao DSP informações detalhadas sobre o usuário final (além do que pode transmitir SSPs na forma de cookies etc.) para justificar a conveniência da compra e o custo proposto.
Hoje existem algumas trocas do Ad Exchange. Além disso, muitos SSPs implementam seus próprios lances (realmente fechando a funcionalidade do Ad Exchange). Mas nosso cliente tinha certeza de que, devido a algumas novas idéias, ele poderia entrar rapidamente no mercado e resistir à concorrência.
As trocas trabalham com princípios diferentes: alguém oferece uma margem maior, alguém menos, alguém vende equipamentos exclusivos, outros se concentram em bens de consumo condicionais. O mercado é bastante jovem e se desenvolve ativamente; portanto, não há modelos de negócios testados ao longo dos anos aqui: tudo se baseia em hipóteses e experimentos ousados. A maioria dos jogadores trabalha de acordo com um esquema simples: recebe uma solicitação de um dos vários SSPs com os quais conseguiu concordar e a envia a todos os DSPs integrados, antecipando uma aposta melhor. Receita do Ad Exchange - a diferença entre o preço de compra e venda de inventário de publicidade no SSP e no DSP menos os custos operacionais.
Nosso cliente sugeriu otimizar esse esquema distribuindo corretamente solicitações de SSP ao DSP - não enviando deliberadamente "perdendo" solicitações, reduzindo assim os custos operacionais. Devido a isso, você pode reduzir a comissão da troca sem perder receita e tornar sua oferta mais atraente no contexto do Ad Exchange concorrente na luta pelo SSP e DSP. E conectar mais parceiros proporcionará renda e estabilidade no mercado.
Para implementar essa estratégia no mercado dos EUA, fomos encarregados de tornar o Ad Exchange com uma distribuição inteligente de solicitações, que forneceria uma boa porcentagem de recompra. Em teoria, para essa distribuição, você pode usar muitas informações que acompanham a solicitação, até mesmo os dados dos sistemas de terceiros (DMP) mencionados acima. No entanto, análises complexas requerem recursos; portanto, a tarefa é encontrar um equilíbrio entre os custos da distribuição inteligente e o ganho (em comparação com outros participantes do mercado) de sua implementação. Em um mercado imaturo relativamente novo, construir soluções muito complexas, apertar décimos de otimização, simplesmente não faz sentido.
Uma característica importante do projeto, além das altas cargas esperadas, foi o cumprimento dos requisitos não funcionais para a velocidade do leilão realizado pelo SSP. Adequado neste segmento de mercado, é o tempo limite para aguardar uma resposta do SSP a 300 ms, que deve ser atendida juntamente com as chamadas para sistemas externos (DSP).
O projeto começou no outono de 2016. Graças à experiência da equipe nessa área, após três meses fizemos o primeiro protótipo e depois de mais três MVP (Produto mínimo viável) prontos, o que nos permitiu coletar as primeiras análises para iniciar a distribuição inteligente de solicitações no Ad Exchange.
O lançamento do MVP mostrou que a hipótese sobre o sucesso comercial do projeto está correta - o Ad Exchange começou a ganhar dinheiro para o cliente. Os planos de desenvolvimento inicial do Ad Exchange incluíram um estudo mais aprofundado dos dados - conectando informações do usuário final de sistemas externos à análise. Mas, no estágio MVP, foi decidido usar apenas os dados que o SSP possui. Isso foi suficiente para obter o lucro esperado.
Arquitetura da solução
A solução é construída com base no modelo da Cadeia de responsabilidade, que permite não corrigir a rota de solicitações no sistema, adicionando facilmente processadores e vários serviços, do próprio leilão às ferramentas de filtragem.
O cliente não nos limitou na pilha de tecnologias usadas. Portanto, cuidando do futuro desenvolvimento e suporte do projeto, criamos uma solução escalável horizontalmente usando o Postgres e o Hadoop.
O próprio Ad Exchange é escrito em Java - ao mesmo tempo, não usamos nenhuma estrutura para não cair na carga (trabalhamos em um nível baixo).
Para manter o tempo limite do SSP mencionado, selecionamos os parâmetros do coletor de lixo (G1 foi usado) e realizamos um trabalho síncrono com um grande número de solicitações - usamos um cliente HTTP que não bloqueia o fluxo, bem como uma extensão do protocolo HTTP keep-alive que permite o envio de várias solicitações dentro uma conexão TCP.
Os componentes de software são implantados no hardware alugado do host, conforme as condições da tarefa não permitiram o uso da nuvem devido à sobreposição de recursos das máquinas virtuais na nuvem (a alocação dos recursos necessários pode levar tempo, mas não temos). No momento, o Ad Exchange usa quatro servidores físicos, um dos quais é redundante (para atualizações contínuas etc.).
O código-fonte aberto Apache Kafka é usado como um intermediário de mensagens - é idealmente integrado ao nosso modelo de "um assinante - muitos editores", embora tivesse que ser ligeiramente distorcido para que as mensagens repetidas não chegassem.
Cada um dos servidores fornece no modo normal o processamento de cerca de 10 mil solicitações por segundo (esses parâmetros foram estabelecidos durante o desenvolvimento da solução). Agora, a carga média é de 15 a 20 mil solicitações por segundo e, no pico, o fluxo de solicitações atingiu 40 mil por segundo por várias horas, e o Ad Exchange fez um ótimo trabalho nisso.
A distribuição de solicitações entre servidores é realizada pelo balanceador de carga do software nginx, configurado para nossa tarefa. Em nossa experiência, no nginx, você pode manter de 60 a 70 mil solicitações por segundo, sem alocar um balanceador de hardware separado. Se, no futuro, a carga no Ad Exchange estiver acima desse limite, planejamos comprar um balanceador de hardware que distribua solicitações entre vários do mesmo tipo nginx.
Ele monitora o que está acontecendo, sujeito a um aumento constante na carga, um sistema de monitoramento que faz parte do Ad Exchange criado.
Armazenamento
Dada a dependência das análises durante a distribuição de consultas, o banco de dados é parte integrante do nosso Ad Exchange. O sistema armazena informações sobre lances, participantes de leilão e transações.
Não faz sentido coletar esse volume de dados para todo o período do Ad Exchange, para que o armazenamento tenha uma arquitetura multinível. Todos os dados do leilão são armazenados por semana. Com base nelas, são construídas unidades intermediárias de nível superior, que são armazenadas por vários meses. E com base nos intermediários, os agregados finais são usados, que são usados em análises de longo prazo e para reconciliações com SSP e DSP. Entre outras informações nessas unidades, há dados sobre quantas apostas foram feitas e quanto dinheiro a bolsa pagará ao SSP ou esperará receber do DSP.
Os pontos de extremidade são armazenados por toda a duração do Ad Exchange.
A coleta de análises e a formação de agregados fornecem serviços separados.
Para que o armazenamento correspondesse à velocidade do próprio sistema, eu também tive que trabalhar com ele. Em particular, por algum tempo brigamos com o hoster, porque os dados da transação simplesmente não tiveram tempo de gravar no banco de dados. Verificou-se que a falha era um problema de hardware com a matriz RAID. Após substituí-lo, conseguimos extrair 90.000 solicitações por segundo no Postgres (inserindo dados no banco de dados).
O restante do Ad Exchange é sem estado, o que proporciona uma escala horizontal fácil no futuro. Ele não armazena dados sobre solicitações - a informação máxima recebida sobre qual DSP deve ser selecionado. Para que possamos adicionar novos servidores para processar solicitações, conforme necessário.
Filtragem de tráfego
Um elemento chave do sistema que permite reduzir a carga e manter os tempos limite indicados pelo cliente é a filtragem de tráfego.
De acordo com a tarefa em mãos, qualquer Ad Exchange:
- aceita solicitações do SSP;
- realiza um leilão (envia solicitações para vários DSPs, compara os preços oferecidos, identifica o vencedor);
- concorda com a vitória do SSP (informa o preço do vencedor menos sua comissão, aguarda uma resposta com o preço final do show);
- conclui a transação (informa o DSP necessário sobre sua vitória, conduz o tráfego do usuário).
A distribuição inteligente de solicitações em nosso Ad Exchange está incluída no estágio inicial do leilão.
Quando recebemos uma solicitação do SSP com determinadas informações (IP, agente do usuário), as detalhamos usando as informações acumuladas nas informações de usuário conhecidas do sistema, uma lista de DSPs para os quais solicitações semelhantes foram enviadas, suas respostas etc. Isso é necessário para selecionar a combinação mais vantajosa de DSP para cada solicitação. Graças à seleção dessa combinação, o sistema permite que você não envie solicitações para os DSPs que não oferecem ou fazem, mas são muito baixos. Para fazer isso, um serviço separado em tempo real compila um mapa de como o DSP responde às solicitações (esses cartões são armazenados no Redis).
Paralelamente, verificamos o status do DSP - se a proporção de respostas dentro do tempo limite cair, o sistema reduzirá automaticamente o número de solicitações para esse DSP. Assim que a carga no DSP é reduzida (e a proporção de respostas corretas em um tempo aceitável aumenta), o número de solicitações retorna gradualmente ao nível anterior.
Entre os DSPs que responderam a tempo, realizamos um leilão interno - selecione a melhor oferta e envie-a para o SSP. Desde a solicitação do SSP até nossa resposta, não passam mais de 300 ms, de acordo com os requisitos do setor.
Como enviamos os dados para o SSP, onde nosso leilão é realizado, precisamos considerar os lances vencidos lá. O servidor de leilões já está envolvido no registro deles no próximo estágio, ao processar o tráfego do usuário. Graças a ele, o mapa de resposta do DSP é enriquecido com novos dados (juntamente com as informações coletadas sobre o usuário final).
Uma comparação dos dados obtidos no estágio do leilão e dos parâmetros conhecidos do tráfego do usuário nos permite filtrar os bots (clickers de publicidade, bots de pesquisa etc.). Esse tráfego não é resgatado pelo DSP e, na ausência de seu próprio sistema de filtragem, ele se transforma em perdas de clientes, que deverão ser cobertas pela margem.
Note-se que a filtragem de tráfego de bot não foi iniciada imediatamente. Porém, após a inclusão de bloqueios simples, o ganho de margem foi de cerca de 50%.
A propósito, além das ferramentas automáticas de filtragem de tráfego em nosso sistema, é possível que o cliente altere manualmente os valores limite de vários parâmetros, ajustando a margem.
O tráfego do usuário em si é crítico para nós, mas quando é processado, não é mais necessário caber em 300 ms. Ele usa um sistema de processamento separado, que pode reter um pouco o usuário, mas não permitirá perder essa solicitação.
Para garantir a estabilidade da solução, foi introduzido um subsistema que, entendendo a carga atual do Ad Exchange, "corta" as solicitações de leilões, que não podem ser processadas fisicamente. Assim, o sistema é protegido contra o crescimento descontrolado de carga do SSP.
Perspectivas
Até o momento, o Ad Exchange que criamos funciona e gera bons lucros. E fornecemos suporte e integração de novos parceiros (DSP / SSP), conforme necessário. No total, várias dezenas de sistemas já foram integrados. Cada integração implica não apenas a conexão de software, mas também testes abrangentes do serviço, porque, sob cargas pesadas, os problemas do serviço conectado podem afetar outros parceiros.
Em geral, o mercado está caminhando para o fato de que o SSP e o DSP se conectarão diretamente, o que tornará as trocas desnecessárias. Mas a integração baseia-se nos recursos do SSP e DSP. Apesar da existência da API aberta (protocolo OpenRTB), ela ainda não é universalmente reconhecida no mercado. Por exemplo, um participante importante como o Appnexus integrou recentemente o suporte ao OpenRTB.
Essencialmente, o Ad Exchange é um provedor de liquidez. Portanto, é improvável que a decisão no futuro perca sua relevância. Além disso, o modelo de troca só está ganhando popularidade no restante do mercado publicitário.
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.