LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Przegląd bloga /Digital Marketing / Meta Marketing API v26.0: zmiany z 27.10.2026...
Ten artykuł w innych językach:

Meta Marketing API v26.0: zmiany z 27.10.2026 i skrypt audytu istniejących integracji

Meta Marketing API v26.0: zmiany z 27.10.2026 i skrypt audytu istniejących integracji
Spis treści
  1. 1. Dlaczego przypięcie wersji przestaje działać 27.10.2026
  2. 2. Co zepsuje się głośno, a co po cichu
  3. 3. Audyt własnej konfiguracji, a nie API
  4. 4. Lista kontrolna dla każdego endpointu i przełączenie na Comscore, którego nikt nie zaplanował
  5. 5. Podsumowanie
  6. Pytania i odpowiedzi
  7. Źródła

Meta udostępniła Graph API v26.0 29.07.2026. Przy automatyzacji reklam odruch jest ten sam, co od lat: przeczytać changelog, zostawić integrację przypiętą do wersji używanej dzisiaj i zarezerwować migrację na spokojny tydzień wiosną. Tym razem ten odruch zawodzi. 27.10.2026 większość kluczowych zmian v26.0 zacznie obowiązywać we wszystkich wersjach, które nadal są wspierane. Wobec nich przypięcie nie daje po tej dacie już nic. Zostało około jedenastu tygodni, a praca do wykonania to problem inwentaryzacyjny, nie programistyczny.

1. Dlaczego przypięcie wersji przestaje działać 27.10.2026

Zwyczajowa umowa z wersjonowanym API jest prosta. Nowa wersja wprowadza zmiany łamiące zgodność, stara zachowuje swoje działanie aż do końca wsparcia, a moment przejścia pozostaje decyzją zespołu utrzymującego integrację. Przypięcie jest właśnie tym, po co istnieje numer wersji.

27.10.2026 ta umowa zostaje złamana celowo. Cztery z sześciu kluczowych zmian v26.0 obejmują wszystkie wersje wspierane tego dnia, a nie tylko wywołania, które mają w ścieżce v26.0. Zdanie, które padnie na najbliższym spotkaniu planistycznym i pojawia się w połowie tekstów o tym wydaniu, jest więc błędne: starsza wersja niczego nie chroni. Nie ma wersji, na której da się pozostać, aby utrzymać przy życiu placement Messenger Stories lub usunięte pola. Tę datę należy traktować jako zmianę platformy z twardym terminem, a numer wersji jako nieistotny dla skali ekspozycji na te cztery zmiany.

2. Co zepsuje się głośno, a co po cichu

Znaczenie ma sześć zmian, uporządkowanych tutaj według tego, jak głośno dają o sobie znać.

  • Instagram Explore Feed placement: usunięty od v26.0 (termin 27.10.2026 nie rozciąga tej zmiany na wszystkie wersje), a żądania w v26.0 lub nowszej, które nadal się do niego odwołują, kończą się twardym błędem. Ten daje o sobie znać w ciągu kilku minut.
  • Trzy pola delivery estimate: usunięte. Dokładne nazwy pól należy wziąć z changeloga i znikąd indziej, również nie z tego artykułu, a następnie porównać je z listami pól, o które faktycznie prosi własny kod.
  • Web-only destination: zniknął. Każdy ad set zbudowany wokół niego wymaga nowej decyzji o destination, a nie korekty konfiguracji.
  • Poll creatives: zablokowane. Tworzenie kreacji kończy się niepowodzeniem.
  • Advantage+ audience: od v26.0 ad sets w kategoriach Housing, Employment i Financial z targetowaniem, które może zostać poluzowane, muszą jawnie ustawiać targeting_automation.advantage_audience na 1 lub 0; dla wszystkich wersji obowiązek ten wejdzie dopiero po wycofaniu v25.0, którego daty Meta jeszcze nie podała. Wartość niejawna lub odziedziczona już nie wystarczy.
  • Messenger Stories: po cichu usunięte z messenger_positions. Bez błędu, bez ostrzeżenia, bez zmiany kodu statusu.

Ostatnia pozycja jest tą kosztowną. Alerting niemal na pewno opiera się na wskaźnikach błędów i liczbie nieudanych zadań, a wskaźnik błędów dla tej zmiany pozostaje zerowy. Ad sets nadal zwracają sukces, struktura dostarczania się przesuwa, a pierwszy sygnał dociera kilka tygodni później jako niewyjaśnione załamanie na wykresie wyników. Wszystko, co kończy się twardym błędem, to sprawa na jeden wtorkowy poranek. Ciche usunięcie placementu to cały kwartał zamulonej atrybucji.

Cztery tory wersji API zbiegające się przy jednej datowanej ścianie, od której cztery z sześciu zmian obejmują wszystkie wersje, obok wyjątki Explore Feed i advantage_audience, a poniżej te cztery zmiany
Cztery tory zbiegają się w jednej dacie. Do 27 października przypięta wersja odpowiada po staremu, później przy większości zmian wszystkie zachowują się jednakowo — a zmiana usuwająca umiejscowienie bez komunikatu o błędzie zasługuje na sprawdzenie w pierwszej kolejności.

3. Audyt własnej konfiguracji, a nie API

Zacznij audyt od konfiguracji zapisanej lokalnie: wyeksportowanych definicji ad sets, szablonów renderowanych przez generator kampanii i list pól w ekstraktorze raportowym. To tam znajdują się ciągi znaków do sprawdzenia, więc nie zaczynaj od odpytywania API. Przepisz informacje dostawcy raz z changeloga do jednego pliku watchlist.json i utrzymuj go ręcznie. Dzięki temu skrypt sprawdza udokumentowane informacje zamiast zgadywać; pozostałe dane pochodzą z własnych zasobów.

Python
#!/usr/bin/env python3
# audit_v26.py - skanuje zapisaną konfigurację ad sets pod kątem ekspozycji na v26.0.
import json, pathlib, sys

WATCH = json.loads(pathlib.Path("watchlist.json").read_text())
CONFIG_DIR = pathlib.Path("/srv/adops/adset_configs")
REGULATED = {"housing", "employment", "financial"}

def flatten(node, path=""):
    if isinstance(node, dict):
        for k, v in node.items():
            yield from flatten(v, f"{path}.{k}" if path else k)
    elif isinstance(node, list):
        for i, v in enumerate(node):
            yield from flatten(v, f"{path}[{i}]")
    else:
        yield path, node

findings = []
for f in sorted(CONFIG_DIR.glob("*.json")):
    doc = json.loads(f.read_text())
    flat = dict(flatten(doc))
    for path, value in flat.items():
        if value in WATCH["hard_fail_placements"]:
            findings.append((f.name, "HARD_FAIL", path, value))
        elif "messenger_positions" in path and value in WATCH["silent_drops"]:
            findings.append((f.name, "SILENT", path, value))
        elif value in WATCH["blocked_creatives"]:
            findings.append((f.name, "BLOCKED", path, value))
    for field in WATCH["removed_fields"]:
        hits = [p for p in flat if p.endswith(field)]
        if hits:
            findings.append((f.name, "REMOVED_FIELD", hits[0], field))
    if doc.get("vertical") in REGULATED and doc.get("targeting_automation", {}).get("advantage_audience") is None:
        findings.append((f.name, "MISSING_ADV_AUD", "targeting_automation.advantage_audience", doc["vertical"]))

for row in findings:
    print("\t".join(str(c) for c in row))
sys.exit(1 if any(r[1] == "HARD_FAIL" for r in findings) else 0)

Skrypt warto uruchamiać co tydzień aż do tej daty, a ten sam kod wyjścia wpiąć w zadanie, które wdraża szablony kampanii. Znalezisko HARD_FAIL w wersji v26.0 lub nowszej oznacza zepsuty deploy, więc lepiej, żeby już teraz przewracał się build, niż później kampania.

Shell
# /etc/cron.d/meta-v26-audit
MAILTO=adops@example.com
15 6 * * 1 adops cd /srv/adops && python3 audit_v26.py > /var/log/adops/v26-$(date +\%F).tsv 2>&1 || echo "v26 audit found blockers"

4. Lista kontrolna dla każdego endpointu i przełączenie na Comscore, którego nikt nie zaplanował

  1. Ad set create i update: usunąć placement Explore Feed, ustawiać messenger_positions jawnie zamiast polegać na wartościach domyślnych i jawnie ustawić targeting_automation.advantage_audience dla każdego ad setu z kategorii Housing, Employment i Financial.
  2. Creative create: odrzucać poll creatives we własnej warstwie walidacji i zaplanować od nowa każdy ad set, który korzystał z web-only destination.
  3. Odczyty delivery estimate: usunąć te trzy pola z listy pól żądania, a następnie prześledzić je w dół strumienia przez tabele staging, modele transformacji i kolumny dashboardów. API przestanie je wysyłać, a schemat bez mrugnięcia okiem utrzyma kolumnę nullable w nieskończoność.
  4. Raportowanie: ponownie sprawdzić wymiar geograficzny, patrz niżej.
  5. Weryfikacja: odtworzyć całą ścieżkę na własnym testowym koncie reklamowym z niskim budżetem, raz przed 27.10.2026 i raz następnego ranka.

Punkt dotyczący raportowania jest niezależny od październikowej daty i obowiązuje już teraz. 22.06.2026 Meta zmieniła rozdzielczość geograficzną w raportowaniu z DMA na Comscore Markets. Jeżeli hurtownia łączy wiersze geo z Meta z tabelą wymiaru DMA, to złączenie po cichu gubi wiersze od siedmiu tygodni, a każdy dashboard porównujący to lato z poprzednim zestawia ze sobą dwie różne geografie. Najpierw należy ustalić skalę szkód, dopiero potem zdecydować o nowym mapowaniu.

SQL
-- Wiersze, które nie mają już dopasowania w starym wymiarze DMA.
SELECT f.report_date, f.geo_name, SUM(f.impressions) AS impressions
FROM meta_geo_daily f
LEFT JOIN dim_dma d ON d.dma_name = f.geo_name
WHERE f.report_date >= DATE '2026-06-01'
  AND d.dma_code IS NULL
GROUP BY 1, 2
ORDER BY impressions DESC
LIMIT 25;

5. Podsumowanie

Powstały dwie niewielkie rzeczy. Pierwsza to skrypt audytowy, który czyta własną, zapisaną konfigurację ad sets, zestawia ją z ręcznie przepisaną listą obserwowanych pozycji i kończy pracę kodem różnym od zera przy wszystkim, co skończy się twardym błędem. Druga to lista kontrolna przypisująca każdą zmianę v26.0 do endpointu i do tabeli, której dotyka dalej w potoku danych. Żadna z nich nie opiera się na zgadywanych odpowiedziach API.

Zyskiem jest różnica między dowiedzeniem się 27.10.2026 a wiedzą już dzisiaj. Głośne zmiany i tak dałyby o sobie znać. Wartość leży w tych dwóch, które tego nie zrobią: w Messenger Stories znikających z messenger_positions bez żadnego błędu oraz w przejściu z DMA na Comscore, które od czerwca zniekształca raportowanie geograficzne. Dochodzi do tego jedno sprostowanie, które warto powtórzyć przy planowaniu kwartału: przypięcie się do starszej wersji nie jest tutaj żadnym zabezpieczeniem. Zanim zmieni się choćby jedna linia, każdą nazwę pola i każdy ciąg placementu należy zweryfikować w źródle pierwotnym: Graph API Changelog, version 26.0.

Pytania i odpowiedzi

Czy przypięcie integracji do starszej wersji API daje cokolwiek do 27.10.2026, czy tylko odsuwa tę samą pracę?

Do 27.10.2026 przypięcie działa normalnie i nic się nie psuje. Tego dnia przestaje chronić przed większością zmian – i to jest cała różnica wobec poprzednich wydań.

Zwyczajowo starsza wersja chroni aż do końca swojego wsparcia, a moment przejścia wybiera zespół utrzymujący integrację. Tym razem cztery z sześciu kluczowych zmian v26.0 obejmują wszystkie wersje wspierane tego dnia, a nie tylko wywołania mające w ścieżce v26.0. Nie ma więc wersji, która chroniłaby przed tymi czterema.

Praktycznie znaczy to, że termin jest sztywny, a praca przed nim polega na spisaniu, które pola i które placementy integracja faktycznie czyta i ustawia. Spis powstaje raz i jest wielokrotnie tańszy niż szukanie przyczyny po 27.10., gdy odpowiedź wróci pusta zamiast z błędem.

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ą.