Google’s June 15 Consent Change Broke WordPress Phone-Call Attribution
Your Google Ads phone-call conversions dropped because, since June 15, 2026, ad_storage in Consent Mode is the single control over advertising data flowing from GA4 to linked Google Ads, and Google Signals no longer acts as a fallback. When a visitor denies ad_storage, no ad cookie or click ID is written, so the call still happens but can’t be tied to the ad click that drove it. The fix for WordPress lead-gen and service sites is server-side imported conversions, which match calls to clicks using stored first-party data instead of browser cookies.
What changed on June 15
Google collapsed two consent controls into one, and the one that’s left lives in your cookie banner, not your GA4 settings.
For years, two separate switches governed whether advertising data flowed from Google Analytics into your linked Google Ads account: the Google Signals toggle in GA4, and the consent signal from your banner. If either said no, the data was limited. That dual-control era is over.
Since June 15, 2026, ad_storage in Consent Mode is the single control over advertising data flowing from GA4 to linked Google Ads, and Google Signals has been demoted to behavioral reporting only (Search Engine Land). The change was announced in Google’s Analytics data-controls update earlier this year, and it landed quietly.
Turning off Google Signals will no longer stop advertising data from flowing into Google Ads. The only switch that matters now is ad_storage, and it lives in your consent banner code (Piwik PRO, 2026).
Here’s the thing: most teams treated the Google Signals toggle as a safety net. After June 15, that fallback is gone, so any site running a loose Consent Mode setup silently loses advertising data the day of the switch (Dataslayer). No error, no warning. Just numbers that quietly stop adding up.
How phone-call attribution works and where it breaks
Call tracking depends on an advertising identifier that Google only writes when ad_storage is granted, so a denied visitor’s call has nothing to match against.
When someone clicks your ad and lands on your WordPress site, Google can swap your displayed phone number for a forwarding number through dynamic number insertion. If that visitor calls, Google ties the call back to the ad click. But that link isn’t free-floating, it’s built on a stored identifier.
Google forwarding numbers count a call as a conversion only when it meets a minimum call length and the Google tag fired after an ad click (Google Ads Help). Both conditions assume the advertising cookie or click ID was actually written. Deny ad_storage, and it never is.
Translation: the call still rings, your team still answers, the lead is still real. Google just can’t see which ad sent it. When a visitor denies ad_storage, no ad cookie or click ID is written, so the call happens but can’t be tied to the ad click that drove it.
This isn’t only a consent problem, either. Apple’s link-tracking protection already strips gclid and related click parameters from ad URLs in Safari, so even a granting visitor on an iPhone can arrive without the identifier your call tracking needs. June 15 just widened a gap that was already there.
You may be interested in: Self-hosted vs managed: which WooCommerce event pipeline fits your store in 2026
Before and after June 15: a side-by-side
The same caller produces a tracked conversion or an invisible one depending entirely on the ad_storage signal.
It helps to see the three states next to each other. The call is identical in every row, what differs is whether Google has an identifier to match it.
| Scenario | What Google stores | Call attributed to the ad click? |
|---|---|---|
| Consent granted (client-side) | Ad cookie and click ID written in the browser | Yes |
| Consent denied (client-side) | No ad cookie or click ID written | No, the call is invisible to Ads |
| Server-side imported conversion | First-party identifier and click ID stored on your server at click time | Yes, even when ad_storage is denied |
The middle row is where WordPress service businesses are bleeding. Consent rejection on EU cookie banners is widely estimated to land anywhere from 40% to 70%, which means a large share of your callers may now fall into that invisible state. And Consent Mode v2 requires all four parameters; without ad_user_data, Enhanced Conversions fail (UniConsent), so a half-configured banner makes the gap worse.
The server-side fix
Move the match off the browser and onto your server, where consent denial and Safari can’t erase the identifier.
The question isn’t how to force more visitors to accept cookies. The question is how to attribute a call without depending on a browser cookie at all.
That’s what server-side imported conversions do. You capture a first-party identifier and the click ID server-side at the moment of the click, then import the matched call back into Google Ads as an offline conversion. The match happens on infrastructure you control, so it survives both consent denial and link-tracking protection.
Server-side imported conversions match a call to a click using stored first-party identifiers instead of browser cookies, so attribution survives even when a visitor denies ad_storage.
This is the model Seresa’s Transmute Engine™ is built on: it captures click context server-side on your WordPress site and imports matched conversions into Google Ads through the first-party layer rather than the browser. For lead-gen and service sites where phone calls are the conversion, that’s the difference between a measured pipeline and a guessed one.
You may be interested in: WooCommerce 10.8 ships product_published, the cleaner catalog-sync hook
What to do this week
Three checks will tell you whether June 15 has already cost you call conversions.
First, look at what your consent management platform actually passes for ad_storage. If you’ve never inspected it, that’s your highest-priority task, because it’s now the only lever over Ads data.
Second, segment your Google Ads call conversions by date and watch for a step-down around June 15. A sudden, unexplained drop in call conversions that lines up with the switch is the signature of this exact failure.
Third, decide whether your call attribution should keep living in the browser at all. If a meaningful share of your leads are phone calls, a server-side import path is no longer a nice-to-have, it’s how you keep seeing the leads you’re already paying for.
Key takeaways
- Single control now: Since June 15, 2026, ad_storage in Consent Mode is the only switch governing GA4-to-Google-Ads data flow, with Google Signals demoted to behavioral reporting.
- Calls go invisible on denial: When a visitor denies ad_storage, no ad cookie or click ID is written, so the call connects but can’t be matched to its ad click.
- Service sites feel it most: Most coverage focuses on ecommerce and remarketing, leaving phone-call attribution on WordPress lead-gen sites unaddressed.
- The fix is server-side: Importing matched conversions from a first-party identifier stored on your server keeps call attribution working through consent denial and Safari link-tracking protection.
Because ad_storage in Consent Mode is now the single control over advertising data flowing from GA4 to linked Google Ads, and Google Signals no longer acts as a fallback. Visitors who deny ad_storage no longer have an ad cookie or click ID written, so their calls can’t be matched to the ad click that drove them.
Yes, for cookie-based call tracking. Google forwarding numbers and click-to-call rely on an advertising cookie or click ID set when ad_storage is granted. If a visitor denies ad_storage, the call still connects but Google has no stored identifier to tie it back to the ad click, so the conversion goes unattributed.
Use server-side imported conversions. Instead of depending on a browser cookie, you capture a first-party identifier and the click ID server-side at the moment of the click, then import the matched call as an offline conversion into Google Ads. The match happens on your server, so it survives consent denial and Safari link-tracking protection.
No, but WordPress lead-gen and service businesses feel it most because so many of their conversions are phone calls rather than on-site checkouts. Most coverage of the June 15 change focuses on remarketing and ecommerce purchases, leaving call attribution on service sites largely unaddressed.
References
- Search Engine Land — Google simplifies Analytics and Ads consent rules (2026). https://searchengineland.com/google-simplifies-analytics-and-ads-consent-rules-474206
- Google Ads Help — About conversions from calls (2026). https://support.google.com/google-ads/answer/6100664
- Dataslayer — GA4 + Google Ads data controls: what changes June 15, 2026 (2026). https://www.dataslayer.ai/blog/ga4-google-ads-data-controls-june-15-2026
- UniConsent — Google Ads Consent Mode change 2026 (2026). https://www.uniconsent.com/blog/google-ads-consent-mode-change-2026
- Piwik PRO — Google is changing how GA4 and Google Ads share data (2026). https://piwik.pro/blog/google-is-changing-how-ga4-and-google-ads-share-data/
If your call conversions dipped this month, a server-side event pipeline is how you get them back, see how Seresa rebuilds attribution that survives consent denial.