Cookie extender Tag vs Cookie saver plugin

Hi there,

I have some doubts about implementing Cookie extender Tag (+ Data event/Data client) as described here vs Cookie keeper plugin as described here.

What I understood about the two systems:

  • Cookie extender Tag (+ Data event/Data client)

This solutions sets, via SGTM, a 1st party cookie set by gtm.yourdomain .com which stores all the main cookies from advertising vendors; in case a single cookie from Meta or Google or equivalent gets deleted from tracking prevention technologies, the cookie is restored with the ID saved in the Cookie extender own cookie.

The data event/data client solution allows Tags as the Meta client side tag to be delayed until the Meta server side tag fires, allowing the latter to set a server side cookie which bypass Safari ITP storage 7 days/24 hours limits.

There are two problems I see with this method.

  1. In Safari 16.4+, server-side cookies are now set with a maximum duration of 7 days even if they are considered 1st party but set from the IP that differs from your website IP.
  2. The data layer push send back from the server is often too slow to arrive, resulting in potential missing Meta client side page views.
  • Cookie keeper plugin

This solutions sets, via the site itself, a 1st party cookie set by yourdomain .com which stores all the main cookies from advertising vendors; in case a single cookie from Meta or Google or equivalent gets deleted from tracking prevention technologies, the cookie is restored with the ID saved in the Cookie extender own cookie.

I see no issues in using this method. Event if ITP deletes the cookie after 24 hours, Cookie keeper will restore it.

Did I understand correctly?
Can we can deprecate the Cookie extender Tag (+ Data event/Data client) solution in favour of the Cookie keeper plugin?

Thanks,
Matteo

Hi,

Thanks for the detailed question.

The Cookie keeper plugin works at the moment only with Safari.
Basically, the code checks if this is Safari or another browser.
That’s done for backward capability. And currently, only Safari 16.4 has these new restrictions.

Cookie extender Tag
It only prolongs desired cookies from the server.

So I think the best option use both and disable the use of backup in Cookie extender Tag as it was made only for Safari.

Ok thank you for making this clear

I activated Cookie extender as advised.

I also activated your Stape Wordpress plugin and Cookie keeper flag.

These are my Google and Meta server side setup:

Here are cookies set in Chrome:

Safari:

I was expecting to see _ga and _fbp cookies expire age set to 2 years.

What am I missing here?

Thanks.

Hi Matteo,

  • Cookies cannot be older than 2 years. The maximum time is 13 months. More info about cookie status here https://www.cookiestatus.com/
  • In Safari cookies will not be renewed in new versions. That’s why there is a cookie keeper, it restores old cookies and does not make cookies have a longer lifetime.
  • From your screenshot it looks like you are also using a web fb pixel, which can override the lifetime of cookies. But this is fixed by the cookie keeper.

Hi Dmytro,

thanks for the “maximum length of 13 months for cookies on Chrome” specification, I didn’t know that.
I guess this addresses the 13 months expiration date for _ga cookie on Chrome, but what about the _fbp cookie I posted above?

I can confirm that in this case I’m using FB pixel server side tag only. I do not have any client side FB pixel. The cookie is set from the server. In this case, shouldn’t the expiration date being set to 13 months in Chrome and 24 months in Safari?

Moving on, basically you are saying that, no matter the cookie expiration date, the Cookie keeper plugin will restore cookies from a backup in case ITP deletes it (if the browser is, of course, Safari).
That’s cool.

Where I can check this backup?

The recommended by Meta expiration date for _fbp cookies is 90 days.

You can refer to our article for a cookie recovery test: