LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Przegląd bloga /Digital Marketing / Meta Insights API: dostępność i kompletność podziałów...
Ten artykuł w innych językach:

Meta Insights API: dostępność i kompletność podziałów danych

Meta Insights API: dostępność i kompletność podziałów danych
Spis treści
  1. Których podziałów dotyczy zmiana?
  2. Status funkcji, data początkowa i dane historyczne
  3. Uzgodnienie sum to alarm, a nie certyfikat kompletności
  4. Praktyczna kolejność weryfikacji
  5. Częste pytania
  6. Źródła

Poprawna odpowiedź Insights API nie dowodzi dostępności ani kompletności podziału danych. Od 6 sierpnia 2026 r. Meta ogranicza wybrane podziały na niektórych kontach reklamowych do czasu włączenia odpowiedniej funkcji. Pusty wynik wymaga więc wyjaśnienia zamiast automatycznego przekształcenia w zero.

Weryfikacja podziałów: Zgodne sumy nie dowodzą kompletności ani poprawności
Cztery oddzielne etapy weryfikacji; zgodna suma uzupełnia kontrole, ale nie zastępuje pozostałych etapów.

Których podziałów dotyczy zmiana?

Komunikat Meta wymienia impression_device, hourly_stats_aggregated_by_audience_time_zone oraz frequency_value. Ograniczenie wymiaru urządzenia obejmuje również kombinacje zawierające ten wymiar. Nie jest to ogólna blokada wszystkich podziałów ani wszystkich kont reklamowych. Podział według strefy czasowej konta reklamowego stanowi odrębny wymiar.

Pozostałe zasady zgodności nadal obowiązują. Na przykład frequency_value jest używany z zasięgiem dla kampanii Reservation. Podziały godzinowe nie obsługują metryk unikalnych, zasięgu ani częstotliwości; udokumentowane zera dla nieobsługiwanych metryk nie dowodzą braku aktywności. Historia danych godzinowych obejmuje ponadto tylko 13 miesięcy. Niektóre metryki działań poza Meta są niedostępne z określonymi podziałami.

Status funkcji, data początkowa i dane historyczne

Odczyt GET /act_<ID>/insights/feature-settings/list-features zwraca dostępne funkcje. GET /act_<ID>/insights/feature-settings zwraca funkcje włączone. Odpowiednie nazwy obejmują impression_device, time_of_day_viewer_tz oraz frequency_value. Nazwa funkcji nie zawsze odpowiada dosłownie parametrowi podziału.

Brak wpisu w kompletnej, autoryzowanej odpowiedzi z listą włączonych funkcji oznacza wyłączenie danej funkcji. Nieudane żądanie, niepełna paginacja lub brak uprawnień nie dostarczają takiego dowodu. Pole insights_effective_date, jeśli występuje, wskazuje pierwszą dostępną datę. Brak tej daty oznacza według dokumentacji dostępność dla wszystkich dat, z uwzględnieniem obowiązujących ograniczeń historii i metryk.

Meta opisuje włączenie funkcji w Menedżerze reklam oraz przez API ustawień funkcji. Operacja API zmienia konfigurację konta, nie ma odpowiednika służącego do wyłączenia i może wymagać około 24 godzin do wejścia w życie. Poprawna odpowiedź na włączenie nie potwierdza jeszcze dostępności danych raportu; znaczenie mają późniejszy status funkcji i rzeczywiste wyniki.

Oficjalne strony dokumentacji różnie opisują rolę żądań asynchronicznych. Uwagi na stronie podziałów przedstawiają żądanie asynchroniczne jako alternatywę dla włączenia funkcji przez administratora. Bardziej szczegółowy komunikat o zmianie z 8 maja, obowiązującej od 6 sierpnia, stwierdza jednak, że bez włączenia zarówno żądania synchroniczne, jak i asynchroniczne mogą nie zwracać wyników. Ten komunikat opisuje asynchroniczne pobieranie historii po włączeniu, z dziennym limitem min(10, number_of_ad_groups). Zadanie asynchroniczne nie jest więc gwarantowanym obejściem. Status funkcji, data początkowa, dopuszczalna historia i faktyczny wynik zadania wymagają weryfikacji dla danego konta.

Uzgodnienie sum to alarm, a nie certyfikat kompletności

Przykładowy porównywalny wynik całego konta zawiera 184 300 wyświetleń, a pobrany podział — 121 940. Różnica wynosi 62 360, czyli około 33,8% wartości całkowitej. Dla obsługiwanego, rozłącznego i wyczerpującego podziału metryki addytywnej taka rozbieżność wymaga wyjaśnienia. Sam procent nie wskazuje przyczyny ani nie dowodzi braku włączenia funkcji.

Porównanie wymaga tego samego konta, poziomu raportowania, zakresu dat, strefy czasowej, filtrów, definicji metryki i faktycznie obowiązujących ustawień atrybucji. Różne momenty pobrania również mogą powodować rozbieżności, ponieważ dane raportowe podlegają zmianom. Uprawnienia, wersja API, nieobsługiwane kombinacje, brakujące strony i nieukończone zadania asynchroniczne pozostają możliwymi przyczynami.

Nie każda metryka jest addytywna. Zasięg może obejmować tę samą osobę w kilku grupach: grupy o zasięgu 80 i 70 mogą mieć łączny zasięg 100. Sumowanie wszystkich typów działań może podwójnie liczyć kategorie hierarchiczne. Wskaźniki i średnie wymagają odpowiednich mianowników. Meta opisuje ponadto wartości podziałów jako szacunki; właściwa tolerancja zależy zatem od metryki i udokumentowanego zachowania.

Nawet idealna zgodność sum nie wystarcza. Oczekiwane wiersze A=60 i B=40 dają taką samą sumę jak błędnie przypisane wiersze A=40 i B=60. Powielone wiersze mogą liczbowo wyrównać brak innych wierszy. Porównanie sum nie potwierdza prawidłowego przypisania, unikalności kluczy ani obecności wszystkich żądanych wymiarów.

Praktyczna kolejność weryfikacji

  1. Kontrakt zapytania: zapis obejmuje dostęp do konta, uprawnienia, wersję API, obsługiwane pola i kombinacje podziałów, status funkcji oraz dostępny okres.
  2. Transport i status zadania: błędy pozostają widoczne. Dla raportów asynchronicznych przed pobraniem wyników sprawdzany jest ukończony status zadania oraz postęp 100%.
  3. Wszystkie strony: pobieranie obejmuje każdy odnośnik paging.next. Pusta strona może nadal zawierać odnośnik do następnej; liczba wierszy nie jest samodzielnym warunkiem zakończenia.
  4. Wiersze i schemat: kontrola obejmuje wymagane pola, żądane wymiary, unikalne klucze wierszy i brakujące wartości. Brak danych pozostaje odróżnialny od zmierzonego zera.
  5. Uzasadnione uzgodnienie sum: tylko zgodne metryki addytywne są porównywane z osobno pobraną wartością całkowitą. Rozbieżność uruchamia wyjaśnianie; zgodność uzupełnia pozostałe kontrole.

Nieudane pobranie lub niewyjaśniony pusty wynik nie powinny zastępować poprawnej partycji danych zerami. Potok może zachować ostatni poprawny stan z widocznym wiekiem danych i statusem błędu. Potwierdzony pusty wynik nadaje się do zapisania jako pusty dopiero po wyjaśnieniu zakresu zapytania i dostępności danych. Ponowne pobieranie historii zależy od zweryfikowanego okresu i limitów, zamiast zakładać dostępność całej przeszłości po włączeniu funkcji.

Częste pytania

Czy HTTP 200 potwierdza kompletność danych?

Nie. Status potwierdza poprawną obsługę na poziomie HTTP. Dostępność funkcji, obsługa metryk, paginacja i kontrola wierszy pozostają osobnymi etapami.

Czy dodatkowe zapytanie o sumę rozwiązuje problem?

Nie. Dodaje użyteczne porównanie dla odpowiednich metryk, ale zużywa limit i wymaga utrzymania. Nie zastępuje kontroli funkcji ani pojedynczych wierszy.

Czy brak włączenia zawsze daje pustą poprawną odpowiedź?

Nie ma tu gwarancji uniwersalnego wzorca odpowiedzi. Komunikat opisuje możliwość braku wyników na objętych zmianą kontach; inne błędy i przyczyny muszą pozostać widoczne.

Źródła

Lukas Wójcik

Lukas Wójcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Masz pytanie lub pomysł na projekt internetowy? Napisz krótko, o co chodzi. Formularz korzysta z reCAPTCHA do ochrony przed spamem.

Napisanie komentarza

Doświadczenia z praktyki i pytania o wdrożenie są tu mile widziane.

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.