Developer disclosure · compliance

StemLabs use of Google Ads API

This document is aimed at API Center and policy reviewers. The stemlabs.site homepage likewise states, upfront, why this domain exists alongside our Ads API registration: publisher identity, Google Ads UA context, and that StemLabs Dashboard is internal-only tooling. Technical detail follows below.
StemLabs is a mobile app publisher. We integrate the official Google Ads API strictly to operate our own advertiser accounts inside internal analytics software. We do not commercialise Google Ads API access as an external product for unrelated advertisers.

Application & product identifiers

Field	Value
Organization / publisher	StemLabs (consumer mobile apps; monetised largely via IAA)
Product name	StemLabs Dashboard — internal UA & monetisation analytics
Live application URL	https://dashboard.stemlabs.site/ (HTTPS; authenticated app surface)
Public marketing domain	https://stemlabs.site/ (this disclosure & company context)
API / compliance email	[email protected]
Privacy policies	Marketing site: stemlabs.site/privacy-policy.html · Signed-in app: dashboard.stemlabs.site/privacy
End users of the Ads integration	Authorised StemLabs operators only — not arbitrary third-party advertisers

Business model & permissible scope

StemLabs earns revenue primarily from in-app advertising (IAA) on apps we build and distribute. We fund user acquisition (UA) via performance marketing; Google Ads is among our UA channels. StemLabs Dashboard is not a multi-tenant “ads SaaS”: it merges acquisition spend from Google Ads (and analogous sources we configure) with publisher monetisation aggregates so we can compute cost, revenue, profit and ROAS for assets we operate.

We promote apps and portfolios we operate, not unmanaged third-party inventories.
We respect Google’s permissible-use classes we select in API Center (reporting today; optimisation / campaign management only as declared and gated).

Product context

StemLabs distributes consumer apps where revenue is overwhelmingly IAA-backed. Typical Google Ads footprints include mobile growth surfaces (App campaigns, Performance Max with application objectives). StemLabs Dashboard (see live URL above) is the authorised interface where internal teams:

Reconcile acquisition cost with monetisation KPIs (ROAS-centric views).
Use tabular layouts (examples: profitability blend, cost detail, geography, mediation / app).
Optional CSV export where the UI exposes it.

OAuth, refresh-token storage, Ads API quotas, developer token usage, and customer routing are constrained to StemLabs-managed integration records — browsers call our backend only.

Google Ads API use case — shipped vs roadmap

Phase	What we do
In production today (Reporting)	Server-side scheduled and on-demand read traffic via Ads API — principally GAQL queries using `GoogleAdsService.SearchStream` / Search-style reporting — against customer IDs tied to StemLabs-managed OAuth authorisations. Results land in private PostgreSQL and power dashboard charts and extracts. When using a manager (MCC) relationship, HTTP header `login-customer-id` is supplied per Google Ads API guidance alongside the target `customer_id`.
Roadmap (Optimisation)	Governed, narrowly scoped mutate operations affecting our campaigns only — e.g., budget adjustments and ENABLED/PAUSED transitions — gated by approvals, auditing, quotas, and validate-only tooling where relevant. Separate job runners from ingestion.
Roadmap (Creation)	Optional constrained creation of high-leverage UA structures (e.g. App campaigns, Performance Max) with playbook-bound fields — not open-ended provisioning for unrelated advertisers.

Technical overview (architecture)

Layer	StemLabs Dashboard
Client	React SPA (HTTPS-only public origin `dashboard.stemlabs.site`).
Application API	Node.js HTTPS services — exposes REST to the UI; persists sessions & config.
Data warehouse	PostgreSQL — stores blended marketing + monetisation facts & aggregates.
Google Ads API calls	Issued solely from StemLabs-controlled server jobs using registered `developer-token`. Browser never obtains Ads developer credentials.
OAuth	We configure scopes exactly as mandated in the current Google Ads API OAuth documentation. Authorized Google identities supply refresh-token material which we store securely for server-to-server ingestion and (later) guarded mutations tied to approval flows.
Reads (examples)	GAQL across campaign hierarchy, segments such as date, geography, paired with performance metrics suited to UA reconciliations.

System architecture (detailed)

StemLabs separates operator-facing browser traffic from privileged Google Ads server jobs. The SPA never obtains developer tokens nor refresh-token material — only StemLabs backends call Google. Note: This section describes Google Ads. It is unrelated to Meta Business Manager approvals; UA from Meta flows through separate documented APIs.

flowchart TB U[["StemLabs operator office or VPN"]] --> SPA[["Dashboard SPA"]] SPA --> API[["Node.js HTTPS REST API"]] API --> PG[("PostgreSQL facts and Ads credentials rows")] J[["Reporting sync runners"]] --> PG J --> GA[["Google Ads API GAQL"]] J --> TOK[["OAuth 2 Google token endpoint"]]

Optional IP allowlisting sits at the perimeter so only StemLabs gateways load /login, /, /assets/*, and gated APIs — reviewers can still retrieve GET /privacy plus /api/health probes without dashboard login. See also dashboard access policy.

OAuth 2.0 for Google Ads access (delegation chain)

Not Meta Business Manager. Google Ads authorisation rides on the Google Account that completes OAuth consent plus that account's Ads hierarchy grants (standard / administrative access on the advertiser or manager MCC subtree). Invite flows from Meta BM do not apply here.

(1) A Google organisational user who already holds Google Ads access for the manager or advertiser accounts where StemLabs buys media (principal seats atop an MCC or linked child customers StemLabs monetises). (2) A company-controlled GCP OAuth client labelled for StemLabs Ads API tooling. (3) StemLabs backend services redeem one-time OAuth authorisation artefacts without ever embedding developer-token material inside browsers.

Delegation steps. (a) The authorised Ads user launches Google's OAuth consent for the StemLabs-labelled client with scopes enumerated in Google's current Ads OAuth guide . (b) Google returns an ephemeral authorisation reference to StemLabs tooling (setup session or scripted exchange) reachable only internally. (c) StemLabs exchanges that reference for OAuth access + offline refresh-token material that we persist beside the Ads customer_id being connected. (d) Subsequent reporting jobs authenticate with bearer material derived from the refresh token; when traversing manager accounts StemLabs transmits the requisite login-customer-id header mandated by Ads API semantics. (e) Account-level revocation inside Google Ads or Google Workspace immediately invalidates future StemLabs retries — StemLabs rotates credentials only via another explicit user approval.

sequenceDiagram autonumber participant U as AuthorisedAdsUser participant O as Google_OAuth_Consent participant B as StemLabs_backend participant A as Google_Ads_API U->>O: Opens consent for StemLabs OAuth client Ads scopes only O->>U: Displays scope disclosures from GoogleAds doc bundle U->>O: Grants access to selected Ads assets O->>B: HTTPS redirect bearer one_time_auth_code B->>O: HTTPS token exchange secured client_credentials O->>B: Access_and_refresh_token_pair Note over B: Refresh token persists server-side keyed to CID plus optional_login_customer_header loop Scheduled_GAQL_sync B->>A: Bearer plus developer-token plus login_customer_id when querying through MCC A-->>B: Streams metrics aggregates for Postgres ingestion end

Dashboard access control layers & optional IP perimeter

StemLabs deployments layer overlapping controls: (1) password-backed sessions backed by HttpOnly Secure cookies sealed with SESSION_SECRET. (2) Signed-in browsing runs only on HTTPS fronts with coarse API rate ceilings. (3) PostgreSQL hosts live on private subnets or VPC-peered interfaces without public ingress unless StemLabs infra explicitly bridges them. (4) A non-empty DASHBOARD_ALLOWED_IP_CIDRS list forces Express-level rejections for every non-matching client before HTML/JSON payloads leave the Node process (dashboard SPA, assets, guarded APIs.)

Bypass list for auditors and uptime checks remains open: GET /privacy, GET /api/health, GET /api/health/db, plus OPTIONS /api/auth/* preflights configured with CORS_ORIGINS. Behind reverse proxies StemLabs pairs TRUST_PROXY=1 (or the hop-count your terminator documents) so X-Forwarded-For feeding Express matches operators' egress ranges.

Layer	StemLabs posture
Perimeter IPs	Optional comma-separated IPv4 rules keep dashboard login plus analytics surfaces off the public Internet; StemLabs operators connect via VPN gateways whose egress IPs populate `DASHBOARD_ALLOWED_IP_CIDRS`.
Application auth	Mandatory shared secrets whenever StemLabs sets both `DASHBOARD_PASSWORD` and corresponding `SESSION_SECRET`; brute-force tempered via login rate-limit middleware.
Secrets handling	Google OAuth client secrets plus refresh-token blobs live exclusively in StemLabs Postgres rows accessible through authenticated API routes invoked by StemLabs-controlled credentials.

Data security & segregation

Topic	Details
Transport	Temporary credentials (dashboard login, bearer tokens minted mid-request) traverse TLS 1.2+ only.
At-rest storage	Marketing cost + monetisation aggregates stay inside Postgres with OS/disk protections from the hosting provider. (Customer-managed encryption hinges on infra policy — contact [email protected] if reviewers need attestation artefacts.)
Credential minimisation	StemLabs rotates refresh tokens lazily, reuses least-privilege Google Ads scope bundles, and isolates ingestion vs future mutation queues so erroneous writes cannot masquerade as reads.
Audit & anomaly control	Centralised structured logging surrounds API traffic. A future mutate executor will stamp operator references + validation snapshots per governance commitments above.
Incident response contact	Operational security escalation path documented at [email protected].

What we explicitly do not claim or offer

No unrestricted Google Ads automation marketplace for unrelated advertisers.
No resale or licensing of Google Ads API quotas as standalone commercial merchandise.
No client-directed browser calls to Ads API endpoints with developer tokens.

Dashboard UI outlines (reference mock descriptions)

Google allows mock-ups or textual descriptions — the blocks below summarise the principal UI surfaces reviewers should expect behind authentication. Operational screenshots labelled for review can additionally be emailed on request to [email protected].

1 · KPI summary strip (profit / ROAS focus)

[+------------------------------------------------------------------+ | StemLabs Dashboard · Profit blend | +-------------------------------------------------------------------+ | Cost (period) │ Revenue │ Profit │ ROAS ··· [date range picker] [CSV] +-------------------------------------------------------------------+ | Sparkline placeholders / delta vs prior strip (internal only) | +------------------------------------------------------------------+]

2 · Segment breakdown table (example: country × metrics)

[+------------------------------------------------------------------+ | Filters: Country | App | Campaign | Version | … | +-------------------------------------------------------------------+ | Country │ Spend │ Installs │ Impressions │ eCPM / ARPU blend … | | … rows sorted by profitability drivers … | +------------------------------------------------------------------+]

3 · Planned mutation governance lane (future)

[+------------------------------------------------------------------+ | Mutation queue · status PENDING_APPROVED_REJECTED · actor · notes | | Change set: CID · campaign · field diff · validate-only transcript | +------------------------------------------------------------------+]

Publishing & privacy

Public privacy notice on this marketing domain: StemLabs Privacy Policy. Policy governing the walled dashboard product: https://dashboard.stemlabs.site/privacy.

Reviewer references

Contact

API Center follow-ups, annex screenshots, or clarifications:
[email protected]