how a call runs
what it reaches
GA4 Data + Admin APIs
server to server · straight to the platform’s API
access granted once · OAuth · scoped to this account
no browser session · no password sharing · no scraping
what you get
read-only by default · Every question is answered without touching the property. Creating an audience or changing a setting is a separate, deliberate step with its own guards, its own record and its own way back.
the narrowest read the vendor offers · An unattended run asks for the smallest permission the platform offers, and keeps nothing on disk. A scheduled report can never reach further than the report needs.
| tool | type of access | what it does | why it exists |
|---|---|---|---|
| events.query | reads only | queries any event sliced any way | the raw behavior record |
| funnels.run | reads only | walks a funnel step by step | shows exactly where buyers are lost |
| revenue.pull | reads only | pulls tracked revenue and what drove it | revenue tied to the source that brought it |
| realtime.read | reads only | confirms data is flowing right now | proof that tracking is alive before a launch |
| anomalies.scan | reads only | flags anything that moved more than it should | movement caught before the weekly report |
| audiences.create | adds new | defines a visitor segment for later targeting | a segment the advertising servers can use, defined once from real behaviour |
covers
All 24 methods of the GA4 Data API, and 50 of the 156 in the Admin API. Not covered: 106 Admin methods, most of them account administration and enterprise features the work does not use, some that need an entitlement or account mode this account does not hold, and five the vendor has retired in favour of key events.
how it operates · alone, or with the rest of the fleet
alone
funnels · revenue · anomalies from the site itself
01
you ask · “Where do mobile buyers drop off?”
02
it picks · the funnel read and the key-event read · reads only
03
comes back · step-by-step exits, mobile read against desktop
04
lands · the one step that leaks, named in plain words
with Tag Manager
GA4 can only report an event that the tag container actually sent. When a funnel step goes quiet, the Tag Manager server reads the container and shows which tag fires on which page, and what the last publish changed. A broken event is traced back to the exact tag and version, instead of being argued about from a chart. Before a release, the two are read together to prove that every tag that fires also lands as an event.
01
you ask · “Why did the checkout event stop counting on Tuesday?”
02
it picks · the key-event read in GA4, then the container read and the version history in Tag Manager · reads only
03
comes back · the day the event went quiet, and what the last publish changed on the checkout pages
04
lands · the tag and the version that broke it, named · a fix drafted for your review, not published
with Google Ads
Google Ads reports the conversions it claims. GA4 records the sessions and purchases behind them. Read together, the platform's number is checked against your own behaviour record, so over-claiming shows up as a gap instead of a success.
01
you ask · “Which campaign sends visitors who actually buy?”
02
it picks · the session and purchase reads in GA4 and the campaign-results read in Google Ads · reads only
03
comes back · purchases per campaign as the site recorded them, beside the conversions the platform claims
04
lands · the campaigns whose claims the site confirms, and the ones it does not · in plain words