Tealium Tools — Simple Cookie Setter

Brian Johnson
3 min readFeb 25, 2021
Colorado Landscape + Farm House

As much as I want to get away from cookies — I mean, totally abandon them — I can’t. At least, I haven’t found a way quite yet. With all of the recent and ongoing changes in browser security and privacy, I’m sure this move will be forced upon me soon enough. Until then, if I‘m stuck with them, I’m going to keep looking for smarter and easier ways to make them work for me.

So, how does this relate to Tealium IQ (TiQ)?

In the process of migrating a client site from one tag management tool to TiQ, I found that TiQ doesn’t have a simple cookie-setting mechanism*. The reason this presents a challenge is probably best illustrated with an example:

  • On page load, I map the first-party “my-id” cookie value to a tag using the typical data layer configuration. This mapping leverages the utag_data[“cp.my-id”] data layer value, which only updates on page load.
  • At some later point while on the page, the “my-id” cookie is updated. Unfortunately, the cookie value is not re-read, and the utag_data[“cp.my-id”] variable still shows the old value.
  • Before navigating away from the page, a different tag fires, also mapped to the “my-id” data layer variable. Unfortunately, the value passed is the original value (first bullet above) and not the new/updated value (second bullet above).

Because, in my situation, the cookies I’m dealing with are both set and consumed by the tag manager, I have the flexibility to ensure that both the cookie and the utag_data[“cp.my-id”] variable are updated at the same time.

My solution…

Because the cookies I’m dealing with are both set and consumed by the tag manager, I have flexibility here. Specifically, I’m able to create a function (extension) that both sets/updates the cookie and updates the utag_data[“cp.my-id”] variable, ensuring the values are always in synch. Here’s how it works:

Tealium Data Layer — First Party Cookie
  1. First, create the first party cookie data layer variable. For this example, name it “my-id”. This variable can be used with any tag, load rule, or extension.
  2. Create a custom Javascript extension with the code snippet shown below. Timing can be whatever you want (BLR, ALR, etc). Used as-is, the setCookie() function will only be accessible inside the extension, but it can easily be modified for access elsewhere. (Note: You’ll need to change the cookie domain to something appropriate for your website on line 9, and may want to modify the cookie path on line 10.)
    In the code snippet, you’ll find an example showing how to store the “my-id” query parameter value the “my-id” cookie, updating the data layer variable at the same time.

Get the code!

JavaScript Code — setCookie() with Data Layer Synch Functionality

You can test this by publishing the above changes and loading the page with the ?my-id=example query parameter. After the page loads, check for the values of both the “my-id” cookie and the utag_data[“cp.my-id”] data layer variable. You should find that they all match with the “example” value.

That’s it. It’s a simple cookie setter that keeps your data layer variables in synch with what’s in the actual cookies. If you find this helpful, let me know!

*That’s not to say that they don’t have cookie resources, because they do. It’s just that they add some (pretty cool) complexity, which would require me to change cookie names, which I’m not in the position to do.

--

--