Disciplina de Anotação

Seis meses depois de uma alteração ninguém se lembra do que foi para produção, pelo que todo o movimento de tráfego é atribuído ao que estiver na moda. As funcionalidades de anotação das ferramentas de analytics são normalmente abandonadas ao fim de um mês porque obrigam a sair do fluxo de trabalho. A solução é tornar o registo o artefacto mais barato possível e registar as coisas que ninguém se lembra de registar.

O ficheiro da competência

---
name: annotation-discipline
description: Use quando estiver a montar ou a reparar o registo do que mudou num site e quando.
---

# Disciplina de Anotação

Seis meses depois de uma alteração ninguém se lembra do que foi para produção, pelo que todo o movimento de tráfego é atribuído ao que estiver na moda. As funcionalidades de anotação das ferramentas de analytics são normalmente abandonadas ao fim de um mês porque obrigam a sair do fluxo de trabalho. A solução é tornar o registo o artefacto mais barato possível e registar as coisas que ninguém se lembra de registar.

## O que precisa primeiro

- uma única folha ou ficheiro partilhado, não uma ferramenta
- acesso a deploys ou a um feed de releases
- acordo sobre quem regista o quê

## Método

1. Use uma tabela plana com data, o que mudou, padrão de URL afetado, quem o fez, efeito esperado. Qualquer coisa mais rica não será mantida.
2. Registe também alterações não-SEO: páginas de preços, fluxos de checkout, reestruturações da navegação, uma alteração no banner de consentimento. As alterações no banner de consentimento destroem a comparabilidade dos dados e nunca estão num registo de SEO.
3. Registe o efeito esperado antes de ver os dados. Esta é a única defesa contra ajustar retroativamente uma história ao que o gráfico fez.
4. Registe a data em que a alteração ficou ativa para os crawlers, não a data do merge. Um template em cache pode estar dias atrasado.
5. Inclua coisas que não fez mas que lhe aconteceram: o relançamento de um concorrente, o aparecimento de uma funcionalidade na SERP, um feed de fornecedor a falhar.
6. Reveja o registo no início de cada ciclo de reporte antes de abrir a analytics, para que o registo enquadre os números e não o contrário.

## O que isto produz

Um registo de alterações datado e mantido que qualquer analista consegue ler a frio e usar para explicar um gráfico.

## Onde isto corre mal

- Registar apenas trabalho de SEO, de modo que a reconstrução de um site de marketing que reduziu o tráfego a metade aparece como um evento algorítmico inexplicado
- Preencher de memória uma vez por trimestre, o que produz datas confiantes erradas por semanas
- Manter o registo privado a uma só pessoa, de modo que morre quando ela sai

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/annotation-discipline

O que precisa primeiro

• uma única folha ou ficheiro partilhado, não uma ferramenta
• acesso a deploys ou a um feed de releases
• acordo sobre quem regista o quê

Método

1. 01 Use uma tabela plana com data, o que mudou, padrão de URL afetado, quem o fez, efeito esperado. Qualquer coisa mais rica não será mantida.
2. 02 Registe também alterações não-SEO: páginas de preços, fluxos de checkout, reestruturações da navegação, uma alteração no banner de consentimento. As alterações no banner de consentimento destroem a comparabilidade dos dados e nunca estão num registo de SEO.
3. 03 Registe o efeito esperado antes de ver os dados. Esta é a única defesa contra ajustar retroativamente uma história ao que o gráfico fez.
4. 04 Registe a data em que a alteração ficou ativa para os crawlers, não a data do merge. Um template em cache pode estar dias atrasado.
5. 05 Inclua coisas que não fez mas que lhe aconteceram: o relançamento de um concorrente, o aparecimento de uma funcionalidade na SERP, um feed de fornecedor a falhar.
6. 06 Reveja o registo no início de cada ciclo de reporte antes de abrir a analytics, para que o registo enquadre os números e não o contrário.

O que isto produz

Um registo de alterações datado e mantido que qualquer analista consegue ler a frio e usar para explicar um gráfico.

Onde isto corre mal

• Registar apenas trabalho de SEO, de modo que a reconstrução de um site de marketing que reduziu o tráfego a metade aparece como um evento algorítmico inexplicado
• Preencher de memória uma vez por trimestre, o que produz datas confiantes erradas por semanas
• Manter o registo privado a uma só pessoa, de modo que morre quando ela sai

Use esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em Métricas e relatórios