Problems with sub-profile caching?

[reid_linker]

Has anyone encountered problems of heavy caching when using the Tealium Profile Loader to load another profile? I have found that the sub profiles do not expire/update as quickly as when working with the profile directly. Can this be overcome using any Publish Settings (Session Timeout) or debug settings in browser (Firebug, Chrome Dev Tools, Fiddler, etc)?

[robert_alderson]

We experienced caching issues in general, and often had to wait up to 5 minutes for the next uncached version. This was unacceptable for development. Jared gave us a tip of adding a cachebuster parameter to the main Tealium js call. After that, we always got a new version each page request. It was a great solution. You could try the same

[reid_linker]

Thanks, I'll give this a try!

[sam_tsai]

Use params with caution when cache busting. There are alternatives that might be safer/reliable as described by Steve Souders (http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/) - somewhat dated, but I think the suggestion still applies. If you only use querystrings in development than it shouldn't be an issue, but if it's meant for production as well, I'd suggest alternatives, like versioning. And I've heard too that Tealium sets a 5-minute cache expires, so that's where that wait comes from.

[Clint]

Sam, utag.js does have a 5 min TTL on our CDNs. From the end user perspective (your browser) 5 minutes is the maximum amount of time that you'd have to wait for an updated file but it often occurs more quickly.

[simon_chong]

The sub profile loader had a bug where the query string (cache busting timestamp of the published date) of the sub profiles didn't get refreshed if changes only specific to a tag (in the sub profile) were made. I think its been fixed but if you still have the problem you can fix it by adding a (All Tags) Javascript Code Extension to the sub-profile and then adding the code "var x=1;". Ever time you publish if you increment x ie "var x=2;" it should cause it to refresh the sub profile. Then after 5 mins republish the parent profile and it should come through. I think this is the same solution that Robert is describing.

[fiann_ohagan]

Simon, you are correct that the bug has been fixed. The problem was caused by the parent profile requesting a version of the sub profile with a cache buster param. When we published the sub profile, it updated the file on the CDN, but they retained the old version with the specific cache buster on it. That's resolved now, so it's not necessary to republish the parent profile any more.

[fiann_ohagan]

Your browser settings also affect this. Although we have a max 5 mins time-to-live, it usually takes no more than 1 or 2 minutes maximum for the updated file to hit the CDN. If you routinely see the file not updating for 5 mins or more, then it's worth changing the "check for new versions of file" setting to Always rather than Automatically.

[sebastian_koeni]

One year later - same problem? I see a utv parameter attached to the subloaded profile. This does not get updated. The version I get is one from yesterday were there were some deployments today, which are more than 1hour old. So still some caching issues here. Any ideas, why this happens and how to resolve it? Possible solution would be to attach the session ID (utag_main_ses_id) to the request, so at least it would refresh for every session.

[Clint]

Hi Sebastian, profile sub-loading has been a deprecated feature for some time. I suggest reaching out to your account manager to discuss the issue and potential solutions.