Browser Cookie Restrictions and Mapp Intelligence

Prev Next

Browsers increasingly limit how long websites and analytics tools can keep cookies and which cookies they accept at all. Apple's Safari with Intelligent Tracking Prevention (ITP) is the best-known example, but other browsers apply their own rules. This article explains how these restrictions affect Mapp Intelligence and which setup keeps your visitor recognition as stable as possible.

Browser rules change with new releases. This article therefore describes principles and does not list limits for specific browser versions. For the current rules, see the documentation of the browser vendor.


Why Browsers Restrict Cookies

Browser vendors want to prevent people from being followed across websites without their knowledge. To achieve this, browsers limit cookies in several ways, for example:

  • Cookies that are created by JavaScript on the page (client-side cookies) can be removed after a short time.

  • Cookies that a website sets in the context of another website (cross-site cookies) can be blocked or restricted.

  • Information that is passed in URL parameters can be treated as a tracking signal, and cookies that store it can be shortened.

These measures are aimed at cross-site advertising, but they can also affect analytics cookies.


What This Means for Mapp Intelligence

Mapp Intelligence recognizes returning visitors with the everId. It is stored in a cookie and is the basis for the visitor metrics. For an overview of all cookies, see Which Cookies Are Set by Mapp Intelligence?

If a browser removes this cookie before it expires, the device is recognized as new on its next visit. The number of counted visitors rises, and the share of returning visitors falls. How strong the effect is depends on how many of your visitors use browsers with strict cookie rules, for example Safari.


Client-Side and Server-Side Cookies

Mapp Intelligence can set its cookies in two ways:

  • Client-side cookies: The tracking script creates the cookie in the browser (cookie option 1 in Pixel Version 4/5). Mapp documentation also calls these first-party cookies.

  • Server-side cookies: The response of the track domain sets the cookie (cookie option 3 in Pixel Version 4/5). Mapp documentation also calls these third-party cookies. With a custom track domain, the track domain is a subdomain of your own website.

Server-side cookies are less exposed to restrictions that target cookies created by JavaScript. They make sense with a custom track domain that is a subdomain of your own website. Without it, the cookie belongs to a different domain than your website, and browsers treat it as a cross-site cookie.

Note

Server-side cookies are not exempt from every restriction, because browser rules differ and change over time. Browser cookie restrictions can apply to a custom track domain with a CNAME and with an A/AAAA-Record alike. The A/AAAA-Record mainly helps against tracking blockers. See Custom Track Domain.


Recommendation

Use a custom track domain and send all tracking requests via HTTPS. If your track domain is a subdomain of your own website, you can additionally use server-side cookies.

Use a Custom Track Domain

A custom track domain is a subdomain of your own website that receives your tracking requests. It improves the completeness of your data and is the prerequisite for server-side cookies on your own domain. Setup steps are described in Custom Track Domain.

Send All Tracking Requests via HTTPS

The server can only set a secure cookie if the tracking request is sent via HTTPS. How you enable this depends on your integration:

  • Smart Pixel and AMP extension: Requests are sent via HTTPS by default.

  • Tag Integration: Activate the checkbox Send all pixel requests via HTTPS in the advanced settings.

  • Pixel Version 4/5: Set the configuration property forceHTTPS in the global configuration.

For details, see Pixel V4/5: Advanced.

Switch to Server-Side Cookies

Switch to server-side cookies only if your track domain is a subdomain of your own website. How you switch depends on your integration:

  • Smart Pixel: Set the property cookie in wtSmart.init. The value 1 creates client-side cookies and is the default. The value 3 creates server-side cookies.

  • Tag Integration: Select the option for server-side cookies (third-party) in the setting Cookie settings of the Mapp Intelligence plugin. Client-side cookies (first-party) are the default.

  • Pixel Version 4/5: Set the cookie option to 3, as in the examples below.

Example: Global Configuration

var webtrekkConfig = {
	trackId: "111111111111111",
	trackDomain: "data.exampleshop.com",
	domain: "www.exampleshop.com",
	cookie: "3"
};

Example: Page-Specific Configuration

var wt = new webtrekkV3();
wt.cookie = "3";
wt.contentId = "de.startseite";
wt.sendinfo();

Important

Existing cookies are lost when you switch from client-side to server-side cookies. Without further action, all returning visitors receive a new everId and are counted as new visitors.

Keep Existing Visitor IDs

To keep existing everIds when you switch to server-side cookies or move to a new track domain, use the Cookie Control Plugin. It migrates the existing cookies to the new setup.

Use Server Sampling

Pixel Sampling stores its decision in a cookie in the browser. If you use Pixel Sampling, switch to Server Sampling. Contact your Mapp Intelligence Customer Success Manager for activation and configuration.

Important

When you change from Pixel Sampling to Server Sampling, the users who are currently sampled are not taken over.

Use the Server-Side Opt-Out

The opt-out cookie is also subject to browser restrictions. If a browser removes it early, visitors have to opt out again. The server-side opt-out prevents this. See Privacy: Setting the Opt-Out Cookie.


After a Track Domain Change

If you move to a new track domain, further parts of your setup can still point to the old one, for example Marketing Automation, server-to-server tracking, or API calls. See Adjusting Your Setup After a Track Domain Change.

FAQ

Are only Safari users affected?

No. Safari with ITP is the best-known example, but other browsers also restrict cookies, each with its own rules. The recommended setup on this page applies to all browsers.

Does a custom track domain protect my cookies from browser restrictions?

A custom track domain mainly helps against tracking blockers. Browser cookie rules can still apply, for a CNAME and for an A/AAAA-Record alike. Server-side cookies on a custom track domain are less exposed to restrictions on JavaScript-created cookies, but they are not exempt from every restriction.

Why do more returning visitors appear as new visitors?

One possible reason is that a browser removed the everId cookie before it expired. Check whether the track domain is called via HTTPS and whether your cookie setup matches the recommendation on this page. If you recently changed the track domain, also check whether you migrated the existing cookies.