GA4 & Google Ads: what changed in 2026

GA4 and Google Ads changed significantly in the first half of 2026. The Google Ads API reached v24.1, GA4 added new lead lifecycle stages, and third-party cookies continued to deprecate. Agencies and small businesses must adapt to these updates to maintain accurate conversion tracking and analytics.

Google Ads API v24.1: what is new

The May 2026 release of the Google Ads API (v24.1) introduced features that affect tracking and conversion measurement.

• GA4 lead lifecycle stages: New conversion types include GOOGLE_ANALYTICS_4_GENERATE_LEAD, GOOGLE_ANALYTICS_4_QUALIFY_LEAD, and GOOGLE_ANALYTICS_4_CLOSE_CONVERT_LEAD. You can track leads through their full lifecycle inside Google Ads from initial form fill to closed deal, all sourced from GA4 data.
• Experiment metrics: A/B test results now include p-values, point estimates, and margin of error across seven core metric families. Agencies running Google Ads experiments receive more rigorous statistical reporting.
• Asset generation service: Generative AI for ad text and images is available via the API. Performance Max campaigns can auto-generate design variations and video assets.

What cookie deprecation actually means in 2026

Third-party cookies are not fully gone, but their effectiveness is severely diminished. Chrome's Tracking Protection limits cross-site tracking by default for a growing percentage of users. This affects your GA4 data directly.

• Consent Mode v2 is no longer optional. It is the only way Google can model conversions for users who decline cookies.
• Server-Side GTM is the primary way to set first-party cookies that survive browser restrictions.
• Enhanced conversions match user-provided data to fill the gap where cookies fail.

What agencies should do right now

If you manage tracking for clients, you must verify Consent Mode v2 is correctly implemented with all four signals. You should also move key conversion tracking to Server-Side GTM and configure enhanced conversions in Google Ads.

Enhanced conversions: setup that actually works

Enhanced conversions sit between cookie-based tracking and server-side measurement. When a user converts on your site (form submission, purchase, booking), you capture a piece of first-party data they provided voluntarily (typically an email address, phone number, or full name and address) and send it along with the conversion event. Google hashes that data and matches it against signed-in Google accounts to attribute the conversion when cookies are blocked or expired.

Agencies consistently trip over two setup requirements. First, the data you pass must be the same data the user entered on your site. If you pass a hashed email from your CRM but the user signed up with a different address on the form, the match fails silently. Second, enhanced conversions require ad_user_data to be granted in Consent Mode v2. If your consent banner has that signal still set to 'denied', Google will not process the data and your enhanced conversions will not fire.

You can implement this via Google Tag (gtag) or Google Tag Manager. GTM is the better route for agencies managing multiple clients because you can deploy once and reuse the configuration. In your Google Ads account, navigate to Goals > Conversions > Settings and enable enhanced conversions. Choose "Google Tag Manager" as the method. In GTM, edit your conversion linker tag and check "Enable enhanced conversions." Create a user-provided data variable that maps your form fields to Google's expected format: email, phone number, name and address (street, city, region, postal code, country).

If your form captures an email field with the ID #form-email, your GTM variable extracts that value and passes it through. Google handles the SHA-256 hashing on its end. You do not hash anything yourself. The most common failure point we see in audits is the variable firing on the page view event rather than the conversion event itself. If your enhanced conversions variable fires on DOM Ready or Page View, it runs before the user has submitted anything. Tie it to your conversion trigger (form submission, purchase confirmation page view, or custom event), not to general page loads.

Use Google Tag Assistant's "Enhanced Conversions" tab under the debug view for testing. It shows exactly what data is captured and whether Google successfully matched it. If you see "No match" consistently, check that your form field selectors are correct (clients rename form IDs mid-campaign without notification) and verify that ad_user_data consent is granted.

Consent Mode v2: the direct impact on Google Ads performance

Consent Mode v2 directly determines how much of your Google Ads conversion data survives. When a user lands on your site and declines marketing cookies, Consent Mode v2 tells Google to send a cookieless ping without setting advertising cookies. Google uses that ping and its behavioural modelling to fill in the gaps. The modelled conversions appear in your Google Ads reports and inform Smart Bidding optimisation.

The modelling quality depends entirely on your baseline data volume. If your site gets fewer than 700 ad clicks per day per domain over a 7-day period, Google's modelling may not run at all because the data is too sparse. For small B2B clients driving 50 clicks a day, every consent rejection is a lost conversion in the system. There is no workaround within Google's framework for this threshold. Pairing Consent Mode v2 with Server-Side GTM and enhanced conversions is necessary for lower-traffic clients. Server-side tracking captures data outside the browser's cookie restrictions, and enhanced conversions match it back to Google accounts. Both operate independently of the modelling threshold.

The ads_data_redaction and url_passthrough settings accompany the consent defaults. They determine whether Google strips ad click identifiers from URLs (ads_data_redaction: true) and whether it passes through the GCLID when ad cookies are denied (url_passthrough: true). If you set url_passthrough to false, denied users lose their ad click identifiers entirely and Google cannot model those conversions. Check both settings in your consent defaults to ensure they are true.

Smart Bidding performance differs measurably when Consent Mode v2 is correctly implemented versus partially deployed. One client running a Performance Max campaign saw their cost per conversion drop by 18% within three weeks of fixing the ad_user_data signal. It had been stuck at 'denied' while the other three signals were correctly toggling. Smart Bidding uses the conversion data to adjust bids, so partial consent signals create a distorted view of campaign performance. Audit all four signals on every client domain at least once per quarter. CMPs update, cookie banners get redesigned, and consent wiring breaks regularly.

Practical migration steps: from legacy to modern tracking

If your agency is still running Universal Analytics-style tracking with client-side GTM and basic Google Ads conversion tags, follow this migration sequence based on 20 client migrations across e-commerce, SaaS, and B2B services.

Step 1: audit what you have. Document every tag, trigger, and variable in your client's current GTM container before modifying anything. Pay special attention to custom HTML tags that fire conversion pixels. These are often undocumented and added years ago by someone who left the company. Export the container JSON and search for anything hitting third-party domains. You will likely find tags you did not know existed.

Step 2: implement Consent Mode v2 first. Get the consent layer working correctly before moving anything server-side. Place the default consent script above the GTM container snippet. Configure all four signals. Test with Tag Assistant until you see clean denied-to-granted transitions for every signal. Do not skip this step and jump straight to server-side. Without correct consent, your server-side container processes data it should not touch.

Step 3: set up enhanced conversions in Google Ads. This takes under 30 minutes once you map your form fields. It fills the cookie gap immediately while you work on the longer server-side migration.

Step 4: deploy a server-side GTM container. Create a Google Cloud project, provision a Cloud Run service, point a subdomain at it, and set up the GTM server container. Start with a single client to build the template, then replicate. The DNS step trips people up. You need a CNAME record pointing your subdomain (e.g. ssgtm.client.com) to gtag-ssl.google.com or your Cloud Run custom domain mapping. If you skip DNS custom domain mapping, your server-side cookies are third-party in the browser's eyes, causing you to lose the first-party cookie advantage.

Step 5: migrate tags one channel at a time. Start with GA4 since it is the lowest risk, allowing you to compare client-side versus server-side data in real time. Once GA4 is stable, move Google Ads conversion tracking. Then move Facebook CAPI, LinkedIn Insight Tag, and any other endpoints. Migrating everything at once complicates debugging. One channel per week is a sustainable pace.

Step 6: validate and monitor. Run both client-side and server-side tracking in parallel for at least two weeks after migration. Compare the data. You should see server-side reporting 10-25% more conversions than client-side alone. That is the adblocker and cookie-blocker gap closing. If you see less, something is misconfigured. Set up a monthly health check. Verify consent signals, check enhanced conversions match rates in Google Ads, and confirm your server-side container is not throwing errors. GTM's server-side container has a built-in error reporting dashboard for you to monitor.