Como eu escolheria o primeiro sinal de ativação de um SaaS

A conta foi criada e o usuário entrou. Qual trabalho ele conseguiu concluir? Para escolher um sinal de ativação do SaaS, eu começaria por essa tarefa. Depois conferiria se o evento mede a conclusão e se as contas voltam a fazer trabalho útil.

Cadastro permite entrar. Login mostra acesso. Um candidato a sinal de ativação precisa descrever um avanço útil dentro do produto. Mesmo assim, eu manteria a palavra candidato até conferir como essa ação se relaciona com uso posterior e pagamento.

Qual trabalho o usuário conseguiu concluir?

Imagine um software fictício de propostas comerciais. Criar a conta e abrir o editor permite começar. Salvar uma proposta vazia ainda diz pouco sobre o trabalho realizado. Gerar uma proposta com informações válidas e conseguir compartilhá-la pode ser um candidato mais próximo da tarefa.

O exemplo não define ativação para qualquer SaaS. Num produto colaborativo, o trabalho pode depender de outro membro participar. Num produto de consulta, uma resposta útil pode aparecer numa única sessão. A ação precisa corresponder à promessa específica do software.

Registro hipotético	O que mostra	O que ainda falta
Conta criada	A pessoa concluiu a entrada.	Saber se fez algo útil.
Editor aberto	A pessoa chegou à área de trabalho.	Saber se concluiu a tarefa.
Proposta válida compartilhada	A tarefa candidata foi concluída.	Conferir se esse resultado foi útil e se houve uso posterior.
Assinatura paga	Há uma compra confirmada.	Saber se o produto está sendo usado e se o pagamento se mantém.

Eu levaria essa lista para produto e atendimento. A pergunta seria: qual registro representa o trabalho concluído, e em quais situações ele engana? Uma proposta criada só para testar o editor, por exemplo, não deveria entrar como uso real sem uma regra que diferencie os dois.

Como eu escreveria a regra antes de abrir o gráfico

Ainda no software fictício, eu preencheria a ficha abaixo. Sete dias para a tarefa inicial e os sete seguintes para retorno são escolhas deste exemplo. O prazo real deve acompanhar a tarefa e o modo de uso do seu produto, sem copiar essa janela como benchmark.

Campo	Definição do exemplo fictício
Tarefa candidata	Concluir uma proposta com destinatário e ao menos um item, com compartilhamento confirmado pelo produto.
Unidade	Conta da empresa, identificada da mesma forma em todos os registros.
Janela inicial	Da criação da conta até completar sete dias.
Uso posterior	Concluir e compartilhar uma proposta válida entre o oitavo e o décimo quarto dia. A regra é igual para os dois grupos, sendo a primeira proposta ou uma seguinte.
Quem entra na comparação	Contas que tiveram quatorze dias completos de observação, com ou sem a tarefa inicial.
Exclusões	Contas internas e testes identificados previamente. Repetições do mesmo registro não criam novas contas ativadas.

Na ficha, proposta válida passou a significar algo que duas pessoas conseguem conferir. Isso melhora a definição do registro, mas ainda não prova que o cliente recebeu valor. Eu manteria o evento como candidato enquanto investigasse o uso posterior e a percepção do usuário.

Clique no botão de compartilhar pode ser uma tentativa que falhou. Eu conferiria se o evento ocorre depois da confirmação da tarefa, e se uma atualização de página dispara o mesmo registro novamente. Antes de discutir taxa de ativação, vale reproduzir esse caminho numa conta de teste.

Você está contando usuários ou empresas?

Se um cliente tem cinco usuários, cinco logins não são cinco clientes ativados. Num software comprado por empresa, talvez uma pessoa prepare a conta e outra conclua a tarefa. Nesse caso, contar só o primeiro usuário pode deixar o uso da empresa incompleto no relatório.

Eu escolheria a unidade conforme a pergunta. Para melhorar a entrada de cada pessoa, usuário faz sentido. Para acompanhar a adoção da empresa, conta pode ser mais adequada. Não somaria os dois numa mesma taxa.

A documentação de funis do PostHog permite analisar etapas e uma janela de conversão. Aqui, isso serve de referência de medição, não de recomendação de ferramenta. A regra da tarefa continua sendo uma decisão sobre o seu produto.

Depois da tarefa inicial, as contas voltam a usar o produto?

Para preencher a comparação fictícia, eu começaria pelas contas que já completaram quatorze dias desde a entrada. Separaria aquelas que realizaram a tarefa nos sete primeiros dias e observaria o uso dos dias oito a quatorze nos dois grupos. Contas mais recentes aguardariam a próxima leitura.

A documentação de retenção do PostHog distingue um evento inicial e um evento de retorno, com períodos de acompanhamento. Eu usaria essa separação para explicitar qual uso posterior está sendo procurado. Voltar para abrir o produto e voltar para concluir uma tarefa são perguntas diferentes.

A conta que só concluiu a tarefa no décimo dia continuaria no grupo sem a ação inicial, mas contaria como uso posterior. A conta que fez a tarefa cedo e voltou a fazê-la no décimo dia também contaria. Eu aplicaria o mesmo evento de sucesso aos dois grupos, sem exigir uma segunda proposta só de um deles.

Antes de interpretar a diferença, compare plano, origem e atendimento recebido. Contas acompanhadas de perto podem completar a tarefa e permanecer mais. Uma diferença entre grupos ajuda a investigar o sinal, mas não prova que obrigar a tarefa fará a outra conta ficar.

Que resultado me faria trocar o candidato?

Eu procuraria exceções que revelem uma definição ruim. Há contas que usam o produto com frequência sem disparar o evento? O evento aparece em contas de teste? Ele depende de uma função que só um dos planos oferece? Cada resposta pode pedir uma regra diferente ou outro candidato.

Também manteria pagamento num registro separado. Uma conta pode pagar antes de usar, durante o teste ou depois de uma venda assistida. Misturar compra com ativação esconderia essa sequência. Essa distinção também ajuda a definir quais novos clientes entram no cálculo do CAC. Uso, permanência e receita precisam conversar sem virar o mesmo número.

A ficha que eu preencheria primeiro

Adapte a ficha preenchida começando pela tarefa do seu produto. Troque a regra de sucesso, a unidade e os prazos. Antes de calcular uma taxa, execute a tarefa numa conta de teste e confira se o registro confirma a conclusão, sem contar a mesma conta duas vezes.

Você já terá uma definição revisável, mesmo antes de ter uma taxa bonita no dashboard. Para conectar essa análise à aquisição, continue em Google Ads para SaaS B2B: como ligar anúncios à receita.