Skip to main content

Introduction

Zeotap

Zeotap is a Customer Intelligence Platform (CIP) that helps companies better understand their customers and predict behaviours, to invest in more meaningful experiences. We enable brands to build on a nucleus of first-party data to win new customers and grow their loyal base. Our independent but integrated modules include customer data unification, identity resolution, enrichment, analytics/modeling (including in data clean rooms), and activation to 100+ partners in the marketing ecosystem. Recognized by Gartner as a “Cool Vendor” (2020) and by AdExchanger as the “Best Data-Enabling Technology” (2019), our platform meets the highest enterprise data privacy and security stan dards, including GDPR, ISO 27001 and CSA STAR. We serve the world’s top brands, agencies and publishers across a dozen countries in Europe, North and Latin America, and APAC.

ID+ Initiative

Zeotap is also the founding member of ID+, a global universal ID solution. The ID+ solution is identifier-agnostic and empowers the marketing ecosystem ––brands, publishers, and vendors alike–– with a privacy-compliant mechanism to overcome identity resolution challenges arising from 3rd party cookie/identifier restrictions and increasingly stringent regulations across the world.

Publisher Onboarding

The Publisher Onboarding process comprises of the following steps:
1
On signing up for ID+ advanced, the Zeotap Product Operations Manager (POM) onboards the publisher to the Zeotap Unity Platform, and provides access to the ID+ and Data Partner Product. This generates the partner ID to use ID+ services and Org ID to be a data partner.
2
The Zeotap POM then shares the ID+ Partner ID and Orgid for the implementation process. Replace the <PARTNER_ID> and Orgid with respective received values.

How does it work?

In the ID+ Advanced model the ID+ partner shares the hashed identifiers as well as the attributes for socio-demographic or interest signals. The JavaScript (JS) tag must have the below format and must be placed within the <head> and </head> of the website.
<script id="zeo_mapping" src="https://spl.zeotap.com/mapper.js?zdid={Orgid}&ctry={Alpha-ISO3-CountryCode}&env=mWeb&eventType=pageview"></script>
Any attributes related to the user/page/event or identifier can be attached to this source URL as query parameters and values. For example, see the sample script below.
<script id="zeo_mapping" src="https://spl.zeotap.com/mapper.js?zdid={Orgid}&ctry={Alpha-ISO3-CountryCode}&env=mWeb&eventType=pageview&property=value"></script>
The following are some important points about the JS and the Zeotap smart pixel end point:
  • The script also makes a GET call to the Zeotap smart pixel endpoint with all the query parameters and values attached.
  • The Zeotap smart pixel endpoint identifies the user with the Zeotap third-party cookies and responds with the relevant cookie syncs
  • The script fires cookie syncs that are returned by the service as image pixels on the device based on the predefined configurations, with a daily frequency cap (that is, one cookie sync per channel per day).
  • The Zeotap smart pixel endpoint can perform the following actions:
    • Accept and record data explicitly attached to the call as query parameters and values
    • Accept and record data in the HTTP headers (IP-based country, telecom, user-agent-based browser type, device-info, pageURL based domain and path)

How to pass the identifiers?

The following steps explain the process of passing the identifiers:
1
When a user logs in, set this action as a trigger for the data collection script in order to perform the ID+ actions.
2
The following are the reserved keywords from Zeotap, that must be used to pass the email addresses and mobile phone numbers:
  • zem for raw email addresses
  • zc_wo for raw mobile phone number without the country code
  • zc_w for raw mobile phone number with the country code
3
In case of raw email addresses, Zeotap’s library converts the email addresses to lowercase and hashes them to sha256 before making the GET calls for data collection.
4
In case of raw mobile phone numbers, Zeotap’s library hashes them to sha256 before making the GET calls for data collection.
5
The following reserved keywords must be used to pass the email addresses and mobile phone numbers that are already hashed:
  • z_e_sha2_l for sha256 hash of email addresses in lowercase
  • z_c_sha2_wo for sha256 hash of mobile phone number without country code
  • z_c_sha2_w for sha256 hash of mobile phone number with country code
The following are the different methods of consent passing that we support: Optin parameter In this method, the consent signal of the user is passed in the JS tag using the optin parameter with yes/no, true/false or 1/0 as the value. optin=yes is used for the following purposes:
  • Activate the ID+ module
  • Drop or read a Zeotap cookie
  • Store other data points

TCF

The following points explains this method:
  • If the optin parameter is not found, then the JS checks the page for the presence of cmp.js.
  • If the cmp.js is found, then it calls the CMP API to fetch the TCF consents.
  • The JS checks if consent is provided for vendorid: 301 for the registered purposes to activate the ID+ module, drop/read zeotap cookie, and store other data points.

Actions when consent=no

The following points explains the actions when consent is no as communicated by either methods above:
  • No ID+ calls are made
  • Existing ID+ cookie are deleted
  • If a user opts out from all the purposes relating to processing of data, the same is communicated to the smart pixel endpoint as revoking of consent. The corresponding user IDs are added to our opt-out pipeline in order to remove the older data collected.
When the email and/or mobile phone numbers are passed during the user login, the following steps must be performed to use the same for ID+ cookie stamping:
1
In the JS tag, set the flags for ID+ as &idp=1 and the consent signals, and attach the ID+ partner ID as &idp_partnerid={IDP_PartnerID} and Page domain as &partner_dom={domain of the page}. This Partner ID will be shared by Zeotap Product Operations Manager. For more information on consent signals, see Consent Setting.
<script id="zeo_mapping" src="https://spl.zeotap.com/mapper.js?zdid={Orgid}&ctry={Alpha-ISO3-CountryCode}&env=mWeb&eventType=pageview&idp=1&idp_partnerid={PARTNER_ID}"></script>
2
When the ID+ flag is set to 1 and the ID+ partner ID added, the ID+ actions are enabled.
3
The script checks for the below information in order to perform the ID+ services:
  • If the user consent is present
  • If the ID+ partner ID is present
  • If email address and/or mobile phone number exists in raw or hashed form
4
When the above-mentioned conditions are satisfied, the JS makes a call to the ID+ stamping service API by passing on the hashed IDs, ID+ partner ID and user consent.
5
The ID+ stamping service resolves the identity of the user and returns the corresponding ID+ value and expiry.
6
The JS then takes the ID+ value returned and stamps this as a first-party cookie named IDP, with expiry as stated. Note that this cookie is a first-party cookie against the Top Level Domain, Secure and Strict. The ID+ value returned has a certain expiry that is stored as a cookie called idp_expiry.
7
On subsequent initialisations of the script, the IDP cookie is reset based on the stored expiry.
Note:
  • The email address or the mobile phone numbers are not stored in any format on the device. Therefore, ensure that a new call is made when a new session is started if the login state is true.
  • If Zeotap is unable to resolve the identity of the user, no IDP cookie is created.

A. ID+ value is not found

When the ID+ value is not found for the user by the ID+ service for a corresponding email address or mobile phone number, the following events take place:
  1. The ID+ API responds with 200 and no response body.
  2. The JS then deletes any existing IDP cookie value that is present.

B. No IDs are passed

Until IDs are passed in the query parameters, no call is made to the ID+ API, even if the idp flag is set to 1. If there is an existing IDP cookie, then the same continues to exist until the cookie expires.

C. Passing the email and mobile phone IDs

The email and/or phone number must be passed in the query parameters along with &idp=1 in the following scenarios:
  • When a user logs in.
  • At the start of a new session if the user is in the logged-in state.
  • If a user is in the logged-in state but no IDP cookie is found.

Integrating with Prebid 

Prebid is an open-source Header Bidder (HB) solution. Zeotap is integrated with Prebid to pick the stamped IDP cookie and send it to the SSP’s. After successfully implementing the JS on your website, the IDP cookie is stamped on the page. Next, it must be passed in the bid request. To let it flow to the downstream systems through Prebid, you have to include Zeotap ID+ in your Prebid Package.
NoteEnsure that your bidder adapter can listen to Zeotap ID+. To know more about integrating your Prebid package, refer to the user ID module of the Prebid document here.
We have also embedded the soon to be legacy functionality of third-party cookie syncing in the JS which can be used until the third-party cookies exist. This means that you are future-ready and you do not have to make any code changes when you transition from a third-party cookie to ID+ in future. The Zeotap JS drops a cookie against the Zeotap domain (third-party cookie ) called zc. Any channels with whom we cookie sync, share their third-party cookies for the users. These third-party cookies are used for populating audience segments on the channels in terms of third-party cookies (as long as they exist). From Zeotapʼs list of integrated partners, you can select the partners with whom you want to cookie sync. Note that these cookies are preconfigured against your Write Key and are fired as image pixels on the site asynchronously, mapped to the ID+ cookie and any user identifiers sent by you. Contact your Zeotap POM (Product Operations Manager) to get the updated list of integrated platforms for the markets you are interested in.
Last modified on February 26, 2026