Keep ad click cookies alive past Safari's 7-day limit
A shopper clicks your ad on her iPhone and comes back to buy ten days later. With browser-only tracking her click cookie is already gone. With the cookie keeper, your own server has kept it.
Illustration of the event flow
What you get
Why script cookies expire
Safari's Intelligent Tracking Prevention caps cookies set by JavaScript at 7 days (24 hours after some ad links). That includes the Meta Pixel's _fbc and _fbp.
Your server, not ours
Cookies set by your own web server are not capped. Once a day the SDK asks your site to re-issue the tracking cookies it already has, for 400 days.
Why not a tracking subdomain
Safari treats a subdomain that points (CNAME) to another company's server as cloaked and caps its cookies at 7 days too, so the refresh has to come from your own server.
Cache-safe and consent-aware
It runs on a POST endpoint that page caches never store, re-issues only known tracking cookies in their own format, and skips ad cookies when ads consent is denied.
Set up in minutes
- 1WooCommerce: nothing to do, the plugin adds /wp-json/trakero/v1/keep and tells the SDK.
- 2Next.js: add a POST route that returns cookieKeeper(req) from @trakero/node and pass its URL as keeper in init.
- 3PHP/Laravel: call Trakero\CookieKeeper::refresh() from a POST route and pass its URL as keeper.
Questions
Does this get around privacy protections?+
It keeps first-party cookies your own site sets, which is what Safari allows. Cookies are not shared with other sites, and ad cookies are not set when the shopper denies ads consent.
What about Chrome and Android?+
Chrome does not shorten first-party script cookies this way; the keeper matters most for iPhone and Mac Safari shoppers.
Platform rules from WebKit: Tracking Prevention, WebKit: CNAME cloaking defense.