How Jumppz uses the Google Ads API
Jumppz uses the Google Ads API for internal, read-only reporting and analysis of advertising accounts managed under our own manager account. It retrieves campaign, search-term, spend, and conversion data to identify wasted ad spend and produce cost-saving recommendations that a human reviews. Jumppz makes no changes to any Google Ads account — every account change is made by the account's own operators inside Google Ads. Access is authorized via OAuth by the account owner, and credentials are stored encrypted.
The sections below expand on that summary. They add detail; they do not change it.
What the integration does
Jumppz reads campaign, search-term, spend, and conversion data for the advertising accounts connected to it, at daily granularity, and stores it so performance can be compared over time.
It analyzes search terms for wasted spend in four categories: terms drawing job-seekers rather than customers; consumer searches reaching a business that serves other businesses; searches for services the business does not offer; and spend producing no measurable outcome. Terms below a minimum activity threshold are ignored, so small samples are not over-read.
Each resulting recommendation carries a confidence level. That confidence is capped when an account's conversion tracking looks unreliable, because flagging waste on broken tracking is noise rather than insight. Every recommendation is presented to a person to review, accept, or reject.
What the integration does not do
Jumppz makes no changes to any Google Ads account. Specifically, it does not create, pause, edit, enable, or remove campaigns, ad groups, ads, keywords, negative keywords, audiences, budgets, or bids. It does not upload conversions or offline user data. It does not apply a recommendation automatically, on a schedule, or on a human's behalf.
Every change to a Google Ads account is made by that account's own operators, by hand, inside Google Ads. A recommendation produced by Jumppz is information for that person — it has no path to execution through our software.
How read-only is enforced
The Google Ads OAuth scope cannot express read-only, so we enforce it in our own code rather than relying on scope alone.
A tripwire script runs as the first step of every build. It scans our Google Ads modules — with comments stripped, so prose may discuss mutation but code may not contain it — for any mutating API surface: a :mutate endpoint, a Mutate request type, a conversion upload, an offline user-data job, or a remove operation. If any is found, the build fails and nothing deploys.
Widening that check requires amending a written architecture decision recorded in our repository. Read-only is therefore a property of our build pipeline, not a policy someone has to remember to follow.
Access, credentials, and data handling
Access is authorized via OAuth by the account owner, who can revoke it at any time in their Google account. Refresh and access tokens are encrypted at rest (AES-256-GCM) and are used only to make these read-only API calls. Disconnecting the integration deletes the stored credentials.
Google Ads data retrieved through the API is used solely to show that business its own advertising performance and to produce the cost-saving recommendations described above. It is never used for advertising targeting, never used to train AI or machine-learning models, never sold or rented, and never shared between businesses — each business sees only its own data.
Jumppz's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Full detail is in our privacy policy.
Read-only by architecture — enforced by a build-failing tripwire
Questions about this integration, or a request to revoke access, go to kenpuhl@tpfswarehouse.com.