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.
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.
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:
Dedique mais tempo ao incidente, porque as perguntas sobre os campos podem ser respondidas só com a especificaçã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:
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.
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.
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:
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.
Além das cláusulas habituais, deixe por escrito:
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.
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.
Traga sua arquitetura atual e o modo de falha que preocupa você, e vamos analisá-lo juntos em meia hora.
Agendar uma call