Cinco contadores de engajamento: o Bluesky tem métricas?

O Bluesky tem métricas?

Pergunte se o Bluesky tem métricas e a resposta é não: os lexicons do AT Protocol que definem cada resposta da API do Bluesky não carregam contador de visualizações, contador de impressões nem endpoint de métricas. Um post volta com cinco contadores de engajamento. Um perfil volta com totais de seguidores, seguindo e publicações. Nada em lugar nenhum diz quantas pessoas viram o que você publicou.

Isso é uma afirmação sobre uma ausência, então aqui está exatamente o que foi verificado antes de fazê-la, em 10 de setembro de 2026:

• Todos os arquivos de lexicon em bluesky-social/atproto no branch main, 404 arquivos JSON no total. Uma busca sem diferenciar maiúsculas e minúsculas em todos eles retorna zero ocorrências de impression, viewCount, analytic e insight.
• A definição de postView em lexicons/app/bsky/feed/defs.json, campo por campo.
• A listagem do diretório lexicons/app/bsky, para nomear cada namespace que existe.
• Uma chamada ao vivo sem autenticação ao AppView público, para confirmar que o serviço em execução devolve o que o schema promete.

A afirmação cobre os lexicons de primeira parte e o AppView público. Ela não diz nada sobre painéis internos que a Bluesky PBC opere para si mesma, nem sobre serviços de terceiros que modelam alcance a partir de outros sinais.

Quais campos o app.bsky.feed.defs#postView carrega de verdade?

Quinze, e cinco deles são contadores.

Dois detalhes dessa tabela passam batido com facilidade. indexedAt é um carimbo de indexação, então é o campo errado para usar como horário de publicação; o valor createdAt dentro de record é o que você quer. E os contadores não estão na lista required da definição, que diz ["uri", "cid", "author", "record", "indexedAt"]. Uma resposta em conformidade pode omitir likeCount por completo, então o código que lê esse campo deve tratar um valor ausente como desconhecido, e não como zero.

Aqui está o serviço em execução dizendo a mesma coisa:

GET https://public.api.bsky.app/xrpc/app.bsky.feed.getAuthorFeed?actor=bsky.app&limit=1
 
"post": {
  "uri": "at://...",
  "cid": "...",
  "author": { ... },
  "record": { ... },
  "embed": { ... },
  "replyCount": 1,
  "repostCount": 2,
  "likeCount": 132,
  "quoteCount": 3,
  "bookmarkCount": 3,
  "indexedAt": "...",
  "labels": []
}

Cinco chaves terminando em Count. Nenhuma sexta.

Existe um namespace de métricas sob app.bsky?

Não. Treze namespaces ficam sob app.bsky, e cada um deles tem uma função que não é medir.

Amplie a busca para além de app.bsky e o quadro se mantém. As outras raízes do repositório são com.atproto para o encanamento do protocolo, chat.bsky para mensagens diretas, tools.ozone para moderação, além de internal.bsky, site.standard e com.germnetwork. Os únicos endpoints de todo o conjunto com sabor estatístico são tools.ozone.report.getLiveStats, tools.ozone.report.getHistoricalStats, tools.ozone.report.refreshStats e tools.ozone.moderation.getReporterStats. Esses relatam filas de moderação para moderadores. getLiveStats está documentado como "Get live report statistics from the past 24 hours. Filter by queue, moderator, or report type." Nada disso encosta no desempenho de um post.

Por que o protocolo define um evento de visualização e nunca o devolve?

Porque o evento de visualização flui para os geradores de feed, não para os autores. Essa é a parte que vale citar quando alguém insiste que o dado tem que estar lá em algum lugar.

app.bsky.feed.sendInteractions é um procedimento cuja entrada é um array de objetos app.bsky.feed.defs#interaction. Cada interação nomeia um item por uma AT URI e um token de evento. Os valores conhecidos incluem:

Ou seja, o vocabulário de uma impressão existe. interactionSeen é, em bom português, um evento de visualização. O que falta é um caminho de leitura. A descrição do próprio procedimento diz que ele envia a informação "back to the feed generator that served them", e o schema de saída é um objeto vazio, {"type": "object", "properties": {}}. Quem opera um feed personalizado consegue contar eventos de visualização dos itens que seu feed entregou. Você, como autor de um post, não tem endpoint algum que devolva quantas vezes seu post foi visto, nesse feed ou em qualquer outro.

Essa assimetria é a resposta honesta para por que o Bluesky dá a sensação de que deveria ter contagem de visualizações. O sinal está definido, é coletado pelos clientes e entregue aos geradores de feed. Para por aí.

O que dá para medir no Bluesky hoje?

Bastante coisa, desde que você pare de procurar alcance.

As listas de contas com nome merecem mais atenção do que recebem. Na maioria das redes você recebe um total de curtidas e nada mais. O Bluesky te entrega as contas, o que significa que dá para perguntar de quem vêm seus reposts, se os mesmos vinte perfis sustentam cada lançamento e quais seguidores nunca interagiram uma vez sequer. Esse é um tipo de análise diferente do de impressões, e em algumas perguntas é melhor.

app.bsky.feed.getPosts recebe um array uris com maxLength de 25, então uma rotina em lote que confere um mês de posts avança em blocos de 25. app.bsky.feed.getAuthorFeed recebe limit com máximo de 100 e padrão de 50, mais um cursor, e está documentado como "Does not require auth", que é por isso que o exemplo acima roda contra public.api.bsky.app sem token.

O que uma ferramenta de métricas do Bluesky pode te dar com honestidade?

Duas coisas, e ela deveria deixar claro qual é qual.

A primeira é o próprio registro de publicação. Um agendador sabe o que enviou, de qual conta, em que minuto, com que texto, hashtags e mídia, porque foi ele quem enviou. Nenhuma API concede isso; são dados de primeira parte que a ferramenta já tem. É também a metade que falta para a maioria das pessoas, porque uma planilha de horários de envio é o que transforma um monte de contadores em comparação.

A segunda são os contadores públicos, amostrados ao longo do tempo. Chamar getAuthorFeed ou getPosts de forma programada e guardar likeCount, repostCount, replyCount, quoteCount e bookmarkCount a cada passagem transforma um número em uma curva, que mostra por quanto tempo um post continuou acumulando engajamento depois de sair.

Junte as duas e você responde perguntas reais: quais dos seus posts no Bluesky conquistaram engajamento, publicados em que hora, em que formato, ao lado dos mesmos posts nas outras redes do seu calendário. É essa junção que as métricas do Bluesky da AdaptlyPost reportam, e o mesmo formato de relatório cobre as outras redes através de métricas de redes sociais.

O que nenhuma ferramenta consegue te dar, incluindo esta, são impressões, alcance, visualizações de vídeo ou visitas ao perfil de um post do Bluesky. Esses números não estão na API, então um painel que os exibe está modelando ou está rotulando outra coisa. A pergunta útil para qualquer fornecedor é de qual campo o número veio. Se a resposta não for um dos cinco contadores ou um total de seguidores, o número é uma estimativa.

Agendar também não muda nada disso. Publicar por um agendador de posts do Bluesky te dá um log de envio limpo para medir; não dá ao Bluesky um contador de visualizações que ele não tem.

O que esta página não afirma

Ela não afirma que o Bluesky nunca vai lançar contagem de visualizações. A lista de campos cresce: bookmarkCount está ao lado dos quatro contadores mais antigos, e app.bsky.bookmark é um namespace completo, com endpoints próprios de criação, exclusão e listagem. Se um viewCount aparecer algum dia, ele vai surgir em lexicons/app/bsky/feed/defs.json antes de surgir em qualquer cliente, e esse arquivo é público. Confira por lá em vez de confiar em uma captura de tela.

Perguntas frequentes

O aplicativo do Bluesky mostra contagem de visualizações em algum lugar?

Não. O cliente oficial renderiza os mesmos contadores que a API devolve, que são curtidas, reposts, respostas, citações e itens salvos. Não existe número de visualizações ou impressões em um post, em um perfil ou em qualquer tela de configurações, porque nenhum endpoint fornece esse dado.

Existe algum endpoint de métricas nos lexicons do AT Protocol?

Não. Uma busca nos 404 arquivos de lexicon de bluesky-social/atproto não retorna arquivo nem campo nomeado por métricas, insights ou impressões. Os quatro endpoints que contêm "Stats" ficam todos sob tools.ozone, o namespace do ferramental de moderação, e relatam denúncias de moderação em vez de posts.

Uma ferramenta consegue estimar impressões do Bluesky pelo firehose?

Medir não, apenas modelar. O firehose com.atproto.sync transmite commits de repositório, então quem consome vê a criação de registros app.bsky.feed.like e app.bsky.feed.repost conforme acontecem. Visualizar um post não cria registro nenhum, o que significa que nada atravessa o firehose quando alguém lê e passa adiante. Qualquer número de impressões derivado dali é saída de modelo.

O app.bsky.feed.sendInteractions me deixa ver quem viu meu post?

Não. É um procedimento, não uma consulta. Os clientes empurram eventos de interação para dentro dele, incluindo interactionSeen, e o schema de saída é um objeto vazio. Os eventos são entregues ao gerador de feed que serviu o item, então não existe rota de volta para o autor do post.

Os contadores de engajamento estão sempre presentes na resposta da API?

Não. A lista required de app.bsky.feed.defs#postView é ["uri", "cid", "author", "record", "indexedAt"], o que deixa cada contador opcional. Trate um likeCount ausente como valor desconhecido em vez de assumir zero, ou uma queda de serviço vai parecer um post que ninguém curtiu.

Quantos posts dá para checar em uma única chamada?

Vinte e cinco com app.bsky.feed.getPosts, que limita o array uris em maxLength: 25. app.bsky.feed.getAuthorFeed devolve até 100 posts por página com um cursor para a próxima, e não precisa de autenticação, então é o caminho mais barato quando você quer o histórico recente de uma conta inteira.

O bookmarkCount do Bluesky significa que mais métricas estão a caminho?

O bookmarkCount é o mais novo dos cinco contadores, somado a likeCount, repostCount, replyCount e quoteCount, e app.bsky.bookmark já tem seu próprio namespace completo com endpoints para criar, excluir e listar. Um viewCount poderia seguir o mesmo caminho. Se chegar, vai aparecer primeiro em lexicons/app/bsky/feed/defs.json antes de qualquer cliente, então esse arquivo é o lugar certo para conferir, não uma captura de tela.

Os endpoints de estatísticas do tools.ozone contam como métricas de post do Bluesky?

Ali não há métricas de post. Os quatro endpoints de estatísticas do repositório, getLiveStats, getHistoricalStats, refreshStats e getReporterStats, ficam todos sob tools.ozone, o namespace de moderação, e reportam sobre filas de moderação e denunciantes para moderadores. Nenhum deles toca em respostas, curtidas ou alcance de um post.

Preciso fazer login para conferir os números de engajamento de um post do Bluesky?

Os contadores públicos não pedem login. app.bsky.feed.getAuthorFeed é documentado como algo que não exige autenticação, por isso uma chamada a public.api.bsky.app sem token retorna os mesmos campos likeCount, repostCount, replyCount, quoteCount e bookmarkCount mostrados neste post. O que fica atrás da sua própria conta, como configurações de notificação, é outra história, mas ler os contadores públicos de outra conta só precisa da URL.

Devo confiar em um painel do Bluesky que mostra impressões ou alcance?

Desconfie se o fornecedor não conseguir nomear o campo. Impressões, alcance, visualizações de vídeo e visitas ao perfil não existem em nenhum lugar dos lexicons do AT Protocol, então um painel que os mostra está modelando o número a partir de outros sinais ou renomeando um dos cinco contadores reais. Pergunte de qual campo o número vem; se a resposta não for likeCount, repostCount, replyCount, quoteCount, bookmarkCount ou um total de seguidores, é uma estimativa.