Diagnostiziere den Zustand, bevor du die Aktion wiederholst
Wenn ein Vorgang hängt oder unvollständig wirkt, sichere mit der Fehlersuche in Activity zuerst seinen Status und die zugehörigen Nachweise.
Scope zuerst
Zustand statt Spinner
Sichere Evidenz
Bewahre den Zustand, bevor du ihn zu beheben versuchst
Schließe zuerst einen falschen Scope aus
Viele leere oder überraschende Ansichten sind korrekte Ergebnisse für die falsche Organisation, den falschen Workspace, Projekt-, Domain-, Länder-, Sprach-, Listen-, Geräte-, Datums- oder View-Kontext. Leere Suche und Filter, aber lies auch die sichtbaren Scope-Angaben.
Verschiebe keine Daten und lockere keine Rechte, bevor du das Problem im beabsichtigten Scope reproduziert hast.
Ladend, leer und veraltet sind drei verschiedene Zustände
| Zustand | Was du prüfst |
|---|---|
| Ladend | Ob die Anfrage noch aktiv ist, ein Quelllauf existiert und der Worker tatsächlich gestartet wurde. |
| Leer | Scope, Filter, Voraussetzungen, Quellenabdeckung und ob überhaupt ein geeigneter Datensatz existiert. |
| Veraltet | Quelldatum, letzten erfolgreichen Lauf, Zeitplanhistorie, Vergleichsbasis und Veröffentlichung eines neueren Laufs. |
Nutze Activity als Index und diagnostiziere dann im Quellprodukt
Activity kann einen unterstützten Vorgang mit normalisiertem Status, Scope, Zählern, Auslöser, Support-Code, Ziel und Billing-Evidenz verbinden. 30- oder 90-Tage-Dashboard, 365-Tage-Kalender, Quellenabfragen und Timeline mit höchstens 100 Zeilen sind begrenzt. Eine fehlende Activity-Zeile beweist keinen fehlenden Produktvorgang.
Activity kann keinen Lauf abbrechen, fortsetzen, wiederholen, reparieren oder veröffentlichen. Folge dem Ziel und prüfe den aktuellen Zustand im Quellprodukt, bevor du handelst.
Eine gespeicherte Anfrage beweist keine ausgeführte Hintergrundarbeit
Trenne bei laufender Arbeit Annahme, Dispatch, Worker-Start, Anbieterantwort, Speicherung und Veröffentlichung. Eine erfolgreiche Submit-Antwort beweist nur den Vertrag, den diese Antwort ausdrücklich beschreibt.
Prüfe vor einer Wiederholung, ob bereits ein Lauf aktiv ist, der ursprüngliche Lauf eine Reservierung besitzt, Teilergebnisse gespeichert wurden und das Produkt eine unterstützte Wiederherstellung anbietet. Wiederholte Versuche können Kosten duplizieren und die Spur unklarer machen.
Teilweise, begrenzte und stichprobenartige Ergebnisse bleiben mit Grenzen nutzbar
- Lies vor einem Zählervergleich die Coverage- oder Limitangabe.
- Behandle Zeilen außerhalb der zurückgegebenen Seite nicht als null.
- Vergleiche Läufe nur bei kompatiblem Scope, Regelstand, Markt, Gerät und Abdeckung.
- Ein Export kann nur die geladenen oder zurückgegebenen Zeilen enthalten.
- Als mindestens markierte Ausgaben sind keine vollständige Finanzsumme.
Verborgene Daten, verweigerte Aktionen und zu wenig Balance brauchen andere Antworten
Ein fehlendes Bedienelement kann aus Capability, Organisationsrolle, Workspace- oder Projektzuweisung, Plan oder Feature Gate folgen. Bitte einen Admin, die konkrete Berechtigung am betroffenen Resource-Scope zu prüfen, statt vorsorglich eine breite Rolle zu vergeben.
Für einen Viewer verborgene Billing-Daten bedeuten nicht null. Wird ein nutzungsabhängiger Vorgang blockiert, prüfe nutzbare Balance, Schätzung oder Reservierung, Quelllauf und Zahlungshistorie getrennt.
Wenn Balance oder Abrechnungszugriff den Start verhindern, prüfe Abrechnung und Nutzung, bevor du den Vorgang wiederholst.
Beweise bei Import und Export die Zeilenmenge
Wiederhole nur, wenn der aktuelle Zustand es trägt
| Beobachteter Zustand | Sichererer nächster Schritt |
|---|---|
| Validierungs- oder Voraussetzungsfehler | Korrigiere Eingabe, Zugriff, Verifikation, Markt oder Setup vor einem neuen Vorgang. |
| Eingereiht oder laufend | Prüfe Dispatch und Worker-Zuständigkeit und vermeide einen doppelten Lauf. |
| Teilweise | Bewahre brauchbare Ergebnisse, identifiziere die Lücke und nutze den dokumentierten Fortsetzungs- oder Wiederholungspfad. |
| Fehlgeschlagen oder abgebrochen | Lies Support-Code, Billing-Disposition und Recovery-Steuerung im Quellprodukt. |
| Erfolgreich, aber Ergebnis wirkt falsch | Prüfe Scope, Coverage, Quelldatum, Transformation und Veröffentlichung vor einer Wiederholung. |
Eskaliere mit einem reproduzierbaren, sicheren Datensatz
- Organisation, Workspace, Produktpfad, Resource-Name und Browser-Zeitzone.
- Versuchte Aktion, erwartetes Ergebnis, tatsächliches Ergebnis und Reproduzierbarkeit.
- Quelllauf oder sichtbare Vorgangsidentität, Zeitstempel, Status, Zähler und Support-Code.
- Coverage, Limit, Filter, Markt, Sprache, Gerät und Datumskontext.
- Billing-Zustand oder Anbieterreferenz, falls relevant, aber keine Tokens, Secrets, Kartendaten oder privaten Kundendaten.
Beispiel: Eine leere Keyword-Tabelle
Nach einem Import sieht eine Nutzerin eine leere Keyword-Tabelle. Bevor sie es erneut versucht, prüft sie Workspace, aktive Liste und Filter und öffnet dann Activity.
Activity zeigt den Import als noch laufend. Nach dem Abschluss erscheinen die Zeilen, und ein zweiter Import, der Duplikate erzeugt hätte, bleibt aus.
Häufige Fragen
Was prüfe ich zuerst, wenn Daten fehlen?
Den Umfang: Organisation, Workspace, Projekt, Domain, Markt, Sprache, Liste, Filter und Zeitraum. Viele leere Ansichten sind richtige Ergebnisse für den falschen Umfang.
Wann ist es sicher, eine Aktion zu wiederholen?
Wenn ein Validierungs- oder Einrichtungsfehler behoben ist oder ein Lauf endgültig fehlgeschlagen ist. Wiederhole nichts, solange ein Lauf wartet oder läuft, und bei teilweisen Läufen nur den fehlenden Teil.
Was gehört in eine Support-Anfrage?
Organisation, Workspace, Bereich, die versuchte Aktion, erwartetes und tatsächliches Ergebnis, Lauf-ID oder Vorgang, Zeitpunkte, Status und der Support-Code genau wie angezeigt.