One of our clients was recently contacted by their French legal team about the expiry dates of some of the cookies being used on their site. They had some that were well over the 12 months that the French team were happy with; some of them were set to three years, and one was 16 years. So what can be done?
Sometimes there’s nothing you can do about the expiry – it is usually set by the (server side) code that writes the marketing pixel. In these cases you will need to contact the provider and ask them to reduce the expiry on their cookies. I’ve had mixed results from doing this in the past. At a previous company we managed to get DoubleClick to reduce their expiry, but other vendors have refused.
However we did discover an Adobe setting that can be used to overwrite the expiry of all the cookies that are set via the internal cookieWrite (or c_w) function.
This is a property of the s object that can be used to limit the lifetime of all cookies written by the scode function. It has three valid values, “SESSION”, “NONE” or a number representing an expiry period in seconds.
“NONE” will mean that scode does not set any cookies. This may impact your reporting capabilities, if you rely on cookies (for example the “previous page” and “performance timing” plug ins both require a cookie).
If you use DTM or Launch then this property can be set from within the Adobe Analytics Tool configuration options.
In Launch, go to the “Extensions” tab, find the Adobe Analytics Extension and click the “Configure”.
In DTM, click the Gear icon on the Adobe Analytics Tool. The drop down is in the Cookies section.
If you use Tealium or another TMS, then you’ll need to set the property manually in the code. It should be set before you call doPlugins:
// Do not write any cookies s.cookieLifetime = "NONE"; // Expire all cookies at the end of the session s.cookieLifetime = "SESSION"; // Expire all cookies after 1 week s.cookieLifetime = "604800";
Notice the seconds value is still a string (ie text, encased in quotes), even though a number is being passed. The code that uses this number can deal with it being a number or a string, but the documentation does specify that it should be a string value.
Some commonly used periods of time in seconds are (don’t include the commas if copy/pasting into some JS code):
1 day: 60 x 60 x 24 = 86,400
1 week: 86,400 x 7 = 604,800
30 days: 86,400 x 30 = 2,592,000
6 months: 86,400 x 182 = 15,724,800
12 months: 86,400 x 365 = 31,536,000
13 months: 86,400 x 392 = 33,868,800
2 years: 31,536,000 x 2 = 63,072,000
Ben Stephenson has worked as a consultant for 120Feet for nearly three years. He has ten years of development experience on ecommerce websites, and five years of Digital Marketing experience as an ecommerce manager looking after a large multinational collection of websites for a Travel and Tourism company. In his spare time he plays guitar, builds with Lego and takes photos (sometimes featuring the guitar or the Lego).