OK, that\u2019s one unappealing title for a blog post, but rest assured that the content more than makes up for this obscurity.<\/p>\n
Recently, my favorite toy in the world, Google Tag Manager\u2019s server container<\/a>, introduced the capability to handle asynchronous operations<\/strong> in variables.<\/p>\n This is done through a JavaScript interface known as Promise<\/a>. A Promise<\/strong> is a way to run code in JavaScript without knowing what its eventual value will be. The \u201cpromise\u201d part of this concept means that the code promises<\/em> that it will reach a value eventually, so other code that relies on this value can execute accordingly.<\/p>\n In this recent update, server-side tagging APIs<\/a> have been updated to handle Promises.<\/p>\n What this means in practice<\/strong>, is that you can attach a variable to a tag, have that variable return a Promise of completing an asynchronous operation<\/strong>, and the tag will automatically wait<\/strong> for the Promise to resolve before completing its work.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n And so what, I hear you ask? You can finally enrich data streams that pass through a Server container<\/strong> without having to create custom Clients and Tags for it!<\/p>\n Just note that everything we go through in this article implicitly requires you to utilize or build custom templates<\/a>, as server-side Google Tag Manager doesn\u2019t have a \u201cCustom JavaScript variable\u201d option to run ad hoc code with.<\/p>\n<\/blockquote>\n \n \n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n <\/span><\/p>\n Previously, variables in Google Tag Manager were processed synchronously<\/strong>.<\/p>\n This meant that when the GTM runtime started parsing a variable, it executed it row by row until it reached a If the variable tried to run an asynchronous<\/strong> operation, meaning it did something that would eventually<\/em> return a value but not when the variable was synchronously executed, the variable would just return an <\/p>\n <\/a><\/p>\n<\/div>\n With this change, variables can now return a Promise<\/strong>, which the runtime code then waits to resolve before proceeding. In other words, the variable doesn\u2019t have to resolve to a value immediately \u2013 it can return a solemn promise that it will eventually reach a value (of course within a given timeout<\/strong>).<\/p>\n And why is this a big deal? Because until now, if you wanted to have your tags<\/strong> and Clients<\/strong> wait for some asynchronous operation, you had to embed these asynchronous calls into the tag \/ Client code itself.<\/p>\n Now all you have to do is make sure the variable returns a Promise, and whatever called the variable will dutifully wait for that Promise to be either resolved or rejected.<\/p>\n Luckily, you don\u2019t have to worry about the Promise interface itself.<\/p>\n Although you can<\/em> use the new Here\u2019s an example of using The To work with them, you just need to utilize the new Promise-friendly syntax. If you\u2019re running this in a variable, remember that the variable needs to return the Promise<\/strong>. The actual return value will be set to what the Promise instance methods ultimately return<\/strong>.<\/p>\n Promises timeout after 5 seconds<\/strong> if neither resolved nor rejected. If the API has its own timeout set (such as the Here\u2019s an example of how you would approach a simple GET request. This API polls the Circle.so public API<\/a> and returns the number of members in the community the authentication token is created for.<\/p>\n Promises have three<\/strong> methods:<\/p>\n So in the example above, I\u2019m only focused on successful resolution<\/strong>, but I could just as well add a To prevent the same API call from being made over and over again, there\u2019s a caching<\/strong> mechanism in place. The cache is scoped to the incoming request, so once a new request comes in to the Server container, the cache is reset.<\/p>\n The cache only works if the response is cacheable<\/strong>. In other words, the cache isn\u2019t forced<\/em> on resources that should not be cached.<\/p>\n If you want to add additional caching with more control, you can utilize the ![\"Asynchronous](\"https:\/\/www.simoahava.com\/images\/2022\/02\/asynchronous-variables-server-side-gtm.jpg#ZgotmplZ\")
<\/p>\n\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\nWhat\u2019s changed<\/h2>\n
return<\/code> statement in the execution context. That value was then returned to whatever source invoked the variable in the first place.<\/p>\nundefined<\/code> value because GTM wouldn\u2019t wait around for the variable to complete.<\/p>\n![\"Asynchronous](\"https:\/\/www.simoahava.com\/images\/2022\/02\/ga4-async-tag.jpg#ZgotmplZ\")
<\/p>\nHow to work with Promises<\/h2>\n
Promise<\/code> API to create custom Promises, and the more hard-core programmers out there can certainly make use of Promise.all<\/code> to chain together multiple Promises, many built-in server-side tagging APIs have been automatically updated to utilize the Promise interface.<\/p>\nPromise.all<\/code> in a variable template:<\/p>\n\/\/ Run multiple API calls and return a single Promise that's resolved when all the API calls have resolved\n<\/span>const<\/span> Promise<\/span> = require('Promise'<\/span>);\nconst<\/span> sendHttpRequest = require('sendHttpRequest'<\/span>);\n\nreturn<\/span> Promise<\/span>.all([\n sendHttpRequest(FIRST_API_URL, FIRST_API_OPTIONS), \n sendHttpRequest(SECOND_API_URL, SECOND_API_OPTIONS)\n]).then(results => {\n \/\/ results will equal [{statusCode: 200, headers: {}, body: ...}, {statusCode: 200, headers: {}, body: ...}];\n<\/span> if<\/span> (results.filter(result => result.statusCode === 200<\/span>).length === 2<\/span>) {\n return<\/span> \"Both API calls executed successfully!\"<\/span>;\n } else<\/span> {\n return<\/span> \"Oops, something went wrong!\"<\/span>;\n }\n});\n<\/code><\/pre>\n<\/div>\nHow existing APIs have changed<\/h2>\n
BigQuery<\/code>, sendHttpGet<\/code>, and sendHttpRequest<\/code> APIs (and the new Firestore API<\/a>!<\/em>) are likely to be the ones you\u2019ll be using most in this new context. They let you run asynchronous HTTP requests to endpoints (such as your enrichment API), and the response can be then used to enrich your tags\u2019 and Clients\u2019 data streams.<\/p>\n\n
sendHttpRequest<\/code>), then that will be honored instead.<\/p>\n<\/blockquote>\nconst<\/span> sendHttpRequest = require('sendHttpRequest'<\/span>);\nconst<\/span> JSON = require('JSON'<\/span>);\n\nconst<\/span> AUTH_TOKEN = 'XXXXXXXXXXXXX'<\/span>;\nconst<\/span> API_URL = 'https:\/\/app.circle.so\/api\/v1\/community_members'<\/span>;\nconst<\/span> OPTIONS = {\n headers: {Authorization: 'Token '<\/span> + AUTH_TOKEN},\n method: 'GET'<\/span>,\n timeout: 2000<\/span>\n};\n\n\/\/ Return the Promise\n<\/span>return<\/span> sendHttpRequest(API_URL, OPTIONS).then(success_result => {\n const<\/span> members = JSON.parse(success_result.body);\n \n \/\/ When the Promise resolves (successfully), the length of the array in the response body is returned\n<\/span> return<\/span> members.length;\n});\n<\/code><\/pre>\n<\/div>\n\n
.then()<\/code> takes two functions as parameters (above I only use the first one, though). The first is for what happens when the Promise is resolved successfully, and the second is for what happens when the Promise is rejected.<\/li>\n.catch()<\/code> takes a single function as a parameter, and it\u2019s executed if the Promise is rejected. This is a handy way to isolate code only for error resolution.<\/li>\n.finally()<\/code> takes a single function as a parameter, and it\u2019s always<\/strong> executed whether the Promise was resolved or rejected.<\/li>\n<\/ul>\n.catch()<\/code> step there to handle issues. However, as this is a simple GET request, I don\u2019t see any reason to specifically treat error cases, so I\u2019m OK with the variable returning undefined<\/code> in case it runs into an error.<\/p>\nCaching<\/h2>\n
templateDataStorage<\/code> API<\/a> for this.<\/p>\n