← Back to changelog

GTM Kit 2.19.0: settings that tell you when they do not save, and a Google tag served from your own domain

Free

GTM Kit 2.19.0 is about two things that were previously invisible. A setting that refuses to save now tells you which one and why, instead of accepting your change and quietly showing you the old value back, and WordPress’s own Site Health screen will now tell you if GTM Kit cannot save anything at all. Separately, you can now serve the Google tag from your own domain instead of from Google, which keeps more of your measurement intact when ad blockers and browser tracking restrictions get in the way. The release also closes a real privacy gap on order confirmation pages, and starts pointing out when your setup is leaving data on the table.


What changed

Serve the Google tag from your own domain

Ad blockers and browser tracking restrictions treat a script loaded from Google differently from one loaded by your own site. A first-party path around that is not a new idea, but until now it meant standing up a server-side container, which is a project rather than a checkbox.

GTM Kit can now serve the container loader from your own domain. It is a setting, it is off by default, and it is a genuine alternative to a server-side container rather than a replacement for one.

The part worth reading is what happens when it stops working. Serving a script from your own origin only works while your server can actually reach Google and while the address you serve from stays reachable. Both of those are properties of your hosting, and both can change without anyone touching WordPress. So GTM Kit checks them before it lets you switch the setting on, refuses if either fails, and repeats both checks once a day afterwards. Each check reports in Site Health. If either stops working later, GTM Kit falls back to loading the container the standard way and tells you it has done so.

That is the whole safety story: the feature can fail, and when it fails your tracking keeps running while you find out. A first-party serving path that silently breaks is worse than not having one.

The setting is mutually exclusive with pointing GTM Kit at your own server-side container domain. If you already run one, you already have this, and the settings screen will not let you configure both.

Full setup instructions: Google tag gateway.

When a setting will not save, the screen now says why

This one comes out of a support case that took four days and should have taken twenty minutes.

A site could not save GTM Kit settings. The screen accepted the change, reloaded, and showed the old value. Nothing said anything was wrong. Worse, every route to finding out why ran through the same interface that was failing, so the diagnostic tools were as mute as the settings screen. The one configuration snapshot that did arrive turned out to be from a different site.

Four changes close that off.

A rejected setting now names itself. If a value is one GTM Kit cannot accept, the screen tells you which setting was rejected and why, and nothing is written. Previously a rejected save reported success and showed you your old settings back, so the change appeared to vanish.

A save that does not stick now says so. If GTM Kit writes a setting and reads back something different, it tells you rather than reporting success. On a site with a persistent object cache it names the cache as the likely cause and tells you to flush it, because that is overwhelmingly what it turns out to be.

Site Health checks that the settings interface answers at all. On a site where something blocks or holds those requests, you get a critical result carrying the actual error, instead of a settings screen that fails quietly. The check is explicit that it tested the path from your server to itself, not the path your browser takes, because those are different and the difference matters when you are debugging.

And if you cannot get your system data to us, you can now carry it by hand. On sites running GTM Kit Premium, if sending system data from the Support screen fails or never finishes, the screen now lets you copy it or download it as a file to email instead. The system data also now records whether your site uses a persistent object cache, which is the first thing worth knowing about a save that does not stick. A related fix: when your site cannot reach our support server at all, the screen now says that, instead of claiming your support ticket was not found.

And your password manager will stop filling them in. Browsers were treating GTM Kit’s settings fields as a login form and autofilling them, so a value you never typed could be saved along with the rest of the form, and a value you deleted could reappear the next time you opened the screen. Every text, search, number and password input on the settings screens now tells the browser to leave it alone.

None of this fixes the underlying site. It makes the next such site diagnosable in one pass instead of four days.

Order confirmation pages now reach only the people entitled to see them

Order confirmation URLs get shared. They get forwarded, pasted into chats, and occasionally guessed.

Until this release, anyone opening one received the full purchase data layer: the order contents, its value, and the shopper’s details. The page itself showed them nothing, correctly, because WooCommerce and Easy Digital Downloads both gate what they display. The data layer did not follow the same rule.

It does now. The order confirmation data layer reaches only visitors that WooCommerce or Easy Digital Downloads would actually show the order to.

There is a second half to this that matters more than it sounds. GTM Kit marks an order as tracked once, so a purchase is never counted twice. A withheld view previously burned that mark, which meant a stranger opening a shared link could stop the real customer’s own visit from ever reporting the purchase. A withheld view no longer counts as tracked, so the buyer’s visit still reports normally.

Verified on real stores on both WooCommerce and Easy Digital Downloads. One deliberate exception on the EDD side: an administrator viewing a receipt they do not own does get the event, because EDD grants them that view. That is correct deference to EDD rather than a gap.

Customer details now describe the buyer

Related, and the one change in this release that alters data you may already be collecting.

The customer details attached to a purchase are now taken from the order itself. They were previously read from the browsing session, which meant that on a confirmation page opened by anyone other than the buyer, the customer details described the visitor instead of the shopper who actually placed the order.

GTM Kit now points out what your setup is not measuring

A correctly configured GTM Kit can still be measuring far less than it could. A WooCommerce store with its ecommerce events switched off is the clearest case: everything is green, and not one purchase is being reported.

GTM Kit now notices three of these and says so: a WooCommerce store with ecommerce events off, a site tagging through its own server whose purchases still depend on the browser, and a site loading only the container and nothing else.

Upgrade notes

Nothing to configure. Serving the Google tag from your own domain is off by default and stays off until you switch it on.

One number may move, and it is a correction. If order confirmation links on your store have been opened by people other than the buyer, those views were generating purchase events with the viewer’s details attached. They no longer do. Stores where this was happening will see purchase counts settle slightly lower, and the difference is data that should never have been collected.

One payload changes shape in a narrow case. The customer details on a purchase now come from the order rather than the browsing session. On a normal confirmation page opened by the buyer, the two agree and nothing changes. They only disagreed when someone other than the buyer opened the page, which is exactly the case the change corrects.

If you run a translated site, check your settings screen after updating. Event names that were being translated will now read in English, which is what GTM Kit has always actually sent.