Drupal Privacy Digest Tracks Consent Across Browser and Server Ad Measurement

Following a consent correction in ChatGPT Ads, Drupal teams using advertising measurement have a concrete reason to examine whether browser-side consent decisions also reach server-side conversion reporting. ChatGPT Ads 1.0.1, released on 27 September 2026, changes how its Conversions API integration handles personal identifiers when the module's consent gate is enabled. The release matters because preventing an advertising pixel from operating in the browser does not automatically prevent Drupal itself from communicating with an advertising platform through a server-side API.

ChatGPT Ads combines OpenAI's browser Measurement Pixel with its server-side Conversions API, using matching event identifiers so the same conversion can be deduplicated. Commerce events can include items being added, checkout starting and orders being created, while Webform submissions can be reported as leads, registrations, appointments or custom events. Depending on configuration and consent state, server-side events can also include hashed email addresses, phone numbers and names, together with an IP address and user agent. The module is a community project supported by Bloomidea and is not affiliated with OpenAI.

Version 1.0.1 corrects a mismatch affecting sites that enabled the consent gate together with the Conversions API. Before the fix, the browser pixel could hold a visitor's events while the server-side channel still attached hashed contact details, an IP address and a user agent before that visitor had answered the consent notice. With the gate enabled, personal identifiers are now attached only when consent was recorded. A conversion can still be sent without those personal identifiers, so the fix should not be described as blocking every server-side request before consent.

Operators also need to consider how consent reaches the backend. A consent manager connected only through the module's browser-side JavaScript contract does not automatically give Drupal a server-side consent decision; with the gate enabled, server events from that setup therefore carry no personal identifiers even when the visitor accepted. The release notes also warn that an order placed before the update and paid afterward can be processed under the earlier rule because it was captured before the corrected gate state was recorded. Sites using both browser and server measurement should therefore test new visits, refusal, acceptance and delayed conversions rather than checking only whether the visible pixel fires.

Bloomidea's implementation account, published on 28 September, describes using the integration with Drupal Commerce, Webform, Klaro, caching and payment methods whose confirmation can arrive after the customer's browser session has ended. The maintainer says the pixel, Klaro gate and cart events have been running on a Portuguese commerce site since mid-September. That provides implementation detail from the module's maintainer rather than independent evidence of wider production adoption, and it does not by itself establish compliance with GDPR or another privacy regime.

Stable release Consent Audit 1.0.0, published on 28 September, addresses a different part of the problem. The module records third-party requests and cookies created before a visitor has made a consent decision or after consent has been refused. It also attempts to trace a finding to the Drupal library, injected asset or markup that caused it, giving developers a way to observe what the browser actually does rather than assume every third-party resource is controlled by the site's consent manager.

Consent Audit is diagnostic rather than preventative. It reports the behaviour it observes rather than blocking the third-party request itself, and a finding does not establish a legal violation. Its observations are also browser-side. A request made directly from Drupal's backend to an advertising platform does not pass through the visitor's browser, so a clean Consent Audit report cannot demonstrate that server-side measurement follows the same consent decision.

That distinction becomes especially relevant with Facebook Pixel 3.0.0-alpha1, released on 28 September. The Drupal 11-only release adds Meta's server-side Conversions API alongside the existing browser pixel, automatic deduplication between the two channels and independent browser and server switches for individual events. A new Klaro submodule is intended to block both the browser pixel and CAPI events until the visitor consents.

Facebook Pixel 3.x can send configured events from either the browser or Drupal's backend, including page views, registrations, content views and Commerce events. The release also adds cache-safe page-view tracking, optional Parameter Builder support for CAPI data and a plugin-based event architecture intended to make additional events easier to implement. The project is supported by DROWL.de, while Meta operates the external Pixel and Conversions API services.

The 3.0.0-alpha1 release should remain clearly separated from the stable 2.x line. Version 3.x currently requires Drupal 11 and remains an alpha release, while the stable 2.x branch supports Drupal 10 and Drupal 11 and provides the established browser-pixel integration. Drupal's security advisory coverage applies to stable covered releases, not this alpha release.

Taken together, the three releases expose a boundary that analytics and privacy reviews can easily miss. Consent interfaces operate where visitors can see and control browser behaviour, while advertising integrations can also send conversions from backend systems that continue operating after the browser session has ended. Drupal Commerce, Webform and analytics teams using both channels should verify which events leave the site, what identifiers accompany them, where consent state is stored and whether refusal or an unanswered notice affects both paths. Browser-side auditing can reveal part of that behaviour, but server-side conversion reporting requires its own testing rather than assumptions carried over from the browser.