Skip to main content

Direct Server Side S2S (Passback)

Commerce Grid DocumentationIntegration Guides WebStandalone / Publisher tag

Introduction

Welcome! This document will explain integrating with Commerce Grid's Direct S2S solution.

Criteo provides a piece of code to be added to the header of the pages. This generates an asynchronous call so Criteo can identify the user and return a set of bids and creatives.

Criteo will respond with the bid price in CPM along with the creative code or raw assets in case of native demand.

Requirements

You will receive from Criteo:

  • The endpoint URL

  • A list of identifiers for each ad placement and/or format you have available on the page

  • Code samples demonstrating how to initialize the Criteo tag and how to map the placements

  • Creative codes to be used in the adserver or directly on the page

We will need you to:

  • Implement the scripts on the page header

  • Map the placements available on each page and use it to initialize our tags

  • Criteo complies with the IAB Consent Framework. Please refer to their documentation for more information and examples of certified CMPs.

Direct S2S Script - Loader

This code initializes the Criteo tags. The code will load the publishertag.js library and will also build the events queue that will be used later. The loader request is asynchronous and is cached on the user browser. No code changes are required on this section.

Direct S2S Script - Placements mapping

The next step is to map all the adunits available on the page and assign their code to its respective Criteo id.

ad unit code

format

Criteo zoneid

ad-unit-0

300x250

775590

ad-unit-1

728x90

775591

Direct S2S Script - Bid request

The mapping is now used to generate a bid request to Criteo's endpoint.

  • Criteo.events.push(function() { : The code wrapped inside this function is added to the Criteo.events queue that will be processed asynchronously as the page loads

  • Criteo.RequestBids([adunits], [timeout]); : This will send a browser request for the given adunits respecting the timeout threshold

User ID Collection

To enrich the bid request data with user IDs (1st Party user IDs, 3rd Party IDs or hashed emails), please use the function Criteo.SetIdentities as described in the sections below.

This function accepts an array of OpenRTB EIDS objects as input:

Field

Type

Description

source

String

Identifier source URL (publisher URL or vendor URL).

uids[].id

String

User identifier

uids[].atype

Integer

Identifier type. 1: an ID which is tied to a specific web browser or device (cookie-based, probabilistic, or other). 2: in-app impressions, which will typically contain a type of device ID (or rather, the privacy-compliant versions of device IDs). 3: a person-based ID, i.e., that is the same across devices.

uids[].ext.stype

String

ID Source type. "dmp" if comes from the in-page DMP named in eids.source. "ppuid" if comes from the publisher named in eids.source

uids[].ext.persistence

String

(Optional, Criteo-specific) "http" if the 1PC was set through an HTTP Set-Cookie directive or "js" if the 1PC was set through JavaScript (either in a cookie or in the local storage).

User ID Collection - First Party IDs

Use the function Criteo.SetIdentities providing the data below (examples on the right):

  • source: your domain

  • id: the user identifier

  • atype: Must be 1 for cookie/device-based ID, must be 3 for person-based ID (e.g.: authenticated user ID, login ID, CRM/customer ID)

  • ext.stype: ppuid

  • ext.persistence: js or http

User ID Collection - Third Party IDs

Use the function Criteo.SetIdentities providing the data below (examples on the right):

  • source: the third-party solution domain

  • id: the user identifier

  • (recommended) atype: 1 for cookie/device based ID, 3 for person-based ID (e.g.: authenticated user ID, login ID, CRM/customer ID)

  • (optional) ext.persistence: js or http

User ID Collection - Hashed Emails

Use the function Criteo.SetIdentities providing the data below (examples on the right):

  • (optional) source: your domain or the domain of the solution operating on your behalf

  • id: the user data

  • atype: 3

  • ext.stype: hashing algorithm used: cleartextemail, hemsha256, hemmd5, hemsha256md5. Please refer to next section for details on hashing formats.

Hashing formats

The hashing should be the users’ email address:

  • Encoded in UTF-8

  • Trimmed of any white space (eg: “test@criteo.com “ should become “test@criteo.com”)

  • Converted to lowercase

  • Hashed with MD5/SHA256/SHA256(MD5) & output as ASCII text

Example:

  • Type: String

  • Original Email: john.doe@gmail.com

  • SHA256: 375320dd9ae7ed408002f3768e16cb5f28c861062fd50dff9a3bff62e9dce4ef

  • MD5: e13743a7f1db7f4246badd6fd6ff54ff

  • SHA256 of MD5: 000e3171a5110c35c69d060112bd0ba55d9631c7c2ec93f1840e4570095b263a

Helpful links: https://www.miraclesalad.com/webtools/md5.php and https://www.miraclesalad.com/webtools/sha256.php