À medida que a Booking.com crescia e se tornava um dos maiores marketplaces de viagens, as equipes de produto corriam o risco de decidir funcionalidades por opinião. A empresa realizava experimentos controlados online havia mais de uma década e queria que todos, não apenas os gerentes de produto, validassem ideias de forma barata, segura e com dados confiáveis.

Fazer da experimentação o sistema de decisão padrão: toda mudança, até mesmo correções de bugs, é lançada envolvida em um teste A/B, e qualquer pessoa pode iniciar testes, consultar o histórico e interromper testes prejudiciais.

Os engenheiros construíram uma plataforma de experimentação interna com um repositório pesquisável de todos os sucessos e fracassos passados, APIs genéricas para recrutamento, rastreamento e métricas, dois pipelines de monitoramento independentes, pools de testes A/A e salvaguardas como pré-registro e revisão por pares dos resultados positivos. Cada departamento recebeu sua própria equipe de suporte dedicada, para que qualquer pessoa pudesse conduzir um experimento de ponta a ponta.

Mais de 1.000 experimentos rodam simultaneamente em aplicativos móveis, ferramentas para hoteleiros, linhas telefônicas de atendimento ao cliente e sistemas internos; todo redesenho, mudança de infraestrutura e correção de bug é envolvido em um teste, de modo que as decisões de produto passaram de opiniões para evidências e os aprendizados são reutilizados entre as equipes.

Na Booking.com, a experimentação não é uma ferramenta que algumas equipes usam — é como a empresa decide. Por mais de dez anos, a plataforma de viagens conduziu desenvolvimento de produto baseado em evidências e, em 2017, seus departamentos executavam e analisavam mais de mil experimentos simultâneos em qualquer dia, em aplicativos móveis, ferramentas para hoteleiros, linhas telefônicas de atendimento ao cliente e sistemas internos.

A escolha deliberada foi a democratização. A plataforma de experimentos funciona como um repositório pesquisável de todos os sucessos e fracassos desde o primeiro experimento, para que qualquer pessoa possa consultar o histórico e formular novas hipóteses. APIs genéricas abstraem recrutamento, randomização e relatórios, e cada departamento tem sua própria equipe de suporte dedicada, de modo que executar um teste não exige permissão da gestão de produto.

A confiança veio da disciplina de engenharia: dois pipelines mantidos separadamente calculam as mesmas métricas e são monitorados um contra o outro, um pool de experimentos A/A valida as estatísticas, e salvaguardas como pré-registro e revisão por pares dos sucessos contêm o p-hacking. Todos na empresa têm o poder de interromper um experimento prejudicial por conta própria.

O resultado foi uma empresa em que "toda mudança, de redesenhos completos e mudanças de infraestrutura a correções de bugs, é envolvida em um experimento", como escreveram os engenheiros em um artigo de 2017 — transformando o desenvolvimento de produto em um fluxo de apostas medidas em vez de uma série de opiniões.

Descentralizar os experimentos permitiu que milhares de pessoas testassem ideias em vez de esperar que os gerentes de produto as priorizassem.

Um histórico pesquisável de sucessos e fracassos permite que as equipes revisitem e construam sobre os aprendizados umas das outras.

Uma infraestrutura confiável (pipelines duplos, pools A/A, pré-registro) tornou as evidências aceitáveis como árbitro das decisões.

Manter a plataforma de experimentos fracamente acoplada à lógica de negócios tornou o lançamento de uma mudança vencedora tão simples quanto remover uma chamada de API.

Dar a qualquer pessoa o poder de interromper um experimento prejudicial manteve a segurança compatível com a velocidade.

Você não precisa de consenso sobre uma opinião se todos podem executar um experimento barato e seguro: infraestrutura mais uma cultura de evidências transformam decisões em testes e fracassos em aprendizado compartilhado e pesquisável.

O framework interno, escrito por engenheiros de Amsterdã em meados dos anos 2000, foi ampliado, mas nunca reescrito; em 2026, o Silicon Canals relatou que a Booking.com ainda executa mais de 1.000 testes simultâneos na página de reservas em produção ao vivo e dezenas de milhares de experimentos acumulados por ano, onde uma variação de 0,1% na conversão representa uma soma de oito dígitos. O padrão se espalhou pela indústria como "cultura de experimentação" — plataformas de fornecedores, manuais públicos e outras empresas de tecnologia adotaram o mesmo modelo de teste como padrão que a Booking.com havia pioneirizado.

CONFIRA AS EVIDÊNCIAS

As fontes

  1. Democratizing online controlled experiments at Booking.com arXiv · arxiv.org ·
  2. Booking.com still runs on the internal A/B testing framework its engineers wrote in Amsterdam in the mid-2000s, with no major rewrite since, and at any given moment it is running more than 1,000 live experiments Silicon Canals · siliconcanals.com ·