Skip to main content

Custom Server-to-Server (OpenRTB) - User Matching

Commerce Grid DocumentationIntegration Guides WebCustom Server-to-Server (OpenRTB)
Table of contents

User Matching

Criteo bids on users it is able to recognize, and wants to optimize bandwidth. Therefore, it relies on explicit signaling of interested users. For this reason, user matching techniques are primarily Criteo-initiated. Note that Criteo is not interested in probabilistic matches or finger-printing and you must not enable such solutions.

User Matching - General Web Context

The general web context requires an operation separate from the bidding process during which:

  1. The partner adds a user to a list of users for which Criteo wishes to receive bid requests for 30 days.

  2. Identifiers for this user are exchanged between Criteo and the partner (the “matching” per se). In web context, this is typically performed by inserting an URL provided by the partner in the user’s browser while he/she browses a Criteo client's website. Criteo populates a query string parameter with its user ID for recovery by the partner.

Ex:

  1. The partner provided an URL similar to http://url.partner.com/match?dsp_user_id={criteo_userid},

  2. When inserting the URL in the user’s browser, Criteo replaces the macro with a Criteo GUID (e.g. 90da0fcc-d9a1-4451-a10e-e8bdabe4714d),

  3. The partner retrieves his own user ID from the cookie (e.g. 54BFB10072661A44368F43FFFB1F4EA9) and stores the matching with the Criteo ID for 30 days,

  4. Within 30 days, if an ad opportunity for user 54BFB10072661A44368F43FFFB1F4EA9 arises, the partner sends a bid request to Criteo and populates the user.id field with the matched Criteo ID, 54BFB10072661A44368F43FFFB1F4EA9.

Since partner URLs used for user matching are placed in the user’s browser, Criteo will ensure the latency is below 100ms. Opportunities to show an ad to a user that wasn’t matched within the last 30 days should not result in a bid request to Criteo, as no bid will be placed.

Note that this specification assumes matching values and substituting them in the bid request is handled by the partner.

This process relies on cookies outside of Criteo or the partner’s domain: the website of the Criteo client, the website of the partner’s client. In some contexts (e.g. In-App, browsers that disable cookie creation by third parties), cookies are not available to Criteo, the partner, or both.

User Matching - Contexts in which third-party cookies are blocked

In order to be able to transact when the user’s browser doesn’t allow third-party cookies, Criteo has developed and has a patent pending for a method called “Real-Time User Synchronization” (or RTUS) to share an user identifier with its SSP partner.

The high level objective is that the user’s browser sends a Criteo identifier when calling the SSP’s tag, and this identifier will be forwarded directly to Criteo, without any intermediary processing, storing or matching.

Please reach out to your Criteo representatives and refer to the RTUS documentation for more details.

User Matching - In-App Context

Criteo currently doesn’t support identifier matching for non-web context. The expectation is that all such traffic will be sent to Criteo without any filtering.

Criteo anticipates to use server-to-server connections to signal interests in specific users in the near future, most likely with the same objectives as for cookie-based systems (reducing bandwidth and sharing identifiers).