Google Ads Data Processing Terms: What Advertisers and Agencies Need to Know

A practical guide to Google Ads Data Processing Terms, processor roles, consent requirements, customer data uploads, and compliance risks for advertisers and agencies.

Category: Consent Management · Author: Mikalai Sasau

This article explains how Google Ads Data Processing Terms affect advertisers and agencies when using Google Ads, Enhanced Conversions, Customer Match, Consent Mode, uploaded customer data, and related processor services.

Executive summary

As of 2 June 2026, the live Google Ads Data Processing Terms page shows Version 8.0 dated 30 May 2024. The most important threshold issue is scope: Google is a processor only for listed “Processor Services” such as Ads Data Hub, Enhanced Conversions, Google Ads Customer Match, Store sales uploads, Campaign Manager 360, Display & Video 360, Search Ads 360, Google Analytics, Tag Manager, Looker Studio and certain listed product features; core Google Ads outside those listed features remains largely in Google’s controller-controller framework. In practice, one advertiser or agency account can sit under both processor and controller terms at the same time, depending on the feature used.

For advertisers, the main burdens stay upstream: determine and document the lawful basis, provide notices and obtain consent where required, limit uploads to permitted data, respond to data-subject requests, manage deletion requests, and handle regulator or third-party breach notifications if Google reports a data incident. For agencies, the privacy burden is sharper when the agency is acting as a processor for its client: the DPT requires ongoing controller authorization, notice pass-through to the client-controller, and a clean written chain of instructions and subcontracting authority.

Google gives meaningful processor-side commitments: documented security measures, ISO 27001, prompt incident notice, a 180-day deletion backstop, contractual flow-down to subprocessors, full liability for subprocessor acts/omissions, and transfer mechanisms built around adequacy, DPF and SCCs. But the DPT is not the whole commercial bargain: liability largely follows the underlying Google Ads agreement, and Google’s own terms finder says the applicable commercial terms vary by product, billing country, currency, account type and payment method.

The biggest practical risks are role confusion, sloppy agency authorization, consent gaps in the EEA/UK/Switzerland, assuming California “service provider” status where Restricted Data Processing no longer covers cross-context behavioral advertising, missing the 30-day/90-day notice windows for subprocessors or terms changes, and overlooking the fact that integrated “Additional Products” fall outside the DPT.

Google Ads Processor Terms

Scope and role allocation

The DPT applies only if the parties have agreed to it and only for the Processor Services in scope of the agreement. Under Section 5.1.1 Processor and Controller Responsibilities, Google is the processor and the customer is the controller or processor “as applicable.” Under Section 14.2 No Effect on Controller Terms, the DPT does not disturb separate controller-controller terms for other services. That means a brand using Customer Match or Enhanced Conversions may be in a controller→processor relationship for those features while still being in a controller→controller relationship with Google for broader Google Ads activity. Agencies should therefore build a feature-by-feature data map, not a single account-level assumption. Key source links: Section 4.1 Application, Section 5.1.1, Section 14.2, Service Information, Google’s GDPR overview for Ads products.

In the processor-service flow, the decisive legal step is the customer’s instruction to Google. Under Section 5.2 Customer’s Instructions, those instructions arise from the agreement, the product settings/functionality used, and any additional written instructions Google acknowledges. Under Section 5.4 Additional Products, if the customer plugs in an integrated Google or third-party “Additional Product,” the DPT does not apply to the personal-data processing for that additional product. That carve-out is one of the most important risk points for both advertisers and agencies.

Advertisers vs agencies: key obligations

The table below synthesizes the principal duties and operational actions from the DPT, the European and U.S. state appendices, Google’s customer-data and consent materials, and Google’s published Ads terms materials.

Topic	Advertisers	Agencies
Typical role	Usually the controller for their own CRM, website, app, lead and offline conversion data sent into Processor Services.	Often a processor/service provider for the advertiser-client; if the agency is the Google customer, DPT Section 5.1.2 adds extra duties.
Core obligation	Choose lawful basis, give notice, obtain consent where required, define instructions, limit uploads, answer DSARs, assess incidents and transfers.	Have written client authority to instruct Google, appoint Google as subprocessor, and permit Google subprocessors; follow only client instructions for client data.
Consent and notice	Meet applicable privacy-law notice rules; for EEA/UK/CH comply with EU User Consent Policy and pass consent signals to Google where relevant.	Do not set consent defaults or upload “consented” data without client authority and a defensible collection workflow; if the agency runs tags/banners, contract that responsibility clearly.
Upload governance	Upload only permitted first-party data or expressly allowed retailer-sourced data; avoid prohibited minors’ and sensitive-category data.	Verify data provenance and contractual permissions from the advertiser and any third-party uploader or retailer before uploading.
Security and incidents	Maintain a current notification email, use product controls securely, and decide whether regulators/data subjects/clients must be notified after a Google incident notice.	Forward Google incident and relevant subprocessor/SCC notices to the client-controller promptly and without undue delay, and maintain an internal escalation path.
Subprocessors and transfers	Monitor subprocessor notices; document whether adequacy, DPF or SCCs support the transfers; use audit/security docs in vendor files and DPIAs.	Pass subprocessor and SCC information through to the client, maintain evidence of the client’s authorization, and calendar the 30-day notice / 90-day objection windows.
Commercial exposure	Liability is largely whatever the underlying Google agreement says for that customer profile.	If local Google Ads terms mirror Google’s published Australia wording, the agency may need authority to bind the advertiser, may be liable if the advertiser is not bound, may owe monthly spend/performance reporting, and must expect possible direct Google disclosure to the advertiser.
Immediate priority	Build a product-by-product role map and consent matrix.	Build a client-by-client instruction, authorization, and notice-pass-through matrix.

Useful clause links: Section 5.1.1 Processor and Controller Responsibilities, Section 5.1.2 Processor Customers, Section 7 Data Security, Section 11 Subprocessors, Appendix 3A European transfer terms, Appendix 3B U.S. State Privacy Laws terms.

Data processing, transfers, security, and breach duties

The DPT does not supply your lawful basis. It says each party must comply with the data-protection obligations applicable to it and that Google processes only on the customer’s lawful instructions. So the lawful basis analysis stays with the advertiser-controller, or with the agency only insofar as the agency must verify and follow the advertiser’s documented instructions. For EEA/UK/Swiss traffic, Google’s EU User Consent Policy requires legally valid consent for cookies/local storage where legally required and for collection, sharing and use of personal data for ad personalization, plus consent records and clear revocation instructions. For U.S. state laws, Google positions Restricted Data Processing as a compliance tool, but also says customers remain responsible for their own compliance and must decide when and how to enable it.

Appendix 1 says the relevant data subjects may include individuals to whom ads are directed, visitors to relevant websites/apps, and customers or users of the customer’s products or services. The Service Information page shows that the categories of personal data vary by product: pseudonymous online identifiers such as cookie IDs, IP addresses, device IDs and client IDs for many services; precise location data for some Campaign Manager 360 and Display & Video 360 uses; partner-provided identifiers in some publisher features; and direct identifiers such as names, emails, phone numbers and addresses for Enhanced Conversions, Customer Match and Store sales uploads. Google’s Customer data policies add important upstream limits: only first-party data is generally allowed, retailer-sourced data is allowed only in limited cases with written controls, minors’ data is barred, and certain sensitive-category conversion data cannot be used for Enhanced Conversions or Store sales uploads.

Purpose is broad at the DPT level: Google processes customer personal data to provide the processor services and related technical support. But Google publishes narrower, product-specific descriptions for some tools. For example, Enhanced Conversions uses hashed first-party conversion data to improve measurement, while Customer Match says uploaded files are used only to match customers to Google accounts and to ensure policy compliance, are not used to build or enhance customer profiles, and are promptly deleted once that process is complete. That narrower product language is operationally useful, but it should be read as product-specific, not as a universal rule for every processor service.

Retention splits into at least three layers. First, under Section 6 Data Deletion, Google must delete data you have truly deleted through in-product functionality, and all remaining customer personal data at term end, as soon as reasonably practicable and within 180 days, unless law requires storage; where a service lacks deletion functionality, Google will handle reasonable deletion requests where possible and may charge a reasonable-cost fee. Second, the DPT points to Google’s general ads retention practices. Third, Google’s current Google Ads Data Retention Policy, effective 1 June 2026, retains sub-monthly reporting data for 37 months and monthly/quarterly/annual data for 11 years. Operationally, that means teams should separate “reporting data availability” from “retention of uploaded customer data,” because they are not the same thing.

On subprocessors and transfers, Google reserves wide operational flexibility. Under Section 10.1 Data Storage and Processing Facilities, Google may process customer personal data in any country where Google or its subprocessors maintain facilities, subject to transfer terms. Under Section 11 Subprocessors, customers specifically authorize the listed subprocessors and generally authorize new ones; Google must contractually limit each subprocessor to the subcontracted tasks and remains fully liable for the subprocessor’s obligations and acts/omissions. The customer’s objection right is narrow: Google gives at least 30 days’ notice before a new subprocessor starts processing, and the customer may object only by terminating the agreement within 90 days. The live Subprocessor Information page shows a broad footprint of affiliate and third-party support/IT entities across many countries, not a small closed list.

For cross-border transfers under European law, Appendix 3A is comparatively well-structured. It says Google will use adequacy where available, an “Alternative Transfer Solution” such as the Data Privacy Framework where adopted, or the relevant SCC module where needed; it also sets out the direct links for controller-to-processor SCCs, processor-to-controller SCCs, and processor-to-processor SCCs. Google’s international transfers page states that Google LLC and its wholly-owned U.S. subsidiaries are certified under the EU-U.S. and Swiss-U.S. DPFs and the UK Extension, and that Google may rely on SCCs where no alternative solution is being adopted. If the customer concludes the safeguards are not appropriate for its use case, Appendix 3A gives a right to terminate immediately.

Security commitments are stronger than the commercial remedies. Google promises technical and organizational measures, encryption at rest and in transit, resiliency and recovery measures, controlled access, confidentiality commitments, personnel security and ISO 27001. Appendix 2 also describes encryption at rest, AES-256 storage-level encryption, encrypted inter-data-center transport, TLS/HTTPS availability, intrusion detection, business continuity testing, pseudonymous-data separation controls, and subprocessor security review. But the breach language matters: Google’s incident notice is “promptly and without undue delay,” not a fixed 24-hour or 72-hour SLA, and Google expressly says incident notice is not an admission of fault; the customer remains solely responsible for any regulator, client or third-party notification obligations that apply to it. On audits, the baseline DPT is mostly documentary; explicit audit rights appear mainly in Appendix 3A for European law and Appendix 3B for U.S. state law/RDP, both subject to scoping limits, confidentiality controls, auditor suitability objections and possible fees. Google also assists with DPIAs, prior consultation and DSAR handling, but mainly through documentation, standard materials and product functionality, not bespoke legal analysis.

A particularly important U.S. nuance is California and other U.S. state compliance. Google says Restricted Data Processing limits Google’s use of data to certain business purposes and can make Google a service provider/processor for data in scope while RDP is enabled, but customers remain responsible for their own U.S. state-law compliance. Google also says that, starting 1 July 2023, it no longer acts as a California service provider for cross-context behavioral advertising in impacted functions such as customer-provided data for personalized advertising; the broader RDP page gives examples including Customer Match, Audience Partner API and some cross-context behavioral advertising uses in DV360. That is a material limitation for agencies and brands running U.S. multi-state privacy programs.

Liability and commercial allocation

The DPT itself is intentionally narrow on commercial allocation. Under Section 13 Liability, DPT liability follows the underlying agreement; for agreements governed by the law of a U.S. state, DPT liability is limited to the agreement’s monetary cap and any general indemnity carve-out in that agreement does not override the cap for data-protection indemnity claims, while for non-U.S.-state-law agreements the DPT simply inherits the agreement’s exclusions and limitations. The DPT does contain customer warranties of authority to accept the DPT and, if the customer is itself a processor, an ongoing warranty that the relevant controller authorized the instructions, Google’s appointment and Google’s subprocessors. What the DPT does not add is a standalone Google indemnity, a standalone service credit regime, or a universal global cap.

That is why advertisers and agencies need to read the commercial Google Ads terms alongside the DPT. Google’s terms finder says the relevant terms depend on product, billing country, currency, account type and payment method. In the currently published Australia version surfaced on Google’s Google Ads Terms & Conditions help page, the customer warrants it has rights in the ads/targets/destinations and that information it provides is accurate; customer indemnifies Google for third-party claims arising from ads, use or breach; implied warranties are broadly excluded; and aggregate liability is capped subject to local-law carve-outs. Because Google itself says the commercial terms vary by location and account setup, that Australia text is best treated as an official example of how the liability architecture may work, not as a universal global baseline.

This variation matters most for agencies. In the published Australia terms, if the customer advertises on behalf of a third party, the customer must be authorized to act for that advertiser and have bound the advertiser to the terms; if not, the customer is liable as if the advertiser had been bound. The same published text also requires advertiser-specific spend/performance reporting at least monthly and allows Google, on advertiser request, to share advertiser-specific information directly with that advertiser. Even where those exact terms do not apply in another billing country, they are a strong signal of the agency-side issues Google may care about commercially: authority, transparency, reporting, and direct client visibility.

Compliance steps and risk mitigation

The most useful bookmarks for implementation are: Section 5 Processing of Data, Section 6 Data Deletion, Section 7 Data Security, Section 11 Subprocessors, Appendix 3A, Service Information, Subprocessor Information, International transfers, EU User Consent Policy, Customer data policies, Restricted Data Processing, Consent mode, and Data Manager consent settings.

Role ambiguity is the primary structural risk. Build and maintain a feature-level register that classifies each Google tool as processor-service, controller-service, or mixed workflow, and record where the DPT was accepted. This matters especially where data moves from one Google product to another, because Google’s own materials split the ads stack between processor and controller regimes.
Agency authorization gaps are the main agency-side legal risk. If an agency touches client first-party data, the advertiser-agency contract should expressly authorize the agency to instruct Google, appoint Google as subprocessor, accept Google subprocessors, pass through incident/subprocessor/SCC notices, share Google’s security documentation with the client, cooperate on DSARs, and allocate who notifies regulators or individuals.
Consent failure is the most common operational risk in Europe. Align your privacy notice and consent banner with Google’s EU User Consent Policy, implement consent mode where Google tags are used, pass the newer ad_user_data and ad_personalization signals where relevant, and do not use Data Manager settings to auto-mark uploaded data as consented unless your workflow actually blocks collection until consent or otherwise supports that choice.
Data-provenance risk is higher than many teams think. Limit uploads to permitted first-party or expressly allowed retailer-sourced data, use Google-approved interfaces, prohibit minors’ data and sensitive-category measurement data, and require written compliance commitments from retailers, third-party uploaders and any agency subcontractors who touch the data before Google receives it.
Out-of-scope integrations need separate review. Any “Additional Product” or non-Google integration should get its own contract, privacy, transfer and security review because the DPT stops at the processor-service boundary; once data is shared onward, the recipient product’s terms govern.
Transfer and subprocessor governance should be calendared, not ad hoc. Archive snapshots of the processor-service list, transfer page and subprocessor page; document whether you rely on adequacy, DPF or SCCs; record any transfer-impact reasoning you need; and track the 30-day notice / 90-day objection windows for new subprocessors and DPT changes.
Prepare your “audit and incident file” in advance. Save the ISO/security documents Google makes available, identify a monitored notification email alias, route Google incident notices into a documented legal/security workflow, and use the materials Google provides for DPIAs, transfer assessments and vendor reviews. If you use Customer Match, also run a refresh routine because list memberships age out after 540 days.

The timelines worth putting straight into a compliance calendar are these: 180 days max for Google deletion after a qualifying in-product deletion; 180 days max for deletion at term end; at least 30 days’ notice before a new subprocessor processes data; 90 days to object by terminating after new-subprocessor notice; at least 30 days’ notice for relevant DPT changes unless law/regulator timing forces shorter notice; and 90 days to terminate after being informed of those changes. In the currently published Australia Google Ads terms, the customer must also provide advertiser reporting at least monthly, and Google gives 30 days’ notice of material terms changes, with urgent legal changes effective immediately.

The bottom line is simple. For advertisers, the critical job is lawful collection and disciplined governance before data ever reaches Google. For agencies, the critical job is provable client authorization and reliable notice pass-through after data reaches Google. Both should treat Google Ads privacy as a mixed-role environment, not as a one-document DPA exercise.

Methodology and sources

This article is based on a review of Google’s official Ads Data Processing Terms, Processor Services list, subprocessor information, international transfer materials, EU User Consent Policy, Customer Data Policies, Restricted Data Processing materials, Consent Mode documentation, Google Ads Data Manager consent settings, and related Google Ads terms materials. The article does not reproduce those documents; it summarizes the operational consequences for advertisers and agencies.

This article is for technical and operational information only and is not legal advice. Privacy, consent, and data protection requirements may vary by jurisdiction and by the exact Google product configuration used.