WooCommerce Conversion Tracking for Google & Meta 2026

For WooCommerce merchants running Google Ads in 2026, the tracking situation is paradoxically both easier and harder than on Shopify or BigCommerce. Easier because the WordPress ecosystem ships dozens of dedicated tracking plugins, each with WooCommerce-specific event mapping out of the box. Harder because that abundance creates the most common WooCommerce-specific failure: running 2-3 overlapping tracking solutions simultaneously, all firing the same conversion event with slightly different transaction_id formats, and getting double-counted reported conversions for months before anyone notices.

This guide walks through the WooCommerce tracking landscape in 2026: the plugin choices (Conversios, PixelYourSite, FunnelKit, the native Google Listings & Ads integration, plus GTM4WP for fully custom setups), when server-side tracking via Stape becomes worth the setup cost, how Enhanced Conversions and Meta Conversions API integrate with WooCommerce specifically, and the WooCommerce-specific pitfalls around product variations, refunds, and double-counting that don't show up the same way on other platforms. The audience is WooCommerce merchants, WordPress developers, and the agencies supporting them who already understand the basics of Google Tag Manager and Google Ads conversions.

Why WooCommerce conversion tracking breaks at scale in 2026

Four forces converge in 2026 to make WooCommerce conversion tracking specifically more fragile than equivalent tracking on Shopify or BigCommerce.

1. The plugin proliferation problem. WordPress's open architecture means dozens of plugins offer tracking features, and most stores accumulate them over time without auditing what's redundant. A typical mid-sized WooCommerce store has: the native Google Listings & Ads plugin firing Google Ads conversion, Conversios firing GA4 ecommerce, PixelYourSite firing Meta pixel, and a custom GTM container the developer set up two years ago that's still injecting tags. All four fire on every purchase. Without explicit audit and consolidation, the store is double or triple-counting conversions across multiple destinations.

2. WordPress hosting performance variability. WooCommerce typically runs on shared hosting, managed WordPress hosting (WP Engine, Kinsta), or self-managed VPS. Page load times vary 2-5x across these tiers. Slow page loads correlate strongly with pixel loss — a page that takes 6 seconds to fully load loses 20-35% of pixel events to users who close the tab before completion. Shopify and BigCommerce run on consistent fast infrastructure; WooCommerce performance is whatever your hosting provides. This means client-side tracking is structurally less reliable on WooCommerce than on hosted platforms.

3. The variation product complexity. WooCommerce treats product variations (size, color, variant) as child products with their own IDs. The default item_id mapping in most plugins uses the parent product ID, but Google Merchant Center feeds typically use the variation ID at the offer level. This mismatch breaks variant-level attribution in Smart Bidding — Google can't match the conversion to the specific offer Smart Bidding optimized toward. We've seen WooCommerce stores with 40-60% lower variant-level match rates than Shopify equivalents, purely because of this default plugin behavior.

4. Custom checkout flows from page builders. Plugins like FunnelKit, CartFlows, Elementor Pro, and Divi Builder allow merchants to replace the default WooCommerce checkout with a custom flow. These custom flows often break the standard WooCommerce hooks tracking plugins rely on — the purchase event fires on a different page than the plugin expects, transaction_id has a different format, or the order data isn't available where the plugin looks for it. Each custom checkout requires testing the tracking integration explicitly; most merchants skip this and discover silent breakage weeks later.

The cumulative effect: a WooCommerce store running stock tracking in 2026 typically has 20-40% under-reporting from pixel loss combined with 30-100% over-reporting from duplicate firing — net inaccuracy of 10-60% in either direction depending on which mode dominates. Server-side tracking with proper deduplication is the durable fix.

The WordPress plugin landscape: Conversios, FunnelKit, PixelYourSite

The five tracking-relevant plugins in the WooCommerce ecosystem in 2026:

Conversios (formerly EnhancedEcom): specialized in GA4 + Google Ads ecommerce tracking with deep variant-level mapping, Enhanced Conversions wiring, and Consent Mode v2 support out of the box. Pricing €120-300/year. Strengths: best-in-class for Google ecosystem tracking, including dynamic remarketing parameters and PMax-friendly item_id formatting. Weaknesses: Meta tracking is secondary feature, no native server-side, custom event support requires Pro tier.

PixelYourSite (Pro): focused primarily on Meta pixel + Google tag deployment with strong support for Meta Conversions API, custom audience triggers, and dynamic remarketing on Meta. Pricing €100-200/year. Strengths: deep Meta ecosystem integration, includes free Meta CAPI relay via their service. Weaknesses: Google Ads support is functional but not as polished as Conversios, no native server-side via your own subdomain.

FunnelKit Funnel Builder: a checkout replacement plugin that ships with built-in tracking. Pricing €250-500/year. The real value is the checkout flow optimization (one-page checkout, order bumps, upsells), not the tracking layer. If you're replacing the default WooCommerce checkout for conversion-rate reasons, the included tracking is convenient. If you're just looking for tracking, FunnelKit is overkill.

Native Google Listings & Ads (official WooCommerce/Google integration): free, ships with WooCommerce, handles Merchant Center feed sync plus basic Google Ads conversion tracking. Strengths: zero-cost, official, well-maintained, Enhanced Conversions out of the box. Weaknesses: limited customization (single-currency, single-store, vanilla checkout assumed), no Meta tracking, no server-side via your own subdomain.

GTM4WP: free WordPress plugin that injects GTM container code and pushes WooCommerce events to the dataLayer in the GA4 ecommerce schema. The "DIY" path — most flexible, requires the most setup work, but produces the cleanest underlying data layer. Strengths: free, works with any GTM destination tag including custom ones, server-side ready when paired with sGTM. Weaknesses: requires GTM knowledge, needs custom configuration for non-standard checkout flows.

The realistic recommendation for most WooCommerce stores in 2026:

• Below €5k/month Google Ads spend: native Google Listings & Ads + PixelYourSite for Meta
• €5k-30k/month: Conversios or PixelYourSite Pro + Stape sGTM for server-side
• Above €30k/month or custom needs: GTM4WP + Stape sGTM with custom dataLayer

Don't run more than one Google Ads tracking plugin simultaneously — pick one and disable the others' Google Ads firing. Meta + Google can coexist via separate plugins because they have distinct destinations, but each destination needs exactly one source of truth.

Architecture: WooCommerce events → GTM → Google Ads + Meta

The cleanest architecture for a serious WooCommerce store in 2026 has three layers:

Layer 1: Event source. GTM4WP plugin reads WooCommerce hooks (woocommerce_add_to_cart, woocommerce_checkout_order_processed, woocommerce_thankyou) and pushes structured events to window.dataLayer in the GA4 ecommerce schema:

// Example dataLayer push on purchase (auto-generated by GTM4WP)
window.dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "12345",
    value: 89.99,
    currency: "USD",
    coupon: "SUMMER20",
    items: [
      {
        item_id: "prod-123-variant-456", // variation ID, not parent ID
        item_name: "Blue T-Shirt - Large",
        price: 29.99,
        quantity: 3,
        item_brand: "YourBrand",
        item_category: "T-Shirts",
      },
    ],
  },
  user_data: {
    email_address: "customer@example.com", // for Enhanced Conversions
    phone_number: "+14155551234",
  },
});

Layer 2: GTM (web) + sGTM (server). The web GTM container reads the dataLayer events and routes them to the server GTM container via the GA4 client. The server container then routes events to destinations: Google Ads conversion (with Enhanced Conversions), Meta Conversions API, optional secondary destinations (Pinterest API, TikTok Events API, etc.).

Layer 3: Destinations. Google Ads receives the conversion via the server container's Google Ads tag with conversion ID, label, transaction_id, value, currency, items array, and user_data block for Enhanced Conversions. Meta receives the event via the Meta Conversions API with event_id for deduplication against the browser-side pixel.

A typical event lifecycle for a WooCommerce purchase:

1. Customer reaches WooCommerce thank-you page (order-received).
2. GTM4WP hooks into woocommerce_thankyou and pushes the purchase event to dataLayer with transaction_id, value, currency, items array including variation IDs, and user_data block.
3. GTM web container reads the dataLayer event, fires the GA4 configuration tag with transport_url pointing to sgtm.yourstore.com.
4. sGTM container receives the event, routes to: GA4 destination, Google Ads conversion tag (firing UploadClickConversions equivalent), Meta CAPI tag.
5. Meta browser-side pixel also fires (if installed) with the same event_id — Meta deduplicates based on event_id within a 7-day window.
6. WooCommerce's order-received page also POSTs to an optional webhook (configured via Stape's webhook ingestion endpoint) as a server-to-server backup if the browser closes before page load.

This architecture solves the double-counting problem (one source of truth, the dataLayer), the variation_id problem (correct IDs at the source), and the pixel-loss problem (server-side delivery + webhook backup). For deeper background on the server-side rationale, see server-side tracking GTM 2026.

Server-side tracking via Stape for WooCommerce

For WooCommerce stores above €5-10k/month in Google Ads spend, server-side tracking via Stape becomes worth the setup investment. Stape is the dominant managed sGTM host, with WooCommerce-specific recipes and pre-built templates.

Setup steps:

1. Create sGTM container in Google Tag Manager. Go to tagmanager.google.com, create a new Server container. Copy the container configuration string.

2. Provision Stape and DNS. Sign up at stape.io, create a new container, paste the config. Stape provides a CNAME target. Add sgtm.yourstore.com → lb.stape.io to your DNS. Wait 30 min for propagation and SSL provisioning.

3. Configure the web GTM container. In your existing web GTM container, update the GA4 configuration tag's transport_url field to https://sgtm.yourstore.com. This routes all GA4 events through the server container.

4. Add Google Ads conversion tag in sGTM. In the server container, create a new tag of type "Google Ads Conversion Tracking." Enter conversion ID (AW-XXX format) and conversion label. Set trigger to fire on the GA4 purchase event. Map value and currency to event parameters.

5. Configure Enhanced Conversions in the server-side Google Ads tag. Expand "User-provided data" section, enable Enhanced Conversions, map fields: email_address to {{event.user_data.email_address}}, phone_number to {{event.user_data.phone_number}}, etc. Hashing is automatic — don't hash on the source side.

6. Add Meta Conversions API tag in sGTM. Use Stape's Meta Conversions API tag template. Enter Meta pixel ID and CAPI access token. Map standard event fields including event_id (set to transaction_id) for deduplication with browser pixel.

7. Test purchase end-to-end. Place a test purchase. In sGTM preview mode, verify the purchase event arrives with correct parameters. In Tag Assistant, verify Google Ads conversion fired and the response was 200. In Meta Events Manager, verify the event shows up with the deduplication indicator.

Stape-specific WooCommerce features: Stape ships pre-built templates for WooCommerce-specific events (subscriptions, refunds via WooCommerce webhooks). Their template gallery includes a "WooCommerce sGTM Recipe" that pre-configures the standard event flow — useful as a starting point even if you customize from there.

Cost: Stape Cloud plan starts at $20/month for 10M requests, scales to $200/month for high-volume stores. For most WooCommerce stores doing €10k-200k/month in Google Ads spend, Stape costs €240-480/year — well below the cost of the lost conversion signal under client-side-only tracking.

Enhanced Conversions for Google Ads on WordPress

Enhanced Conversions add hashed first-party identifiers (email, phone, name, address) to each Google Ads conversion event. Google matches these to logged-in user accounts on Google's side, recovering attribution for users whose gclid cookie was lost or never set.

On WooCommerce, every order has structured customer data: email is always present, phone is usually present, billing address is always present. The data is readily available — the challenge is mapping it into the conversion event correctly.

Implementation steps:

1. Verify customer data is in the dataLayer. GTM4WP and most plugins push user_data on the purchase event automatically. If using a custom setup, ensure your woocommerce_thankyou hook includes:

add_action('woocommerce_thankyou', 'push_enhanced_conversions_data');
function push_enhanced_conversions_data($order_id) {
    $order = wc_get_order($order_id);
    $user_data = [
        'email_address' => $order->get_billing_email(),
        'phone_number' => format_phone_e164($order->get_billing_phone()),
        'address' => [
            'first_name' => $order->get_billing_first_name(),
            'last_name' => $order->get_billing_last_name(),
            'street' => $order->get_billing_address_1(),
            'city' => $order->get_billing_city(),
            'region' => $order->get_billing_state(),
            'postal_code' => $order->get_billing_postcode(),
            'country' => $order->get_billing_country(),
        ],
    ];
    ?>
    <script>
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
        event: 'enhanced_conversion_data',
        user_data: <?php echo json_encode($user_data); ?>,
    });
    </script>
    <?php
}

2. Configure the Google Ads tag in sGTM. Expand the User-provided data section, enable Enhanced Conversions for Web, map each field to its corresponding dataLayer variable.

3. Test match rate after go-live. In Google Ads > Tools > Conversions > [conversion action] > Diagnostics, check the Enhanced Conversions match rate. Healthy stores see 60-80% match rates within 7 days of go-live. Below 50% indicates a problem — usually a phone format issue (must be E.164: +1XXXXXXXXXX) or accidental client-side hashing (hash on server-side only).

WooCommerce-specific gotchas:

• Phone format: WooCommerce stores billing phone as user-entered, which may be "(415) 555-1234" or "415-555-1234". Convert to E.164 in PHP before pushing to dataLayer.
• Email normalization: WooCommerce typically stores emails as user-entered. Lowercase and trim in PHP before pushing (the sGTM tag template does this automatically if you pass the raw value).
• Multi-language stores using WPML or Polylang: customer data may live in language-specific tables. Ensure you're reading from the canonical order, not a translation.

For a full Enhanced Conversions deep-dive including diagnostic interpretation, see Enhanced Conversions Google Ads setup guide.

Meta Conversions API (CAPI) for WooCommerce

Meta's Conversions API is the server-side equivalent of the Meta browser pixel. For WooCommerce, the canonical setup runs both: the browser-side pixel for client context (user agent, IP, fbp cookie) and CAPI for server-side reliability. The two events deduplicate via a shared event_id.

CAPI setup steps:

1. Generate CAPI access token in Meta Events Manager. Events Manager > your pixel > Settings > Conversions API > Generate Access Token. Save it to your secrets vault.

2. Add Meta CAPI tag in sGTM. Use the Meta Conversions API tag template (from GTM template gallery or Stape's library). Enter pixel ID and access token.

3. Map event parameters:

   • event_name: 'Purchase' (Meta's standard event taxonomy)
   • event_time: {{event.event_time}} or current timestamp
   • event_id: {{event.transaction_id}} — this is the deduplication key
   • user_data: hashed email, phone, fbp (Facebook browser ID cookie), fbc (Facebook click ID)
   • custom_data: value, currency, content_ids (array of variation IDs), content_type='product'

4. Verify deduplication. In Meta Events Manager > Overview > Events Received, look for the "Server" and "Browser" event counts. They should be roughly equal (within 5-10%); deduplication should show in the "Deduplicated" column. If server count is double the browser count, the event_id is mismatched.

WooCommerce-specific CAPI considerations:

• fbp cookie: set by the browser pixel on first page load. Read it server-side via PHP in the woocommerce_thankyou hook and pass to the dataLayer. The fbp is essential for Meta's matching algorithm.
• fbc cookie: set when the user arrives via a Meta ad with click ID. Same handling as fbp.
• Test events: Meta provides a Test Events panel in Events Manager. Use it during setup to verify CAPI events arrive with correct parameters before going live.

The migration to CAPI + browser pixel dual-tracking on WooCommerce typically lifts Meta-reported conversions by 15-30% — same magnitude as the Google Ads sGTM lift, for the same underlying reasons (recovered signal from blockers and ITP).

CAPI event quality scoring: Meta scores each CAPI event quality (in Events Manager > Diagnostics) based on how many matching parameters you pass. The score ranges 0-10. Bare events with just email and value typically score 5-7. Full events with email, phone, fbp, fbc, name, city, address, IP, and user agent score 8-10. Higher scores improve Meta's matching to user profiles, which in turn improves both reported conversion volume and Advantage+ campaign optimization. For WooCommerce, pushing all available customer fields (which the order object already has) lifts most stores from a quality score of 5-6 to 8-9 without additional data collection — you're just passing data you already have.

Subscription products and Meta CAPI: WooCommerce Subscriptions renewal events should fire as Subscribe events (Meta's standard event), not Purchase events. The distinction lets Meta optimize differently for subscription acquisition vs. one-time purchases. If you're running both Subscribe and Purchase events through the same Meta pixel, configure two distinct events in the Conversions API tag, one firing on initial purchase (Purchase event) and one firing on renewals (Subscribe event) — with the subscription product subset routed to Subscribe.

Common pitfalls: variant_id, refunds, double-counting

Five WooCommerce-specific pitfalls account for the majority of tracking failures we see in audits.

Pitfall 1: variant_id mismatched between conversion event and Merchant Center feed. WooCommerce variations have their own IDs separate from parent products. Default plugin behavior often sends the parent product ID as item_id, but Google Merchant Center feeds typically list the variation as the offer. The mismatch breaks variant-level Smart Bidding optimization. Fix: ensure item_id in the purchase event is the variation ID (get_variation_id() in PHP), not the parent product ID. Check Merchant Center > Products > Diagnostics for "Conversions matched" — should be above 90%.

Pitfall 2: Double-counting from multiple tracking plugins. Most common WooCommerce-specific failure. A merchant installs Conversios (Google), then adds PixelYourSite (Meta), and the native Google Listings & Ads plugin is still active from the initial WooCommerce setup. All three fire Google Ads conversions. Fix: audit every plugin's tracking surface, pick one source of truth per destination, disable the others' destination firing in the plugin settings.

Pitfall 3: Refunds not propagated. WooCommerce refunds fire the woocommerce_order_refunded action, but most plugins don't hook into it for Google Ads adjustments. The Google Ads conversion remains counted, reported revenue inflates, Smart Bidding optimizes against stale numbers. Fix: configure a hook on woocommerce_order_refunded that POSTs to sGTM (or directly to Google Ads UploadConversionAdjustments) with the GCLID, original timestamp, and RETRACT/RESTATE.

Pitfall 4: Test orders firing real conversions. WooCommerce test gateways (Stripe test mode, PayPal sandbox, WooCommerce Manual gateway) fire the same hooks as production gateways. Test orders generate real Google Ads conversion uploads. Fix: in the sGTM container or plugin settings, filter out orders with test-mode payment methods. Most plugins have a checkbox for this; if using custom GTM, add a transformation that checks the payment_method field.

Pitfall 5: Custom checkout flows breaking standard hooks. FunnelKit, CartFlows, Elementor Pro custom checkouts may not fire woocommerce_thankyou on the standard thank-you page. The purchase event fires (or doesn't fire) on a different page than the plugin expects. Fix: test the tracking integration explicitly after installing any checkout-replacement plugin. Use Tag Assistant and verify the event fires with the correct transaction_id at the right step.

Pitfall 6: Currency formatting errors in multi-currency setups. WooCommerce stores using WPML's currency switcher or WooCommerce Multi-currency may expose values in the customer's selected currency while the order is stored in the base currency. The plugin may send the wrong currency code in the conversion event. Fix: explicitly read both order_total and order_currency from the canonical order object, not from session state.

Pitfall 7: Subscription renewals counted as new purchases. WooCommerce Subscriptions fires woocommerce_thankyou on every renewal (each renewal creates a new "order"). Most plugins don't distinguish initial purchase from renewal, sending both as the same Google Ads conversion. Smart Bidding sees inflated conversion volume from recurring revenue. Fix: in the conversion event, check $order->get_meta('_subscription_renewal') and route renewals to a separate conversion action ("Subscription Renewal") that's NOT included in Smart Bidding optimization. Initial purchases remain the optimization signal; renewals are tracked separately for reporting.

Pitfall 8: Caching plugins serving stale tracking code. WordPress caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) cache the HTML output of pages including tracking scripts. When you update a tracking plugin or GTM config, the cached HTML still serves the old tracking code for hours or days depending on cache lifetime. The result: a configuration change that should fix tracking continues to ship the broken version. Fix: clear all caches (page cache, object cache, CDN cache) after any tracking change. For server-side tracking, the issue is reduced but not eliminated — page-cached dataLayer pushes can still serve stale data. Test cached pages explicitly after any tracking update by hard-refreshing in incognito mode.

Pitfall 9: Multi-store WooCommerce networks (WordPress Multisite) firing wrong events. Stores running WordPress Multisite with multiple WooCommerce installations under one network can accidentally fire events from one store to another store's Google Ads account. The shared codebase makes it easy for a network-activated plugin to inherit the wrong conversion ID. Fix: explicitly set conversion IDs at the site level, not network-wide. Run Tag Assistant on each store individually to verify it's firing to the correct Google Ads account. This audit is essential after any multi-site plugin update.

Pitfall 10: Page builders injecting their own tracking code. Page builders like Elementor Pro, Divi Builder, Beaver Builder, and Brizy sometimes inject their own tracking integrations (Google Analytics, Meta Pixel) at the page level, separate from the site-wide GTM/plugin setup. The page-level scripts fire alongside the site-level scripts, creating yet another duplicate firing source. Fix: in each page builder's settings, disable any built-in analytics or pixel integrations. Rely on the GTM/plugin layer as the single source of truth.

Most of these pitfalls don't show up in Tag Assistant testing — they only surface when you reconcile a full month of WooCommerce orders against Google Ads conversions and find the totals don't match. Schedule the reconciliation at days 30, 60, and 90 post-migration as a recurring check.

30-day implementation plan with rollout checkpoints

The HowTo schema above gives the day-by-day; strategic framing for the 30-day rollout:

Week 1 — Audit and design (Days 1-7). Document every currently-firing tracking plugin. Run Tag Assistant to identify all Google Ads conversion sources currently active. Export 30 days of WooCommerce orders and compare to Google Ads reported conversions — the gap is your signal loss + duplicate inflation. Pick your target architecture (plugin path vs GTM4WP + sGTM path) based on store size. Provision Stape if going server-side.

Week 2 — Implementation (Days 8-15). Install or configure your chosen plugin/GTM setup. Configure dataLayer to push correct events with variation IDs and user_data. Build the sGTM container with Google Ads conversion tag, Meta CAPI tag, and GA4 client. Run end-to-end test purchases and validate every layer (Tag Assistant, Network tab, Google Ads diagnostics, Meta Events Manager test events).

Week 3 — Hardening (Days 16-22). Wire Enhanced Conversions for Google Ads. Wire Meta CAPI with proper event_id deduplication. Add refund handling (woocommerce_order_refunded → adjustment endpoint). Stand up WooCommerce-vs-Google reconciliation dashboard. Run for 5-7 days to catch silent failures before declaring the migration complete.

Week 4 — Cutover and tuning (Days 23-30). Disable redundant tracking plugins or surfaces. Cut Smart Bidding over to the new conversion action if you're using a separate action for sGTM-imported conversions. Expect 14-30 days of bid volatility while Smart Bidding re-learns. Don't change target CPA during the learning period.

Rollout checkpoints:

• End of week 1: audit complete, architecture decided, Stape provisioned (if server-side)
• End of week 2: test purchases firing through entire pipeline, no errors in logs
• End of week 3: live conversions flowing, reconciliation within 5%, refunds processing
• End of week 4: redundant surfaces disabled, Smart Bidding learning, team trained

Beyond day 30: schedule quarterly tracking audits. WooCommerce stores accumulate tracking debt fast — new plugins installed for unrelated reasons may add tracking surfaces, theme updates may break dataLayer pushes, hosting migrations may break webhooks. A 1-hour quarterly check catches these before they degrade Smart Bidding for months.

Annual cost of operating a server-side WooCommerce tracking stack in 2026: Stape Cloud plan €240-720/year, plugin license (if using Conversios/PixelYourSite) €120-300/year, developer maintenance roughly 1-2 days per quarter for WordPress/WooCommerce updates that occasionally break tracking integrations. Total: €600-1,500/year all-in for a mid-sized WooCommerce store doing €20-100k/month in Google Ads spend. Compare this to the typical 18-30% under-reporting under client-side-only tracking, which on a €30k/month account represents €5,400-9,000/month of conversion signal Smart Bidding never sees — payback on the investment is typically under 60 days.

Hiring vs DIY: most WooCommerce merchants either underinvest in tracking (leaving the default plugin and never auditing) or overinvest (hiring a tracking specialist for €5-15k who builds an over-engineered stack that's hard to maintain). The right middle path for stores below €100k/month in spend is a one-time engagement (€800-2,500) with a tracking-focused freelancer to set up the architecture, then in-house operation by your existing developer or operations person. For stores above €100k/month, a permanent partner (agency or fractional CRO/RevOps) maintaining tracking as part of broader optimization work is the durable answer.

If you want a second pair of eyes on your WooCommerce tracking before or after migration, SteerAds runs a free 14-day audit that includes a server-side tracking review and Smart Bidding signal-quality check.

For related WooCommerce + WordPress Google Ads context, see Shopify server-side tracking for Google Ads and Consent Mode v2 Google Ads RGPD.

Sources

Official and third-party sources consulted for this guide:

• woocommerce.com — Google Listings & Ads

  — Official documentation for the native WooCommerce/Google integration

• gtm4wp.com

  — GTM4WP plugin documentation, dataLayer events, hooks reference

• stape.io/blog

  — Stape's WooCommerce sGTM recipes, Meta CAPI templates, deduplication guides

• developers.facebook.com — Conversions API

  — Official Meta Conversions API reference and deduplication documentation

• support.google.com — Enhanced Conversions for Web

  — Official Google Ads documentation on Enhanced Conversions setup and match rate diagnostics

Related reading: Claude Skills for PPC Managers: 12 Real Workflows 2026 · Consent Mode v2: Conversion Modeling & Loss Recovery 2026 · Enhanced Conversions for Leads: ECLID Debug Guide 2026 · GA4 → BigQuery → Looker: Paid-Channel ROI Dashboards 2026 · Iterable → Google Ads Customer Match 2026 · Microsoft Dynamics 365 ↔ Google Ads Offline Conversions 2026

FAQ