Google Ads data strength and WooCommerce: how to implement first-party data and server-side GTM

In autumn 2026 Google put first-party data at the centre of Google Ads measurement. On 10 September it announced a Data Strength Uplift metric and an expanded Data Manager (Google Ads and Commerce blog), and its Data Strength Best Practices help page now reads as a step-by-step implementation guide. The direction is clear: copy-pasting a JavaScript conversion tag into the site header is no longer enough. Under tightening privacy rules, browser restrictions such as Safari ITP and widespread ad blocking, e-commerce campaign performance now depends on first-party data quality and on measurement infrastructure that runs on the server.

For WooCommerce store owners and WordPress technical architects, this demands moving past superficial third-party plugins. A store that feeds incomplete or fragmented order data to Google pays for it: Smart Bidding loses attribution clarity and acquisition costs rise.

This guide explains what Data Strength covers, which signals Google asks for, the data engineering requirements of Enhanced Conversions, and how to deploy Google tag gateway and Server-Side Google Tag Manager (sGTM) on your own domain.

#What is Google Ads data strength and why does it dictate ad spend efficiency

Data Strength is Google’s umbrella term for the first-party measurement setup that feeds Google Ads. The help page splits it into four steps: connect your data sources, maximize your signals, activate Google AI (Smart Bidding, AI Max for Search, Demand Gen, Performance Max) and prove your ROI with incrementality experiments and the Meridian marketing mix model. It is an input for the machine learning models that bid in Performance Max, Demand Gen and Search campaigns, so gaps in the data become gaps in bidding.

Two things in Google Ads put a number on it. The new Data Strength Uplift metric “calculates the additional conversions recovered by your first-party data setup”, according to Google’s announcement. The quality ratings come from diagnostics: offline data diagnostics label imported data Excellent (at least 90% of events properly formatted), Good (roughly 70 to 90%), Needs attention (under 70%) or No recent data (nothing in the last 28 days). Enhanced Conversions have their own diagnostics report.

On a WooCommerce store, the setup Google describes comes down to four technical conditions:

1. Transaction attribute completeness: Every purchase event must transmit an accurate order value, an ISO 4217 currency code, and a unique Transaction ID to prevent double-counting.
2. First-party data match density: Supplying normalized and hashed customer email addresses, phone numbers, and physical addresses that allow Google to associate purchases with signed-in accounts.
3. Consent Mode v2 compliance: Properly transmitting ad_user_data and ad_personalization signals aligned with the user selections in your Consent Management Platform (CMP). Google’s help page does not list consent as a Data Strength step, but in the EU no identifier may be sent without it.
4. Data pipeline uptime: Eliminating gaps caused by script timeouts, third-party payment gateway redirects, or client-side network blocking.

When data is incomplete, Smart Bidding operates with missing information. It sees fewer conversions than the store records, so it values clicks on less evidence, and return on ad spend (ROAS) and cost per acquisition (CPA) move the wrong way.

#Which signals Google’s data strength guide asks advertisers to send

The “maximize your signals” step on the Data Strength Best Practices page lists the identifiers Google wants with each conversion:

• Customer data: hashed email or phone, used by Enhanced Conversions to match against Google’s signed-in data and recover unobserved conversions.
• IP address: sent with Data Manager imports. Google reports up to a 3% increase in observed conversions on Search, and over 10% on YouTube in an offline simulation.
• Transaction ID: the order or lead number that connects a front-end click to a back-end sale.
• GCLID: the click identifier that tells Google which campaign drove the sale.
• Session attributes: campaign ID, full landing page URL, session timestamp, browser and operating system.
• GBRAID and WBRAID: URL parameters that recover attribution for iOS conversions and private browsing.

Two rules follow. Google recommends passing at least 3 identifier signals per event, with GCLID and IP prioritized alongside hashed customer data, and passing all conversion events instead of a subset.

In WooCommerce most of these already exist on the order. $order->get_order_number() is the transaction ID, $order->get_customer_ip_address() holds the IP recorded at checkout, and the billing fields carry the customer data. GCLID, GBRAID and WBRAID only appear as query parameters on the landing URL, so a store that wants to upload conversions from the server has to capture them on the first page view and save them with the order.

Google backs the page with its own figures, each with a stated basis:

These are Google’s internal measurements, not independent studies. Treat them as the direction of the effect, and measure your own store before and after.

#Why traditional browser pixels lose conversions

For more than twenty years, e-commerce web analytics relied on client-side tracking executed in the customer browser. A shopper completed a purchase, a JavaScript snippet extracted values from the Document Object Model (DOM) of the thank-you page, and sent an HTTP request to third-party ad servers. In 2026, this client-side model has become deeply fragile.

#How ad blockers and Safari ITP shorten cookie lifespan

Three primary technical bottlenecks cause systematic data loss in client-side tracking architectures:

When a customer pays through an external payment gateway and fails to wait for the automatic redirect back to the thank-you screen, traditional client-side tags never trigger. The order exists in the WooCommerce database, but Google Ads remains unaware of the transaction.

#Why Smart Bidding algorithms require first-party data

Modern bidding algorithms predict the likelihood of purchase before submitting an automated bid in an ad auction. The more reliable identity points an algorithm can connect to an auction impression, the more accurately it calculates expected customer value.

Without first-party data, the model observes only an anonymous session and an isolated click. With a hashed email address, Google matches the conversion to a signed-in Google account and can attribute it to the ad interaction that preceded it (Google Ads Help). More attributed conversions give the bidding model more examples of which clicks lead to orders.

#How Enhanced Conversions work in a WooCommerce store

Enhanced Conversions supplements standard transaction tags with hashed first-party identifiers captured during checkout. Since April 2026 Enhanced Conversions for web and for leads are a single on/off setting in Google Ads, and existing users were migrated automatically.

#What customer data must be hashed with SHA-256 before transmission

Google’s Enhanced Conversions setup guide requires personal data to be normalized and hashed with hex SHA-256, and every value passed as a string:

• Email address: Remove all leading and trailing whitespace, convert all characters to lowercase, and compute the SHA-256 hash. For [email protected], the normalized input string must be [email protected]. For gmail.com and googlemail.com addresses, also remove the dots before the @.
• Phone number: Strip spaces, hyphens, and brackets. Format the number according to the international E.164 standard, 11 to 15 digits including the plus sign and country code (for example, +14155552671), then apply SHA-256.
• First and last name: Lowercase characters, trimmed whitespace, and stripped punctuation.
• Postal code and country: Postal code trimmed of excess whitespace, paired with a standard two-letter ISO 3166-1 alpha-2 country code (such as US or GB). An address match needs first name, last name, postal code and country together.

#Complete PHP code for woocommerce_thankyou and dataLayer

The code snippet below hooks into woocommerce_thankyou inside a child theme functions.php file or a dedicated site plugin. It populates a dataLayer object on the order confirmation screen with normalized SHA-256 hashes generated directly in PHP:

<?php
/**
 * Implement dataLayer for Google Ads Enhanced Conversions in WooCommerce
 */
add_action('woocommerce_thankyou', 'wppoland_inject_enhanced_conversions_datalayer', 20);

function wppoland_inject_enhanced_conversions_datalayer($order_id) {
    if (!$order_id) {
        return;
    }

    $order = wc_get_order($order_id);
    if (!$order || $order->has_status('failed')) {
        return;
    }

    // Normalize and hash customer email address
    $raw_email = strtolower(trim($order->get_billing_email()));
    // gmail.com and googlemail.com: remove dots before the @
    if (preg_match('/^([^@]+)@(gmail|googlemail)\.com$/', $raw_email, $m)) {
        $raw_email = str_replace('.', '', $m[1]) . '@' . $m[2] . '.com';
    }
    $hashed_email = hash('sha256', $raw_email);

    // Normalize and hash phone number (E.164 format)
    $raw_phone = preg_replace('/[^0-9+]/', '', $order->get_billing_phone());
    if (strpos($raw_phone, '+') !== 0 && strlen($raw_phone) === 10) {
        $raw_phone = '+1' . $raw_phone; // Default prefix for North American numbers
    }
    $hashed_phone = hash('sha256', $raw_phone);

    // Prepare name and address attributes
    $raw_first_name = strtolower(trim($order->get_billing_first_name()));
    $raw_last_name  = strtolower(trim($order->get_billing_last_name()));
    $hashed_first_name = hash('sha256', $raw_first_name);
    $hashed_last_name  = hash('sha256', $raw_last_name);

    $postal_code = trim($order->get_billing_postcode());
    $country_code = strtoupper(trim($order->get_billing_country()));

    // Collect line items
    $items = [];
    foreach ($order->get_items() as $item) {
        $product = $item->get_product();
        if ($product) {
            $items[] = [
                'item_id'   => (string) $product->get_id(),
                'item_name' => $item->get_name(),
                'price'     => (float) $order->get_item_total($item, false, false),
                'quantity'  => (int) $item->get_quantity(),
            ];
        }
    }

    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
        event: 'purchase',
        ecommerce: {
            transaction_id: '<?php echo esc_js($order->get_order_number()); ?>',
            value: <?php echo (float) $order->get_total(); ?>,
            tax: <?php echo (float) $order->get_total_tax(); ?>,
            shipping: <?php echo (float) $order->get_shipping_total(); ?>,
            currency: '<?php echo esc_js($order->get_currency()); ?>',
            items: <?php echo json_encode($items); ?>
        },
        user_data: {
            sha256_email_address: '<?php echo esc_js($hashed_email); ?>',
            sha256_phone_number: '<?php echo esc_js($hashed_phone); ?>',
            address: {
                sha256_first_name: '<?php echo esc_js($hashed_first_name); ?>',
                sha256_last_name: '<?php echo esc_js($hashed_last_name); ?>',
                postal_code: '<?php echo esc_js($postal_code); ?>',
                country: '<?php echo esc_js($country_code); ?>'
            }
        }
    });
    </script>
    <?php
}

By computing SHA-256 hashes inside server-side PHP, plain-text customer personal data never touches client-side JavaScript variables, strengthening data privacy and preventing accidental leakage.

#How to check that enhanced conversions work in WooCommerce

Google gives three checks, all in the same help article:

1. Network request on the thank-you page: place a test order, open Chrome DevTools, go to the Network tab and find the conversion request. It should carry an em parameter: an email appears as tv.1~em followed by a hash, a phone number as tv.1~pn. A prefix with no hash after it means the field was empty when the tag fired, which on WooCommerce usually points to the tag firing before the dataLayer push.
2. Diagnostics report: Google Ads shows the Enhanced Conversions diagnostics about 48 hours after implementation.
3. Impact: the effect on reported conversions becomes visible after about 30 days.

Two settings block collection silently. Data is not collected until the customer data terms are accepted in Google Ads or Google Analytics, and in a Google tag the option Allow user-provided data capabilities has to be on. When the code snippet method and automatic detection both supply data, Google says the code snippet is always prioritized.

#How to deploy Server-Side Google Tag Manager on a custom subdomain

A complete dataLayer payload inside a customer browser remains vulnerable if client-side network calls are blocked by ad-blocking tools or firewall rules. Deploying a Server-Side Google Tag Manager (sGTM) container addresses this.

#Why server-side GTM on your own domain is harder to block

Under conventional tracking setups, the browser dispatches analytics data directly to third-party endpoints like googleadservices.com. Browser ad blockers maintain comprehensive lists of these domains and terminate requests before they leave the device.

In a Server-Side GTM deployment, the tracking endpoint runs on the store’s own domain, for example a subdomain such as:

https://metrics.your-store.com

Google’s custom domain guide describes three options:

To the browser, requests to either of the first two options belong to the store’s own domain (first-party context), so domain blocklists aimed at Google endpoints do not match them. There is one caveat for the subdomain route: since Safari 14, WebKit detects third-party CNAME cloaking and caps cookies set in those responses to 7 days (WebKit blog). A subdomain that is a CNAME to a hosting provider’s domain can fall under that rule, which is one more reason to prefer the same-origin path.

The sGTM container then:

1. Receives a single unified payload from the customer browser.
2. Sanitizes the payload and strips unwanted user agent parameters.
3. Sets cookies in its HTTP response on the store’s own domain instead of through JavaScript.
4. Distributes events simultaneously to Google Ads, Meta Conversions API (CAPI), and Google Analytics 4.

#How much server-side GTM on Cloud Run costs to run

Google’s Cloud Run setup guide gives sizing figures worth reading before a store commits to sGTM:

• Each tagging server is a Cloud Run instance with 1 vCPU and 0.5 GB of memory, billed on the CPU-always-allocated model. Google estimates about 45 USD per server per month.
• Google recommends a minimum of 2 instances in production to reduce the risk of data loss during an outage.
• Autoscaling between 2 and 10 servers is expected to handle 35 to 350 requests per second, depending on the number of tags.
• The max-instances value is the worst case for what you will pay, so set it deliberately and add a billing alert.
• The preview server, which powers Tag Manager’s preview mode, is provisioned separately.
• For a global audience Google suggests deploying to multiple regions behind a load balancer.

App Engine and a manual setup on any platform are documented as alternatives. For a small WooCommerce store, two instances running all month are a fixed monthly cost to weigh against the conversions they recover.

#How offloading analytics scripts to the server speeds up page loading

Typical WooCommerce storefronts load numerous third-party tracking scripts: Google Ads, Meta Pixel, TikTok, Pinterest, and heatmapping tools. Each external script consumes JavaScript execution budget on mobile devices, degrading Core Web Vitals, particularly Interaction to Next Paint (INP).

Server-side tagging consolidates client-side scripts into a single lightweight collector tag. The browser transmits one event stream, while payload mapping, token management, and vendor API integrations run on the tagging server instead of on the visitor’s phone. Google lists “improve page performance” among the benefits of server-side tagging (Google for Developers).

#How Google tag gateway differs from server-side GTM

Google tag gateway for advertisers is the lighter option, and Google names it in the first step of the Data Strength guide. It “lets you deploy a Google tag using your own first-party infrastructure, hosted on your website’s domain” (Google for Developers). The gateway runs on a CDN, load balancer or web server you already have. It serves the Google tag and its measurement requests from your domain, but it does not process or redistribute events the way an sGTM container does.

With Cloudflare the setup happens in the Google tag itself (Google Ads Help):

1. In the Google tag settings, open Admin and select Google tag gateway.
2. Sign in to Cloudflare. The account needs the Super Administrator, Administrator or Zaraz Admin role.
3. Select the website domains to activate and click Complete setup. The domains should then show the status Active.

The gateway uses a measurement path on your domain, by default four random characters, which can be changed (for example to /metrics). Google asks you to review consent settings first, because enabling the gateway affects how the Google tag fires.

The two are complementary. Google tag gateway gets Google’s own tags onto your domain with little infrastructure. Server-side GTM adds a processing layer that can also feed Meta CAPI, GA4 and other endpoints. Google recommends completing both for the most durable tagging setup.

#How to align Consent Mode v2 with GDPR and privacy regulations

Transmitting first-party customer data within the European Union and other regulated jurisdictions requires compliance with the ePrivacy Directive and GDPR. Google Consent Mode v2 serves as the technical link between user consent selections and tag behavior. Google’s documentation is explicit that the site owner remains responsible for obtaining consent.

Consent Mode v2 works with four consent types:

// Default consent state before user interaction
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

• ad_storage: Controls cookie storage for advertising purposes.
• analytics_storage: Manages statistical and analytics cookies.
• ad_user_data: Governs whether hashed customer identifiers can be sent to Google for conversion attribution.
• ad_personalization: Determines whether user data can be leveraged for dynamic remarketing.

In basic mode, Google tags do not load until the visitor interacts with the consent banner, and nothing is sent if consent is refused. In advanced mode, tags load with denied defaults, and when a visitor rejects advertising cookies they transmit cookieless pings to Google servers. These pings carry event information without persistent identifiers, and Google uses them to model conversions once the tag meets a data collection threshold (Google for Developers).

#How to build data strength in WooCommerce step by step

Building Data Strength on a WooCommerce store works best as a fixed sequence. The flowchart below outlines the recommended path:

+-------------------------------------------------------------------+
|             DATA STRENGTH IMPLEMENTATION WORKFLOW                 |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ STEP 1: Audit purchase event parameters in dataLayer ]
                 (Verify transaction ID, value, and item array)
                                  |
                                  v
        [ STEP 2: Implement PHP SHA-256 hashing on checkout ]
               (Hash email, phone, and name directly on server)
                                  |
                                  v
       [ STEP 3: Configure Consent Mode v2 in certified CMP ]
               (Ensure ad_user_data signals update dynamically)
                                  |
                                  v
      [ STEP 4: Deploy tag gateway and Server-Side GTM ]
               (Same-origin path or subdomain, Cloud Run container)
                                  |
                                  v
         [ STEP 5: Map Enhanced Conversions inside sGTM ]
               (Pass user_data attributes to Google Ads tag)
                                  |
                                  v
       [ STEP 6: Upload orders that never reach the thank-you page ]
               (Server-side upload via Google Ads API or Data Manager)

1. Audit purchase data: Ensure your purchase event consistently outputs unique transaction IDs, gross values, tax, shipping, and currency.
2. Implement server-side hashing: Normalize user fields and generate SHA-256 hashes within PHP before publishing the data to the browser.
3. Integrate a certified CMP: Install a Consent Management Platform that supports Consent Mode v2 and dynamically updates consent parameters upon user approval.
4. Deploy tag gateway and Server-Side GTM: Serve the Google tag from your own domain and route events through a tagging server on a same-origin path or a subdomain.
5. Configure conversion tags: In the sGTM container, enable Enhanced Conversions within the Google Ads tag and map the hashed user_data attributes from incoming requests.
6. Upload missing orders from the server: For orders confirmed through asynchronous payment gateways where customers do not return to the thank-you page, use a hook on woocommerce_order_status_completed to send the conversion with its transaction ID and stored GCLID to Google Ads, through the Google Ads API or the Data Manager API.

#Implementation takeaways for e-commerce stores and PPC engineers

Raising your Google Ads Data Strength is a technical data engineering project, and its result can be checked in the account.

Implementing clean Enhanced Conversions, securing user data through SHA-256 hashing, and routing event streams through Google tag gateway and Server-Side GTM gives a store:

• Conversions that a browser-only tag misses (blocked requests, closed thank-you pages) reach Google Ads, and the Data Strength Uplift metric shows how many.
• At least 3 identifiers per order (transaction ID, hashed email, IP, GCLID where captured), which is what Google’s guide asks for.
• Fewer third-party scripts in the visitor’s browser, which helps mobile Core Web Vitals.
• A consent setup that matches Consent Mode v2 and European privacy law.

To evaluate your store architecture against European privacy and technical mandates, explore our dedicated WooCommerce EU readiness assessment.

Building a resilient, privacy-safe tracking infrastructure keeps advertising measurement working through future browser policy changes.