Recentemente lançamos aqui no Convenia um MVP (Minimum Viable Product ou Mínimo Produto Viável) na nossa área de benefícios, com a principal motivação de entender se seria possível vender produtos de parceiros diretamente para os RHs das empresas, sem a necessidade de ter um intermediador (vendedor) no processo.
Mas para isso ocorrer deveríamos seguir fielmente o propósito de um MVP que é ter um produto bem feito, sem falhas, sendo uma versão mais "clean" e que resolva o problema que gostaríamos de validar, neste caso se o RH contrata ou não um benefício.
A primeira etapa foi desenhar a ideia, normalmente poderia ser feito em papel, ou em qualquer ferramenta de wireframes. Nosso time de UXs com o passar do tempo deixou de utilizar essas opções, e com a evolução do nosso design system normalmente entregam um esboço além das expectativas.
Além de pensar no MVP, o time de UXs já pensa em possíveis melhorias futuras, acrescentando outras áreas do sistema, simulando como poderia ser a evolução da área. Para o MVP, existe um alinhamento com o PO e com o time de desenvolvedores para entender o que seria viável para a primeira entrega em um curto espaço de tempo, e assim separando os principais itens para o processo de desenvolvimento.
Alinhada a expectativa entre produto, uxs e desenvolvedores, se inicia o desenvolvimento.
Neste caso específico o projeto durou um pouco menos de 8 dias trabalhados.
E o resultado foi:
Veja que o resultado foi bem mais simples do que o proposto pelos UXs em um primeiro momento.
MVP finalizado chegou a hora de ter maneiras de mensurar se o projeto foi bem sucedido ou se falhou em alguma etapa para conseguirmos atacar o problema, caso tenha.
Para esse teste específico utilizamos a dupla do barulho Tag Manager + Analytics.
Foi importante uma boa estruturação do código para conseguirmos emitir eventos por meio do Tag Manager. Veja abaixo como o call to action de visualizar informações de um benefício foi criado com um data atribute 'data-exclusive-benefit-open', nele é adicionado o nome do parceiro.
Já no Tag Manager criamos uma variável que ficaria responsável por mandar para o data layer o valor do nome do data atribute criado.
Com a variável criada criamos uma tag responsável por emitir um evento para o analytics, essa tag é a responsável por mandar junto do evento o valor da variável que criamos na etapa anterior e mais informações do usuário logado.
Feito isso só faltou criar um trigger para executar essa tag.
Seguimos esse padrão para as 3 etapas que gostaríamos de obter dados do MVP.
1 - Acesso a página de benefícios (neste caso sem a informação do parceiro)
2 - Clique o call to action
3 - Contratação do benefício
Com isso temos dados valiosos no analytics onde podemos por exemplo criar um funil de conversão e atacar possíveis problemas.
Por exemplo nesta imagem, por que apenas 5% dos usuários que acessaram a área de benefícios converteram?
E que se inicie uma nova etapa de entrevistas com os usuários, teste a/b entre outras formas de validação para identificarmos os problemas =)
E ai? Visualiza no projeto que está trabalhando alguma forma de aplicar um fúnil de conversão ou uma integração entre Tag Manager e Analytics?
Em caso de dúvidas fico a disposição =)
Além disso estamos sempre com vagas para o time de produto:
https://convenia.gupy.io
Abs
Top comments (2)
Great article!
Can you share more examples of Conversion funnel and Dev team integration?
What is the role of the technology team to discover and test conversion bottlenecks?
Thanks!
In my point of view the technology team should have interaction at all stages of development product.
Maybe the correct word be "interest". This way the team could create new options to increase the way to get data.
In the future, I will share more examples with google analytics.