Cinq compteurs d'engagement : Bluesky a-t-il des statistiques ?

Bluesky a-t-il des statistiques ?

Posez la question, Bluesky a-t-il des statistiques, et la réponse est non : les lexicons de l'AT Protocol qui définissent chaque réponse de l'API Bluesky ne portent aucun compteur de vues, aucun compteur d'impressions et aucun endpoint de statistiques. Une publication revient avec cinq compteurs d'engagement. Un profil revient avec des totaux d'abonnés, d'abonnements et de publications. Rien nulle part ne vous dit combien de personnes ont vu ce que vous avez publié.

C'est une affirmation portant sur une absence, alors voici exactement ce qui a été vérifié avant de la formuler, le 10 septembre 2026 :

• Chaque fichier de lexicon dans bluesky-social/atproto sur la branche main, soit 404 fichiers JSON au total. Une recherche insensible à la casse sur l'ensemble renvoie zéro occurrence de impression, viewCount, analytic et insight.
• La définition postView dans lexicons/app/bsky/feed/defs.json, champ par champ.
• Le listing du répertoire lexicons/app/bsky, pour nommer chaque namespace existant.
• Un appel en direct non authentifié à l'AppView public, pour confirmer que le service en fonctionnement renvoie bien ce que le schéma annonce.

L'affirmation couvre les lexicons de première partie et l'AppView public. Elle ne dit rien des tableaux de bord internes que Bluesky PBC exploite pour elle-même, ni des services tiers qui modélisent la portée à partir d'autres signaux.

Quels champs app.bsky.feed.defs#postView porte-t-il réellement ?

Quinze, et cinq d'entre eux sont des compteurs.

Deux détails de ce tableau passent facilement inaperçus. indexedAt est un horodatage d'indexation, c'est donc le mauvais champ pour servir d'heure de publication ; la valeur createdAt à l'intérieur de record est celle qu'il vous faut. Et les compteurs ne figurent pas dans la liste required de la définition, qui se lit ["uri", "cid", "author", "record", "indexedAt"]. Une réponse conforme a le droit d'omettre entièrement likeCount, donc le code qui le lit devrait traiter une valeur absente comme inconnue plutôt que comme zéro.

Voici le service en fonctionnement qui dit la même chose :

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": []
}

Cinq clés se terminant par Count. Pas de sixième.

Existe-t-il un namespace de statistiques sous app.bsky ?

Non. Treize namespaces se trouvent sous app.bsky, et chacun d'eux a une fonction qui n'est pas la mesure.

Élargissez la recherche au-delà de app.bsky et le tableau tient. Les autres racines du dépôt sont com.atproto pour la plomberie du protocole, chat.bsky pour les messages privés, tools.ozone pour la modération, plus internal.bsky, site.standard et com.germnetwork. Les seuls endpoints de tout l'ensemble à saveur statistique sont tools.ozone.report.getLiveStats, tools.ozone.report.getHistoricalStats, tools.ozone.report.refreshStats et tools.ozone.moderation.getReporterStats. Ceux-là rendent compte des files de modération, pour les modérateurs. getLiveStats est documenté comme « Get live report statistics from the past 24 hours. Filter by queue, moderator, or report type. » Rien de tout cela ne touche à la performance d'une publication.

Pourquoi le protocole définit-il un événement de vue sans jamais le restituer ?

Parce que l'événement de vue circule vers les générateurs de flux, pas vers les auteurs. C'est la partie à citer quand quelqu'un insiste sur le fait que la donnée doit bien se trouver quelque part.

app.bsky.feed.sendInteractions est une procédure dont l'entrée est un tableau d'objets app.bsky.feed.defs#interaction. Chaque interaction nomme un élément par une AT URI et un token d'événement. Les valeurs connues comprennent :

Le vocabulaire d'une impression existe donc. interactionSeen est, en clair, un événement de vue. Ce qui manque, c'est un chemin de lecture. La description de la procédure indique qu'elle renvoie l'information « back to the feed generator that served them », et son schéma de sortie est un objet vide, {"type": "object", "properties": {}}. Un opérateur qui fait tourner un flux personnalisé peut compter les événements de vue des éléments que son flux a servis. Vous, en tant qu'auteur d'une publication, n'avez aucun endpoint qui renvoie le nombre de fois où votre publication a été vue, dans ce flux ou dans un autre.

Cette asymétrie est la réponse honnête à la raison pour laquelle Bluesky donne l'impression de devoir afficher des compteurs de vues. Le signal est défini, collecté par les clients et livré aux générateurs de flux. Il s'arrête là.

Que pouvez-vous mesurer sur Bluesky aujourd'hui ?

Beaucoup de choses, tant que vous cessez de chercher la portée.

Les listes de comptes nommés méritent plus d'attention qu'elles n'en reçoivent. Sur la plupart des réseaux, vous recevez un total de J'aime et rien d'autre. Bluesky vous remet les comptes, ce qui veut dire que vous pouvez demander d'où viennent vos republications, si les mêmes vingt identifiants portent chaque lancement, et quels abonnés n'ont jamais réagi une seule fois. C'est un autre type d'analyse que les impressions, et sur certaines questions c'est le meilleur.

app.bsky.feed.getPosts accepte un tableau uris avec un maxLength de 25, un traitement par lots qui vérifie un mois de publications avance donc par blocs de 25. app.bsky.feed.getAuthorFeed accepte limit avec un maximum de 100 et une valeur par défaut de 50, plus un cursor, et il est documenté comme « Does not require auth », d'où l'exemple ci-dessus qui tourne sur public.api.bsky.app sans token.

Que peut honnêtement vous donner un outil de statistiques Bluesky ?

Deux choses, et il devrait dire clairement laquelle est laquelle.

La première est son propre journal de publication. Un planificateur sait ce qu'il a envoyé, depuis quel compte, à quelle minute, avec quel texte, quels hashtags et quels médias, parce que c'est lui qui a fait l'envoi. Aucune API n'accorde cela ; ce sont des données de première partie que l'outil détient déjà. C'est aussi la moitié qui manque à la plupart des gens, parce qu'un tableau des heures d'envoi est ce qui transforme un tas de compteurs en comparaison.

La seconde, ce sont les compteurs publics, échantillonnés dans le temps. Appeler getAuthorFeed ou getPosts selon un calendrier et stocker likeCount, repostCount, replyCount, quoteCount et bookmarkCount à chaque passage transforme un nombre en courbe, qui montre combien de temps une publication a continué à récolter de l'engagement après sa sortie.

Joignez les deux et vous répondez à de vraies questions : lesquelles de vos publications Bluesky ont gagné de l'engagement, publiées à quelle heure, dans quel format, à côté des mêmes publications sur les autres réseaux de votre calendrier. C'est cette jonction que restituent les statistiques Bluesky d'AdaptlyPost, et la même forme de rapport couvre les autres réseaux via les statistiques de réseaux sociaux.

Ce qu'aucun outil ne peut vous donner, celui-ci compris, ce sont les impressions, la portée, les vues de vidéo ou les visites de profil d'une publication Bluesky. Ces nombres ne sont pas dans l'API, donc un tableau de bord qui les affiche les modélise ou réétiquette autre chose. La question utile à poser à n'importe quel fournisseur est de savoir de quel champ vient le nombre. Si la réponse n'est pas l'un des cinq compteurs ou un total d'abonnés, le nombre est une estimation.

La planification n'y change rien non plus. Publier via un planificateur de publications Bluesky vous donne un journal d'envoi propre à mesurer ; cela ne donne pas à Bluesky un compteur de vues qu'il n'a pas.

Ce que cette page n'affirme pas

Elle n'affirme pas que Bluesky ne livrera jamais de compteurs de vues. La liste des champs s'allonge : bookmarkCount s'est ajouté aux quatre compteurs plus anciens, et app.bsky.bookmark est un namespace complet avec ses propres endpoints de création, de suppression et de listage. Si un viewCount arrive un jour, il apparaîtra dans lexicons/app/bsky/feed/defs.json avant d'apparaître dans le moindre client, et ce fichier est public. Vérifiez-le là plutôt que de vous fier à une capture d'écran.

Questions fréquentes

L'application Bluesky affiche-t-elle un compteur de vues quelque part ?

Non. Le client officiel affiche les mêmes compteurs que ceux renvoyés par l'API, à savoir J'aime, republications, réponses, citations et signets. Il n'y a aucun chiffre de vues ou d'impressions sur une publication, sur un profil ou dans le moindre écran de réglages, parce qu'aucun endpoint n'en fournit.

Existe-t-il un endpoint de statistiques quelque part dans les lexicons de l'AT Protocol ?

Non. Une recherche sur les 404 fichiers de lexicon de bluesky-social/atproto ne renvoie aucun fichier ni champ nommé d'après les statistiques, les insights ou les impressions. Les quatre endpoints contenant « Stats » vivent tous sous tools.ozone, le namespace de l'outillage de modération, et ils rendent compte des signalements de modération plutôt que des publications.

Un outil peut-il estimer les impressions Bluesky à partir du firehose ?

Pas les mesurer, seulement les modéliser. Le firehose com.atproto.sync diffuse les commits de dépôt, un consommateur voit donc la création des enregistrements app.bsky.feed.like et app.bsky.feed.repost au fil de l'eau. Regarder une publication ne crée aucun enregistrement, ce qui veut dire que rien ne traverse le firehose quand quelqu'un lit puis passe son chemin. Tout chiffre d'impressions qui en découle est une sortie de modèle.

app.bsky.feed.sendInteractions me permet-il de voir qui a vu ma publication ?

Non. C'est une procédure, pas une requête. Les clients y poussent des événements d'interaction, dont interactionSeen, et son schéma de sortie est un objet vide. Les événements sont livrés au générateur de flux qui a servi l'élément, il n'y a donc aucune route de retour vers l'auteur de la publication.

Les compteurs d'engagement sont-ils toujours présents dans une réponse de l'API ?

Non. La liste required de app.bsky.feed.defs#postView est ["uri", "cid", "author", "record", "indexedAt"], ce qui laisse chaque compteur facultatif. Traitez un likeCount absent comme une valeur inconnue plutôt que de le ramener à zéro, sinon une panne de service ressemblera à une publication que personne n'a aimée.

Combien de publications puis-je vérifier en un seul appel ?

Vingt-cinq avec app.bsky.feed.getPosts, qui plafonne son tableau uris à maxLength: 25. app.bsky.feed.getAuthorFeed renvoie jusqu'à 100 publications par page avec un cursor pour la suivante, et il ne demande aucune authentification, c'est donc la voie la moins coûteuse quand vous voulez tout l'historique récent d'un compte.

Le bookmarkCount de Bluesky annonce-t-il l'arrivée d'autres métriques ?

bookmarkCount est le plus récent des cinq compteurs, ajouté à côté de likeCount, repostCount, replyCount et quoteCount, et app.bsky.bookmark dispose déjà de son propre namespace complet avec des endpoints pour créer, supprimer et lister. Un viewCount pourrait suivre le même chemin. S'il arrive, il apparaîtra d'abord dans lexicons/app/bsky/feed/defs.json avant tout client, donc c'est ce fichier qu'il faut vérifier, pas une capture d'écran.

Les endpoints de statistiques de tools.ozone comptent-ils comme des statistiques de publication Bluesky ?

Pas pour les publications. Les quatre endpoints statistiques du dépôt, getLiveStats, getHistoricalStats, refreshStats et getReporterStats, se trouvent tous sous tools.ozone, le namespace de modération, et rendent compte des files de modération et des rapporteurs pour les modérateurs. Aucun ne touche aux réponses, aux likes ou à la portée d'une publication.

Dois-je me connecter pour consulter les chiffres d'engagement d'une publication Bluesky ?

Les compteurs publics ne demandent aucune connexion. app.bsky.feed.getAuthorFeed est documenté comme ne nécessitant pas d'authentification, ce qui explique qu'un appel à public.api.bsky.app sans jeton renvoie les mêmes champs likeCount, repostCount, replyCount, quoteCount et bookmarkCount montrés dans cet article. Ce qui se trouve derrière votre propre compte, comme les réglages de notifications, relève d'un autre sujet, mais lire les compteurs publics d'un autre compte ne demande que l'URL.

Faut-il faire confiance à un tableau de bord Bluesky qui affiche des impressions ou une portée ?

Méfiez-vous si le fournisseur ne peut pas nommer le champ. Les impressions, la portée, les vues vidéo et les visites de profil n'existent nulle part dans les lexicons de l'AT Protocol, donc un tableau de bord qui les affiche modélise le chiffre à partir d'autres signaux ou renomme l'un des cinq compteurs réels. Demandez de quel champ provient le nombre ; si la réponse n'est ni likeCount, ni repostCount, ni replyCount, ni quoteCount, ni bookmarkCount, ni un total d'abonnés, c'est une estimation.