Eventos rastreados

Uma visualização de página informa qual página foi aberta. Ela não informa se o leitor copiou o trecho, perguntou ao assistente, rolou a página além da introdução ou saiu para a página de cadastro. Esta página contém a lista completa de tudo o que é registrado, campo a campo, para que você possa verificar, antes de criar uma meta ou um funil, se aquilo que deseja medir já está sendo medido.

O que você obtém#

Trinta e seis eventos docs.* nomeados, em sete categorias, registrados em todos os sites de documentação sem configuração e sem um gerenciador de tags. Cada um deles é uma linha que você pode filtrar em Feeds, associar a uma meta, classificar na visão geral das análises ou consultar por visitante via MCP.

O registro deles não consome nada do saldo do seu projeto, e nada na lista muda de acordo com o seu plano.

O catálogo#

Cada evento inclui o nome completo do seu projeto (owner/repo). A coluna Também inclui mostra o que ele adiciona além disso. Os eventos marcados como beacon são entregues por navigator.sendBeacon no momento em que o leitor sai; os demais usam o transporte comum de registro, que agrupa os eventos por dois segundos.

Assistente de IA#

docs.ai_navigate e docs.ai_outbound são deliberadamente dois eventos, não um. O primeiro diz que o leitor confiou na resposta o suficiente para abrir a página que ela citou; o segundo diz que o assistente o encaminhou para seu aplicativo, seu repositório ou para algum outro lugar — uma questão comercial, não de compreensão.

Pesquisa#

Leitura e engajamento#

docs.pageview é o único evento que o navegador não envia. Ele é gravado no servidor, portanto existe para leitores com JavaScript desativado — e é também por isso que uma visita composta apenas por visualizações de página é tratada como um rastreador. Em páginas servidas pelo cache, a visualização de página é enviada como beacon pelo navegador, e o endpoint de ingestão preenche o mesmo IP e a mesma geografia, portanto os dois caminhos produzem a mesma linha.

seconds é emitido sem processamento e limitado a 300 segundos antes que qualquer relatório faça a soma. Esse limite, e o motivo de sua existência, são explicados em tempo de leitura.

Ações de conteúdo#

Navegação#

docs.heading_nav e docs.heading_view compartilham intencionalmente o formato #anchor para que uma seção agregue os mesmos dados, independentemente de os leitores terem saltado até ela ou rolado até ela.

Saídas e fontes#

docs.page_exit é disparado apenas em uma saída ou recarregamento real. A navegação no site não produz um, e é isso que faz com que o último docs.page_exit de uma visita seja a página da qual o leitor realmente saiu.

Feedback#

A direção está no nome do evento, não em um campo vote: o esquema do armazenamento de eventos é um conjunto fixo de nomes de campos, e um campo não reconhecido é rejeitado imediatamente, em vez de ser descartado. Os votos são registrados por meio de uma rota do servidor para que um webhook possa ser acionado por eles; se essa solicitação falhar, o navegador registra o mesmo evento diretamente, para que a contagem seja preservada.

Automático ou dependente de um recurso#

Não há nenhuma opção de rastreamento em nenhum lugar do Docsbook, nem um sinalizador enabled em nenhum evento. Todos os eventos acima são emitidos sempre que aquilo que os produz existe, o que divide a lista em duas partes:

Um evento "vazio" nos seus relatórios, portanto, tem duas interpretações possíveis, e elas são diferentes: ninguém fez isso ou nada pode fazê-lo ainda.

Como é entregue#

Os eventos comuns passam por um transporte que agrupa os eventos por dois segundos e os envia por fetch. Isso é suficiente para um clique que mantém a página aberta, mas perde tudo no caso de um clique que não mantém a página aberta — por isso, os eventos associados à saída seguem um segundo caminho:

1. Os componentes registram um coletor de saída. Em pagehide, todos os coletores são esvaziados em um único beacon, limitado a 100 eventos, enviado para um endpoint da mesma origem.
2. No iOS, visibilitychange → hidden aciona o mesmo envio, porque pagehide não é confiável nesse sistema.
3. Os coletores retornam apenas o que ainda não enviaram, portanto um envio no iOS seguido por uma saída real não contabiliza duas vezes, e uma página restaurada do cache de voltar/avançar pode enviar novamente.

As visualizações de títulos são coletadas com um IntersectionObserver no limite 0 e com uma -15% margem inferior, e cada título deixa de ser observado assim que é visto: um título é contabilizado uma vez por visualização de página e somente depois que ultrapassa a parte inferior da janela de visualização, em vez do instante em que aparece parcialmente.

Por que esta é a maneira correta#

Como ler os eventos de um visitante#

Duas ferramentas MCP reconstroem o percurso de um visitante anônimo de ponta a ponta, e ambas são operações de leitura: get_top_visitors lista os visitantes mais ativos durante um período, get_visitor_activity retorna os eventos de um visitante em ordem.

get_top_visitors(period: "7d", limit: 25)
  → [{ visitor_id: "a1b2…", pageview_count: 14, first_seen, last_seen, country }, …]
 
get_visitor_activity(visitor_id: "a1b2…", period: "7d")
  → { first_seen, last_seen, country, language, pageview_count,
      events: [
        { event: "docs.pageview",           at, path: "guides/quick-start" },
        { event: "docs.page_feedback_down", at, path: "guides/quick-start" },
        { event: "docs.search_no_result",   at, query: "rotate api key" },
        … ] }

visitor_id é um hash com salt do IP do leitor, limitado ao seu projeto; IPs brutos nunca são retornados. Consulte como funciona a medição.

Limites e questões em aberto#

• Nenhum webhook pode ser disparado em um evento docs.*. Esses eventos ficam no armazém de eventos, e nada os despacha. Eles podem ser filtrados nos Feeds e salvos em uma lista, e aparecem como not_sent nela porque é isso que são. Os alertas sobre o comportamento dos leitores passam pelos eventos de webhook derivados — queda de tráfego, pesquisa popular, pesquisa sem resultados — e não por este catálogo. Consulte webhooks.
• Os eventos são contabilizados por evento, não por visita. Um leitor copiando cinco snippets gera cinco linhas docs.copy_code. Tudo o que precisa ser contabilizado por visita — rejeição, conversão, uma meta — é derivado pela reconstrução da visita, não pela soma desta lista.
• Um leitor com JavaScript desativado contribui apenas com docs.pageview. Todos os outros eventos acima precisam de um script em execução, que é exatamente aquilo em que o filtro de rastreador comportamental se baseia.
• Os campos question e answer contêm tudo o que o leitor digitou. As leituras brutas de eventos passam por um processo de mascaramento que oculta qualquer campo cuja chave ou valor pareça um token, uma chave, um JWT ou um cabeçalho de autorização, mas um leitor que digita algo pessoal no seu assistente está digitando isso no seu armazenamento de eventos. A retenção é de 30 dias.
• Questão em aberto: o catálogo é autoritativo, mas não é exaustivo em relação ao fluxo. O que pode ser verificado é que estes 36 nomes são os que todas as interfaces — o painel, os Feeds, a validação de metas, o MCP — leem de uma única lista compartilhada, portanto uma meta só pode ser declarada para um nome presente nela. O que não pode ser verificado: alguns nomes docs.* adicionais são emitidos pelo fluxo de teaser de site não reivindicado e não estão nessa lista, o que significa que chegam ao armazenamento e ficam invisíveis na interface. Considere os 36 como o conjunto completo de eventos sobre os quais você pode agir, não como um inventário completo de todas as strings no fluxo.

Relacionado#

• Como funciona a medição — identidade do visitante, filtragem de bots, retenção e privacidade para tudo nesta página
• Visão geral da análise — os cartões e números alimentados por esses eventos
• Metas e funis — declarar um resultado em um desses nomes de evento
• Tempo de leitura — docs.read_time como um relatório
• Webhooks — os eventos que podem notificá-lo