English
Deutsch
PolskiGoogle Ads API: dostęp projektu Cloud i koniec v22 7 października 2026
Management Summary
Google Ads API łączy zewnętrzne programy z kontami reklamowymi, na przykład do raportowania i automatycznych zmian kampanii. Połączenia dotyczą dwie odrębne zmiany: dostęp jest teraz zatwierdzany przez projekty Google Cloud, grupujące ustawienia aplikacji, a wersja 22 została wyłączona 7 października 2026. Firmy i agencje potrzebują zarówno właściwego dostępu, jak i obsługiwanej wersji. Rozróżnienie tych warunków pomaga znaleźć przyczynę awarii, także w rzadko uruchamianych zadaniach.
Spis treści
Od 9 września 2026 dostęp do Google Ads API jest zarządzany przez projekty Google Cloud. Niezależny termin wyłączenia v22, 7 października 2026, już minął. Zatwierdzenie projektu nie przywraca wyłączonej wersji API; nowsza biblioteka nie nadaje projektowi dostępu produkcyjnego. [1, 2, 3]
Liczy się projekt powiązany z uwierzytelnianiem
Nowy model Google wiąże poziom dostępu z projektem Cloud używanym do uwierzytelniania. Przy logowaniu użytkownika jest to projekt klienta OAuth, a przy koncie usługi projekt będący właścicielem tego konta. Dotychczasowe poziomy przeniesiono na podstawie użycia API w ciągu 90 dni przed zmianą. Sam od dawna zatwierdzony token programisty nie dowodzi więc poprawnej konfiguracji wszystkich projektów organizacji. [1, 2]
Projekt Cloud grupuje ustawienia aplikacji i dostęp API w Google Cloud. Klient OAuth identyfikuje aplikację proszącą o dostęp przez logowanie użytkownika. Konto usługi zapewnia osobną tożsamość dla procesów automatycznych. Dostęp projektu oraz uprawnienie do odczytu lub zmiany konkretnego konta Ads są osobnymi zgodami.
Przykładowa agencja ma codzienny system raportowy i drugą aplikację używaną tylko podczas okazjonalnych migracji. Obie wcześniej korzystały z tego samego zatwierdzonego tokenu, lecz ich dane uwierzytelniające należą do różnych projektów. Działający raport dzienny niewiele mówi o gotowości drugiej aplikacji. Spis integracji wymaga projektu powiązanego z uwierzytelnianiem, a nie tylko identyfikatora konta menedżera.
Trzy osobne warstwy
| Warstwa | Pytanie kontrolne |
|---|---|
| Uwierzytelnianie | Który użytkownik lub które konto usługi wysyła żądanie? |
| Dostęp API | Jaki poziom dostępu ma powiązany projekt Cloud? |
| Wersja API | Czy żądanie trafia do obsługiwanej wersji? |
Uprawnienia na koncie klienta pozostają kolejnym warunkiem. Tabela określa kolejność analizy, a nie gwarancję powodzenia każdej operacji. Pozwala uniknąć traktowania błędu wersji jak problemu z hasłem albo przebudowy kampanii z powodu brakującej zgody dla projektu.
Co zapisać po nieudanym żądaniu
Google dokumentuje błąd CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION w v25 i nowszych, gdy projekt z dostępem testowym wywołuje konto produkcyjne. Starsze wersje używają w tej sytuacji ACTION_NOT_PERMITTED. Aktualna strona pomocy opisuje również problemy przejściowe dotyczące części nowo zatwierdzonych projektów. Widoczna zgoda i odrzucone żądanie wymagają więc analizy, a nie natychmiastowego wniosku o błędnych danych logowania. [2]
Rejestr integracji – przykładowe pola
Aplikacja i odpowiedzialny zespół
Numer projektu Cloud
Metoda uwierzytelniania i identyfikator danych dostępowych
Konto docelowe: testowe lub produkcyjne
Wersja API widoczna w żądaniach
Dokładny kod błędu i identyfikator żądania
Czas ostatniego poprawnego wykonaniaRejestr potrzebuje identyfikatorów, a nie tajnych wartości. Token odświeżania, klucz prywatny i sekret klienta nie powinny trafiać do arkusza obsługi incydentów. W przykładowej agencji taki zapis odróżnia zapomniany proces miesięczny od działającego raportu dziennego bez zmiany konfiguracji kampanii.
Termin v22 pozostaje niezależny
Zapowiedź Google wskazuje, że żądania v22 od 7 października 2026 roku kończą się błędem. Metryki API w Cloud Console pomagają znaleźć niedawno wywoływane metody; nazwa metody zawiera wersję. Uzupełnia to przeszukiwanie kodu, ponieważ stary wdrożony proces może nadal działać po aktualizacji głównego repozytorium. [3]
Przegląd obejmuje zaplanowane eksporty, przesyłanie konwersji, skrypty utrzymaniowe i rzadko wykonywane zadania administracyjne. Poprawne odświeżenie panelu nie wystarcza, jeżeli import nocny nadal korzysta z v22. Migrację należy oceniać według rzeczywiście wykonywanych operacji. Odczyt danych i operacje zapisujące wymagają osobnych prób.
Kontrolowana zmiana zamiast kilku równoległych napraw
Praktyczna kolejność obejmuje najpierw zapisanie stanu dostępu projektu, następnie aktualizację biblioteki i odpowiedniego kodu żądań, a na końcu sprawdzenie reprezentatywnych operacji. Jeśli jest to możliwe, odrębne konto testowe umożliwia próby przed zapisem produkcyjnym. Dokumentacja powinna rozróżniać walidację od wykonanej zmiany i przechowywać identyfikatory utworzonych zasobów.
Dotychczasowy nagłówek developer token jest według Google obecnie opcjonalny i ignorowany. Google zaleca jego usunięcie i zapowiada odrzucanie w przyszłej wersji głównej. Bez osobnego ogłoszenia nie należy utożsamiać tego przyszłego kroku z terminem wyłączenia v22. Zaktualizowane biblioteki obsługują żądania bez tego tokenu. [1, 2]
Odpowiedzialność jest częścią utrzymania
Kontakty z rolami Owner i Editor w projekcie stają się również istotne dla komunikatów o usłudze. Technicznie działająca integracja może być źle utrzymywana, jeśli powiadomienia trafiają do byłych pracowników. Przegląd odpowiedzialności i alarmów powinien towarzyszyć migracji technicznej. Powiązany artykuł o passkeys dotyczy innej warstwy: konta człowieka stojącego za autoryzacją. Nie zastępuje kontroli dostępu projektu opisanej tutaj.
Powiązane narzędzie
GoogleAds – eksplorator zapytań GAQL
Wymóg passkey w Google Ads API: czego dotyczy i jak znaleźć zapomniane autoryzacje
Pytania i odpowiedzi
Jak znaleźć rzadko uruchamiane procesy, które wciąż korzystają z v22?
Przez kilka źródeł, bo każde widzi tylko część obrazu:
- Metryki API w Cloud Console, osobno dla każdego projektu. Pokazują tylko wywołania z wybranego projektu i tylko z wybranego okresu; kwartalny eksport, który w tym okresie nie działał, nie pojawia się w nich, a drugi projekt pojawia się dopiero po jego wybraniu.
- Kontroli wymagają wdrożone zależności oraz konfiguracja żądań. Plik lockfile ustala wersje bibliotek, a obraz kontenera zawiera określoną instalację. Żaden z tych elementów sam nie potwierdza wybranej wersji API. Dowodem jest skonfigurowany adres usługi lub wersja oraz dziennik rzeczywistych żądań. Aktualizacja głównego repozytorium nie aktualizuje automatycznie starszego wdrożonego procesu.
- Harmonogramy obejmują crontaby, zadania Cloud Scheduler i inne automatyzacje. Pokazują następne planowane wykonanie, również zadań kwartalnych, które nie działały od wyłączenia wersji.
Nieaktywny proces nie zgłasza błędu wyłącznie z powodu nadejścia terminu. Problem staje się widoczny dopiero po następnym żądaniu do wyłączonej wersji. Czas ostatniego poprawnego wykonania oraz następny termin pomagają wykryć takie opóźnione ryzyko.
Jak wygląda sytuacja zewnętrznych narzędzi, które korzystają z Google Ads w imieniu agencji?
Dostęp API zależy od projektu klienta OAuth. Przy kliencie zarządzanym przez dostawcę to dostawca odpowiada za zatwierdzenie projektu i migrację API. Jeśli narzędzie korzysta z klienta należącego do agencji, odpowiedzialność za projekt pozostaje po stronie agencji. Rejestr integracji powinien wskazywać stosowany wariant. W obu przypadkach nadal potrzebne są ważne dane uwierzytelniające i uprawnienia na koncie klienta.
Źródła
- Google Ads: nowy proces rejestracji
- Google Ads API: zmiana modelu tokenów programisty
- Google Ads API: przypomnienie o wyłączeniu v22
Źródła sprawdzone: 26 października 2026.
Powiązane artykuły
