Soluções · SaaS
Rode o seu próprio programa, no seu próprio site
O seu time é dono do roadmap e roda os testes. O Pertento é a plataforma por baixo: uma tag de script, um editor visual e resultados que ninguém precisa aceitar por fé.
Rodando por conta própria
A partir da primeira tarde
Como instalar, quem você convida, e como uma mudança é implantada quando não tem tempo de engenharia para gastar nisso.
Para começar
No ar na primeira tarde
Uma tag de script no head e o console começa a reportar. Nada para comprar, nenhum pipeline de dados para construir, nenhum sprint de engenharia para agendar.
- Um tracker de 0,9 KB, sem cookies, sem dados pessoais
- O editor visual roda a partir de uma extensão do Chrome no seu site no ar
- Um teste novo é um rascunho até você iniciá-lo e publicar o site
O time
Convide todo mundo, pague por sessões
O preço é por sessão no site, não por assento, então o designer que escreve a variante e o analista que lê o resultado não custam a mais.
- Usuários ilimitados em todos os planos
- Papéis para quem pode iniciar, parar e implantar
- Um registro de atividade de quem mudou o quê
Sem engenharia
Implante a mudança, repasse o vencedor
A maioria das variantes nunca precisa de um desenvolvedor. As que valem a pena manter geram um ticket de implementação com o seletor e a mudança exata, então o repasse é um colar em vez de uma reunião.
- Edição sem código de texto, estilo, layout e posição
- Repasse de implementação para vencedores que vale a pena fixar no código
- O teste continua servindo até o código ir ao ar
Na prática
Como é rodar isso sozinho em uma terça-feira
A parte difícil de um programa interno raramente é o primeiro teste. É manter vários deles andando quando experimentação não é o trabalho de tempo integral de ninguém.
O tráfego não limita o seu ritmo
Cada visitante elegível entra em cada teste elegível, então um time pequeno consegue manter oito testes no ar em um site de porte médio sem que nenhum demore mais para concluir. O conselho de rodar um por vez é uma limitação das outras ferramentas.
Quem decide é o backlog, não a voz mais alta
Dê nota a cada ideia em potencial, exposição e esforço, e a lista se organiza sozinha. Quando nada está quebrado e nada espera decisão, o console diz qual rascunho retomar.
Somente leitura é um papel de verdade
Os membros veem tudo e não mudam nada, e é isso que torna seguro dar uma conta para o time inteiro. Iniciar, parar e publicar ficam com administradores e proprietários, e cada mudança é registrada no teste com um nome.
O segundo teste sai mais barato que o primeiro
Duplicar um teste leva junto as variantes, as mudanças, as capturas de tela e os três tipos de segmentação. A maior parte do custo de um programa é remontar configurações, e a maior parte dos erros está justamente na parte que se reconstrói na mão.
Ninguém precisa lembrar de parar
Agende o início e o fim já na hora de montar. A parada na significância vem por cima, com duração mínima e data de fim obrigatória, de modo que uma parada antecipada só pode ser antecipada e nunca a única coisa que encerra um teste.
Ele avisa quando um teste quebra
Uma divisão que parou de bater com a configuração, ou um dia sem tráfego nenhum, chega para você por e-mail e no Slack em vez de esperar alguém notar. Nos dois casos costuma significar que um deploy levou o script ou que uma regra de segmentação parou de casar.
Perguntas
Antes de trazer isso para dentro de casa
Quão pequeno pode ser o time?
Uma pessoa que saiba editar o site e ler um gráfico. O trabalho que normalmente exige um especialista é exatamente a parte que já vem embutida: o editor tira o desenvolvedor da maioria das variantes, a ordenação do backlog tira a discussão sobre o que rodar em seguida, e a fila do que espera decisão tira a checagem diária de se algo quebrou. O que ele não faz é decidir o que vale a pena testar, e nenhuma plataforma faz. Se ninguém é dono dessa pergunta, comprar software não cria um dono.
O que os nossos desenvolvedores vão precisar fazer?
Três coisas, e só a primeira é inevitável. Colocar um script no head, uma vez, que é a única mudança no seu site. Construir os testes no servidor, onde o seu próprio backend decide o que é entregue, que são o único tipo de teste realmente feito de código. E fixar os vencedores no código quando você quiser que uma mudança viva na sua base de código em vez de ser entregue por nós, o que é passado com a mudança exata anexada e é um colar em vez de uma reunião. Tudo que fica no meio é feito apontando elementos no site em produção.
Como o custo se comporta quando crescemos?
Ele segue o tráfego testado e não o número de pessoas, então quem faz um programa funcionar não carrega cada um um preço. A designer que escreve a variante, o analista que lê o resultado e quem quer acompanhar podem todos ter conta, e os membros são somente leitura em toda a plataforma, então distribuir essas contas é seguro. O que cresce com você é o tráfego que passa pelos testes, que é a parte ligada ao que você recebe de volta.
Já temos GA4. Isso substitui?
Não, e é melhor que você mantenha. Configure o site para GA4 e o runtime lê os eventos que já circulam na sua camada de dados, então as conversões que medimos são as mesmas que a sua analytics conta. Isso elimina a discussão de sempre entre duas ferramentas com duas definições de compra. A exposição à variante também volta para fora, então um teste passa a ser uma dimensão para segmentar dentro do relatório em que o seu time já confia.
O que acontece com o trabalho se pararmos?
Tudo que já está fixado no código está na sua própria base de código e não é mexido, e é exatamente por isso que a fila de implementação fica insistindo nos vencedores que ainda entregamos. Vencedores ainda entregues pela plataforma param quando ela para, do mesmo jeito que qualquer variante para. Os testes, as hipóteses por trás deles e o registro de cada decisão ficam na conta e não na planilha de um consultor: o que você leva é um programa documentado e não uma pasta de capturas de tela.