Server-Side Cookies: What They Do for Returning Customers and Where They Stop

A server-side cookie is a cookie your website's server sets in an HTTP response, as opposed to one written by JavaScript in the browser. It's still stored in the visitor's browser, but browsers often let it live much longer. That makes returning customers on the same device easier to recognize, up to a point this post will spell out.

If you sell something people rebuy, that longer life matters. A customer who bought a bag of coffee five weeks ago may come back on the same phone with no account login. Whether your store knows them depends partly on how the cookie was written.

How does a server-side cookie differ from a script-set one?

Every cookie reaches the browser in one of two ways. A script running on the page can write it, using JavaScript. Or the server can include a Set-Cookie header in its response when the browser requests a page. The second kind is the server-side cookie, sometimes called a server-set or HTTP cookie.

	Script-set cookie	Server-side cookie
Written by	JavaScript on the page	The server, in an HTTP response
Stored in	The browser	The browser
Safari's 7-day script cap	Applies	Not covered by that rule
Readable by page scripts	Yes	Not if marked HttpOnly
Setup	Add a tag	Needs a server response on or near your domain
Crosses devices	Never	Never

The name causes confusion. "Server-side cookie" is often used alongside "server-side tracking", which means sending events from a server to a platform. They're separate things. A brand can have one without the other.

Why do server-side cookies last longer?

Browsers treat script-writable storage with more suspicion, because tracking scripts have used it heavily. WebKit's tracking prevention policy sets a 7-day cap on script-writable storage. Cookies from HTTP responses aren't covered by that JavaScript rule.

Klaviyo's cookie documentation is a useful real example. Its __kla_id cookie is set by JavaScript for two years, though browsers can shorten that. Safari deletes it after 7 days of browser use without interaction with the site. Klaviyo's server-set __kle_id, used by its First-Party ID feature, can restore __kla_id after it's lost. Elevar (now sold as Audiense Online) describes a first-party, one-year server-set cookie in its docs.

What are the advantages?

• Longer memory on the same device. A customer who returns after several weeks is more likely to be recognized by the same browser, and consumable buyers often return on that sort of gap.
• A way to restore what got deleted. A durable server-set identifier can bring back a shorter-lived one, which is how Klaviyo uses its First-Party ID.
• Better protection from page scripts. An HttpOnly cookie can't be read by JavaScript on the page.
• Fewer missed triggers. If a tool recognizes a browser for longer, flows relying on that recognition have more people to work with on that device.

Where do server-side cookies stop working?

Quick summaries tend to leave these out. Each of these limits is a real one.

Exception	What happens
Safari and mismatched IPs	Safari 16.4 can cap server-set cookies at 7 days when the setting server's IP doesn't match the first half of the site's IP, per Aimerce's write-up. Elevar's docs carry a similar caveat.
Safari and CNAME setups	WebKit has a defense against CNAME cloaking. Klaviyo says the 7-day cap applies to its server-set cookie when a subdomain points to a cross-site host.
Brave	Per Klaviyo's docs, Brave caps script-set cookies at 7 days and server-set cookies at 6 months.
Chrome	Cookies last up to 400 days, per the same docs. That's a long time, and it does have an end.
Other devices	A cookie stays on one browser on one device. A phone never sees a laptop's cookie.
Consent	Your consent banner still applies however the cookie was set.
Unknown people	A cookie can tie a browser to a person only if that person was identified at some point. Klaviyo's First-Party ID identifies only people with an existing profile.

A customer can also clear their browser data or use a private window, and no cookie survives either.

So the accurate summary goes like this. A server-side cookie often extends recognition on the same browser, sometimes for many months. Whether it reaches that in Safari depends on how it was implemented, so ask any vendor how theirs is hosted and what they see in Safari. A durable cookie does nothing for the cross-device cart problem.

How do you recognize returning customers when browser cookies go away?

Assume the cookie will sometimes go away, and design for that. The most durable approach treats the cookie as a convenience and keeps the real memory somewhere else.

Three ideas do most of the work.

Keep the record on a server. If what you know about a customer lives only in the browser, losing the cookie loses it all. A server-held record of orders, carts and contact details survives. The browser only needs a way to point at it.

Give people ways to reconnect. Customers identify themselves all the time in ordinary use. They click an email sent to their own address, or they log in, or they enter an email at checkout. Each of these can reconnect a browser to a known person, including a brand-new browser on a device you've never seen.

Separate the device from the person. Device recognition says "this browser has been here before". Returning customer recognition says "this is someone who has bought from us". A shared family tablet shows why the difference matters, and it's a reason to hold back sensitive details when your confidence is low.

Situation	What can recognize them	Does a durable cookie help?
Same phone, five weeks later	A surviving cookie	Yes, if it survived
Same phone, cookie deleted	A new email click or login	No, reconnection does the work
New device, from an email	The email click plus a server-held record	No
New device, no click, no login	Nothing first-party	No

That last row is the honest limit of first-party recognition. Some vendors fill it with shared identity networks, which is a different choice with its own trade-offs.

Should you add server-side cookies to your stack?

Start with what you already pay for. If you're on Klaviyo, its Extended ID is on all plans, free and paid. Turn that on first, then read our comparison of Extended ID and First-Party ID. Then look at how many shoppers you still appear to be missing. A vendor can help with what remains, and your Safari questions above are a good way to compare them.

What does reOtter do about this?

reOtter recognizes people who've already given your brand their details, without a third-party network, in a record that doesn't depend on a browser cookie surviving. It doesn't identify strangers and it doesn't use a shared identity network.

That recognition is there to serve the customer on the page. A recognized returning customer can see their usuals and due items through the on-site widget, with no login. And when someone clicks a cart email from your Klaviyo flow, the cart recovery page puts their cart back on whatever device they're on, when reOtter holds the cart and knows who clicked. Carts are held only with analytics consent from your store's banner, and held carts last 30 days. If the cart isn't held or the clicker isn't known, the shopper sees the page with whatever cart that device has.

If you want to see where recognition leads once a shopper clicks, start with our abandoned cart recovery page.