Adobe Analytics API to interfejs REST Adobe do odpytywania danych raportowych, zarządzania segmentami i calculated metrics, audytu konfiguracji report suite i przenoszenia danych analitycznych do własnej hurtowni. To to samo API, które napędza UI Analysis Workspace, i sięgasz po nie wtedy, gdy wyrosłeś z scheduled reportów i data feedów.
Jeśli kiedykolwiek czekałeś 4 godziny, aż raport w Workspace się wyrenderuje, żeby potem zorientować się, że potrzebujesz go w 28 wariantach dla różnych stakeholderów, wiesz już, dlaczego API ma znaczenie. Scheduled reports w UI kończą się na 150 aktywnych. Data Feeds dają surowe hity, ale nic zagregowanego. API wypełnia lukę między tymi dwoma.
Poniżej opiszę, co Adobe Analytics API faktycznie robi w 2025, jak zmieniła się autoryzacja po wygaszeniu JWT, które endpointy są potrzebne i realne workloady, w których API się zwraca. Używam tego API do pipeline'ów BigQuery, masowych migracji segmentów i miesięcznych audytów report suite dla europejskich zespołów analitycznych od 2020 roku.
Kluczowe wnioski
Adobe Analytics ma trzy API, które mają znaczenie w 2025: Reporting API 2.0 (obecne), Reporting API 1.4 (legacy, wciąż działa) i Customer Journey Analytics API (osobny produkt, osobny endpoint). Większość zespołów potrzebuje tylko 2.0.
Autoryzacja przeszła na OAuth Server-to-Server w 2025. Credentiale JWT Service Account są w pełni wycofane. Jeśli Twój data pipeline padł po cichu na początku 2025, to właśnie dlatego.
Limit to 12 requestów na sekundę na integrację, maksymalnie 60 równoległych requestów. Pojedynczy raport w stylu Workspace dla dużego zakresu dat może zająć 30+ sekund, więc paralelizacja znaczy mniej, niż mogłoby się wydawać.
Najbardziej wartościowe workloady: dzienne automatyczne pobrania do BigQuery lub Snowflake, migracja segmentów między report suite, monitoring driftu konfiguracji, backendy dashboardów, gdzie Workspace jest zbyt wolny.
API jest w cenie każdej licencji Adobe Analytics. Płacisz za czas inżyniera plus sporadyczne kredyty Data Warehouse API na duże eksporty (ponad 1 milion wierszy).
Czym naprawdę jest Adobe Analytics API
Adobe Analytics to 20-letnia enterprise'owa platforma analityczna z kilkoma równoległymi warstwami dostępu do danych. Zrozumienie, którego API użyć, zaczyna się od wiedzy, które z nich najszybciej odpowie na Twoje pytanie.
Trzy API, które warto znać
Reporting API 2.0 (obecne, domyślne). Endpointy REST pod analytics.adobe.io/api/{COMPANY_ID}. Używane do wszystkiego, co zbudowałbyś w Analysis Workspace: raportów, freeform tables, calculated metrics, segmentów. To jest "Adobe Analytics API" w 95% przypadków w 2025.
Reporting API 1.4 (legacy, wciąż działa). Stare API SOAP/REST z czasów sprzed Workspace. Adobe nadal je utrzymuje dla klientów ze starymi integracjami. Nie buduj nowych pipeline'ów na 1.4. Jeśli dziedziczysz kod uderzający w api.omniture.com albo w legacy endpointy REST, to jest 1.4.
Customer Journey Analytics (CJA) API. CJA to nowszy produkt Adobe zbudowany na Experience Platform. Ma swoje własne API pod analytics.adobe.io/api/{IMS_ORG}/reports (inny kształt, inne koncepcje). Jeśli Twój zespół migrował na CJA, jesteś na zupełnie innej powierzchni API. Większość klientów Adobe Analytics w 2025 wciąż jest na klasycznym Analytics i używa Reporting API 2.0.
Jest też Data Warehouse API do ogromnych eksportów (ponad 1 milion wierszy), Real-Time API do dashboardów na żywo i Classification API do masowego zarządzania klasyfikacjami. Dotykasz ich tylko w specyficznych edge case'ach.
Co faktycznie możesz zrobić z Reporting API 2.0
- Uruchamiać raporty odpowiadające wszystkiemu w Analysis Workspace: freeform tables, cohort, flow, attribution.
- Zarządzać segmentami: listować, tworzyć, aktualizować, kasować, udostępniać między report suite.
- Zarządzać calculated metrics: ten sam CRUD co segmenty, z pełną biblioteką funkcji.
- Listować metryki i dimensions dostępne w report suite (przydatne do dynamicznych dashboardów).
- Odpytywać userów w Twojej organizacji i ich uprawnienia.
- Odpytywać ustawienia report suite: timezone, waluta, definicja visit, podsumowanie processing rules.
- Zarządzać virtual report suites: listować, tworzyć, aktualizować.
Czego nie zrobisz z 2.0: zmodyfikowania wywołań trackingu (to AppMeasurement/Web SDK), masowej zmiany klasyfikacji (osobne Classification API) ani dostępu do surowego clickstream (to Data Feeds, nie API).
Autoryzacja: OAuth Server-to-Server
Historia autoryzacji jest prawie identyczna jak dla Reactor API. Jeśli czytałeś mój poradnik Reactor API, możesz przelecieć tę sekcję wzrokiem.
Credentiale JWT Service Account zostały wycofane 1 stycznia 2025. Każda integracja Adobe Analytics API, która nie została zmigrowana na OAuth Server-to-Server do początku 2025, nie działa.
Flow setupu:
- Wejdź na console.adobe.io i stwórz Project.
- Dodaj Adobe Analytics jako API.
- Wybierz credentiale OAuth Server-to-Server.
- Przypisz integrację do Product Profile z dostępem do Adobe Analytics (i do właściwych report suite). Uprawnienia mają znaczenie: integracja dosięgnie tylko tych report suite, które są przypisane do jej Product Profile.
- Dostajesz Client ID, Client Secret, Organization ID i listę scope'ów. Potrzebne scope'y:
openid,AdobeID,additional_info.projectedProductContext,session. - Wymień credentiale na 24-godzinny access token pod ims-na1.adobelogin.com/ims/token/v3.
- Dołączaj access token, Client ID, Organization ID i Company ID w nagłówkach requestów.
Jeden specyficzny dla Adobe Analytics detal: potrzebujesz Global Company ID (krótki alfanumeryczny string, nie Twój IMS Org). Znajdziesz go w Adobe Analytics pod Admin > Company Settings, albo zawołaj GET /discovery/me z tokenem i zobacz pole globalCompanyId.
Odświeżanie access tokena, obsługa błędów i logika retry działają tak samo, jak w reszcie ekosystemu Adobe I/O.
Core endpointy, których faktycznie będziesz używał
Realna praca z Adobe Analytics API dotyka może sześciu endpointów, nie pełnej powierzchni. Oto co się liczy.
POST /reports
Koń roboczy. Wysyłasz definicję raportu w JSON, dostajesz w odpowiedzi tabelę wierszy/kolumn. Minimalna definicja raportu zawiera rsid (report suite), globalFilters (zakres dat i segmenty), metricContainer.metrics (co zliczyć) i dimension (jak rozbić).
Przykładowo, "Page Views by Page ostatnie 30 dni dla report suite acme-prod":
{
"rsid": "acme-prod",
"globalFilters": [{"type": "dateRange", "dateRange": "2025-08-27T00:00:00.000/2025-09-26T00:00:00.000"}],
"metricContainer": {"metrics": [{"columnId": "0", "id": "metrics/pageviews"}]},
"dimension": "variables/page"
}Paginacja: raporty domyślnie mają 10 wierszy. Realne zapytania używają settings.limit (max 50 000) i settings.page do paginacji. Dla dużych datasetów paginuj równolegle aż do limitu rate.
GET /segments
Listuje wszystkie segmenty dostępne dla Product Profile integracji, w ramach wszystkich autoryzowanych report suite. Wspiera filtrowanie po rsids, tags i ownerId. Najczęstsze użycie: wyciągnięcie wszystkich segmentów z tagiem production do migracji albo audytu.
POST /segments
Tworzy nowy segment. Ciało to definicja segmentu w tym samym kształcie JSON, którego Workspace używa wewnętrznie. Najbezpieczniejszy sposób wygenerowania tego JSON-a to zbudowanie segmentu w UI Workspace, a potem eksport definicji przez GET /segments/{id}?expansion=definition.
GET /calculatedmetrics i POST /calculatedmetrics
Ten sam wzorzec co segmenty. Definicje calculated metrics używają drzewa funkcji (add, subtract, ratio itd.) nad base metrics. Jak przy segmentach, łatwiej zbudować w UI i wyeksportować definicję.
GET /collections/suites
Listuje wszystkie report suite, do których integracja ma dostęp, z kluczowymi ustawieniami: timezone, waluta, definicja visit, liczba hitów. Przydatne do dynamicznych dashboardów, które muszą przełączać suite, i do audytów konfiguracji.
GET /dimensions i GET /metrics
Zwracają pełną listę dimensions i metryk (w tym eVar, sProps i calculated metrics) dostępnych dla danego report suite. Przydatne, kiedy budujesz dynamiczny report builder i musisz wiedzieć, co jest dostępne, zanim zawołasz /reports.
Zastanawiasz się, czy API rozwiązuje konkretne wąskie gardło raportowe, które masz? Napisz do mnie po zescope'owaną ocenę. Powiem wprost, czy API to właściwy fix, czy coś w Twoim setupie Workspace jest faktycznym problemem.
Realne use case'y
Cztery workloady, w których Adobe Analytics API zwraca się już przy pierwszym projekcie.
Use case 1: Dzienny pipeline do BigQuery lub Snowflake
Najczęstszy legalny workload API. Chcesz, żeby dane Adobe Analytics leżały obok danych CRM, subskrypcji i ad-spend w hurtowni, złączone po user ID lub account ID.
Kiedy Dawid, lead data engineering w polskiej firmie SaaS, zaczął konsolidować dane martech do BigQuery na początku 2025, jego zespół miał dwie opcje. Eksport Data Feeds (surowy clickstream, 50 GB dziennie, wymagał parsowania) albo zbudowanie pipeline'u API, który codziennie pobierałby preagregowane raporty.
Poszli z API. Python job działający w Cloud Composer pobiera 12 definicji raportów każdego ranka o 6:00 UTC, dla poprzedniego dnia i okna 30 dni. Dane lądują w tabeli BigQuery spartycjonowanej po dacie. Stakeholderzy odpytują ją przez Looker Studio i Sigmę, nie dotykając Workspace.
Development: 3 tygodnie. Miesięczny koszt runtime: poniżej 100 EUR. Alternatywa (parsowanie Data Feeds) była szacowana na 4 miesiące pracy inżyniera.
Use case 2: Masowa migracja segmentów między report suite
Jeśli Twoja organizacja ma wiele report suite (jedna per brand, region albo środowisko), segmenty zbudowane w jednej nie istnieją automatycznie w innych. Workspace pozwala skopiować jeden segment naraz. Wolno, ręcznie, podatne na błędy.
Aleksandra, senior analityczka w europejskiej grupie retailowej, musiała przenieść 78 segmentów z głównego report suite do 6 regionalnych suite latem 2025. Ręcznie to 468 rekreacji segmentów. Przez API to 30-linijkowy skrypt: GET każdego segmentu z expansion, POST do każdego docelowego suite z podmienionym rsid.
Całość pracy API: 2 dni. Większość tego czasu poszła na napisanie walidacji, która potwierdzi, że segmenty rozwiązują się identycznie między suite.
Use case 3: Monitoring driftu konfiguracji
Enterprise'owe wdrożenia Adobe Analytics mają dziesiątki report suite, każdy z własnymi definicjami zmiennych, processing rules i ustawieniami marketing channels. Drift konfiguracji między siostrzanymi suite to główna przyczyna raportów, które wyglądają poprawnie, ale nie są.
Miesięczny skrypt audytu API może pobrać ustawienia każdego report suite, każdą definicję eVar/sProp/event, każdą processing rule i zdiffować je względem referencyjnego suite. Zmiany do przeglądu.
Kiedy uruchomiłem ten audyt dla klienta z branży finansowej w lipcu 2025, skrypt wyflagował 34 ciche zmiany w 9 report suite, o których nikt w zespole analitycznym nie wiedział. Dwie z nich powodowały 15% rozbieżność danych na kluczowej metryce lejka. Zespół debugował "tajemnicze" odchylenie przez 3 tygodnie, zanim audyt wyjaśnił je w jednym przebiegu.
Use case 4: Własne dashboardy, gdy Workspace jest zbyt wolny
Workspace jest świetny do analizy eksploracyjnej. Jest fatalny o 9:00 w poniedziałek, kiedy 40 osób ładuje ten sam dashboard i każdy request zajmuje 20 sekund.
Fix: pre-compute raporty dashboardu przez API w nocy, cachuj wyniki w Redisie albo dedykowanej tabeli i serwuj dashboard z cache'a. Czas ładowania spada z 20 sekund do sub-sekundowego. Workspace staje się narzędziem eksploracyjnym, Twój custom dashboard staje się narzędziem codziennego użytku.
Masz konkretne wąskie gardło dostępu do danych w Adobe Analytics? Zobacz moje usługi, żeby zescope'ować prace API, development pipeline'ów i audyty.
Limity, błędy i best practice'y
Limit Adobe Analytics API: 12 requestów na sekundę na integrację, z limitem 60 równoległych requestów. W praktyce wąskim gardłem dla większości zespołów jest czas wykonania raportu (Adobe uruchamia Twoje zapytanie po swojej stronie), nie sam limit rate.
Kody odpowiedzi, które zobaczysz:
200: raport przeszedł, dane w ciele.202 Accepted: dla raportów anomaly detection dostajesz ticket do pollowania. Większość zespołów tego nie dotyka.400: zmalformowany JSON raportu. Ciało błędu zwykle wskazuje winne pole.401: token wygasł albo jest niewłaściwy. Odśwież i spróbuj raz.403: Product Profile Twojej integracji nie ma dostępu do żądanego report suite.408: raport wykonywał się zbyt długo (zwykle ponad 10 minut). Zawęź zakres dat albo dodaj filtry.429: rate-limited. Wycofaj się.500: błąd po stronie Adobe. Retry z exponential backoffem. Jeśli utrzymuje się przy konkretnym raporcie, zapytanie prawdopodobnie przekracza wewnętrzny limit na breakdowns albo liczbę wierszy.
Best practice 1: buduj raporty najpierw w Workspace, eksportuj definicję JSON. Prawie każdy raport Adobe Analytics API da się zbudować w Workspace i wyeksportować. Nie ma powodu, żeby ręcznie pisać JSON.
Best practice 2: sprawdź swoje zakresy dat. Raporty Adobe Analytics uruchamiają się w timezone report suite, nie w UTC. Uruchamianie raportu "wczoraj" z UTC cron joba w report suite w timezone US Pacific produkuje 17 godzin wczoraj i 7 godzin z dnia poprzedniego. Zawsze konstruuj daty jawnie w timezone report suite.
Best practice 3: paginuj przez settings.page i cachuj wyniki. Duży breakdown (powiedzmy, wszystkie strony dla okna 90 dni) może mieć 500 000 wierszy. Pobierz raz, zacachuj, odpytuj cache. Nie uruchamiaj tego samego raportu co godzinę.
Best practice 4: użyj społecznościowego SDK Python aanalytics2. Adobe nie ship'uje oficjalnego klienta Python, ale open-source'owa biblioteka aanalytics2 (autorstwa Juliena Picciniego) jest szeroko używana, aktywnie utrzymywana i obsługuje paginację, odświeżanie tokena i dziwactwa definicji raportów 2.0. Oszczędza tygodnie developmentu.
Kiedy NIE używać API
Szczera odpowiedź: większość użytkowników Adobe Analytics powinna zostać w Workspace.
- Jeśli Twoje potrzeby raportowe obsługuje 10 scheduled reportów, nie buduj pipeline'u API. Workspace scheduled reports wysyła PDF-y albo CSV-y bez kodu.
- Jeśli potrzebujesz surowych danych clickstream, Data Feeds albo source connections Customer Journey Analytics są lepsze niż API. API zwraca zagregowane raporty, nie hity.
- Jeśli Twój zespół nie ma capacity Python albo Node.js, API zgnije. Początkowy pipeline działa, ale potem zmienia się odświeżanie tokena, Adobe wycofuje parametr, i sześć miesięcy później nic nie działa.
- Jeśli oceniasz, czy Adobe Analytics to w ogóle właściwa platforma, zacznij od poradnika Adobe Analytics i pomocy z Adobe Analytics. Praca z API ma sens dopiero wtedy, gdy podstawowe wdrożenie Workspace jest zdrowe.
API nagradza zespoły ze strukturalnymi potrzebami raportowymi. Jeśli Twoje potrzeby danowe mieszczą się w Workspace, zostań tam.
Najczęściej zadawane pytania
Jaka jest różnica między Adobe Analytics Reporting API 1.4 a 2.0?
API 2.0 to nowoczesne API ery Workspace, wypuszczone w 2017 i teraz domyślne. API 1.4 to legacy'owe API SOAP/REST z czasów Omniture. Oba wciąż działają, ale 2.0 ma wszystkie nowe koncepcje Workspace (freeform tables, attribution IQ, anomaly detection). Nie buduj nowych integracji na 1.4. Jeśli dziedziczysz legacy'ową integrację, planuj migrację.
Czy potrzebuję osobnej licencji Adobe Analytics na API?
Nie. Dostęp do API jest w cenie każdej licencji Adobe Analytics. Możesz potrzebować konkretnych uprawnień produktu dla service accounta, ale nie ma dodatkowego kosztu za sam dostęp do API.
Jak autoryzuję się do Adobe Analytics API dziś?
OAuth Server-to-Server przez Adobe Developer Console. Stwórz Project na console.adobe.io, dodaj Adobe Analytics API, wygeneruj credentiale OAuth Server-to-Server i wymień je na 24-godzinny access token pod ims-na1.adobelogin.com/ims/token/v3. Autoryzacja JWT Service Account została wycofana 1 stycznia 2025.
Jakie są limity Adobe Analytics API?
12 requestów na sekundę na integrację, z limitem 60 równoległych requestów. Większość zespołów ma wąskie gardło w czasie wykonania raportu (zapytania idące na backend Adobe), nie w samym limicie rate.
Czy mogę użyć Adobe Analytics API do pobrania surowych danych hit-level?
Nie, API zwraca zagregowane raporty, ekwiwalent tego, co widzisz w Workspace. Do surowego clickstream potrzebujesz Data Feeds albo source connections Customer Journey Analytics.
Jaki jest najlepszy klient Python dla Adobe Analytics API?
Społecznościowo utrzymywana biblioteka aanalytics2 Juliena Picciniego to najbardziej kompletny klient Python dziś. Adobe nie ship'uje oficjalnego SDK Python. aanalytics2 obsługuje autoryzację, paginację, zarządzanie segmentami i calculated metrics oraz dziwactwa definicji raportów Reporting API 2.0.
Podsumowanie
Adobe Analytics API to odpowiedź, kiedy Workspace i scheduled reports nie wystarczają. Trzy workloady, w których zwraca się już przy pierwszym projekcie: dzienny pipeline do hurtowni danych, masowa migracja segmentów między suite i monitoring driftu konfiguracji. Jeśli Twoje raportowanie mieści się w Workspace, zostań tam. Jeśli Twój zespół nie ma developera Pythona albo Node.js, nie zaczynaj.
Zacznij od zbudowania jednego raportu w Workspace, wyeksportowania jego definicji JSON i uruchomienia jej przez API przez Postmana albo curla. Kiedy zobaczysz kształt odpowiedzi, rozumiesz 80% tego, co to API robi. Reszta to paginacja, segmenty i schedule management.
Zastanawiasz się, czy Adobe Analytics API pasuje do Twojego stacku? Napisz do mnie po zescope'owaną ocenę. Przegląd Twojego obecnego setupu raportowego, identyfikacja, czy wąskie gardło to faktycznie problem API, i realny estymat inżynieryjny. Bez slajdów sprzedażowych, bez upsellu.
Potrzebujesz szczerej oceny Adobe Analytics API?
Przegladam setupy raportowe Adobe Analytics i scopuje prace API, ktore faktycznie rozwiazuja waskie gardlo. Bez slajdow, bez upsellu.
Zobacz moje uslugiPotrzebujesz pomocy? Napisz do mnie
Masz pytanie dotyczące analityki? Wypełnij formularz, zwykle odpowiadam w ciągu 24 godzin.
