About first-party cookies

Last update: 2024-02-02
  • Topics:
  • Cookies
    View more on this topic
  • Created for:
  • Experienced

Analytics uses cookies to provide information on variables and components that do not persist between image requests and browser sessions. Where possible Adobe uses first-party cookies to record activities on your site. To record activity on different sites such as other domains you may own, third-party cookies are required.

Many browsers and anti-spyware applications are designed to reject and delete third-party cookies. Adobe ensures that cookies can always be set even if third-party cookies are blocked. The specific behavior varies depending on whether you are using the Experience Platform Identity Service (ECID Service) or Analytics’ legacy identifiers (aka the s_vi cookie):

  • The Experience Platform Identity Service (ECID Service) will automatically set first-party cookies regardless of whether your collection domain matches your site domain. If they do not match, the Identity Service will use JavaScript to set cookies in your site’s domain.
  • If you are using Analytics legacy identifiers (aka the s_vi cookie) it depends on how you have configured your data collection server. If the data collection server matches your site’s domain, then cookies are set as first-party. If the collection server does not match your current domain, then cookies are set as third party. In this case, if third-party cookies are blocked, Analytics sets a first-party fallback id (s_fid) instead of the standard “s_vi” cookie.

If you would like to ensure your collection server matches your site’s domain, you can use a CNAME implementation which will enable forwarding from a custom domain specified in your CNAME implementation to Adobe’s collection servers. This involves changes to your company’s DNS settings to configure a CNAME alias to pointing to an Adobe hosted domain. Please note that while various Adobe products support using a CNAME, in all cases the CNAME is used to a create a trusted first-party endpoint for a specific customer and is owned by that customer. If you control multiple domains, they may use a single CNAME endpoint to track users across their domains, but wherever the site domain does not match the CNAME domain cookies are set as third party.


Regardless of whether your collection domain matches your site domain, Apple’s Intelligent Tracking Prevention (ITP) program makes the first-party cookies set by Adobe short-lived on browsers that are governed by ITP, which include Safari on macOS and all browsers on iOS and iPadOS. As of November 2020, cookies set via CNAME also have the same expiry as cookies set via JavaScript. This expiry is subject to change.

If you want to establish a CNAME for data collection and if your site has secure pages using the HTTPS protocol, you can work with Adobe to obtain an SSL certificate.

The SSL certificate issuance process can often be confusing and time consuming. As a result, Adobe established a partnership with DigiCert, an industry-leading Certificate Authority (CA), and developed an integrated process by which the purchase and management of these certificates is automated.

With your permission, we work with a CA to issue, deploy, and manage a new SHA-2 SSL certificate for you. Adobe continues to manage this certificate and ensure that an unexpected expiration, revocation, or security concern, does not threaten the availability of your organization’s secure collection.

Adobe-Managed Certificate Program

The Adobe Managed Certificate Program is the recommended process for setting up the first-party SSL certificate needed for a CNAME implementation which ensures your Adobe collection server matches your site domain.

The Adobe Managed Certificate program lets you implement a new first-party SSL certificate at no additional cost (for your first 100 CNAMEs). If you currently have your own Customer-Managed SSL certificate, speak with Adobe Customer Care about migrating to the Adobe-Managed Certificate Program.


Here is how you implement a new first-party SSL certificate for first-party data collection:

  1. Fill out the First-party domain request form and open a ticket with Customer Care requesting to set up first-party data collection on the Adobe-Managed program.

    Each field is described within the document with examples.

  2. Create CNAME records (see instructions below).

    Upon receiving the ticket, a customer care representative should provide you with a CNAME record. These records must be configured on your company’s DNS server before Adobe can purchase the certificate on your behalf. The CNAME is similar to the following:

    Secure - For example, the hostname smetrics.example.com points to: [random-10-character-string].data.adobedc.net.


    In the past, Adobe recommended that customers set up two CNAMEs, one for HTTPS and one for HTTP. Since it is a best practice to encrypt traffic, and most browsers are strongly discouraging HTTP, we no longer recommend setting up a CNAME for HTTP. It is now considered best practice to set both trackingServer and trackingServerSecure with the same CNAME. For example, both trackingServer and trackingServerSecure would be set to smetrics.example.com. HTTP is only allowed for 3rd-party host names.

  3. When the CNAME is in place, Adobe works with DigiCert to purchase and install a certificate on Adobe’s production servers.

    If you have an existing implementation, you should consider visitor migration to maintain your existing visitors. After the certificate has been pushed live to Adobe’s production environment, you can update your tracking server variables to the new hostnames. Meaning, if the site is not secure (HTTP), update the s.trackingServer. If the site is secure (HTTPS), update both s.trackingServer and s.trackingServerSecure variables.

  4. Validate hostname forwarding (see below).

  5. Update Implementation Code (see below).

Maintenance and renewals

Thirty days before your first-party certificate expires, Adobe validates whether the CNAME is still valid and in use. If so, Adobe assumes that you want to continue using the service and automatically renews the certificate on your behalf.


If the CNAME has been removed and/or is no longer valid (Does not map to the provided Adobe SSL Hostname), Adobe cannot renew the certificate and the entry in our system is marked for removal without further communication.

Frequently asked questions

Question Answer
Is this process secure? Yes, the Adobe-Managed program is more secure than our legacy method as no certificate or private key changes hands outside of Adobe and the issuing certificate authority.
How can Adobe purchase a certificate for our domain? The certificate can only be purchased when you have pointed the specified hostname (for example, telemetry.example.com) to an Adobe owned hostname. This is essentially delegating this hostname to Adobe and allows Adobe to purchase the certificate on your behalf.
Can I request that the certificate be revoked? Yes, as the owner of the domain, you are entitled to request that the certificate is revoked. Open a ticket with Customer Care to have this completed.
Will this certificate be using SHA-2 encryption? Yes, Adobe works with DigiCert to issue a SHA-2 certificate.
Does this incur any additional cost? No, Adobe is offering this service to all current Adobe Digital Experience customers at no additional cost.

Create CNAME records

Your organization’s network operations team should configure your DNS servers by creating CNAME records. Each hostname forwards data to Adobe’s data collection servers.

The FPC specialist provides you with the configured hostname and what CNAME they are to be pointed to. For example:

  • SSL Hostname:smetrics.example.com
  • SSL CNAME:[random-10-character-string].data.adobedc.net

If you still use non-secure, it will look like this:

  • Non-SSL Hostname:metrics.example.com
  • Non-SSL CNAME:[random-10-character-string].data.adobedc.net

As long as implementation code is not altered, this step will not affect data collection and can be done at any time after updating implementation code.

Validate hostname forwarding

The following methods are available for validation:

Validate using a browser

If you have a CNAME set up and the certificate installed, you can use the browser for validation:



You are issued a security warning if a certificate is not installed.

Validate using curl

Adobe recommends using curl from the command line. (Windows users can install curl from: https://curl.se/windows/)

If you have a CNAME but no certificate is installed, run:
curl -k https://smetrics.adobe.com/_check
Response: SUCCESS

(The -k value disables the security warning.)

If you have a CNAME set up and the certificate is installed, run:
curl https://smetrics.adobe.com/_check
Response: SUCCESS

Validate using nslookup

You can use nslookup for validation. Using smetrics.adobe.comas an example, open a command prompt and type nslookup smetrics.adobe.com

If everything is successfully set up, you see a return similar to:

nslookup smetrics.adobe.com

smetrics.adobe.com    canonical name = adobe.com.ssl.d1.sc.omtrdc.net.
Name:  adobe.com.ssl.d1.sc.omtrdc.net
Name:  adobe.com.ssl.d1.sc.omtrdc.net
Name:  adobe.com.ssl.d1.sc.omtrdc.net

Update implementation code

Before you edit code on your site to use first-party data collection, complete these prerequisites:

  • Request an SSL certificate, by following the steps described above in the Implement section of the Adobe-Managed Certificate Program.
  • Create CNAME records (see above).
  • Validate the hostnames (see above).

After you have verified your hostnames are responding and forwarding to Adobe data collection servers, you can alter your implementation to point to your own data collection hostnames.

  1. Open your core JavaScript file (s_code.js/AppMeasurement.js).

  2. If you want to update your code version, replace your entire s_code.js/AppMeasurement.js file with the newer version and replace any plugins or customizations (if any). Or, if you want to update the code only pertinent to first-party data collection, locate the s.trackingServer and s.trackingServerSecure (if using SSL) variables, and point them to your new data collection hostnames. For example:

    s.trackingServer = "metrics.example.com";
    s.trackingServerSecure = "smetrics.example.com";
  3. Upload the updated core JavaScript file to your site.

  4. If you are moving to first-party data collection from a long-standing implementation, or changing to a different first-party collection hostname, Adobe recommends migrating visitors from the previous domain to the new domain.

See Visitor Migration in the Analytics Implementation Guide.

After you have uploaded the JavaScript file, everything is configured for first-party data collection. Adobe recommends that you monitor Analytics reporting for the next several hours to ensure that data collection continues as normal. If it does not, verify that all above steps have been completed and have one of your organization’s supported users contact Customer Care.

On this page