Reporting Google Ads ROI without third-party cookies.

Removing Google Analytics from a WordPress site (and the consent banner that came with it) raises an immediate question from the marketing team: how do we report on Google Ads now? The answer is mostly fine. Conversion tracking, ROAS, conversion-based bidding strategies — all of it works server-side, without client-side cookies. The honest exception is retargeting, which genuinely depends on browser-side tracking and doesn’t have a clean equivalent. Here’s the realistic accounting.

A consistent follow-up question from the marketing team, the moment Google Analytics gets removed from a WordPress site, is some version of “OK, but how do we report on the Google Ads spend?” The instinct is to assume that pulling the GA tag breaks Google Ads measurement. It mostly doesn’t. The Google Ads stack supports server-side conversion tracking that doesn’t depend on client-side cookies, and most of what marketing teams actually use day-to-day — conversion counts, ROAS, conversion-based bidding — survives the transition cleanly. The honest exception is retargeting, which is genuinely browser-cookie-dependent and doesn’t have a clean server-side equivalent.

This is the natural follow-up to dropping Google Analytics for a self-hosted alternative. The privacy and performance wins from that move are real, and the Google Ads question is the most common reason teams hesitate. Here’s the realistic accounting of what you keep and what you give up.

What server-side Google Ads tracking actually is.

Instead of relying on Google’s tracking script in the visitor’s browser, the conversion event is recorded on your server and pushed to Google’s APIs directly. Several pieces interact:

• Enhanced Conversions for Web: when a conversion happens (form submit, purchase), your server sends a hashed user identifier (email or phone) to Google’s API. Google matches that hash against the ad-click record to attribute the conversion. No client-side cookie needed.

• Enhanced Conversions for Leads: same mechanism for lead conversions that close later. The hashed identifier is uploaded at lead capture; the conversion is uploaded when the lead becomes a customer, with the same hash linking them.

• Offline Conversion Imports: for conversions that close off the web entirely (sales calls, in-store), the click identifier (GCLID, WBRAID, or GBRAID) is captured at click time, stored alongside the lead, and uploaded with the conversion when it eventually closes.

• GA4 Measurement Protocol: if GA4 is still in the stack as a relay (some teams keep it as a server-side conduit to Google Ads without exposing it to visitors), server-side events sent to GA4 via API feed conversions through to Ads via the standard import.

• Server-side Google Tag Manager: the visitor’s browser talks to a tag endpoint on your own domain; that endpoint cleans the data and forwards what’s needed to Google. It looks like first-party to the browser and reduces the script and cookie load on the page itself.

None of these require Google’s tracking script to load in the visitor’s browser. None of them rely on dropping client-side tracking cookies. All of them can be configured to fit cleanly inside a privacy posture that doesn’t need a site-wide consent banner for Google Ads — though hashed-identifier uploads still need to be disclosed in the privacy policy and, in some jurisdictions, consented to. The disclosure is narrower and more honest than a blanket “we use Google” banner.

What still works.

The day-to-day Google Ads reporting most marketing teams care about:

• Conversion counts and conversion value: flow through cleanly via Enhanced Conversions and offline imports.

• ROAS and cost-per-conversion reporting: calculated from the conversion data above. Works exactly the same.

• Conversion-based bidding strategies: Maximize Conversions, Maximize Conversion Value, Target CPA, Target ROAS — all run on the conversion signal, which the server-side path delivers.

• Campaign-level attribution: which campaigns are driving conversions and at what cost.

• Customer Match audiences: uploaded customer lists work the same as before. They’re first-party data you already have.

• Click-based attribution: capture the GCLID, WBRAID, or GBRAID on landing, store it with the lead, attribute the eventual conversion back to the original click. The cleanest attribution model and the one that survives all browser cookie deprecation.

For a marketing team running performance-focused acquisition campaigns — the most common Google Ads workload — the above is the entire dashboard they actually open weekly. None of it requires the GA script on the page.

What you genuinely can’t do well server-side.

The honest list of what gets harder or goes away:

• Retargeting and remarketing audiences: building a “people who visited this product page” audience requires Google’s pixel to identify the visitor across the Google ad network. Server-side can’t reconstruct this. The audience either doesn’t get built, or it gets built only from the subset of visitors you can identify via first-party data (logged-in users, leads). Retargeting campaigns get smaller or stop working.

• View-through attribution: when a user sees an ad but doesn’t click, then later visits the site directly, Google’s view-through attribution requires the impression cookie and a way to recognize the same browser later. Without client-side cookies, that credit goes away. The conversion still happens; it just gets attributed to “direct” rather than to the ad impression.

• Audience-based Smart Bidding signals: some Smart Bidding signals (in-market audiences, affinity audiences) depend on Google’s cross-site behavior tracking. Smart Bidding still works; it just makes bidding decisions on a smaller signal set. Most reports show this as a modest performance variance, not a collapse.

• Lookalike modeling seeded by site-behavior audiences: Customer Match lookalikes (seeded by uploaded customer lists) still work; lookalikes seeded by site-visitor audiences degrade or disappear with the underlying audience.

The honest framing for the marketing team: retargeting is the biggest concrete loss. Everything else either still works, works with a smaller signal set, or has a first-party equivalent.

The pragmatic case on retargeting.

The interesting follow-up question is whether retargeting was worth what you were paying to keep it. Across most B2B and most considered-purchase B2C campaigns, retargeting audiences are the lowest-quality bucket in the campaign. The people in them are, by definition, the people who decided not to convert the first time. The conversion uplift from showing them additional impressions is often inside the noise floor.

Teams that audit their Google Ads retargeting spend honestly — comparing the incremental conversion rate of retargeting audiences to the cost of running them — frequently conclude the budget was better deployed against brand search, conversion campaigns, or first-touch acquisition. Pulling retargeting because you can’t do it cleanly without the cookie banner is a forcing function for an audit that was overdue anyway.

The exceptions are high-volume ecommerce (where retargeting against cart abandonment has documented ROI) and short-cycle consumer offers (where the impression-to-conversion window is short enough that retargeting is the campaign). Those teams should expect a real performance hit and budget for it. Most others won’t notice.

What the migration looks like.

Realistic project arc:

1. Capture the GCLID (as well as WBRAID and GBRAID for iOS traffic) on every landing page from a Google Ads click and store it with whatever lead-capture system you have. This is the foundation; without it, none of the rest works.

2. Set up Enhanced Conversions for Web via the Google Ads API or the supported Google Tag Manager flow. Configure the conversion to fire server-side and include the hashed user identifier.

3. For longer-cycle conversions, wire up offline conversion imports — either a CSV upload on a schedule, or a direct API push from the CRM.

4. Run the new tracking in parallel with the old GA-based setup for a few weeks. Confirm the conversion counts track within expected variance (they will differ slightly; methodologies differ).

5. Pull GA from the site, remove the consent banner, and update the privacy policy to disclose the hashed-identifier uploads.

6. Migrate retargeting budget to whatever the campaign audit suggests is the better deployment.

Allow 2-3 weeks of light project work, mostly in the parallel-running and validation phase. The result is Google Ads reporting that survives the loss of client-side tracking cookies, a cleaner privacy posture for the site, and — often — a more honest read on what was actually driving conversions in the first place. See privacy built into the platform for the rest of the surfaces this same approach applies to.