Den Montagsreport erstellen mit einem Meta-Muse-Connector für Analytics-Reporting

Ein Wochenreport ist die eine Aufgabe, die ein Meta-Muse-Connector für Analytics-Reporting erledigen kann, ohne je eine Zahl zu ändern, weil jeder Endpunkt, den er dafür braucht, ein GET ist. Muse schreibt diesen Connector selbst aus Flowserys öffentlicher API-Spezifikation. Parallel berichtete am 14. September 2026, dass die Arbeit auf der Cloud-VM läuft, die Meta jedem Muse-Konto pro Nutzer bereitstellt; Metas eigene Formulierung geht nicht weiter als die Aussage, diese VM habe genug Rechenleistung für echte Arbeit. Einrichtung und Zugangsdaten stehen im Leitfaden zum Meta-Muse-Connector für Web-Analytics; dieser Beitrag beginnt bei dem Report, der jeden Montag läuft.

Kurzversion: Ein Wochenreport ist einmal GET /websites, zweimal GET /overview, GET /timeseries für den Verlauf, dann GET /channels und GET /breakdown, um die Ursache zu benennen. Sechs Lesezugriffe, null Schreibzugriffe und eine websiteId bei jedem einzelnen.

Welche Aufrufe braucht ein Wochenreport tatsächlich?

Ein Flowsery-Wochenreport besteht aus sechs Aufrufen, und die Reihenfolge zählt mehr als die Anzahl. GET /websites liefert die IDs, die jeder spätere Aufruf mitführt. GET /overview läuft zweimal, einmal pro Zeitraum. GET /timeseries macht aus der Differenz einen Verlauf, sodass ein einzelner schwacher Dienstag nicht mehr wie ein Trend aussieht. Dann benennen GET /channels und GET /breakdown, was sich bewegt hat.

GET /countries, /devices, /browsers und /realtime gehören zur Anschlussfrage, nicht zum geplanten Report. Dem Connector trotzdem die ganze Liste geben: ein Endpunkt, den er nie aufruft, kostet nichts, und einer, den er an einem Dienstag braucht und nicht hat, kostet einen neu gebauten Connector.

Wie fragt man einen Zeitraumvergleich ab?

Beide Datumsbereiche explizit benennen und die Zeitzone benennen. Muse löst "letzte Woche" selbst auf, bevor der Aufruf rausgeht, und Meta veröffentlicht nichts darüber, welche Uhr dabei gilt. Flowsery ordnet startAt und endAt dann der Zeitzone der Website zu, sofern der Aufruf keine nennt. Zwei getrennte Auflösungen, beide still, beide in der Lage, einen Report um einen Tag zu verschieben.

Report on flowsery.com for the week of 8 to 14 September and the week of
1 to 7 September, timezone Europe/Berlin.
 
Call GET /websites on the first run only, then carry the saved websiteId
through every call.
Then GET /overview once per period.
If sessions or conversions moved more than 10%, call
GET /breakdown?dimension=channel for both periods and name the channel.
Numbers first. No recommendations. If nothing moved, say so and stop.

"Zahlen zuerst, keine Empfehlungen" steht dort zu Recht. Ein Agent, den man um Analyse bittet, liefert Analyse, und einer mit zweiundzwanzig Lese-Endpunkten und ohne Zugriff auf die eigene Roadmap baut sie allein auf Traffic auf. Die Grok-Bot-Vorlage für Analytics-Reporting liefert dieselbe Anweisung aus demselben Grund.

Warum braucht jeder Aufruf einen Website-Selektor?

Ein Flowsery-Workspace-Token deckt jede Website im Workspace ab, die API kann also nicht erraten, welche gemeint ist. Jeder Aufruf braucht websiteId oder domain. Fehlt der Selektor, hat das Workspace-Token keine Website zum Auflösen, der Aufruf schlägt also fehl, statt stillschweigend die Zahlen einer beliebigen Website zurückzugeben.

Wo das flow_ws_-Token hingehört und warum es nie in den Chat gehört, steht im Pillar-Beitrag. Was der Report abfangen muss, ist dessen Reichweite: ein Token erreicht jede Website.

Dem Connector sagen, dass er die Website-IDs nach dem ersten Lauf speichern und wiederverwenden soll. Ab Woche zwei besteht der Report aus fünf Aufrufen, und ein erneutes GET /websites lohnt sich nur, wenn eine Site dazukommt.

Was kann ein Reporting-Connector ändern?

Nichts. Jeder Endpunkt in diesem Beitrag ist ein GET, und das macht einen Reporting-Connector zum Sichersten, was man einem Agenten geben kann: keine Freigabe einzurichten, kein Schreibzugriff zu beaufsichtigen, kein Rückgängigmachen zu planen.

Meta sagt klar, dass es weder eigene Connectoren prüft noch deren Umgang mit den eigenen Informationen, und diese fehlende Prüfung wiegt weniger, wenn der gesamte Wortschatz des Connectors lesend ist.

Was macht ein zusammengesetzter Report falsch, was ein Dashboard nicht falsch macht?

Ein Agent, der einen Report zusammensetzt, macht drei Fehler, die ein Dashboard nicht machen kann: Er schreibt Prosa über Zahlen, statt sie zu zeichnen.

Er rundet und argumentiert dann über die gerundete Zahl. "Unverändert gegenüber der Vorwoche" schluckt einen Rückgang von 9 %. Die Rohwerte neben dem Satz mit abfragen.

Er schreibt Ursachen zu, die er nie abgefragt hat. GET /breakdown?dimension=channel benennt den Kanal, der sich bewegt hat. Kein Flowsery-Endpunkt liefert einen Grund, und der Connector hat weder ein Release-Log noch eine Ticket-Queue, aus der er einen lesen könnte. Der Agent liefert trotzdem einen Grund, solange man es ihm nicht verbietet.

Er vergleicht ungleiche Zeitfenster. Ein Feiertag, ein Sieben-Tage-Fenster gegen ein Sechs-Tage-Fenster, eine Zeitzonenverschiebung. Ein Dashboard liegt auf sichtbare Weise falsch; ein Absatz nicht.

Die Lösung für alle drei ist GET /timeseries mit interval=day. Tageswerte unter der Wochensumme lassen einen Leser den Satz des Agenten gegen den Verlauf prüfen, und genau deshalb bleibt das Dashboard daneben offen.

Was kostet ein Wochenreport, wenn er jede Woche läuft?

Muse rechnet alles gegen ein einziges wöchentliches Token-Kontingent ab, und die Zahlen zu den Tarifen stehen im Pillar-Beitrag. Was ein geplanter Job ändert, ist die Form der Ausgaben, nicht die Preisliste: dieselben Lesezugriffe laufen 52-mal im Jahr, ob jemand das Ergebnis liest oder nicht.

Sechs Lesezugriffe und ein Absatz Prosa sind eine kleine Wochenausgabe. Die Variante, die schiefgeht, ist es nicht: ein Agent, der einen fehlschlagenden Aufruf zwanzigmal wiederholt, jeden Montag, für immer, weil ihm niemand gesagt hat, dass der Selektor Pflicht ist.

Die API ist in beiden Flowsery-Tarifen enthalten, der wöchentliche Lauf hängt also nicht davon ab, in welchem man ist.

Was geht speziell beim Reporting kaputt?

Vier Dinge, und keines davon ist die Authentifizierung, die beim ersten Aufruf funktioniert oder eben nicht.

Das erste ist die Zeitzone, der Fehler mit der längsten Lebensdauer, weil der Report trotzdem ankommt und trotzdem korrekt aussieht. startAt und endAt ohne timezone werden gegen die Zeitzone der Website selbst einsortiert, also die in Flowsery eingestellte und nicht die, in der die Person lebt, die den Report angefordert hat, sodass "letzte Woche" still und leise sieben andere Tage abdeckt als die im eigenen Kalender.

Das zweite ist die fehlende websiteId, die der Agent zu lösen versucht, indem er die Abfrage umschreibt, statt den Parameter zu ergänzen.

Das dritte ist die Drift im gespeicherten Skill. Parallel berichtete am 14. September 2026, dass Muse eine eigene Integration als wiederverwendbaren Skill speichert, der über Konversationen hinweg bestehen bleibt, womit die Aufrufliste auf dem Stand des Bauzeitpunkts einfriert. Meta dokumentiert das nicht, also gilt das Einfrieren als beobachtetes Verhalten und nicht als Zusicherung. Wenn sich die API ändert, gilt die Ein-Nachricht-Reparatur aus dem Pillar-Beitrag unverändert. Niemand schaut zu, wenn ein geplanter Report kaputtgeht, also die Referenz per Kalendererinnerung neu lesen statt erst nach einem Fehlschlag.

Das vierte ist der Report, den niemand liest. Einer, der die Abweichung nennt, den Kanal benennt und aufhört, wird jahrelang gelesen; einer, der eigene Einschätzungen abgibt, wird ab dem dritten Monat ignoriert.

Häufig gestellte Fragen

Kann ein Muse-Reporting-Connector meine Flowsery-Daten ändern?

Nicht, wenn er allein aus den Reporting-Endpunkten gebaut wird. Die dreizehn, die ein Reporting-Connector tatsächlich braucht, lesen alle: GET /overview, /timeseries, /pages, /referrers, /channels, /campaigns, /countries, /devices, /browsers, /breakdown, /goals, /realtime und /websites. Flowserys Schreibaufrufe betreffen Ziele, Zahlungen und den Status von Issues; einem Reporting-Connector wird von keinem davon erzählt.

Warum kommt der zweite Zeitraum leer zurück?

Das zweite GET /overview führt ein startAt und endAt mit, die der Connector selbst geschrieben hat, also prüfen, was er tatsächlich gesendet hat: Flowsery setzt startAt standardmäßig auf vor dreißig Tagen und endAt auf jetzt, sobald eines von beiden fehlt, und ein Fenster ohne Traffic kommt als Nullen zurück statt als Fehler. Muse beide Zeiträume als konkrete Daten im Prompt übergeben statt als "die Vorwoche", und prüfen, dass sich die beiden Antworten unterscheiden, bevor man die Differenz liest.

Kann er mehr als zwei Zeiträume vergleichen?

Ja. Jeder Zeitraum ist ein eigener GET /overview- oder GET /timeseries-Aufruf mit eigenem startAt und endAt, vier Quartale kosten also vier Aufrufe. Jedem davon dieselbe Zeitzone geben, sonst umfasst der Vergleich unterschiedliche Tagesgrenzen.

Läuft der Wochenreport auch bei geschlossener App?

Meta sagt, Muse arbeite nach dem Schließen der App weiter und melde sich zurück, wenn sich etwas ändert oder eine Freigabe nötig ist. Das Help Centre dokumentiert Erinnerungen und geplante Aufgaben als Muse-Funktion und sagt nichts darüber, dass ein eigener Connector darin läuft (geprüft am 20. September 2026). Einen unbeaufsichtigten Wochenlauf einen Monat lang prüfen, bevor man sich darauf verlässt.

Muse oder die Grok-Bot-Vorlage dafür nutzen?

Die Wahl hängt davon ab, wo der Report landen muss. Die Grok-Bot-Vorlage für Analytics-Reporting installiert sich aus einem Share-Link mit bereits fertigem Skill-Text und postet in den Chat, den das Team ohnehin liest; Muse schreibt seinen Connector selbst aus der öffentlichen Spezifikation und behält die Ausgabe in der eigenen App. Beide lesen dieselbe Flowsery-API, und jeder Endpunkt, den eines von beiden aufruft, ist ein GET.

Was ruft der Connector als Erstes auf?

Er ruft GET /websites auf, einmal, beim ersten Lauf. Das liefert die Website-IDs, die jeder spätere Aufruf mitführt. Sag dem Connector, dass er sie speichern und wiederverwenden soll, dann besteht der Report ab Woche zwei aus fünf Aufrufen.

Welchen Token nutzt ein Muse-Reporting-Connector?

Einen flow_ws_-Workspace-Token, den du in die sichere Zugangsdaten-Abfrage von Muse einfügst und nie in den Chat. Ein Workspace-Token deckt jede Website im Konto ab, der Connector erreicht also alle. Deshalb nennt jeder Aufruf trotzdem eine websiteId.

Was passiert, wenn ein Aufruf keine websiteId hat?

Der Aufruf schlägt fehl. Ein Workspace-Token hat keine einzelne Website, die sich auflösen ließe, deshalb liefert die API nicht stillschweigend die Zahlen einer Seite. Der Agent versucht das Problem durch Umschreiben der Abfrage zu lösen, also sag ihm vorab, dass der Selektor Pflicht ist.

Brauche ich für den Wochenreport einen bestimmten Flowsery-Tarif?

Nein. Die API gehört zu beiden Flowsery-Tarifen, der Wochenlauf hängt also nicht davon ab, welchen du hast. Das wöchentliche Token-Kontingent von Muse ist ein eigenes Limit.

Welche Zeitzone verwendet ein Flowsery-Wochenreport?

Die, die du im Aufruf nennst. Kommen startAt und endAt ohne timezone an, ordnet Flowsery sie der Zeitzone der Website zu, die in Flowsery eingestellt ist und nicht deine sein muss. Nenne die Zeitzone im Prompt, sonst kann "letzte Woche" andere sieben Tage abdecken als dein Kalender.

Ein Workspace-Token erstellen und Muse die Spezifikation übergeben, oder vorher die API-Referenz lesen.

Quellen: Metas Hilfeartikel zu Muse-Connectoren, Parallels Beitrag zu Muse Custom Integrations (14. September 2026) und die Flowsery-OpenAPI-Spezifikation. Geprüft am 20. September 2026.