Funis SaaS: conte as mesmas pessoas na ordem certa

Um funil é uma pergunta com regras de contagem

Um funil de conversão SaaS mede como um grupo elegível avança por uma sequência definida de ações. Sua utilidade depende das regras: quem entra, quais ações contam, se a ordem importa, quanto tempo a conclusão pode levar e qual identificador representa uma pessoa ou conta.

Um gráfico com visualizações da página inicial, cadastros e pagamentos do mesmo mês não é automaticamente um funil. Os pagamentos podem pertencer a cadastros do mês passado. Visualizações podem incluir visitas repetidas da mesma pessoa. Comece pela jornada que quer entender, não pelos eventos mais convenientes para desenhar.

Escolha uma sequência curta ligada ao valor

Para um produto fictício de relatórios, um funil de ativação razoável seria conta criada, fonte de dados conectada e primeiro relatório útil visualizado. Pagamento pode ser um resultado final separado. Clicar em um menu costuma ser um evento diagnóstico, não uma definição de sucesso. Se o usuário alcança valor sem conectar uma fonte, explicite esse caminho alternativo em vez de classificá-lo silenciosamente como abandono.

Decida se a pergunta é sobre contas ou pessoas. Em uma conta de equipe, alguém pode instalar e outra pessoa comprar. Unir os dois exige uma associação de conta documentada e autorizada. Se a implementação só reconhece sessões de navegador, chame de funil de sessões, não de pessoas reconhecidas entre dispositivos.

Documente entrada, ordem e tempo

Um funil fechado exige entrada pelo primeiro passo. Um aberto permite entrar nos passos seguintes. A documentação de exploração de funis do Google explica essa distinção e a ordem dos passos. Use o fechado para perguntar o que acontece com novas contas. Use uma visão aberta para explorar onde as pessoas entram em uma jornada existente.

Decida se outras ações podem ocorrer entre os passos, se tentativas repetidas contam e se a pessoa é contada uma ou várias vezes. “Conectou uma fonte em até sete dias após o cadastro” é reproduzível. “Ativou em algum momento” muda conforme coortes antigas ganham mais tempo. Guarde a definição ao lado do gráfico e crie versões quando o produto mudar.

Contrato de exemplo: produto fictício de relatórios
Unidade: account ID, contado uma vez
Entrada: primeira criação bem-sucedida da conta
Sequência: account_created -> source_connected -> report_viewed
Ordem: obrigatória; outros eventos podem ocorrer entre os passos
Janela: 7 dias a partir da criação da conta
Exclusões: contas internas, de teste e automatizadas conhecidas

Calcule taxas entre passos e conversão total separadamente

Suponha uma coorte semanal fictícia e completa com 100 contas. Em sete dias, 60 conectam uma fonte e 30 depois visualizam um relatório útil. A conversão de cadastro para conexão é 60 / 100 = 60%. De conexão para relatório é 30 / 60 = 50%. A ativação geral é 30 / 100 = 30%.

A primeira transição perde 40 contas; a segunda, 30. Isso não torna a primeira automaticamente mais importante. A segunda pode ter um defeito grave que atinge compradores adequados, enquanto a primeira inclui cadastros casuais. Priorize falhas reproduzíveis, intenção, esforço e impacto esperado, não apenas a maior barra vermelha.

Não divida os 30 pagamentos deste mês pelos seus 100 cadastros sem confirmar que pertencem à mesma coorte. Em um relatório de conversão para pagamento, associe o primeiro pagamento válido à coorte elegível, remova duplicatas e preserve a janela definida de observação.

Dê a todas as coortes a mesma oportunidade

Se contas criadas ontem têm sete dias para ativar, seu resultado ainda está incompleto. Compará-las com contas de três semanas atrás prejudica as mais novas. Espere a janela terminar ou identifique coortes imaturas e compare o mesmo tempo transcorrido.

Uma tabela útil mostra início da coorte, contas elegíveis, contas com janela completa, resultados válidos e última atualização. Quando o tempo de acompanhamento difere, informe a limitação em vez de transformar resultados ausentes em zero. Da mesma forma, um identificador removido ou inacessível é ausência de evidência, não prova de abandono.

Depure a mensuração antes de redesenhar o produto

Passe uma conta de teste autorizada por cada fluxo de cadastro disponível. Verifique login por e-mail, login social, convites e atalhos de upgrade que contornem o caminho inicial. Confirme que os eventos existem no projeto correto com horário e associação de conta adequados. Teste também uma falha: clicar em Conectar não deve contar como conexão concluída.

Depois examine alguns casos reais aos quais tenha acesso legítimo. O pré-requisito foi concluído? O usuário recebeu um resultado útil? O evento chegou atrasado? Uma ruptura súbita logo após alterar a instrumentação pede uma revisão da instrumentação primeiro. Não prova que os clientes passaram a rejeitar o produto de repente.

Transforme o achado em um teste

Escolha uma hipótese específica: “Contas abandonam a conexão porque as permissões necessárias não são explicadas”. Melhore a explicação, registre a data da publicação e compare coortes maduras de aquisição semelhante. Com poucos casos, comentários de usabilidade podem ser mais úteis do que um experimento elaborado.

Separe o que mudou do que foi observado. Uma taxa melhor após a publicação não prova, sozinha, que a mudança a causou. O guia de plano analítico ajuda a escolher a pergunta de negócio; o de atribuição explica a ligação separada entre uma jornada e dinheiro verificado.

Referências

• Google Analytics: funis ordenados, abertos e fechados
• Google Analytics: retenção e abandono no funil

Guias relacionados