Google Data Manager for WordPress

New in 2.1.0. It works with WooCommerce and with Easy Digital Downloads 3.0 or newer. Every option on this page is experimental and off by default.
GTM4WP 2.0.x: there is no Google Data Manager integration.

What the Data Manager API does for your store

Google Analytics 4 does not learn about a refund you issue in WooCommerce or Easy Digital Downloads unless something sends it. Tags in the browser see what visitors do on your pages. A refund happens somewhere else: you issue it in the store admin, where your Google Tag Manager container does not load, so no tag can report it. Google Analytics keeps counting the revenue you have already given back.

The Google Data Manager API is Google’s interface for sending this kind of data from a server. GTM4WP uses it to send a refund event to Google Analytics 4 for each refund you issue, matched to the purchase it reverses. Google recommends the Data Manager API for new server-to-server integrations. The older Measurement Protocol keeps working, and Google has no plans to deprecate it.

The sending runs in the background, signed with a Google Cloud service account whose key you upload to the plugin. Nothing leaves your site until you turn a feature on.

What you need

• WooCommerce, or Easy Digital Downloads 3.0 or newer.
• A Google Cloud project with the Data Manager API enabled, and a service account in that project with a JSON key file. The service account guide walks through it.
• The Editor role for that service account on your Google Analytics 4 property.
• A Google Analytics 4 tag in your Google Tag Manager container that fires for the measurement ID you send to. GTM4WP reads the visitor’s Analytics client ID from that tag. The GA4 setup guides for WooCommerce and Easy Digital Downloads cover that tag.
• For the consent rules, a consent tool that sets Google consent mode.
• The PHP OpenSSL extension, and the AUTH_KEY, SECURE_AUTH_KEY, AUTH_SALT and SECURE_AUTH_SALT constants defined in wp-config.php. The service account key is encrypted with them, or with GTM4WP_ENCRYPTION_KEY when you define it.

Setting it up

1. Create the service account and upload its key file in the Google service accounts section of the GTM4WP settings.
2. In the Google Data Manager section, add a row for your Google Analytics 4 property on the Destinations tab. Press the Test button below the table, then save.
3. On the Sending events tab, turn on Send refunds to Google Analytics and choose the consent rule. Add the two new cookies to your cookie notice.
4. After your next refund, check the Recent sends list below the destinations table.

Only refunds of orders placed after step 3 can be sent. An order placed earlier has no client ID stored, so its refunds are skipped.

Settings

The Google Data Manager section of the GTM4WP settings has two tabs: Destinations and Sending events. This part of the page follows the same order.

Data Manager destinations (experimental)

Default: empty.

One row for each Google Analytics 4 property GTM4WP may send events to. A row holds an optional label, the service account that signs the requests, the type (Google Analytics 4 is the only type for now), the GA4 property ID and the measurement ID.

The property ID is the all-numeric ID shown under Property details in the Google Analytics admin. The measurement ID starts with G- and belongs to the web data stream of the same property. Each measurement ID can appear in only one row.

The Test button below the table sends a validation request, which Google checks and does not store. It confirms the key, that the Data Manager API is enabled in the Cloud project and that the service account can reach the property, so a mistyped ID or a missing permission shows up before a real event is sent. Developers can change the list at runtime with the gtm4wp_gdm_destinations filter.

Send refunds to Google Analytics (experimental)

Default: off. Needs at least one destination.

Sends a refund event to every destination when a refund is issued in your store, so Google Analytics stops counting revenue you have given back. Every refund reports its own amount, the items it covers and the shipping and tax it returned, whether it covers one line or the whole order. The event is sent in the background a minute after the refund, so issuing a refund is never slowed down.

Turning it on also stores, with every new order, what is needed to match a refund to its purchase in Google Analytics: the Analytics client ID, the session ID for each destination, the Google Ads click IDs of the visit (gclid, gbraid and wbraid) and the consent state. Only refunds of orders placed after that can be sent, because an older order has no client ID stored.

The IDs come from the official Google tag API, so the Google Analytics 4 tag for the destination’s measurement ID has to fire in your container. If it does not, the browser never answers and nothing is stored. Site Health warns you when none of the recent orders has anything stored.

Refund sending also loads a small script on every page and writes two first-party cookies for every visitor, not only for buyers. gtm4wp_gdm_ids holds the IDs and gtm4wp_gdm_consent holds the consent answer, both for 90 days. The consent cookie is written even when the answer is no, because the consent rule below is checked against it. Mention both cookies in your cookie notice. The GDPR page lists every cookie GTM4WP can set.

Storing follows the visitor’s consent. The Analytics IDs are not stored when analytics_storage was denied, and the click IDs are not stored when ad_storage was denied. If the buyer’s only page view was the checkout, the purchase confirmation page tries once more and fills in whatever was missing. Developers can override the stored consent state with the gtm4wp_gdm_order_consent filter, for example for a consent tool that does not use Google consent mode.

Known limitation of Google Analytics data processing itself: when one order is refunded in several steps, Google Analytics processes only the first of them. It has been reported to Google. Every step is still sent, so no plugin update is needed once Google fixes it. The refunds guide covers what the event carries, when a refund is skipped and how to send one again.

Require consent before sending (experimental)

Default: Only for buyers in the EEA, the UK and Switzerland.

Decides for which orders the stored consent state has to allow analytics storage before anything about them is sent to Google. The billing country of the order decides the region, which is more reliable than a guess from the visitor’s IP address.

Choice	What it does
Only for buyers in the EEA, the UK and Switzerland (recommended)	An order with a billing country in the European Economic Area, the United Kingdom or Switzerland is sent only if analytics_storage was granted. Other orders are sent without a consent check. These are the countries Google’s EU user consent policy covers.
For every order	Every order needs analytics_storage granted.
Never – I assert my own lawful basis	No consent check. GTM4WP sends whatever it holds, whatever the stored answer. You take responsibility for the legal basis of the transfer, so choose this only as a deliberate decision.

Where the rule applies, an order is skipped when consent was denied, and also when no consent answer was recorded at all, for example because the buyer ordered before the consent banner loaded or the site runs no consent tool. The Recent sends list shows the reason.

No choice here can send an order whose buyer refused analytics storage. Such an order has no client ID stored, because the browser was never allowed to keep one, so nothing can be sent for it, not even with Never.

What GTM4WP stores and sends

With refund sending on, every new order gets these fields. They are written into the order and never shown on the site.

Order field	Content
_gtm4wp_ga_client_id	The Google Analytics client ID of the buyer’s browser
_gtm4wp_ga_session_ids	The session ID for the measurement ID of each destination
_gtm4wp_gclid, _gtm4wp_gbraid, _gtm4wp_wbraid	The Google Ads click IDs of the visit, when it had any
_gtm4wp_consent_state	The consent mode answers and when they were recorded

A refund event sends Google the transaction ID of the order, the client ID, the refunded amounts and items, and the ad_user_data and ad_personalization consent answers where they were recorded. No name, email address or other customer detail is sent.

The order fields are part of the WordPress personal data export (Tools → Export Personal Data) and are removed by its erasure (Tools → Erase Personal Data), for WooCommerce and Easy Digital Downloads orders alike. Uninstalling GTM4WP deletes the stored service account keys, the send history and the health records, but it leaves these fields in your orders. Use the erasure tool to remove them for one person.

Checking that it works

• Recent sends, below the destinations table, lists the latest server-side sends and what became of them, including refunds skipped on purpose and the reason. A failed refund, or one skipped for a reason a setting can fix, can be sent again.
• An admin notice names a destination after three failed sends in a row. It goes away by itself after the next successful send.
• Tools → Site Health has two status tests. “Google Data Manager is working” turns critical while a destination keeps failing, and recommends a look when none of the recent orders has attribution stored. “Google service account keys are readable” fails when a stored key can no longer be decrypted. The Info tab lists the settings and destinations.

Setup guides