Your Google Ads Are Converting. You Just Can’t See It.

You spend $15,000/month on Google Ads. Your WooCommerce dashboard says you made 340 purchases last month. But Google Ads only reports 260. That gap of 80 conversions is not rounding error. It is real revenue that your ad platform cannot see, which means your bidding algorithms are working with bad data, your ROAS calculations are wrong, and you are probably killing campaigns that are actually profitable.

This is the conversion gap. And for most ecommerce stores in 2026, it is getting worse, not better.

Why Your Conversion Numbers Don’t Match

Google Ads tracks conversions using a JavaScript tag (gtag.js or a Google Tag Manager container) that fires when someone completes a purchase. That tag needs three things to work: it needs to load, it needs to fire, and it needs to connect the conversion back to the original ad click. All three of those steps are now routinely broken.

Ad blockers prevent the tag from loading

Extensions like uBlock Origin, Brave’s built-in shields, and Firefox’s Enhanced Tracking Protection block requests to Google’s tracking domains outright. The conversion tag never loads. The purchase happens. Google Ads never knows.

Browser privacy restrictions kill cookie persistence

When someone clicks your ad, Google stores a click identifier (called a GCLID) in a first-party cookie on your domain. When that person comes back three days later and buys, the conversion tag reads the GCLID from the cookie and reports the conversion back to Google Ads. But Safari’s Intelligent Tracking Prevention (ITP) now caps JavaScript-set cookies at 7 days. If the purchase happens on day 8, the cookie is gone. The conversion fires, but it cannot be attributed to the ad click.

Cross-device journeys break attribution entirely

A customer clicks your ad on their phone during lunch. That evening, they open their laptop and buy. Different browser, different device, no shared cookie. Google Ads sees an ad click with no conversion and a conversion with no ad click.

The Three Google Click Identifiers

Before getting into the fix, you need to understand the three identifiers Google uses to connect ad clicks to conversions. Most ecommerce operators only know about one of them.

GCLID is the original. When someone clicks an ad, Google appends ?gclid=abc123... to your landing page URL. This is the identifier that gets stored in cookies and used for conversion attribution. It works well when cookies persist and tracking scripts load.

GBRAID was introduced for privacy-restricted browsers. It is appended as ?gbraid=xyz789... and is designed to work within the same browser session without relying on long-lived cookies. You will see this on iOS Safari clicks.

WBRAID handles the specific case where a user clicks an ad in an iOS app (like the Google app or YouTube) and converts on your website. It bridges the app-to-web gap that Apple’s App Tracking Transparency created.

If you are only capturing GCLID, you are missing conversions from the exact users that privacy restrictions were designed to obscure: iOS users, Safari users, and users with ad blockers.

A proper conversion recovery system needs to capture and store all three.

The Fix: Server-Side HTTPS Conversion Imports

Google Ads has a feature called offline conversion imports that was originally built for businesses with offline sales (car dealerships, B2B companies). But it turns out to be the best tool available for recovering lost ecommerce conversions, because it completely bypasses the client-side tracking chain.

The concept is straightforward:

Instead of relying on a JavaScript tag to fire in the browser, you capture the click identifier (GCLID, GBRAID, or WBRAID) from the URL when someone lands on your site, store it server-side alongside your own first-party JavaScript, and then when a purchase happens, you pair the click identifier with the conversion data and make it available to Google Ads via a CSV file served over HTTPS.

Google Ads Data Manager can then pull from that CSV endpoint on a daily schedule, automatically importing any conversions it missed through the standard client-side tag.

Why this works when client-side tracking doesn’t

• Ad blockers don’t block your own domain. The click identifier capture happens via first-party JavaScript on your own domain, not a request to google-analytics.com or googleads.g.doubleclick.net. Ad blockers have no reason to block it.
• Server-side storage isn’t subject to cookie expiry. You store the click identifier in your own database. Safari can’t delete your database rows after 7 days.
• The CSV endpoint is just a URL on your site. Google Ads Data Manager fetches it like any other HTTP request. No browser restrictions apply because there is no browser involved.

The CSV Format Google Ads Expects

Google Ads is specific about the CSV format for conversion imports. Get one column name wrong and the import silently fails. Here is exactly what the file needs to look like:

Parameters:TimeZone=America/New_York
Google Click ID,Conversion Name,Conversion Time,Conversion Value,Conversion Currency
CjwKCAjw...,Purchase,2026-02-15 14:23:00,89.99,USD
EAIaIQob...,Purchase,2026-02-15 15:01:22,142.50,USD
CjwKCAjw...,Add to Cart,2026-02-15 16:44:11,0.00,USD

The first line sets the timezone. Every timestamp in the file is interpreted in this timezone. The headers must match exactly. And each row contains one conversion event with its associated click identifier.

Mapping ecommerce events to conversion actions

Most ecommerce stores track more than just purchases. Here is a practical mapping of standard GA4 ecommerce events to Google Ads conversion actions:

You do not need to import all of these. At minimum, import purchase events because those are the conversions that directly affect your ROAS and bidding. The micro-conversions (add to cart, begin checkout) are useful for audience building and funnel analysis but less critical for bid optimization.

How To Implement This — Step by Step

This is not conceptual. Here is the actual implementation, from click capture to automated Google Ads import.

1. Capture click identifiers on landing

   When a visitor lands on your site from a Google ad, the URL contains a gclid, gbraid, or wbraid parameter. Your JavaScript needs to extract this from the URL and store it somewhere persistent. localStorage works well because it survives across sessions (unlike sessionStorage) and is not subject to the same expiry rules as cookies. Store all three identifier types — you will not know which one Google appended until the visitor arrives.

2. Intercept ecommerce dataLayer events

   If you are already using Google Tag Manager with GA4 ecommerce tracking, your site pushes events like “purchase” and “add_to_cart” to the dataLayer. Instead of relying on GTM to send these to Google Ads (which ad blockers can block), intercept the dataLayer.push() calls with your own JavaScript. When a tracked event fires, package the event data with the stored click identifier and send it to your own server via your own REST API endpoint.

3. Store conversion data server-side

   Your server receives the event data (event type, conversion value, currency, transaction ID) paired with the click identifier. Store this in a database table. Include a timestamp, and keep the raw event data (items, quantities) for debugging. Index the click identifier columns so you can query them efficiently.

4. Serve a CSV endpoint

   Create an HTTPS endpoint on your domain (e.g., yourdomain.com/conversions.csv) that queries your database and outputs the CSV in the exact format Google Ads requires. Protect it with HTTP Basic Authentication so only Google Ads Data Manager can access it. Support query parameters for date range filtering (the last 30-90 days is typical).

5. Connect Google Ads Data Manager

   In your Google Ads account, go to Tools & Settings → Data Manager. Create a new HTTPS data source. Enter the CSV endpoint URL and the HTTP Basic Auth credentials. Map the CSV columns to Google Ads fields. Set a daily import schedule and run a test import to verify the data flows correctly.

6. Deduplicate against client-side conversions

   Google Ads will automatically deduplicate conversion imports that share the same click ID and transaction ID as conversions already recorded by the client-side tag. This means you can run both tracking methods simultaneously without double-counting. The server-side import fills in the gaps where client-side tracking failed, and Google handles the overlap.

The dataLayer Events You Need to Capture

If your site uses GA4 ecommerce tracking (and it should), these events are already being pushed to the dataLayer. Here is what the purchase event looks like — this is the most important one to capture:

// Pushed to dataLayer on order confirmation page
dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "ORD-28491",
    value: 142.50,
    currency: "USD",
    items: [
      {
        item_id: "SKU-1042",
        item_name: "Organic Face Serum",
        price: 47.50,
        quantity: 3
      }
    ]
  }
});

Your server-side capture system needs to intercept this push, pair it with the stored GCLID/GBRAID/WBRAID, and send both to your backend. The transaction_id is critical — it is what Google uses for deduplication.

What This Looks Like in Practice

Here is a realistic scenario showing exactly why this matters for an ecommerce store.

In this example, client-side tracking missed 80 conversions (23.5%). The server-side import recovered 62 of them — the remaining 18 had no click identifier at all (likely cross-device or direct navigation). But the impact on ROAS is significant:

The campaigns are the same. The ads are the same. The customers are the same. The only difference is that Google Ads can now see what was actually happening. And because Smart Bidding uses conversion data to set bids, the algorithm starts bidding more confidently on the campaigns that were actually performing well — which in turn brings cost per acquisition down over the following weeks.

Setting Up Google Ads Data Manager

Once your CSV endpoint is live and serving data, connecting it to Google Ads takes about ten minutes.

1. Create the conversion actions

   In Google Ads, go to Goals → Conversions → Summary. Create a conversion action for each event type you are importing (at minimum, “Purchase”). Set the conversion value to “Use the value in the tag/import” so the CSV value is used. Set the attribution model to data-driven.

2. Open Data Manager and add HTTPS source

   Navigate to Tools & Settings → Data Manager. Click “Connect Product” and select “HTTPS” as the data source type. Enter your CSV endpoint URL and provide the HTTP Basic Auth username and password.

3. Map columns and set schedule

   Google will preview the CSV data. Map “Google Click ID” to the click identifier, “Conversion Name” to the conversion action name, and the remaining columns to their respective fields. Set the import to run daily — once per day is sufficient for most ecommerce stores.

4. Run a test import and verify

   Trigger a manual import. Check the import history for errors. The most common issues: mismatched conversion action names, timestamps in the wrong timezone, or click IDs that are older than 90 days (Google rejects these). Once the test import succeeds with zero errors, you are done.

Common Pitfalls and How to Avoid Them

Conversion action names must match exactly

If your Google Ads account has a conversion action called “Purchase – Website” and your CSV says “Purchase”, the import will succeed but the conversion will not be recorded. Google does not do fuzzy matching. Check your conversion action names in Goals → Conversions and copy them character for character.

Timezone mismatches cause attribution errors

The first line of your CSV specifies the timezone. Every timestamp in the file is interpreted in that timezone. If your server stores timestamps in UTC but your CSV header says Parameters:TimeZone=America/New_York, every conversion will be attributed 4-5 hours off. This is especially damaging for day-parting analysis and can cause conversions to land on the wrong date.

Click IDs expire after 90 days

Google rejects conversion imports where the click ID is older than 90 days. For most ecommerce purchases this is not an issue (typical purchase cycles are 1-14 days), but if you are importing micro-conversions from long consideration cycles, keep this limit in mind.

Don’t import conversions that are already tracked client-side without transaction IDs

Deduplication relies on having a consistent transaction_id. If your client-side tag fires a purchase conversion without a transaction ID, and your server-side import also sends the same conversion without a transaction ID, Google will count it twice. Always include the order number as the transaction ID in both your GTM tag and your CSV.

Privacy and Consent Considerations

Server-side conversion tracking does not bypass consent requirements. If your store operates in the EU (GDPR), UK, or anywhere with consent regulations, you still need user consent before collecting and transmitting click identifiers for advertising purposes.

In practice, this means:

• Your cookie consent banner must cover advertising/analytics cookies and first-party data collection for ad attribution
• Click identifier capture should only activate after consent is granted
• Your privacy policy should mention that conversion data is shared with Google Ads for campaign optimization
• Under GDPR, this processing is typically covered under “legitimate interest” for existing customers or “consent” for new visitors

The click identifier itself is pseudonymous data (it identifies a click, not a person), but paired with conversion data it can constitute personal data under GDPR. Handle accordingly.