> ## Documentation Index > Fetch the complete documentation index at: https://docs.armin.cx/llms.txt > Use this file to discover all available pages before exploring further. # Berichte und Metriken > Support-Metriken entdecken und Berichtsdaten mit der Public API v1 abfragen. Mit der Reporting-API von Chatarmin CX verfolgst du Ticketvolumen, Antwortzeiten, Zufriedenheit und Automatisierung in deinen eigenen Dashboards. ## Zugriff und Limits Beide Endpoints erweitern die bestehende `/public/v1`-API. Sende deinen API-Schlüssel im Header `cx-api-key`. Der Schlüssel braucht `analytics:read` und muss einem Support-Agenten zugewiesen sein. Richte ihn unter [Einstellungen → API](https://armin.cx/app/_/settings/api) ein. Berichtsabfragen beachten die Dashboard-Berechtigungen sowie Kanal-, Team- und Agenten-Einschränkungen dieses Agenten. Eine Metrik im Katalog gibt dir nicht automatisch Zugriff auf ihre Daten. | Endpoint | Zweck | Rate-Limit-Stufe | | -------------------------------- | ---------------------------- | ----------------------------- | | `GET /public/v1/reports/metrics` | Metrikdefinitionen entdecken | Liste: 60 Requests/Minute | | `POST /public/v1/reports/query` | Berichtsergebnisse lesen | Analytics: 10 Requests/Minute | Keiner der Endpoints verändert Tickets oder sendet Nachrichten. Unter [Rate Limits](/de/api/rate-limits) findest du Hinweise zu Wiederholungen. Die [OpenAPI-Referenz](https://api.armin.cx/docs/v1) enthält die vollständigen Antwortschemas. ## Metriken entdecken ```bash theme={null} curl 'https://api.armin.cx/public/v1/reports/metrics' \ -H "cx-api-key: $CX_API_KEY" ``` Die Antwort ist `{ "success": true, "data": [...] }`. Sie enthält den vollständigen statischen Katalog ohne Pagination. Jeder Eintrag hat folgende Felder: | Feld | Bedeutung | | ---------------------- | ------------------------------------------------------------------------------- | | `id` | Metrik-ID für `SHOW` und `VISUALIZE`, zum Beispiel `new_tickets` | | `label`, `description` | Anzeigename und Definition | | `group`, `dataType` | Metrikkategorie und Werttyp | | `format` | `count`, `duration-seconds`, `percent`, `decimal` oder `currency-eur` | | `aggregation` | `count`, `sum`, `median`, `average` oder `ratio` | | `attribution` | Welches Ereignis oder welcher aktuelle Zustand den Zeitraum der Metrik bestimmt | | `denominator` | Optionale Erklärung zum Nenner oder zur Berechnung | | `snapshot` | Ob die Metrik den aktuellen Zustand statt historischer Aktivitäten beschreibt | | `higherIsBetter` | Ob ein höherer Wert eine Verbesserung bedeutet | Der Katalog enthält keine Tickets, Kundendaten, Workspace-Entitäts-IDs oder internen Datenquellennamen. Namen und Beschreibungen sind auf Englisch. Cache diese Metadaten, statt sie vor jeder Abfrage neu zu laden. Nicht jede Metrik unterstützt jede Gruppierung oder Visualisierung. ## Berichtsdaten abfragen Starte mit einer Metrik und einem kurzen Zeitraum. Sende JSON mit genau zwei Feldern: `query` und einer IANA-Zeitzone in `timezone`, zum Beispiel `Europe/Vienna` oder `UTC`. ```bash theme={null} curl 'https://api.armin.cx/public/v1/reports/query' \ -H "cx-api-key: $CX_API_KEY" \ -H 'Content-Type: application/json' \ --data '{"query":"FROM tickets\nSHOW new_tickets\nDURING yesterday\nVISUALIZE new_tickets TYPE kpi","timezone":"Europe/Vienna"}' ``` Die Antwort nutzt `{ "success": true, "data": ... }`. Über `data.kind` erkennst du die Ergebnisform: `kpi` enthält zum Beispiel `value`, `previousValue` und `format`; `time-series` enthält `series` und `points`. Du erhältst Diagrammdaten, kein Bild und keinen CSV-Export. ### Abfragesprache Schreibe jede Klausel in eine eigene Zeile. Das ist die CX-Berichtsabfragesprache, kein SQL: Beliebige Tabellen, Joins und SQL-Ausdrücke sind nicht erlaubt. | Klausel | Verwendung | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | `FROM tickets` | Pflicht. Nur der Datensatz `tickets` ist verfügbar. | | `SHOW new_tickets, resolved_tickets` | Pflicht. Nutze IDs aus dem Metrikkatalog. | | `DURING yesterday` | Pflichtzeitraum, alternativ `SINCE ... UNTIL ...`. Weitere benannte Zeiträume sind `today`, `this_week`, `last_week`, `this_month` und `last_month`. | | `SINCE 2026-08-01 UNTIL 2026-08-07` | Konkrete Kalendertage in der angegebenen Zeitzone, einschließlich Enddatum. Nicht mit `DURING` kombinieren. | | `WHERE status is_one_of open, resolved` | Optionaler Filter. Wiederhole `WHERE` in separaten Zeilen, um mehrere Bedingungen gleichzeitig zu verlangen. | | `GROUP BY channel` | Optionale Gruppierung nach Kategorie. | | `TIMESERIES day` | Optionale Zeitgruppierung: `hour`, `day`, `week` oder `month`. | | `COMPARE TO previous_period` | Optionaler Vergleich für KPIs und unterstützte Zeitreihen; auch `previous_year` ist möglich. | | `ORDER BY new_tickets DESC` | Optionale Sortierung mit `ASC` oder `DESC`. | | `LIMIT 25` | Optionales Ergebnislimit bis 1.000. | | `OPTIONS {"showAverageRow":true}` | Optionale freigegebene Visualisierungsoptionen, zum Beispiel für eine Datentabelle. | | `VISUALIZE new_tickets TYPE kpi` | Pflicht. Wähle Metriken aus `SHOW` und eine unterstützte Visualisierung. Nutze für einen KPI genau eine Metrik. | Gängige Visualisierungen sind `kpi`, `line`, `area`, `grouped_bar`, `stacked_bar`, `horizontal_bar` und `data_table`. Diagramme brauchen Metriken mit demselben `format`. Eine `data_table` darf Formate mischen und braucht genau eine Gruppierungsdimension. Alle Metriken, auch Automatisierung und CSAT, nutzen `FROM tickets`; es gibt keine separaten Nachrichten- oder Umfragedatensätze. ## Abfragebeispiele Sende jede vollständige Abfrage unten als `query`-String im HTTP-Request oben, mit `timezone: "Europe/Vienna"`. Datumsangaben und Metrik-IDs behalten in allen Beispielen dasselbe Format. ### Tägliches Ticketvolumen Vergleiche erstellte und gelöste Tickets je Tag. Das sind unterschiedliche Ereignisgruppen, nicht unbedingt dieselben Tickets. ```text theme={null} FROM tickets SHOW new_tickets, resolved_tickets TIMESERIES day SINCE 2026-08-01 UNTIL 2026-08-07 VISUALIZE new_tickets, resolved_tickets TYPE line ``` ### Ticket-KPI für gestern Vergleiche neue Anfragen mit dem Vortag. ```text theme={null} FROM tickets SHOW new_tickets DURING yesterday COMPARE TO previous_period VISUALIZE new_tickets TYPE kpi ``` ### Neue Tickets nach Kanal Sortiere Kanäle nach eingehendem Ticketvolumen. Kanalschlüssel im Ergebnis identifizieren die Kanäle deines Workspaces, keine allgemeingültige Liste von Kanalnamen. ```text theme={null} FROM tickets SHOW new_tickets GROUP BY channel DURING last_week ORDER BY new_tickets DESC LIMIT 10 VISUALIZE new_tickets TYPE horizontal_bar ``` ### Zeiten bis zur ersten Antwort Vergleiche die mediane Wartezeit auf eine qualifizierende menschliche oder KI-Antwort mit der Wartezeit auf eine menschliche Antwort. Beide Reihen liefern Sekunden, keine Durchschnittswerte. ```text theme={null} FROM tickets SHOW customer_first_response_time, human_first_response_time TIMESERIES day DURING last_week VISUALIZE customer_first_response_time, human_first_response_time TYPE line ``` ### CSAT-Wert und Stichprobengröße Zeige die Anzahl der Antworten neben dem Wert, damit du kleine Stichproben einschätzen kannst. Eine Tabelle erlaubt Dezimalwert und Anzahl in einem Ergebnis. ```text theme={null} FROM tickets SHOW csat_average, csat_responses, low_csat_tickets GROUP BY day DURING last_month ORDER BY label ASC VISUALIZE csat_average, csat_responses, low_csat_tickets TYPE data_table ``` ### Einsparungen und KI-Ausgaben Vergleiche geschätzte Einsparungen mit geschätzten Ausgaben in EUR. Dieses Tagesdiagramm nutzt dasselbe Format für beide Reihen und ist kein Rechnungsabgleich. Diese speziellen Automatisierungsmetriken unterstützen KPIs, tägliche Diagramme oder Tabellen sowie Aktionsaufteilungen, außer bei KI-Ausgaben. Mische sie nicht mit anderen Ticketmetriken und ergänze keine Kategorieaufteilungen. ```text theme={null} FROM tickets SHOW money_saved, ai_spend TIMESERIES day DURING last_week VISUALIZE money_saved, ai_spend TYPE line ``` ### Gefilterte Teamauslastung Prüfe gelöste deutschsprachige Tickets nach Team, einschließlich Lösungsdauer. Mehrere Filter werden mit AND verknüpft. `status` ist der aktuelle Ticketstatus, nicht der Status bei Erstellung. Nutze für Filter wie `team`, `channel` oder `human_agent` die Entitäts-IDs deines Workspaces statt Anzeigenamen. ```text theme={null} FROM tickets SHOW resolved_tickets, full_resolution_time WHERE language is de WHERE status is resolved GROUP BY team DURING last_week ORDER BY resolved_tickets DESC LIMIT 25 OPTIONS {"showAverageRow":false} VISUALIZE resolved_tickets, full_resolution_time TYPE data_table ``` ### Aktuell auf Kunden wartende Tickets Zähle offene Tickets, die auf Informationen vom Kunden warten, nicht Kunden, die auf den Support warten. Die Sprache verlangt eine Datumsklausel, aber diese macht einen Snapshot nicht zu historischen Daten. Ergänze bei Snapshots weder `TIMESERIES` noch `COMPARE TO`. ```text theme={null} FROM tickets SHOW awaiting_response_now DURING today VISUALIZE awaiting_response_now TYPE kpi ``` ## Ergebnisse lesen Diese Antwortformen nutzen erfundene Beispielwerte, keine garantierten Ergebnisse für die Beispielzeiträume. Zeilen und Datenpunkte sind gekürzt. Nutze zurückgegebene Labels und Schlüssel, statt übersetzte Labels oder feste Kanal-IDs anzunehmen. Ein KPI liefert eine Zahl und ihr Format. `previousValue` kann `null` sein; historische KPIs können auch ohne expliziten Vergleich einen Vorperiodenwert enthalten. Mit `COMPARE TO` wählst du den Vergleichszeitraum ausdrücklich. Snapshot-KPIs haben keinen historischen Vergleich. ```json theme={null} { "success": true, "data": { "kind": "kpi", "value": 42, "previousValue": 38, "format": "count" } } ``` Werte in Zeitreihenpunkten nutzen die Schlüssel aus `series`. Explizite Vergleiche ergänzen Reihenschlüssel mit der Endung `__compare`. ```json theme={null} { "success": true, "data": { "kind": "time-series", "format": "count", "series": [ { "key": "new_tickets", "label": "New tickets" }, { "key": "resolved_tickets", "label": "Resolved" } ], "points": [ { "date": "2026-08-01", "label": "Aug 1", "values": { "new_tickets": 42, "resolved_tickets": 35 } } ] } } ``` Ein Kategorieergebnis enthält Werte mit Labels. ```json theme={null} { "success": true, "data": { "kind": "category", "format": "count", "items": [{ "key": "channel_example", "label": "Support email", "value": 42 }] } } ``` Eine Tabelle beschreibt Metrik und Format jeder Spalte. Addiere oder mittle keine täglichen Prozentsätze, Mediane oder Durchschnittswerte, um einen Zeitraum-KPI nachzubauen. Frage stattdessen den KPI für diesen Zeitraum ab. ```json theme={null} { "success": true, "data": { "kind": "data_table", "rowDimension": "day", "columns": [ { "measureId": "csat_average", "label": "CSAT", "format": "decimal" }, { "measureId": "csat_responses", "label": "CSAT responses", "format": "count" }, { "measureId": "low_csat_tickets", "label": "Low-CSAT tickets", "format": "count" } ], "rows": [ { "key": "2026-08-01", "label": "Aug 1", "values": { "csat_average": 4.5, "csat_responses": 10, "low_csat_tickets": 1 } } ] } } ``` ## Metrikreferenz Unten stehen alle 50 registrierten Metrik-IDs, gruppiert wie im Katalog. Aggregation, Format und Zuordnung sind die exakten Katalogwerte. Du wählst die Metrik, keine eigene Aggregationsfunktion. * `count` zählt die definierten Tickets, Nachrichten, Umfragen, Aktionen oder Ereignisse; `sum` addiert Werte; `average` ist das arithmetische Mittel; `median` ist der mittlere Beobachtungswert; `ratio` teilt den passenden Zähler durch seinen Nenner. * `duration-seconds` liefert Sekunden, `currency-eur` EUR, `decimal` einen Dezimalwert und `percent` Prozentwerte: `75` bedeutet 75 %, nicht `0.75`. CSAT-Werte nutzen eine Skala von 1 bis 5. * Die Zuordnung bestimmt den Datumsbezug: `ticket_created` ist eine Erstellungskohorte; `ticket_resolved`, `reply_event`, `reopen_event`, `reassignment_event`, `survey_submitted`, `action_executed` und `order_paid` beziehen sich auf das jeweilige Ereignis. `agent_presence` misst Online-Sitzungszeit; `mixed_events` kombiniert Erstellung und Lösung; `current_snapshot` bedeutet jetzt. * Werte einer Erstellungskohorte können sich mit den Tickets weiterentwickeln. Besonders `messages` und `messages_per_ticket` enthalten erfasste Nachrichten auf Tickets, die im Zeitraum erstellt wurden, nicht nur Nachrichten, die darin gesendet wurden. Für öffentliche menschliche Nachrichten mit Sendedatum im Zeitraum nutze `agent_messages`. * Aktuelle Snapshots erlauben keine Zeitdimensionen oder historischen Vergleiche. Das Alter offener Tickets zählt ab Erstellung, nicht ab der letzten Nachricht. Auch mit einer älteren Datumsklausel rekonstruiert ein Snapshot keinen Rückstand zum Periodenende. * Raten nutzen die Nenner in den Definitionen unten, innerhalb des jeweiligen Umfangs. Nullwerte oder leere Ergebnisse beweisen allein keine fehlende Aktivität: Berichtsdaten können unvollständig sein oder auf Aktualisierung warten. Prüfe wichtige Summen, bevor du sie für Zusagen oder Finanzberichte nutzt. * `csat_response_rate` ist eine Kohorte versendeter Umfragen: bewertete Einreichungen geteilt durch im Zeitraum versendete Umfragen. Im Katalog steht `survey_submitted`, aber diese Berechnung nutzt anders als die übrigen CSAT-Metriken das Versanddatum. * `time_saved` und `money_saved` sind Schätzungen aus den Aktionszeiten und dem Stundensatz deines Workspaces. `ai_spend` rechnet erfasste KI-Credits mit einem EUR-pro-Credit-Ersatzwert um; das ist weder deine Rechnung noch eine Garantie deines Vertragspreises. Obwohl im Katalog `action_executed` steht, zählt für Ausgaben das Erstellungsdatum des KI-Laufs, auch an Tagen ohne erfasste Aktionen. ### Volumen und Auslastung | Metrik-ID | Definition und Nenner | Aggregation | Format | Zuordnung | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------ | -------------------- | | `new_tickets` | Im Zeitraum erstellte Tickets. | `count` | `count` | `ticket_created` | | `resolved_tickets` | Im Zeitraum gelöste Tickets. | `count` | `count` | `ticket_resolved` | | `tickets_replied_to` | Eindeutige Tickets mit einer erfassten öffentlichen Support-Antwort im Zeitraum. | `count` | `count` | `reply_event` | | `answered_tickets` | Eindeutige Tickets mit einer einem Agenten zugeordneten menschlichen oder KI-Nachricht im Zeitraum. | `count` | `count` | `reply_event` | | `reopened_tickets` | Eindeutige im Zeitraum wiedereröffnete Tickets, nicht die Anzahl der Wiedereröffnungen. | `count` | `count` | `reopen_event` | | `backlog_now` | Aktuell offene, ungelöste Tickets. | `count` | `count` | `current_snapshot` | | `backlog_over_24h` | Offene Tickets, die vor mehr als 24 Stunden erstellt wurden. | `count` | `count` | `current_snapshot` | | `backlog_over_48h` | Offene Tickets, die vor mehr als 48 Stunden erstellt wurden. | `count` | `count` | `current_snapshot` | | `awaiting_response_now` | Offene Tickets, die auf Informationen vom Kunden warten, nicht auf den Support. | `count` | `count` | `current_snapshot` | | `net_backlog_change` | Neue minus gelöste Tickets im Zeitraum; keine Rekonstruktion jeder Rückstandsänderung. | `sum` | `count` | `mixed_events` | | `messages` | Alle Kunden-, menschlichen und KI-Nachrichten auf im Zeitraum erstellten Tickets. | `sum` | `count` | `ticket_created` | | `agent_messages` | Im Zeitraum gesendete öffentliche Geschäftsnachrichten menschlicher Agenten. | `count` | `count` | `reply_event` | | `messages_per_ticket` | Kunden-, menschliche und KI-Nachrichten geteilt durch im Zeitraum erstellte Tickets. | `average` | `decimal` | `ticket_created` | | `agent_online_time` | Gesamte Online-Zeit der Agenten im Posteingang im Zeitraum, keine Ticketbearbeitungszeit. | `sum` | `duration-seconds` | `agent_presence` | | `one_touch_tickets` | Gelöste Tickets mit genau einer öffentlichen Support-Antwort und ohne Wiedereröffnung. | `count` | `count` | `ticket_resolved` | | `one_touch_rate` | One-Touch-Tickets geteilt durch gelöste Tickets. | `ratio` | `percent` | `ticket_resolved` | | `zero_touch_tickets` | Gelöste Tickets ohne menschliche Antwort; KI oder Automatisierung kann trotzdem aktiv gewesen sein. | `count` | `count` | `ticket_resolved` | | `reassignments` | Zuweisungsänderungen im Zeitraum; ein Ticket kann mehrfach zählen. | `count` | `count` | `reassignment_event` | | `reassignment_rate` | Neu zugewiesene Tickets geteilt durch im Zeitraum erstellte Tickets. | `ratio` | `percent` | `ticket_created` | | `demand_coverage` | Erstellte Tickets mit abschließender Lösung geteilt durch neue Tickets im Zeitraum, nicht Lösungsdurchsatz geteilt durch neue Anfragen. | `ratio` | `percent` | `ticket_created` | | `support_revenue` | Support-Tickets zugeordneter Shopify-Bestellumsatz in EUR, nach Zahlungsdatum. | `sum` | `currency-eur` | `order_paid` | ### Antwort und Lösung | Metrik-ID | Definition und Nenner | Aggregation | Format | Zuordnung | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | ------------------ | ----------------- | | `customer_first_response_time` | Mediane Wartezeit bis zur ersten qualifizierenden menschlichen oder KI-Antwort. | `median` | `duration-seconds` | `reply_event` | | `human_first_response_time` | Mediane Wartezeit bis zur ersten qualifizierenden menschlichen Antwort. | `median` | `duration-seconds` | `reply_event` | | `ai_first_response_time` | Mediane Wartezeit bis zur ersten qualifizierenden KI-Antwort. | `median` | `duration-seconds` | `reply_event` | | `full_resolution_time` | Mediane verstrichene Zeit von Ticketerstellung bis Lösung. | `median` | `duration-seconds` | `ticket_resolved` | | `active_resolution_time` | Mediane Zeit innerhalb der Geschäftszeiten von Erstellung bis Lösung, abzüglich Wartezeiten auf den Kunden. | `median` | `duration-seconds` | `ticket_resolved` | | `waiting_on_customer_time` | Median der gesamten Kundenwartezeit pro gelöstem Ticket innerhalb der Geschäftszeiten. Pro Ticket werden die Intervalle zwischen menschlicher Support-Antwort und nächster Kundenantwort summiert. | `median` | `duration-seconds` | `ticket_resolved` | | `sla_resolution_met` | Rechtzeitig eingehaltene Lösungs-SLA-Fristen für im Zeitraum erstellte Tickets. | `count` | `count` | `ticket_created` | | `sla_resolution_breached` | Überschrittene Lösungs-SLA-Fristen für im Zeitraum erstellte Tickets. | `count` | `count` | `ticket_created` | ### Qualität und Zufriedenheit | Metrik-ID | Definition und Nenner | Aggregation | Format | Zuordnung | | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------- | --------- | ------------------ | | `reopen_rate` | Gelöste Tickets mit Wiedereröffnung geteilt durch gelöste Tickets. | `ratio` | `percent` | `ticket_resolved` | | `csat_average` | Durchschnittlicher Wert von 1 bis 5 aus im Zeitraum eingereichten bewerteten Umfragen. | `average` | `decimal` | `survey_submitted` | | `csat_responses` | Im Zeitraum eingereichte bewertete Umfragen. | `count` | `count` | `survey_submitted` | | `csat_response_rate` | Im Zeitraum versendete und bewertete Umfragen geteilt durch versendete Umfragen; beachte die Versanddatum-Ausnahme oben. | `ratio` | `percent` | `survey_submitted` | | `low_csat_tickets` | Eindeutige Tickets mit einem eingereichten Wert von höchstens 3. | `count` | `count` | `survey_submitted` | ### KI und Automatisierung | Metrik-ID | Definition und Nenner | Aggregation | Format | Zuordnung | | --------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------- | ------------------ | ------------------ | | `ai_involved_tickets` | Im Zeitraum erstellte Tickets, auf denen ein KI-Agent lief oder eine erfasste Aktion abschloss. | `count` | `count` | `ticket_created` | | `ai_resolved_tickets` | Tickets, deren abschließendes Ergebnis durch einen KI-Agenten gelöst wurde. | `count` | `count` | `ticket_resolved` | | `ai_resolution_rate` | KI-gelöste Tickets geteilt durch gelöste Tickets mit KI-Beteiligung, nicht durch alle eingehenden Tickets. | `ratio` | `percent` | `ticket_resolved` | | `human_handoffs` | Gelöste Tickets mit erfasster KI-Übergabe an einen Menschen, nach Lösungsdatum statt Übergabezeitpunkt. | `count` | `count` | `ticket_resolved` | | `handoff_rate` | Menschliche Übergaben geteilt durch gelöste Tickets mit KI-Beteiligung. | `ratio` | `percent` | `ticket_resolved` | | `workflow_resolved_tickets` | Durch Workflow-Automatisierung abgeschlossene gelöste Tickets. | `count` | `count` | `ticket_resolved` | | `workflow_resolution_rate` | Durch Workflows gelöste Tickets geteilt durch gelöste Tickets. | `ratio` | `percent` | `ticket_resolved` | | `ai_actions` | Erfasste kundenbezogene Aktionen, die KI im Zeitraum abgeschlossen hat. | `count` | `count` | `action_executed` | | `human_actions` | Erfasste kundenbezogene Aktionen, die Menschen im Zeitraum abgeschlossen haben. | `count` | `count` | `action_executed` | | `action_automation_rate` | KI-Aktionen geteilt durch alle erfassten Aktionen, kein Mittelwert der Automatisierungsanteile je Ticket. | `ratio` | `percent` | `action_executed` | | `time_saved` | Geschätzte durch KI-Aktionen gesparte menschliche Zeit anhand der Aktionszeiten des Workspaces. | `sum` | `duration-seconds` | `action_executed` | | `money_saved` | Geschätzte EUR-Einsparung anhand gesparter Zeit und des Workspace-Stundensatzes. | `sum` | `currency-eur` | `action_executed` | | `ai_spend` | Geschätzte EUR aus erfassten KI-Credits zum Ersatzwert; beachte die Laufdatum-Ausnahme oben. | `sum` | `currency-eur` | `action_executed` | | `ai_reopen_rate` | Wiedereröffnete KI-gelöste Tickets geteilt durch KI-gelöste Tickets. | `ratio` | `percent` | `ticket_resolved` | | `ai_csat` | Durchschnittlicher eingereichter CSAT-Wert für Tickets mit KI-Beteiligung, auf der Skala von 1 bis 5. | `average` | `decimal` | `survey_submitted` | | `ai_suggestion_used_rate` | Verwendete KI-Antwortentwürfe geteilt durch angebotene KI-Vorschläge, auf im Zeitraum gelösten Tickets. | `ratio` | `percent` | `ticket_resolved` | ## Fehlerbehebung | Antwort | Was du prüfen solltest | | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `401` | Sende einen gültigen API-Schlüssel. | | `403` | Vergib `analytics:read`, weise den Schlüssel einem Agenten zu und prüfe für Abfragen dessen Dashboard-Berechtigungen. | | `400` | Prüfe Syntax, Metrik-IDs, Zeitzone und die Kombination aus Metrik und Gruppierung. Begrenze den Zeitraum auf 90 Kalendertage, bei Stundenberichten auf 31 Tage. Zu große Zeiträume liefern `VALIDATION_ERROR` mit `details.requested_days`, `details.max_days` und `details.timezone`. Teile die Abfrage in nicht überlappende `SINCE`/`UNTIL`-Zeiträume auf. Beide Daten sind inklusive, beginne den nächsten Zeitraum also am Folgetag. Reduziere Metriken oder Vergleiche, wenn die Abfrage ihr Ausführungsbudget überschreitet. | | `429` | Warte die Zeit aus dem Header `Retry-After` ab. | Zeitraumvalidierung, eine geschätzte Aufwandsprüfung und Limits für zurückgegebene Zeilen oder Punkte garantieren weder eine allgemeine maximale Laufzeit noch eine Grenze für jede Ergebniszelle oder zugrunde liegende Datenbankoperation. `LIMIT` kürzt zurückgegebene Zeilen oder Punkte; es ist keine Pagination und garantiert nicht weniger Datenbankarbeit. Teile große Reporting-Aufgaben in kleinere Zeitfenster. Historische Vollständigkeit und Aktualität hängen von den verfügbaren Berichtsdaten ab; eine erfolgreiche Antwort bestätigt beides nicht. Scheitert eine gültige kleine Abfrage oder wirken Summen unvollständig, kontaktiere den Support mit der `request_id` aus der Antwort, der Zeitzone und einer bereinigten Abfrage. Teile niemals deinen API-Schlüssel.