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

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 kluczowe zmiany v26.0 zaczną obowiązywać we wszystkich wersjach, które nadal są wspierane. Po tej dacie przypięcie nie daje 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. Kluczowe zmiany 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 usunięte placementy i pola. Tę datę należy traktować jako zmianę platformy z twardym terminem, a numer wersji jako nieistotny dla skali ekspozycji.

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, a żądania, 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.
• Special Ad Category: ad sets w kategoriach Housing, Employment i Financial muszą ją teraz ustawiać jawnie. 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.

3. Audyt własnej konfiguracji, a nie API

Punktem wyjścia nie jest odpytywanie API, lecz konfiguracja już przechowywana lokalnie, bo to w niej mieszkają problematyczne ciągi znaków: wyeksportowane definicje ad sets, szablony renderowane przez generator kampanii, listy pól w ekstraktorze raportowym. Fakty pochodzące od dostawcy należy trzymać w jednym, ręcznie utrzymywanym pliku watchlist.json, przepisanym raz z changeloga, tak aby nic w skrypcie nie było zgadywane. Cała reszta pochodzi z własnych danych.

#!/usr/bin/env python3
# audit_v26.py - skanuje PANSTWA 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 not doc.get("special_ad_category"):
        findings.append((f.name, "MISSING_SAC", "special_ad_category", 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 po 27.10.2026 oznacza zepsuty deploy, więc lepiej, żeby już teraz przewracał się build, niż później kampania.

# /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 ustawić Special Ad Category 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.

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