Fünf Engagement-Zähler: Hat Bluesky Analytics?

Hat Bluesky Analytics?

Stellen Sie die Frage, hat Bluesky Analytics, und die Antwort lautet nein: die AT-Protocol-Lexicons, die jede Bluesky-API-Antwort definieren, enthalten keinen View-Count, keinen Impression-Count und keinen Analytics-Endpoint. Ein Post kommt mit fünf Engagement-Zählern zurück. Ein Profil kommt mit Follower-, Following- und Post-Summen zurück. Nirgendwo steht, wie viele Menschen das gesehen haben, was Sie veröffentlicht haben.

Das ist eine Behauptung über eine Abwesenheit, deshalb hier genau das, was am 10. September 2026 geprüft wurde:

• Jede Lexicon-Datei in bluesky-social/atproto im main-Branch, insgesamt 404 JSON-Dateien. Eine Suche ohne Beachtung der Groß- und Kleinschreibung über alle Dateien liefert null Treffer für impression, viewCount, analytic und insight.
• Die postView-Definition in lexicons/app/bsky/feed/defs.json, Feld für Feld.
• Das Verzeichnislisting von lexicons/app/bsky, um jeden existierenden Namespace zu benennen.
• Ein unauthentifizierter Live-Aufruf der öffentlichen AppView, um zu bestätigen, dass der laufende Dienst zurückgibt, was das Schema verspricht.

Die Aussage deckt die First-Party-Lexicons und die öffentliche AppView ab. Sie sagt nichts über interne Dashboards, die Bluesky PBC für sich selbst betreibt, und nichts über Drittanbieter, die Reichweite aus anderen Signalen modellieren.

Welche Felder trägt app.bsky.feed.defs#postView tatsächlich?

Fünfzehn, und fünf davon sind Zähler.

Zwei Details in dieser Tabelle übersieht man leicht. indexedAt ist ein Indexierungs-Zeitstempel und damit das falsche Feld für eine Veröffentlichungszeit; der Wert createdAt innerhalb von record ist der richtige. Und die Zähler stehen nicht in der required-Liste der Definition, die ["uri", "cid", "author", "record", "indexedAt"] lautet. Eine konforme Antwort darf likeCount komplett weglassen, also sollte Code, der das Feld liest, einen fehlenden Wert als unbekannt behandeln und nicht als null.

Hier sagt der laufende Dienst dasselbe:

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

Fünf Keys, die auf Count enden. Kein sechster.

Gibt es unter app.bsky einen Analytics-Namespace?

Nein. Dreizehn Namespaces liegen unter app.bsky, und jeder einzelne hat eine Aufgabe, die nichts mit Messung zu tun hat.

Weiten Sie die Suche über app.bsky hinaus aus, und das Bild bleibt gleich. Die anderen Wurzeln des Repositorys sind com.atproto für die Protokoll-Infrastruktur, chat.bsky für Direktnachrichten, tools.ozone für Moderation, dazu internal.bsky, site.standard und com.germnetwork. Die einzigen Endpoints im gesamten Set mit statistischem Einschlag sind tools.ozone.report.getLiveStats, tools.ozone.report.getHistoricalStats, tools.ozone.report.refreshStats und tools.ozone.moderation.getReporterStats. Sie berichten über Moderations-Queues für Moderatoren. getLiveStats ist dokumentiert als „Get live report statistics from the past 24 hours. Filter by queue, moderator, or report type." Nichts davon berührt die Performance von Posts.

Warum definiert das Protokoll ein Seen-Event, meldet es aber nie zurück?

Weil das Seen-Event zu Feed-Generatoren fließt, nicht zu Autoren. Das ist der Teil, den man zitieren sollte, wenn jemand darauf beharrt, die Daten müssten doch irgendwo drin stecken.

app.bsky.feed.sendInteractions ist eine Procedure, deren Input ein Array von app.bsky.feed.defs#interaction-Objekten ist. Jede Interaktion benennt ein Item über eine AT-URI und ein Event-Token. Zu den bekannten Werten gehören:

Das Vokabular für eine Impression existiert also. interactionSeen ist, schlicht gesagt, ein View-Event. Was fehlt, ist ein Lesepfad. Die Beschreibung der Procedure sagt, sie sende Informationen „back to the feed generator that served them", und ihr Output-Schema ist ein leeres Objekt, {"type": "object", "properties": {}}. Wer einen Custom Feed betreibt, kann Seen-Events für die Items zählen, die sein Feed ausgeliefert hat. Sie als Autor eines Posts haben keinen Endpoint, der zurückgibt, wie oft Ihr Post gesehen wurde, in diesem Feed oder in irgendeinem anderen.

Diese Asymmetrie ist die ehrliche Antwort darauf, warum sich Bluesky anfühlt, als müsste es View-Counts haben. Das Signal ist definiert, wird von Clients gesammelt und an Feed-Generatoren geliefert. Dort endet es.

Was können Sie auf Bluesky heute messen?

Eine Menge, solange Sie aufhören, nach Reichweite zu suchen.

Die namentlichen Account-Listen verdienen mehr Aufmerksamkeit, als sie bekommen. In den meisten Netzwerken bekommen Sie eine Like-Summe und sonst nichts. Bluesky gibt Ihnen die Accounts, und damit können Sie fragen, von wem Ihre Reposts kommen, ob dieselben zwanzig Handles jeden Launch tragen und welche Follower noch nie reagiert haben. Das ist eine andere Art von Analyse als Impressionen, und bei manchen Fragen die bessere.

app.bsky.feed.getPosts nimmt ein uris-Array mit einer maxLength von 25, ein Batch-Job über einen Monat Posts arbeitet sich also in Blöcken von 25 durch. app.bsky.feed.getAuthorFeed nimmt limit mit einem Maximum von 100 und einem Default von 50, dazu einen cursor, und ist dokumentiert als „Does not require auth", weshalb das Beispiel oben ohne Token gegen public.api.bsky.app läuft.

Was kann Ihnen ein Bluesky-Analytics-Tool ehrlicherweise liefern?

Zwei Dinge, und es sollte klar sagen, welches welches ist.

Das erste ist das eigene Publishing-Protokoll. Ein Scheduler weiß, was er gesendet hat, von welchem Account, zu welcher Minute, mit welchem Text, welchen Hashtags und welchen Medien, weil er das Senden übernommen hat. Keine API gibt das her; es sind First-Party-Daten, die das Tool ohnehin besitzt. Es ist auch die Hälfte, die den meisten fehlt, denn eine Tabelle mit Sendezeiten ist das, was aus einem Haufen Zähler einen Vergleich macht.

Das zweite sind die öffentlichen Zähler, über die Zeit abgetastet. Wer getAuthorFeed oder getPosts nach Zeitplan aufruft und bei jedem Durchlauf likeCount, repostCount, replyCount, quoteCount und bookmarkCount speichert, verwandelt eine Zahl in eine Kurve, die zeigt, wie lange ein Post nach dem Absenden weiter Engagement gesammelt hat.

Verbinden Sie diese beiden, und Sie können echte Fragen beantworten: welche Ihrer Bluesky-Posts Engagement verdient haben, zu welcher Stunde veröffentlicht, in welchem Format, neben denselben Posts in den anderen Netzwerken Ihres Kalenders. Genau diese Verbindung liefert Bluesky-Analytics von AdaptlyPost, und dieselbe Report-Form deckt über Social-Media-Analytics auch die anderen Netzwerke ab.

Was Ihnen kein Tool geben kann, dieses eingeschlossen, sind Impressionen, Reichweite, Videoaufrufe oder Profilbesuche für einen Bluesky-Post. Diese Zahlen stehen nicht in der API, ein Dashboard, das sie anzeigt, modelliert sie also oder etikettiert etwas anderes um. Die nützliche Frage an jeden Anbieter lautet, aus welchem Feld die Zahl stammt. Wenn die Antwort nicht einer der fünf Zähler oder eine Follower-Summe ist, ist die Zahl eine Schätzung.

Am Scheduling ändert das ebenfalls nichts. Wer über einen Bluesky-Post-Scheduler veröffentlicht, bekommt ein sauberes Sendeprotokoll, gegen das er messen kann; einen View-Zähler, den Bluesky nicht hat, bekommt er dadurch nicht.

Was diese Seite nicht behauptet

Sie behauptet nicht, Bluesky werde nie View-Counts ausliefern. Die Feldliste wächst: bookmarkCount steht neben den vier älteren Zählern, und app.bsky.bookmark ist ein vollwertiger Namespace mit eigenen Create-, Delete- und List-Endpoints. Falls jemals ein viewCount landet, erscheint es in lexicons/app/bsky/feed/defs.json, bevor es in irgendeinem Client auftaucht, und diese Datei ist öffentlich. Prüfen Sie es dort, statt einem Screenshot zu vertrauen.

Häufig gestellte Fragen

Zeigt die Bluesky-App irgendwo einen View-Count?

Nein. Der offizielle Client rendert dieselben Zähler, die die API zurückgibt, also Likes, Reposts, Antworten, Zitate und Lesezeichen. Es gibt keine View- oder Impression-Zahl an einem Post, an einem Profil oder in irgendeinem Einstellungsbildschirm, weil kein Endpoint eine liefert.

Gibt es irgendwo in den AT-Protocol-Lexicons einen Analytics-Endpoint?

Nein. Eine Suche über alle 404 Lexicon-Dateien in bluesky-social/atproto liefert keine Datei und kein Feld, das nach Analytics, Insights oder Impressionen benannt ist. Die vier Endpoints mit „Stats" im Namen liegen alle unter tools.ozone, dem Namespace für Moderations-Tooling, und sie berichten über Moderationsmeldungen statt über Posts.

Kann ein Tool Bluesky-Impressionen aus der Firehose schätzen?

Nicht messen, nur modellieren. Die Firehose com.atproto.sync streamt Repository-Commits, ein Consumer sieht also die Erzeugung von app.bsky.feed.like- und app.bsky.feed.repost-Records, während sie passiert. Das Ansehen eines Posts erzeugt keinen Record, es geht also nichts über die Firehose, wenn jemand liest und weiterscrollt. Jede daraus abgeleitete Impression-Zahl ist ein Modellergebnis.

Kann ich mit app.bsky.feed.sendInteractions sehen, wer meinen Post gesehen hat?

Nein. Es ist eine Procedure, keine Query. Clients schieben Interaktions-Events hinein, darunter interactionSeen, und das Output-Schema ist ein leeres Objekt. Die Events gehen an den Feed-Generator, der das Item ausgeliefert hat, es gibt also keinen Rückweg zum Autor des Posts.

Sind die Engagement-Zähler in einer API-Antwort immer vorhanden?

Nein. Die required-Liste von app.bsky.feed.defs#postView lautet ["uri", "cid", "author", "record", "indexedAt"], damit ist jeder Zähler optional. Behandeln Sie ein fehlendes likeCount als unbekannten Wert statt es auf null zu setzen, sonst sieht eine Störung des Dienstes aus wie ein Post, den niemand geliket hat.

Wie viele Posts kann ich in einem Aufruf auf Zähler prüfen?

Fünfundzwanzig mit app.bsky.feed.getPosts, das sein uris-Array bei maxLength: 25 deckelt. app.bsky.feed.getAuthorFeed gibt bis zu 100 Posts pro Seite zurück, mit einem cursor für die nächste Seite, und braucht keine Authentifizierung, es ist also der günstigere Weg, wenn Sie die gesamte jüngere Historie eines Accounts wollen.

Bedeutet der bookmarkCount, dass Bluesky bald mehr Metriken bringt?

bookmarkCount ist der neueste der fünf Zähler, hinzugekommen neben likeCount, repostCount, replyCount und quoteCount, und app.bsky.bookmark hat bereits einen eigenen vollständigen Namespace mit Endpoints zum Erstellen, Löschen und Auflisten. Ein viewCount könnte denselben Weg nehmen. Falls er kommt, taucht er zuerst in lexicons/app/bsky/feed/defs.json auf, bevor er in irgendeinem Client erscheint, also ist diese Datei die richtige Stelle zum Nachsehen, nicht ein Screenshot.

Zählen die tools.ozone-Stats-Endpoints als Post-Analytics für Bluesky?

Nicht für Posts. Die vier Stats-Endpoints im Repository, getLiveStats, getHistoricalStats, refreshStats und getReporterStats, liegen alle unter tools.ozone, dem Moderations-Namespace, und sie berichten über Moderationswarteschlangen und Melder für Moderatoren. Keiner davon berührt Antworten, Likes oder Reichweite eines Posts.

Muss ich mich einloggen, um die Engagement-Zahlen eines Bluesky-Posts zu prüfen?

Öffentliche Zähler brauchen keinen Login. app.bsky.feed.getAuthorFeed ist als ohne Auth dokumentiert, weshalb ein Aufruf gegen public.api.bsky.app ohne Token dieselben Felder likeCount, repostCount, replyCount, quoteCount und bookmarkCount liefert, die in diesem Beitrag gezeigt werden. Alles, was hinter Ihrem eigenen Konto liegt, etwa Benachrichtigungseinstellungen, ist eine andere Sache, aber die öffentlichen Zähler eines fremden Kontos zu lesen braucht nur die URL.

Sollte ich einem Bluesky-Dashboard vertrauen, das Impressionen oder Reichweite zeigt?

Seien Sie misstrauisch, wenn der Anbieter das Feld nicht benennen kann. Impressionen, Reichweite, Video-Views und Profilbesuche kommen in den AT-Protocol-Lexicons überhaupt nicht vor, also modelliert ein Dashboard, das sie zeigt, die Zahl aus anderen Signalen oder benennt einen der fünf echten Zähler um. Fragen Sie nach, aus welchem Feld die Zahl stammt; wenn die Antwort nicht likeCount, repostCount, replyCount, quoteCount, bookmarkCount oder eine Follower-Zahl ist, ist es eine Schätzung.