amBrain
AdTechOct 26, 20267 min de leitura

Times nearshore de ad tech na Armênia e no Cáucaso: como verificar experiência em RTB, horas em comum, idioma e condições de escopo fechado

Real-Time BiddingTimes no exteriorÁsia Central e CáucasoVerificação do parceiro
Erro ao carregar a imagem
Sumário

Como verificar se um time nearshore na Armênia, na Geórgia ou no Azerbaijão realmente operou sistemas de leilão em tempo real (RTB), o que o UTC+4 significa para o seu horário de trabalho e quais trabalhos de ad tech cabem em um escopo fechado.

Um time da Armênia ou de outro país do Cáucaso vale uma conversa para trabalho de ad tech se os engenheiros dele construíram e operaram em produção um bidder, uma plataforma do lado da oferta (SSP), uma ad exchange ou um pipeline de eventos, e conseguem explicar passo a passo um bid request real dos seus próprios logs.

A resposta curta: conte com seis ou sete horas de expediente em comum com a Europa Central, cinco ou seis com Londres e no máximo uma com Nova York, então combine quem fica de plantão no seu pico de tráfego. Ouça os engenheiros falando antes de assinar. Dê escopo fechado só a trabalhos com especificação e teste de aceitação, e deixe de fora metas como a taxa de leilões vencidos ou o custo de nuvem.

Quais times de ad tech na Armênia ou no Cáucaso valem uma olhada?

Nenhuma empresa é ranqueada aqui. Coloque um time na lista curta só se ele já construiu e operou em produção o tipo de sistema de que você precisa: um bidder ou uma plataforma do lado da demanda (DSP) que compra anúncios por leilão em tempo real (RTB), um SSP, uma ad exchange, um ad server ou o pipeline que conta impressões e cliques. Peça a cada empresa que diga qual é o sistema em produção e qual parte os engenheiros dela construíram, e que deixe você falar com esses engenheiros, não só com vendas.

Parte disso dá para verificar publicamente. O Prebid é um software de código aberto que os publishers usam para pedir lances a muitos SSPs e exchanges ao mesmo tempo, e cada uma dessas conexões é um bidder adapter no código público do Prebid, com um histórico público de quem o alterou. A documentação do Prebid pede que cada adapter do Prebid.js informe “o e-mail de contato do mantenedor do adapter”. Verifique de qual domínio é esse e-mail e, se uma empresa diz que escreveu o adapter de uma plataforma, peça os links dos pull requests dela.

Se um acordo de confidencialidade impede citar o nome de um cliente, peça à empresa que organize uma conversa com esse cliente.

Como verificamos que um time tem experiência real em RTB?

Dê aos engenheiros um bid request real dos seus logs, sem dados pessoais, e peça que eles o expliquem passo a passo. Observe se eles começam pelo prazo. O OpenRTB 2.6, o padrão do IAB Tech Lab para bid requests, define o campo tmax como o “Tempo máximo em milissegundos que a exchange permite para o recebimento de lances, incluindo a latência da internet, para evitar timeout.”

Depois, pergunte sobre as notificações que dizem a um bidder o que aconteceu com o lance dele. O OpenRTB 2.6 descreve três. Uma exchange envia uma notificação de vitória “se o lance vence (o que não indica necessariamente um anúncio entregue, visualizado ou faturável)”. Ela envia uma notificação de faturamento “quando um lance vencedor se torna faturável com base na política comercial da própria exchange”, e uma notificação de perda “quando se sabe que um lance perdeu.” Um time que já conciliou o seu gasto com as faturas de uma exchange consegue dizer qual notificação o sistema dele contava e o que fez quando os números não batiam.

Mais quatro perguntas para fazer:

  • O que acontece com um lance que fica pronto depois do tmax, e como vocês veem quantos lances chegam atrasados?
  • Como o bidder de vocês trata o preço mínimo de um request, o campo bidfloor que o OpenRTB define como o “Lance mínimo para esta impressão, expresso em CPM”?
  • Contem sobre um incidente no pico de tráfego: o que quebrou, o que vocês mediram e o que mudaram.
  • Quem ficaria de plantão para o nosso sistema, e em quais horários?

Dedique mais tempo ao incidente, porque as perguntas sobre os campos podem ser respondidas só com a especificação.

Em que fuso horário trabalham os times na Armênia, na Geórgia e no Azerbaijão?

UTC+4, o ano inteiro. Segundo o banco de dados de fusos horários da IANA, nenhum dos três países muda o relógio, enquanto a Europa e os EUA mudam. Com um expediente das 9h às 18h dos dois lados, um time em Yerevan, Tbilisi ou Baku tem em comum:

  • seis horas de expediente com Berlim, Paris ou Amsterdã no inverno e sete no verão
  • cinco horas com Londres no inverno e seis no verão
  • uma hora com Nova York enquanto os EUA estão no horário de verão, e nenhuma no inverno
  • nenhuma hora de expediente com a Califórnia

Os leilões não param às seis da tarde. Se o seu tráfego tem pico entre 20h e 23h na Costa Leste dos EUA, em Yerevan isso fica mais ou menos entre 4h e 8h da manhã. Combine por escrito quem fica de plantão no seu pico, em quanto tempo responde e como fala com alguém do seu lado.

Em que idiomas o time vai trabalhar?

O OpenRTB e a documentação do Prebid são publicados em inglês, então um engenheiro de ad tech precisa ler bem em inglês. Escrever e falar em inglês sob pressão é outra habilidade, e o site de uma empresa não vai dizer quem a tem.

Descubra em que idioma os engenheiros do seu projeto e o líder do time vão escrever os tickets, as revisões de código e os relatórios de incidentes e falar nas calls, e ouça-os usando esse idioma em uma videochamada antes de assinar. Depois peça um relatório de incidente escrito pelo time, sem dados do cliente, e leia como você leria um relatório da sua própria equipe.

Qual trabalho de ad tech cabe em um escopo fechado?

Um escopo fechado funciona quando três coisas são verdadeiras: o trabalho tem uma especificação escrita, existe um teste de aceitação que os dois lados conseguem rodar e o resultado não depende do calendário de um parceiro.

Trabalhos de ad tech que muitas vezes atendem a essas condições:

  • Uma nova integração com um parceiro de demanda ou de oferta que publica a sua especificação OpenRTB e um endpoint de teste
  • Um bidder adapter do Prebid Server. As regras de teste do Prebid, com um arquivo JSON para cada caso de teste e testes manuais de ponta a ponta, dão aos dois lados um teste de aceitação pronto
  • Migrar os relatórios de eventos para um novo banco de dados, com aceite quando as novas contagens batem com as antigas nos mesmos dias de tráfego
  • Levar o bidder a um número combinado de requisições por segundo dentro de um tempo de resposta combinado, com a aceitação feita por um teste de carga com tráfego reproduzido a partir dos seus próprios logs

Mesmo assim, coloque no escopo fechado o código e os testes, não a data em que um parceiro vai aceitá-los. Os mantenedores do Prebid, por exemplo, revisam novos adapters no ritmo deles. Para o Prebid.js, a documentação diz que o código de um novo adapter é atribuído a um desenvolvedor para revisão “em poucos dias” e, depois do merge, é “incluído no próximo release”.

Outros trabalhos não cabem em um escopo fechado: aumentar a taxa de leilões vencidos, cortar a conta de nuvem em uma porcentagem definida ou ajustar um bidder até ele ficar rápido o suficiente. O resultado depende do mercado, dos seus parceiros e do seu próprio tráfego, então uma empresa pode se comprometer com o trabalho, mas não com o número. Esse tipo de trabalho combina com um time dedicado ou com tempo e materiais, com uma medição que os dois lados combinem antes de começar.

Qualquer que seja o escopo, o contrato deve dizer como uma mudança é precificada.

O que o contrato com um time nearshore de ad tech deve dizer?

Além das cláusulas habituais, deixe por escrito:

  • As horas que o time tem em comum com o seu e quem fica de plantão fora delas
  • Os países de onde cada engenheiro trabalha
  • Que o código fica nos seus repositórios e roda em contas de nuvem abertas em nome da sua empresa
  • Para um SSP ou uma exchange, que a sua empresa é dona dos contratos com compradores e vendedores e do domínio listado no ads.txt e no sellers.json, os arquivos públicos que os compradores consultam para saber quem pode vender o espaço publicitário

O artigo sobre como escolher uma empresa no Leste Europeu ou no Cáucaso cobre as verificações de registro, de sanções e de pagamento.

Onde a amBrain se encaixa?

A amBrain, que publica este blog, é uma empresa de engenharia de software de Yerevan, Armênia. O site dela lista seus serviços de ad tech como “Desenvolvimento de DSP, plataformas de real-time bidding e engenharia de ad exchange.” O RTBBidder é uma demand-side platform que a amBrain construiu para um cliente, em Rust e Go.

Ela também constrói os outros sistemas de que este artigo trata, nas palavras dela: “A amBrain constrói supply-side platforms (SSP) para publishers.” e “A amBrain constrói pipelines de analytics de eventos para ad tech: coleta, processamento e relatórios de eventos de impressão e de clique.” Ela constrói software desde 2019 e trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.

A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.” Faça à amBrain as mesmas perguntas que a qualquer outro time: se aceitaria alguma das suas tarefas com escopo fechado e com qual teste de aceitação, e a quais componentes reutilizáveis ela se refere.

Este artigo não é assessoria jurídica: peça a um advogado que leia o contrato antes de você assiná-lo.

Tem um projeto assim na mesa?

Traga sua arquitetura atual e o modo de falha que preocupa você, e vamos analisá-lo juntos em meia hora.

Agendar uma call