English
Deutsch
PolskiMeta Insights API: Verfügbarkeit und Vollständigkeit von Breakdowns prüfen
Inhalt
Eine erfolgreiche Antwort der Insights API belegt weder die Verfügbarkeit noch die Vollständigkeit eines Breakdowns. Seit dem 6. August 2026 beschränkt Meta bestimmte Aufschlüsselungen auf einigen Werbekonten bis zur Aktivierung der entsprechenden Funktion. Leere Ergebnisse benötigen deshalb eine ausdrückliche Diagnose statt einer automatischen Umwandlung in null.
Welche Aufschlüsselungen sind betroffen?
Metas Ankündigung nennt impression_device, hourly_stats_aggregated_by_audience_time_zone und frequency_value. Die Einschränkung der Gerätedimension betrifft auch Kombinationen mit dieser Dimension. Das ist keine allgemeine Sperre sämtlicher Breakdowns oder Werbekonten. Die Aufschlüsselung nach Zeitzone des Werbekontos ist eine andere Dimension.
Weitere Kompatibilitätsregeln gelten weiterhin. Beispielsweise wird frequency_value zusammen mit Reichweite für Reservation-Kampagnen verwendet. Stündliche Aufschlüsselungen unterstützen keine Unique-Metriken, Reichweite oder Frequenz; dokumentierte Nullwerte nicht unterstützter Metriken belegen keine ausgebliebene Aktivität. Außerdem reicht die Historie stündlicher Daten nur 13 Monate zurück. Bestimmte Aktionen außerhalb von Meta sind mit einzelnen Aufschlüsselungen nicht verfügbar.
Funktionsstatus, Anfangsdatum und historische Daten
Der lesende Endpunkt GET /act_<ID>/insights/feature-settings/list-features listet verfügbare Funktionen auf. GET /act_<ID>/insights/feature-settings liefert aktivierte Funktionen. Zu den betreffenden Funktionsnamen gehören impression_device, time_of_day_viewer_tz und frequency_value. Diese Namen stimmen nicht immer mit dem jeweiligen Breakdown-Parameter überein.
Ein fehlender Eintrag in einer vollständigen, autorisierten Antwort über aktivierte Funktionen bedeutet einen deaktivierten Funktionsstatus. Eine fehlgeschlagene Anfrage, unvollständige Seitennavigation oder fehlende Berechtigung liefert diesen Nachweis nicht. Falls vorhanden, kennzeichnet insights_effective_date das erste verfügbare Datum. Ein fehlendes Anfangsdatum bedeutet laut Dokumentation Verfügbarkeit für alle Daten, vorbehaltlich der geltenden Historien- und Metrikgrenzen.
Meta dokumentiert die Aktivierung im Ads Manager und über die Feature-Settings-API. Der API-Aufruf verändert die Kontokonfiguration, besitzt keine entsprechende Deaktivierungsoperation und kann ungefähr 24 Stunden bis zur Wirksamkeit benötigen. Eine erfolgreiche Aktivierungsantwort bestätigt noch keine verfügbaren Berichtsdaten; entscheidend sind der anschließende Funktionsstatus und die tatsächlichen Ergebnisse.
Die offiziellen Dokumentationsseiten formulieren die Rolle asynchroner Anfragen unterschiedlich. Hinweise auf der Breakdown-Seite nennen einen asynchronen Abruf als Alternative zur Aktivierung durch die Administration. Die speziellere Änderungsankündigung vom 8. Mai mit Wirkung zum 6. August erklärt dagegen, dass ohne Aktivierung sowohl synchrone als auch asynchrone Anfragen ohne Ergebnisse bleiben können. Diese Ankündigung beschreibt den asynchronen Abruf historischer Daten nach der Aktivierung mit einer täglichen Quote von min(10, number_of_ad_groups). Ein asynchroner Auftrag ist deshalb kein garantiert funktionierender Umweg. Funktionsstatus, Anfangsdatum, zulässige Historie und tatsächliche Auftragsergebnisse benötigen eine Prüfung für das betreffende Konto.
Der Summenabgleich ist ein Alarm, kein Vollständigkeitsnachweis
Angenommen, ein vergleichbarer Kontogesamtwert enthält 184.300 Impressionen, die abgerufene Aufschlüsselung dagegen 121.940. Die Differenz beträgt 62.360 beziehungsweise rund 33,8 Prozent des Gesamtwerts. Bei einer unterstützten, überschneidungsfreien und vollständigen Aufteilung einer additiven Metrik ist diese Abweichung untersuchungsbedürftig. Der Prozentsatz bestimmt weder die Ursache noch beweist die Zahl eine fehlende Aktivierung.
Ein Abgleich benötigt dasselbe Konto, dieselbe Berichtsebene, Datumsgrenzen, Zeitzone, Filter, Metrikdefinition und tatsächlich wirksame Attributionseinstellungen. Auch unterschiedliche Abrufzeitpunkte können wegen nachträglicher Datenänderungen Abweichungen verursachen. Berechtigungen, API-Version, nicht unterstützte Kombinationen, fehlende Seiten und unvollständige asynchrone Aufträge bleiben mögliche Ursachen.
Nicht jede Metrik ist additiv. Reichweite kann dieselbe Person in mehreren Gruppen zählen: Zwei Gruppen mit Reichweite 80 und 70 können zusammen eine Reichweite von 100 besitzen. Auch die Addition aller Aktionstypen kann hierarchische Kategorien doppelt zählen. Quoten und Durchschnittswerte benötigen passende Bezugsgrößen. Meta beschreibt Breakdown-Werte zudem als Schätzungen; eine angemessene Toleranz hängt deshalb von Metrik und dokumentiertem Verhalten ab.
Selbst exakte Gleichheit genügt nicht. Die erwarteten Zeilen A=60 und B=40 ergeben dieselbe Summe wie die falsch zugeordneten Zeilen A=40 und B=60. Doppelte Zeilen können ausgelassene Zeilen rechnerisch ausgleichen. Ein Summenvergleich belegt weder die korrekte Zuordnung noch eindeutige Schlüssel oder sämtliche angeforderten Dimensionen.
Eine praktische Prüfreihenfolge
- Abfragevertrag: Kontozugriff, Berechtigungen, API-Version, unterstützte Felder und Breakdown-Kombinationen, Funktionsstatus und verfügbarer Zeitraum werden festgehalten.
- Transport und Auftragsstatus: Fehler bleiben sichtbar. Bei asynchronen Berichten werden ein abgeschlossener Auftragsstatus und 100 Prozent Fertigstellung vor dem Ergebnisabruf geprüft.
- Alle Seiten: Jeder Verweis in
paging.nextwird verfolgt. Auch eine leere Seite kann einen Folgeverweis enthalten; die Zeilenanzahl allein ist kein Abbruchkriterium. - Zeilen und Schema: Pflichtfelder, angeforderte Dimensionen, eindeutige Zeilenschlüssel und fehlende Werte werden geprüft. Fehlende Daten bleiben von einer gemessenen null unterscheidbar.
- Geeigneter Summenabgleich: Nur kompatible additive Metriken werden mit einem separat abgerufenen Gesamtwert verglichen. Eine Abweichung löst eine Untersuchung aus; Gleichheit ergänzt die übrigen Prüfungen.
Ein fehlgeschlagener oder ungeklärt leerer Abruf sollte keine bisher gültige Datenpartition mit Nullen überschreiben. Die Pipeline kann den letzten gültigen Stand mit sichtbarem Alter und Fehlerstatus erhalten. Bestätigte leere Ergebnisse dürfen erst bei geklärtem Abfrageumfang und Verfügbarkeitsstatus als leer gespeichert werden. Historische Nachläufe richten sich nach nachgewiesenem Zeitraum und Quoten, statt nach einer Aktivierung pauschal sämtliche früheren Daten vorauszusetzen.
Häufige Fragen
Belegt HTTP 200 vollständige Daten?
Nein. Der Status bestätigt die erfolgreiche Behandlung auf HTTP-Ebene. Funktionsverfügbarkeit, Metrikunterstützung, Seitennavigation und Zeilenprüfung bleiben eigenständige Prüfungen.
Löst eine zusätzliche Gesamtwertabfrage das Problem?
Nein. Die Abfrage ergänzt einen nützlichen Vergleich für geeignete Metriken, verursacht aber zusätzliche Quoten- und Wartungskosten. Funktionsprüfung und Prüfung einzelner Zeilen bleiben notwendig.
Führt eine fehlende Aktivierung immer zu einer leeren Erfolgsantwort?
Ein universelles Antwortmuster ist hier nicht garantiert. Die Ankündigung beschreibt mögliche fehlende Ergebnisse betroffener Konten; andere Fehler und Ursachen müssen weiterhin sichtbar bleiben.
Quellen
Passend dazu
