AMP support
How GTM4WP loads a Google Tag Manager container on the AMP version of your pages, what data it sends, and what it cannot do there.
This page describes GTM4WP 2.0.0 and newer. Where the legacy 1.x versions of the plugin behaved differently, the older behavior is marked with a bold GTM4WP 1.x: lead-in.
What you need first
AMP support only does something on a site that produces AMP pages, which means the official AMP plugin from the AMP Project. GTM4WP hooks into that plugin and lets it build the markup, so it works in all of its template modes: Standard, Transitional, Reader, and the deprecated Legacy Reader mode.
GTM4WP 1.x: the integration only ran in Legacy Reader mode, because it relied on hooks that the newer modes do not fire. On a site using Standard or Transitional mode nothing was added to the AMP pages at all.
You also need a container of the AMP type in Google Tag Manager. An AMP container is a different container type from the web one and has its own ID, its own tags and its own triggers. You cannot use your web container ID here. Google describes how to create one in its help center article on the AMP snippet.
The setting
Google Tag Manager “AMP” Container ID
Default: empty, which means nothing is added to your AMP pages.
Enter the ID of your AMP container, in the same GTM-XXXXXX format as a web container. To load more than one, separate the IDs with a comma and no space.
With a value here, two things change on an AMP request. The AMP plugin adds an <amp-analytics> element for each container you listed, pointed at Google’s remote configuration for that container. The normal web container code is left out of that request, so a page is never tagged twice.
What reaches the container
GTM4WP hands the compiled data layer to the AMP element as its analytics variables. Everything the plugin works out on the server is therefore available to your AMP tags: the page and post attributes, the site and visitor data, the search term, and the WooCommerce values that are written when the page is generated.
What does not reach it is anything the plugin normally measures in the browser. The AMP runtime does not run arbitrary JavaScript, so the trackers that produce media events, form interaction events, the add to cart and checkout events, and the click events on product lists cannot run. Those events exist on the regular version of the page only.
The practical consequence is that an AMP container is worth setting up for page level measurement, and that conversion tracking that depends on a visitor interacting with the page belongs on your canonical pages rather than the AMP ones.
Checking that it works
Open the AMP version of a page and view its source. Search for amp-analytics: you should find one element per container ID you entered, each with a configuration URL containing that ID, followed by a block of JSON holding the data layer values.
If the element is there but your tags do not fire, the problem is on the Google Tag Manager side rather than in WordPress. Check that the ID belongs to an AMP container and that the container has been published.
If the element is missing entirely, the request was probably not an AMP request at all. Confirm that the AMP plugin is active and that the URL you opened is the AMP version of the page.
