Performance Max only scales as well as the data feeding it. Most accounts we audit are running PMax with the conversion plumbing they had wired up in 2022 - third-party cookies still implicitly assumed, no Enhanced Conversions, Customer Match list either absent or stale, Consent Mode v2 either off or misconfigured. The algorithm makes the best of what it has, but the ceiling is set by the data.
This post is the full first-party data integration playbook we use to set up PMax accounts running through the 1Digital® Performance Max management practice. It's the prerequisite work, not the campaign work. Skipping it caps the campaign work's results.
What does PMax actually need from the first-party data layer?
Three categories of signal:
- Conversion events with reliable attribution. Enhanced Conversions sends hashed first-party identifiers (email, phone, name, address) with each conversion event, letting Google match server-side and recover attribution that third-party cookies used to provide.
- Audience signals built from owned data. Customer Match lists, CRM-derived segments, GA4 audiences. These power both the audience signal inputs to PMax and value-based bidding.
- Modeled conversion data where consent is denied. Consent Mode v2 feeds Google's modeling system the contextual signal it needs to estimate conversions for users who declined consent. Without it, those users disappear from your reporting and from the algorithm's inputs.
All three are necessary. Doing one without the others leaves performance on the table.
How do I set up Enhanced Conversions correctly?
Enhanced Conversions ships hashed customer data with each conversion event. The setup:
- Enable Enhanced Conversions for Web at the account level in Google Ads.
- Choose the implementation method: Google Tag Manager, gtag.js, or via the Google Ads API. Most ecommerce stacks use GTM.
- Map the user data fields. Email (required for most accounts), phone, first name, last name, address. The more fields you map, the better the match rate.
- Hash client-side or trust Google to hash server-side. If your privacy posture requires client-side hashing, do it via the standard SHA-256 in your tag template. Otherwise, let Google's tag handle it.
- Verify match rates in the Google Ads diagnostics dashboard. Below 30% match rate is a red flag - usually means the data fields are populated inconsistently.
For Shopify, BigCommerce, and Magento accounts, the native GTM templates handle most of this. For headless stacks, the conversion-event payload needs explicit attention. The audit finding for most accounts: the email field is sent on order completion but not on lead form submission, so the lead-gen side of the account runs without Enhanced Conversions even though the ecommerce side has it.
What about Customer Match?
Customer Match uploads your CRM contacts to Google Ads as a hashed audience. Used three ways:
- Audience signal input to PMax. Tells the algorithm: "Customers who look like these are valuable." Strong signal, especially for new accounts without much conversion history.
- Exclusion audience for prospecting campaigns. Don't pay to acquire someone already in your CRM.
- Inclusion audience for retargeting and loyalty campaigns. Especially useful for ecommerce email marketing accounts where Klaviyo segments mirror the lifecycle stages.
Setup:
- Export your CRM customers segmented by lifecycle stage (engaged prospect, customer, repeat customer, VIP, churned).
- Upload each segment as a separate Customer Match list. Don't merge them. The granularity is what lets you use them differentially.
- Refresh monthly, minimum. Stale lists degrade match rate and audience accuracy.
- Combine Customer Match with value-based bidding. Customer Match by predicted LTV cohort lets the algorithm prefer high-LTV-cohort lookalikes.
For B2B PPC accounts, Customer Match is also the input to Microsoft Ads' UET-driven Customer Match equivalent - see our Microsoft Ads playbook.
How does Consent Mode v2 fit in?
Consent Mode v2 is Google's framework for handling user consent denial without blinding the bidding algorithm. When a user declines consent, the tags still fire but with cookieless signals - and Google's modeling system uses those signals to estimate conversions for the un-consented slice.
The setup:
- Configure your CMP (Consent Management Platform) to surface the consent state to Google's tags. Cookiebot, OneTrust, Iubenda, custom - same pattern across them.
- Set
ad_user_dataandad_personalizationconsent signals in addition to the standardad_storageandanalytics_storage. These are required in v2; v1 only required the latter. - Verify in the Google Tag Manager preview that consent signals fire correctly across regions and user choices.
- Validate modeled conversion volume in the Google Ads conversion diagnostic. A meaningful gap between observed and modeled conversions suggests the consent signaling is misconfigured.
For EU and UK traffic, this is non-negotiable. For accounts with no EU/UK exposure, Consent Mode v2 still benefits attribution for users with restrictive browser settings (Safari ITP, brand-blocked tracking) - set it up anyway.
What about GA4 audiences as signals?
GA4 audiences can be imported into Google Ads and used as audience signals on PMax, exclusion audiences on prospecting, and inclusion audiences on retargeting. The patterns we use:
- High-intent on-site behavior segments (multiple product views, deep category scrolls) as audience signals.
- Cart abandoners as a retargeting inclusion.
- Purchasers as a prospecting exclusion.
- Loyal repeat-purchasers as a seed audience signal.
The GA4 → Google Ads link needs to be set up at the property level and re-validated whenever GA4 schema changes. Stale audience syncs are a recurring failure mode.
How does the first-party data stack power Google Shopping feed optimization?
The same Customer Match cohorts inform Shopping campaign performance - value-based bidding on Shopping uses the customer cohorts to prefer high-LTV lookalikes, and the Enhanced Conversions data flows through to attribution on Shopping clicks just like it does on Search and PMax.
Practically, the implication is that you set up the first-party data stack once at the account level and it benefits every campaign type. Don't treat it as a PMax-specific configuration.
How does this interact with Amazon and other channels?
Amazon PPC management runs on Amazon's own first-party data - the integration playbook there is a separate exercise (Amazon Attribution, brand registry, AMC). But the principle is identical: the algorithm scales as well as the data feeding it, and clean first-party signals beat third-party signals every time.
For the broader digital marketing stack, the first-party data layer is the common foundation. Email lists feed paid audiences; paid audiences feed retargeting; retargeting feeds remarketing; the customer data layer that owns the canonical state of each customer is the asset that compounds across every channel.
Key takeaways
- Performance Max scales as well as the first-party data feeding it. Most accounts cap performance by under-investing in the data layer.
- Enhanced Conversions is the table-stakes setup. Verify match rates; below 30% is a red flag.
- Customer Match lists, segmented by lifecycle stage, power PMax audience signals, prospecting exclusions, and retargeting inclusions.
- Consent Mode v2 is required for clean modeled conversions, especially for EU/UK traffic. Configure both v2 signals (
ad_user_data,ad_personalization) in addition to the v1 ones. - GA4 audiences feed PMax as both signals and exclusions. The link needs ongoing maintenance.
- The first-party data stack benefits every campaign type, not just PMax. Set it up at the account level once.
Want this set up on your account?
The first-party data stack is the unglamorous prerequisite. Done well, it lifts every campaign in the account. Done poorly, it caps performance below the algorithm's ceiling. The 1Digital® PPC services team will audit your first-party data integration and the PMax campaigns it feeds - tell us about your account to start.
