Cookies used by Marfeel

The Marfeel SDK sets 2 first-party cookies in the publisher domain. The first cookie stores persistent user information: the unique user identifier, the registered user ID when provided, the first visit time, the previous visit time, and the original referrer. The second is a temporary cookie that stores session information such as the visit start time, referrer domain, and landing page.

Depending on browser capabilities, the first cookie can also be stored in local storage and the second one in session storage.

Storage is only used when the user gives consents to do so via the publisher [CMP (Cookie Management Platform)](consent-management-platform-cmp-integration-with-marfeel.md).

Cookie and local storage reference

Here is the complete list of cookies and local storage entries that Marfeel may set:

• _nrbi: Stores user data both as a cookie and in LocalStorage.
• _nrbic: Stores current session browsing data both as a cookie and in LocalStorage.
• compass_sid: Marfeel session id.
• compass_uid: Marfeel user id.
• compass_rfv_$ACCOUNT_ID: RFV of the user.
• ___m_rec: Data about recirculation module.
• marfeel-sdk-store: LocalStorage entry with user data including achieved goals, number of Flowcard impressions, experiment groups, and information about HUD.

Browser feature detection

Marfeel uses feature detection techniques to assess whether a browser supports certain APIs.

The SDK checks for Local Storage and Session Storage support by creating a temporary entry in each. These entries contain no personal or user data and are created and deleted during initialization of the Marfeel Tracker.

Local Storage entries

To assess whether a browser supports local storage, the Marfeel SDK creates and immediately deletes a __test_local_storage entry. Here is the function in the Marfeel SDK:

See SDK isLocalStorageAvailable method

export const isLocalStorageAvailable = (() => {
  try {
    const testKey = '__test_local_storage__';

    window.localStorage.setItem(testKey, testKey);
    window.localStorage.removeItem(testKey);

    return true;
  } catch (e) {
    return false;
  }
})();

Session Storage entries

To assess whether a browser supports session storage, the Marfeel SDK creates and immediately deletes a __test_session_storage entry. Here is the function in the Marfeel SDK:

See SDK isSessionStorageAvailable method

export const isSessionStorageAvailable = (() => {
  try {
    const testKey = '__test_session_storage__';

    window.sessionStorage.setItem(testKey, testKey);
    window.sessionStorage.removeItem(testKey);

    return true;
  } catch (e) {
    return false;
  }
})();

Tracking users across subdomains

By default, user information is tracked at the root-domain level and shared across all subdomains. A user visiting domain.com and sub.domain.com is considered the same user, sharing all data points like the RFV.

This default behavior can be configured so each different subdomain tracks the user independently. This is useful in situations where the root domain is a platform domain and each subdomain belongs to independent publishers. Some examples:

• medium.com vs obie.medium.com vs judedoyle.medium.com
• substack.com vs lenny.substack.com vs awesomepeopleco.substack.com).

Tracking users across domains and third-party cookies

When multiple root domains are used under the same Marfeel Account, cross-domain user tracking becomes necessary. Common scenarios include:

1. A media publisher owning different publications: siteA.com, siteB.com, siteC.com, etc.
2. A publisher with a publication under siteA.com and subscriptions on subscriptionsdomain.com

To support these scenarios, Marfeel sets a third-party cookie under the Marfeel-owned domain events.newsroom.bi. This cookie allows Marfeel to reconcile a user across the domains of the publisher account, enabling publishers to:

• Uniquely identify the same user on different domains such as siteA.com, siteB.com, and siteC.com
• Share user data like RFV across all domains
• Use subscription attribution models that work across domains while maintaining user uniqueness

Cross-domain user tracking works only when third-party cookies are enabled at the browser level. Browsers like Safari and Firefox implement mechanisms such as Intelligent Tracking Prevention (ITP) or SameSite cookies to prevent cross-site tracking.

When third-party cookies are blocked:

1. The same user visiting siteA.com and siteB.com will be tracked as 2 different users unless the publisher provides a unified userId
2. Users starting navigation on siteA.com and completing a subscription on subscriptionsdomain.com will have disconnected attribution models

The third-party cookies are named using the site ID as a prefix:

• {site_id}_u stores the user id
• {site_id}_s stores temporary session
• {site_id}_lv stores last visit
• {site_id}_ut stores user type

What first-party cookies does the Marfeel SDK set?

The Marfeel SDK sets two first-party cookies: _nrbi for persistent user data (unique identifier, registered user ID, first visit time, previous visit time, original referrer) and _nrbic for current session data (visit start time, referrer domain, landing page). Additional cookies include compass_sid, compass_uid, compass_rfv_$ACCOUNT_ID, and ___m_rec.

Does the Marfeel SDK use local storage or session storage?

Yes. Depending on browser capabilities, the first-party cookie data can also be stored in local storage and session storage. The SDK uses a marfeel-sdk-store entry in local storage for user data including achieved goals, Flowcard impressions, experiment groups, and HUD information. Storage is only used when the user gives consent via the publisher CMP.

How does Marfeel track users across multiple domains?

Marfeel sets a third-party cookie under the domain events.newsroom.bi to reconcile users across multiple root domains within the same account. This works only when third-party cookies are enabled. Browsers like Safari and Firefox with ITP or SameSite restrictions will prevent cross-domain tracking, in which case the publisher must provide a unified userId to maintain user identity.