← Back to changelog

GTM Kit 2.20.0: the loader Stape issues for your container, and a Safari fix for Cookie Keeper

Free

GTM Kit 2.20.0 is mostly for sites whose server-side Google Tag Manager container runs on Stape. You can now switch to the loader Stape issues for your container, which ad blockers find harder to recognise than the standard one, and Safari visitors on sites using Cookie Keeper get a fix for a loader address that stopped working when Stape changed its identifiers. The release also stops GTM Kit from redoing its update work on every admin page load on sites with a persistent object cache such as Redis.

What changed

Use the loader Stape issues for your container

If you run a server-side container on Stape, the script that loads your GTM container comes from your own sGTM domain. That already helps, but the standard address still ends in a query string that carries your container ID in plain text, which is exactly what an ad-blocker filter list can match. Stape now issues each container its own loader, with a file name and a query that carry no readable container ID.

GTM Kit can now use that loader. Under Server-side Tagging, switch on Get the loader from Stape. The setting is available once your container ID, sGTM container domain and Stape container identifier are filled in.

When you save those settings, or press Refresh loader, GTM Kit asks Stape’s API for the loader. The status line under the setting tells you which loader your pages use and when it was fetched. If Stape cannot be reached, or does not return a loader, your pages keep the standard loader, which still works, and the screen says so. You can then try again, or choose Paste the code instead and paste the Google Tag Manager code Stape shows for your container.

Two things about how this works are worth knowing.

GTM Kit only asks Stape when you do. It sends the request when you save a change to the settings the loader depends on, or press Refresh loader. Never on a schedule, never when a visitor opens a page. The request carries your Stape container identifier, container ID, sGTM container domain and data layer name, plus the Cookie Keeper cookie name when Cookie Keeper is on. No visitor data. That is also why the setting is off by default: the container identifier field is not only used by Stape customers, so GTM Kit does not contact Stape unless you ask it to.

GTM Kit never adds Stape’s code to your pages. It reads the loader address out of what Stape returns, or out of the code you paste, and writes its own container snippet with that address. So everything GTM Kit’s snippet already does still applies: your data layer name, your GTM environment settings, the script attributes your consent platform relies on, and Cookie Keeper’s Safari handling.

If you already use Stape with GTM Kit, nothing changes until you switch this on. Your current loader keeps working.

Setup details: Server-side tracking (sGTM).

Cookie Keeper: Safari visitors could get a loader address Stape rejects

With Cookie Keeper on, Safari 16.4 and later load your container from a slightly different address, so Stape can set cookies that last longer than Safari normally allows. GTM Kit built that address by putting kp in front of your Stape container identifier. That matched what Stape expected while identifiers were eight characters long.

Stape’s identifiers are now longer, and for those Stape expects kp in a different position. GTM Kit sent Safari to an address Stape rejects, so those visitors loaded no container and were not tracked. Chrome and Firefox were unaffected, which is why it was easy to miss.

GTM Kit now builds the address the way Stape does, for identifiers of any length. We checked it in a real Safari against a live Stape container.

Were you affected? Only if Cookie Keeper is on and the Stape container identifier in GTM Kit is longer than eight characters. If both are true, expect Safari traffic in your reports to rise after updating. That is visitors who were there all along.

More on Safari and cookie lifetime: Safari ITP and cookie lifetime.

A faster admin on sites with Redis or another persistent object cache

After an update, GTM Kit runs a short update routine once and records the new version. On a site with a persistent object cache, the cache could keep handing back the old version number, so GTM Kit decided on every admin page load that it still needed to update, and ran the routine again. That included admin-ajax requests, so it could slow down more than the pages you were looking at.

GTM Kit now clears that cached value when it records the new version, so the routine runs once. The routine also no longer logs a notice from Action Scheduler the first time it runs. GTM Kit Premium gets the same fix in its own update.

Clearer wording on serving the Google tag from your own domain

The 2.19.0 setting that serves the Google tag from your own domain now describes itself more precisely. It changes where the tag loads from. The measurement the tag sends still goes to Google, unless your CDN or host provides Google’s tag gateway, which this setting cannot switch on. The setting behaves exactly as before; only the description changed, to match the correction we made to the 2.19.0 release notes.

Developer notes

  • No new hooks. No gtmkit_* filter or action is added in this release.
  • New option: general.sgtm_stape_issued_loader (boolean, default false). When it is on and a loader has been fetched or pasted, the container snippet uses that loader’s path and query. It is ignored when the Google tag gateway is on.
  • No event or data layer changes.

Upgrade notes

  • Nothing changes on update. The Stape loader is opt-in.
  • If Cookie Keeper is on and your Stape identifier is longer than eight characters, Safari traffic should rise after updating (see above).