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.
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:
- 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.
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.
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.