There are definitely ways, it depends on your use-case.
For example, if your deployment uses utag.sync.js, you could make sure that the script reference includes a Math.random cachebuster (e.g. utag.sync.js?cb=0.54245424), and then have utag.sync.js write its current ##UTVERSION## value into a global variable, that's then used as a cachebuster on your request for utag.js. What that means is that every customer will be forced to download a fresh utag.sync.js with every pageview (so you lose cache efficiency there), but will always get the new utag.js if the published version has changed. This is not dissimilar to the way in which the individual tag files are cachebusted only on change, but it does impact performance due to the need to re-download utag.sync.js on every page.
Alternatively, if it's just for testing purposes, you can use thing like Chrome dev tools to disable caching of resources, or add an optional cookie-based cachebuster to the utag.js request that allows you to set a cookie to force a cachebusted request.
All things are usually possible, just depends on exactly what you need, and what cost (i.e. complexity, performance, changes to the way the resources are loaded) you can live with.
... View more
Yes, you're right. I've come across this issue before. Doing the setTimeout isn't ideal as you say but the queue is a good idea. I wrote something like this a while ago and I've just re-jigged it. Here it is:
Run this as an extension:
Run this code in-line to queue calls (or fire them immediately if utag.view() or utag.link() exist):
I hope this helps!
... View more