# Experimentos ![](/files/-M_VsFl1Pqa8fMQQ3-Gy) ## Escrever antes de fazer Configurar experimentos é uma atividade-chave no nosso dia-a-dia. Um bom time de produto e design escreve seus experimentos de forma clara. Quanto mais tempo aplicamos no racional e escrita do experimento, menos tempo passamos: * Defendendo a ideia com outros stakeholders; * Explicando a importância do experimento para o time tech; * Construindo o experimento. ### Pergunta-chave Essa pergunta é importante no alinhamento com outras áreas e times, para não perdermos o foco quando formos discutir o experimento. Antes de tudo, garanta que todas as pessoas envolvidas concordam com a pergunta. Só depois apresente o experimento.\ \ Ao formular uma pergunta-chave, tenha em mente que experimentos geralmente não respondem perguntas que começam com `Como` e `Por que`. Essas perguntas acabam sendo muito genéricas e são melhor respondidas em uma abordagem mais qualitativa. \ \ Por isso, evite perguntas como: {% hint style="danger" %} Como vamos vender este produto dentro do Marketplace? {% endhint %} Prefira: {% hint style="success" %} Qual é a demanda por terceirização dentro do produto? {% endhint %} ### Método Agora, chegou o momento de decidir qual tipo de experimento vamos fazer. \ Vale **teste A/B**, **concierge**, **mágico de oz**, **fake door**, entre outros. \ \ Escolher o método certo não é fácil, por isso dê preferência por fazer as coisas mais manualmente no começo e só depois automatizá-las. Agora, vamos entender o que esse monte de nomes significa. {% tabs %} {% tab title="Teste A/B" %} **O que é**\ Exibir versões diferentes de uma interface para o público, geralmente dividindo a audiência em 50/50. **Para o que serve**\ Otimizar a conversão. Conseguimos entender se as alterações que propusemos fizeram as pessoas utilizarem mais ou não o produto. **Ferramentas** \ Google Optimize. Se não rolar por lá, é só pedir ajuda para o time de tech. {% endtab %} {% tab title="Concierge" %} **O que é**\ Antes de fazermos uma melhoria ou desenharmos um serviço dentro do produto, utilizando código, rodamos ele como um serviço manual.\ \ **Para que serve**\ Validar valor. Se entendermos que as pessoas ficaram satisfeitas com o serviço, aí podemos partir para o uso da tecnologia, o que vai aumentar ainda mais a percepção desse valor. **Ferramentas** \ Geralmente é bem manual: Whatsapp, planilhas, e-mail e etc. {% endtab %} {% tab title="Mágico de Oz" %} **O que é**\ Similar ao concierge, mas com um *plot twist*: aqui usamos ferramentas para a pessoa usuária sentir que está usando algo automatizado. Sim, igual no final do filme `O Mágico de Oz.`E não, isso não é spoiler, o filme tem mais de 80 anos! **Para que serve**\ Assim como o concierge, serve para validar valor. **Ferramentas**\ Zapier, Webflow, Google Forms, Whatsapp, E-mail. O céu é o limite. {% endtab %} {% tab title="Fake door" %} **O que é**\ Dentro do nosso produto, criamos um banner (ou qualquer coisa do tipo) anunciando a feature, como se ela já estivesse pronta. A pessoa clica e - *tcharam -*, avisamos que ainda não está pronta. **Para que serve**\ Validar demanda. Aqui queremos saber se tem gente interessada no produto ou feature que ainda vamos criar. **Ferramentas** \ Google Optimize. Se não rolar por lá, é só pedir ajuda para o time tech. {% endtab %} {% endtabs %} ### Assumption (fatos + suposições) O que você realmente já sabe e o que você apenas supõe sobre o problema que você identificou? Liste dados e fatos sobre o que você já sabe sobre o problema ou comportamento da pessoa usuária. Trazer um baseline (uma métrica já existente) deixa sua assumption mais robusta e já fornece um ponto de vista. \ \ Depois, também traga pra cá o que você supõe que seja verdade e o porquê. Não faça: {% hint style="danger" %} Talentos da Revelo não sabem que trabalhamos com empresas e vagas nos EUA (ReveloTalent). {% endhint %} Faça: {% hint style="success" %} Em campanha anterior do Google Ads, a LP do ReveloTalent converteu 0,38%. Acreditamos que dentro do produto teremos mais demanda do que fora. {% endhint %} ### Hipótese Qual ação vai gerar qual resultado? * Formato: ***fazer** (tal coisa) **vai gerar** (tal resultado)* * Importante termos apenas uma hipótese por experimento * O resultado deve se conectar com o que você quer aprender com o experimento * Clareza: evite expressões ambíguas e subjetivas * Use poucas palavras Não faça: {% hint style="danger" %} Apresentar o ReveloTalent para empresas após elas enviarem um primeiro convite de entrevista para um talento da Revelo vai fazer essas empresas gostarem do serviço. {% endhint %} O exemplo acima é ruim, pois usa uma métrica muito subjetiva. Como vamos medir que a empresa gostou? Isso é muito subjetivo.\ \ Faça: {% hint style="success" %} Apresentar o ReveloTalent para empresas após elas enviarem um primeiro convite de entrevista para um talento da Revelo vai fazer essas empresas ficarem interessadas em saber mais sobre o serviço. {% endhint %} ### **Critério de sucesso** Qual é o resultado quantificável esperado? Defina o que é sucesso com o time. Evite ter várias métricas de sucesso para um experimento. Idealmente, use um baseline (uma métrica já existente) para embasar o critério. No caso de produtos novos, sem baseline, vale pensar em uma métrica de tração (Ex.: vender para 20 pessoas).\ \ Não faça: {% hint style="danger" %} Empresas interessadas {% endhint %} Faça: {% hint style="success" %} 2 empresas interessadas (>%1 de conversão) {% endhint %} ### Distribuição e período Entenda quantas pessoas usuárias passam pelo fluxo atual, a ser analisado, e por quanto tempo o teste ficará no ar para você ter um resultado estatisticamente válido. {% hint style="info" %} 30 empresas enviam convites para entrevistas por semana. Vamos trabalhar com 100% do tráfego por 14 dias. Ou seja, mostraremos o teste para 60 empresas. {% endhint %} ## Depois do experimento... * Lembre-se de sempre **documentar o aprendizado.** Atualmente, estamos trabalhando em um repositório de pesquisas, onde você vai poder documentar seus experimentos e suas pesquisas. Enquanto ele não fica pronto, você pode documentar seu experimento com esse [**template**](https://docs.google.com/presentation/d/1dPtiMe4pQMw48KSbPsIvG5qQ9gwsWvg5Cdek8hczVLE/edit?usp=sharing) lindão que usamos aqui na Revelo. É só duplicar o arquivo! * Volte na sua hipótese para constatar se ela foi validada ou não. {% hint style="info" %} [Template para documentar experimentos](https://docs.google.com/presentation/d/1dPtiMe4pQMw48KSbPsIvG5qQ9gwsWvg5Cdek8hczVLE/edit#slide=id.ge9289d9f13_0_8) {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://revelo.gitbook.io/playbook/introducao/configuracao-de-experimentos.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.