Iniciar sessão Começar grátis
MÉTRICAS E RELATÓRIOS

Plano de tracking para um lançamento

Use quando uma funcionalidade está prestes a sair e precisa de decidir o que medir em vez de remendar depois.

event-taxonomy-tracking-plan.md
Transferir .md 
És um engenheiro de medição a escrever um plano de tracking. Não estás a escrever código de implementação, apenas a especificar o que é enviado e porquê.

Funcionalidade ou lançamento: {{FEATURE_DESCRIPTION}}
Perguntas a que temos de conseguir responder depois do lançamento: {{QUESTIONS_TO_ANSWER}}
Eventos já em uso e a convenção de nomes que seguem: {{EXISTING_EVENTS}}
Plataformas no âmbito: {{PLATFORMS}}

Devolve:
1. Um mapa de pergunta para evento: Pergunta | Evento que lhe responde | Parâmetros necessários | Porque é que nada em {{EXISTING_EVENTS}} já lhe responde.
2. Uma tabela de eventos a cobrir cada passo de {{FEATURE_DESCRIPTION}}: Nome do evento | Gatilho, descrito com precisão suficiente para que dois programadores o disparassem no mesmo momento | Parâmetros com tipo e valor de exemplo | Plataforma de {{PLATFORMS}} | Obrigatório ou opcional.
3. Decisões de nomenclatura, seguindo a convenção em {{EXISTING_EVENTS}}. Se essa convenção já for inconsistente, di-lo e escolhe uma.
4. Identidade: que identificador fica anexado a cada evento, e o que acontece aos eventos disparados antes do início de sessão.
5. Uma checklist de QA: para cada evento, o que fazer no produto e o que deve aparecer.

Regras:
- Não acrescentes um evento de que nenhuma pergunta em {{QUESTIONS_TO_ANSWER}} precise. Enumera o que consideraste e deixaste cair.
- Nunca ponhas um endereço de email, um nome ou um campo de texto livre num parâmetro. Assinala qualquer pergunta que o exigisse.
- Onde uma pergunta não puder ser respondida só com eventos do cliente, diz que dados de backend ou de faturação são precisos em vez disso.
- Mantém o plano em 12 eventos ou menos.

Preencher antes de executar

Substitua cada espaço pelos seus próprios dados. Quanto mais específico for, menos o modelo inventa.

  • {{FEATURE_DESCRIPTION}}
  • {{QUESTIONS_TO_ANSWER}}
  • {{EXISTING_EVENTS}}
  • {{PLATFORMS}}

Como obter um resultado melhor

  1. Escreve a secção 1 com quem pediu a funcionalidade; perguntas sem dono produzem eventos que ninguém consulta.
  2. Dá uma plataforma por linha em vez de "todas", ou o passo de QA acaba saltado na plataforma mais pequena.
  3. Congela os nomes dos eventos antes de a sprint começar; renomear depois do lançamento parte o histórico em dois.