Kaputte Sessions triagieren mit einem Meta-Muse-Connector für Session-Analyse

Ein Agent, der Traffic-Zahlen abruft, und ein Agent, der kaputte Sessions triagiert, machen unterschiedliche Arbeit, und ein Meta-Muse-Connector für Session-Analyse ist die zweite Sorte. Das Ergebnis ist kein Diagramm, sondern eine sortierte Kurzliste dessen, was auf deiner Site schiefgegangen ist, mit angehängten Aufzeichnungen, sodass der Agent entscheidet, was ein Mensch als Nächstes öffnet.

Kurzfassung: Drei der vier Session-Endpunkte lesen nur. Bau den Connector, füge ein flow_ws_-Workspace-Token in Muses sichere Anmeldedaten-Abfrage ein und sag ihm in derselben Nachricht, dass PATCH /issues/{issueId} tabu ist.

Muse schreibt den Connector selbst aus einer öffentlichen API-Spezifikation, und Parallel berichtete am 14. September 2026, dass der Code, den es schreibt, in der eigenen Cloud-Runtime-Zelle des Agenten läuft. Der Leitfaden Meta-Muse-Connector für Webanalyse behandelt diesen Mechanismus und den Anmeldedaten-Ablauf. In diesem Beitrag geht es darum, ihn auf Issues zu richten.

Was sieht der Connector, wenn Muse ein Issue öffnet?

Muse sieht den Issue-Datensatz, den Flowsery erzeugt hat, nicht die Aufzeichnung dahinter. Flowserys Erkennung erfasst Rage Clicks, JavaScript-Fehler, Dead Clicks und Abbrüche, und jeder Datensatz trägt einen Titel, eine Beschreibung, einen Schweregrad, einen Status, sessionsCount, firstSeenAt, lastSeenAt, geordnete stepsToReplicate und eine sampleRecordingId.

Severity nimmt low, medium, high und critical. Ein Workspace-Token deckt jede Website im Workspace ab, daher braucht jeder Aufruf websiteId oder domain, um eine davon zu benennen.

GET /issues/{issueId} ist der Aufruf, den es sich lohnt, Muse früh beizubringen, denn er liefert neben den Sessions auch die Kommentare zurück, die dein Team an einem Issue hinterlassen hat. Das trennt einen Abbruch, den noch niemand gesehen hat, von einem, den letzten Donnerstag schon jemand angeschaut hat.

Kann Muse ein Session-Replay anschauen?

Nein. Ein Replay ist videoförmig und die API gibt JSON zurück, deshalb liest Muse eine strukturierte Zusammenfassung einer Aufzeichnung statt der Aufzeichnung selbst. Am nächsten kommt die API mit dem occurrences-Array: jeder markierte Moment trägt eine Beschreibung, einen Schweregrad und einen atSeconds-Versatz in die Aufzeichnung.

Praktisch heißt das: Muse kann dir sagen, dass ein Rage-Click-Cluster 41 Sessions getroffen hat, dir die Schritte zur Reproduktion vorlesen und die Aufzeichnung nennen, die es am besten zeigt. Es kann dir nicht sagen, dass der Absenden-Button ausgegraut aussah. Der Browser-Weg rettet das nicht: Meta sagt, der Browser-Sub-Agent liest einen Snapshot des Accessibility-Baums, nicht das rohe DOM.

Was fügst du in Muse ein, um den Connector zu bauen?

Eine Nachricht, die die Spec-URL, die Auth-Art und das Schreibverbot trägt. Das Verbot gehört in die erste Nachricht statt in eine spätere Korrektur, denn der Connector, den Muse speichert, wird aus dem gebaut, was es beim Einrichten gelesen hat.

Build a custom connector for Flowsery from the API reference at
https://flowsery.com/docs/api-introduction.md. It is public, so read it
without logging in. Full spec: https://flowsery.com/openapi.json.
 
Base URL: https://analytics.flowsery.com/analytics/api/v1
Auth: an "Authorization: Bearer <token>" header. I will paste the token into
the secure credential prompt, not into this chat. It starts with flow_ws_.
 
Use GET /issues, GET /issues/{issueId} and GET /visitors/{visitorId} only.
Do not call PATCH /issues/{issueId}. Start with GET /websites and list the
website IDs you can see.

Der Leitfaden zur Webanalyse geht die Anmeldedaten-Abfrage Schritt für Schritt durch. Was sich bei Issues ändert, ist der letzte Absatz: die drei Lesevorgänge benennen, den einen Schreibvorgang benennen, ihn verbieten. Dann nach offenen kritischen Issues auf einer Website fragen, was den Lesepfad durchspielt und nichts schreibt.

Welche Session-Aufrufe lesen, und welcher schreibt?

Vier Endpunkte zählen und genau einer ändert Daten: PATCH /issues/{issueId} aktualisiert den Status eines Issues, und darin steckt das ganze Aufsichtsproblem.

Halte den Connector in der ersten Woche rein lesend. Warum ein Connector, den Muse selbst geschrieben hat, weniger Isolation bekommt als ein eingebauter, und was Metas Freigabe-Voreinstellungen dagegen tun, ist Thema des Leitfadens zur Webanalyse. Bei Issues kostet diese Haltung nichts, denn Triage braucht den Schreibvorgang nie.

Sollte Muse den Status eines Issues ändern dürfen?

Nicht in der ersten Woche, und danach nicht nach Zeitplan. Ein Agent, der PATCH /issues/{issueId} hält, kann etwas auflösen, das sich niemand angeschaut hat, und ein gelöstes Issue verlässt die Liste, die morgens alle öffnen. Suspended ist schlimmer: ein suspendiertes Issue fällt aus der Standardantwort von GET /issues heraus, bis jemand nach status=suspended fragt.

Status-Hygiene ist genau die Fleißarbeit, in der ein Agent gut aussieht, und ein Durchlauf, der zwölf abgestandene Kritische auf resolved setzt, erzeugt eine kürzere Liste mit demselben kaputten Checkout darunter.

Meta sagt, manche Agenten-Aktionen lassen sich nicht rückgängig machen, und überlässt dir das Aufräumen. Mit Stand 20. September 2026 ist deine Spur Muses Aktivitätsprotokoll, eine chronologische Aufzeichnung der ausgeführten Aktionen und der von dir erteilten Berechtigungen, also lies es, bevor du eine Berechtigung erweiterst. Erlaube einen Schreibvorgang einmal, für das Issue vor dir, nachdem du das Replay geöffnet hast.

Was geht speziell bei der Session-Analyse kaputt?

Fünf Dinge gehen hier schief, die bei einem Reporting-Connector nicht schiefgehen.

Eine Regel gilt weiter aus dem Leitfaden zur Webanalyse: die Muse-VM sitzt in Metas Cloud, also ist alles hinter deinem VPN oder auf deinem Laptop außer Reichweite. Für dieselbe Schleife ohne Muse führt die Grok-Bot-Vorlage für Session-Analyse die identische Aufrufkette aus.

Häufig gestellte Fragen

Unterstützt Meta Muse MCP für Session-Analyse?

Parallel fand am 14. September 2026 keine Einstellung "MCP-Server hinzufügen", und der Leitfaden zur Webanalyse hat die vollständige MCP-Antwort. Für die Triage ändert das nichts: die drei Lesevorgänge und der eine Schreibvorgang laufen so oder so über REST, und Flowserys gehosteter MCP-Server bedient stattdessen Claude, Cursor und Codex.

Kann Muse ein Flowsery-Issue eigenständig schließen?

Nur wenn du es lässt. PATCH /issues/{issueId} ist der einzige Aufruf, der ein Issue zwischen open, in_progress, resolved und suspended bewegt, und die Setup-Nachricht oben verbietet ihn rundheraus. Metas Freigabe-Abfragen erscheinen in der Client-Oberfläche statt im Chat, ein unerwarteter Schreibvorgang ist also sichtbar, bevor er passiert.

Was sieht Muse über einen Besucher?

Mehr als eine Zeitleiste. GET /visitors/{visitorId} gibt einen identity-Block mit Land, Region, Stadt, Browser, OS, Gerät und Viewport zurück, dazu activity, revenue und ein profile mit userId, name und email, sobald deine Site identify aufgerufen hat. Die Visitor-ID ist der First-Party-Wert _fs_vid, und Flowsery speichert keine IP-Adressen und setzt keine seitenübergreifenden Identifikatoren. Entscheide, ob Muse das halten soll, bevor du das Token erstellst.

Ersetzt das, das Replay zu öffnen?

Nein. Der Connector sortiert und grenzt ein, und die Aufzeichnung ist der Ort, an dem der Grund steckt. Lass Muse die drei Sessions wählen, die zehn Minuten wert sind, und verbringe dann die zehn Minuten. Aggregierte Fragen gehören auf die Webanalyse-Seite desselben Connectors.

Welchen Flowsery-Tarif brauche ich?

Beide reichen. GET /issues und die KI-Session-Analyse dahinter sitzen sowohl auf Team zu $250 pro Monat als auch auf Pro zu $500 pro Monat, und beide starten mit einer 14-tägigen kostenlosen Testphase ohne Karte. Der Leitfaden zur Webanalyse schlüsselt die Limits für Sitzplätze, Websites und Replay-Aufbewahrung auf, die sie unterscheiden.

Was braucht Muse, um GET /issues mit einem Workspace-Token aufzurufen?

Ein Workspace-Token deckt jede Website im Workspace ab, deshalb braucht jeder Aufruf websiteId oder domain, um eine zu benennen. Ohne das liefert Flowsery 404 Website not found und keinen Auth-Fehler. Sag Muse, es soll zuerst GET /websites aufrufen und die ID durchreichen.

Woher bekommt Muse eine Besucher-ID für GET /visitors/{visitorId}?

Aus GET /realtime/map, dem einzigen Lesezugriff, der visitorId zurückgibt. Der Endpunkt erwartet einen _fs_vid-Wert, und kein Issue-Payload enthält einen. Eine geratene ID liefert 404, also sag Muse, dass es keine erfinden soll.

Was passiert, wenn Muse ein Flowsery-Ratelimit erreicht?

Flowsery antwortet mit 429 und ergänzt Retry-After in Sekunden. Jede Antwort enthält außerdem RateLimit-Remaining und RateLimit-Reset. Sag Muse, es soll diese Header lesen und den Durchlauf drosseln, statt blind zu wiederholen.

Warum fehlt ein ausgesetztes Issue in den Muse-Ergebnissen?

GET /issues lässt ausgesetzte Issues in der Standardantwort weg, bis du status=suspended anfragst. Die vier Status sind open, in_progress, resolved und suspended. Wenn ein Issue unerwartet verschwunden ist, prüfe das Activity log von Muse.

Was soll Muse tun, wenn ein Issue keine Beispielaufzeichnung hat?

sampleRecordingId kann null sein, daher kommen manche Issues ohne etwas zum Öffnen an. Muse soll das Issue ohne Aufzeichnung melden, statt eine ähnliche unterzuschieben. Schweregrad und sessionsCount bekommst du trotzdem.

Ein Workspace-Token erstellen und einen rein lesenden Issue-Durchlauf starten, oder zuerst die API-Referenz lesen.

Quellen: Metas Hilfeartikel zu Muse-Connectors, Wie wir Sicherheit in Muse eingebaut haben, Parallels Beitrag zu Muse Custom Integrations (14. September 2026) und die Flowsery-API-Referenz. Geprüft am 20. September 2026.