OpenRTB 2.6-202409

2.6.md

@@ -8,7 +8,7 @@ Stanislav Belov, Software Engineer, Google; Allen Dove, CTO, Magnite; Steven Kat
 
 ### IAB Tech Lab Lead:
 
-Hillary Slattery, Director of Product, IAB Tech Lab
+Hillary Slattery, Sr. Director of Product, IAB Tech Lab
 
 ### License <a name="license"></a>
 
@@ -223,6 +223,7 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT
 ## [Appendix A. Additional Information](#appendixa)
 
 ## [Appendix B. Specification Change Log](#appendixb)
+## [Appendix C. Cookie Based ID Syncing](#appendixc)
 
 ## Getting Started <a name="started"></a>
 
@@ -2304,7 +2305,9 @@ This object provides information pertaining to the device through which the user
   <tr>
     <td><code>ifa</code></td>
     <td>string</td>
-    <td>ID sanctioned for advertiser use in the clear (i.e., not hashed).</td>
+    <td>ID sanctioned for advertiser use in the clear (i.e., not hashed)
+
+  <br>Unless prior arrangements have been made between the buyer and the seller directly, the value in this field is expected to be an ID derived from a call to an advertising API provided by the device’s Operating System.</br></td>
   </tr>
   <tr>
     <td><code>didsha1</code></td>
@@ -2446,12 +2449,18 @@ This object contains information known or derived about the human user of the de
   <tr>
     <td><code>id</code></td>
     <td>string</td>
-    <td>Exchange-specific ID for the user.</td>
+    <td>Exchange-specific ID for the user.
+
+<br>Unless prior arrangements have been made between the buyer and the seller directly, the value in this field is expected to be derived from an ID sync. (see <a href="https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/develop/2.6.md#appendix-c-cookie-based-id-syncing-">Appendix: Cookie Based ID Syncing)</a></br>
+    </td>
   </tr>
   <tr>
     <td><code>buyeruid</code></td>
     <td>string</td>
-    <td>Buyer-specific ID for the user as mapped by the exchange for the buyer.</td>
+    <td>Buyer-specific ID for the user as mapped by the exchange for the buyer.
+
+<br>Unless prior arrangements have been made between the buyer and the seller directly, the value in this field is expected to be derived from an ID sync. (see <a href="https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/develop/2.6.md#appendix-c-cookie-based-id-syncing-">Appendix: Cookie Based ID Syncing)</a></br>
+    </td>
  </tr>
   <tr>
     <td><code>yob</code></td>
@@ -2751,15 +2760,38 @@ Extended identifiers support in the OpenRTB specification allows buyers to use a
     <td><strong>Type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</strong></td>
     <td><strong>Description</strong></td>
   </tr>
+<tr>
+    <td><code>inserter</code></td>
+    <td>string</td>
+    <td>The canonical domain name of the entity (publisher, publisher monetization company, SSP, Exchange, Header Wrapper, etc.) that caused the ID array element to be added. This may be the operational domain of the system, if that is different from the parent corporate domain, to facilitate WHOIS and reverse IP lookups to establish clear ownership of the delegate system.<br>
+    </br>This should be the same value as used to identify sellers in an ads.txt file if one exists.<br>
+</br>For ad tech intermediaries, this would be the domain as used in ads.txt. For publishers, this would match the domain in the <code>site</code> or <code>app</code> object.
+</td>
+ </tr>
   <tr>
     <td><code>source</code></td>
     <td>string</td>
-    <td>Source or technology provider responsible for the set of included IDs. Expressed as a top-level domain.</td>
+    <td>Canonical domain of the ID.</td>
+  </tr>
+<tr>
+    <td><code>matcher</code></td>
+    <td>string</td>
+    <td>Technology providing the match method as defined in <code>mm</code>.<br>
+</br>In some cases, this may be the same value as inserter.<br>
+</br>When blank, it is assumed that the <code>matcher</code> is equal to the <code>source</code><br>
+</br>May be omitted when mm=0, 1, or 2.<br>
+</td>
+ </tr>
+<tr>
+    <td><code>mm</code></td>
+    <td>int</td>
+    <td>Match method used by the <code>matcher</code>. Refer to <a href="https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/develop/AdCOM%20v1.0%20FINAL.md#list-id-match-methods-">List: ID Match Methods</a> in AdCOM 1.0
+    </td>
   </tr>
   <tr>
     <td><code>uids</code></td>
     <td>object array</td>
-    <td>Array of extended ID <code>UID</code> objects from the given source. Refer to 3.2.28 Extended Identifier UIDs</td>
+    <td>Array of extended ID <code>UID</code> objects from the given source. Refer to the <code>Extended Identifier UIDs</code> object (Section 3.2.28)</td>
  </tr>
   <tr>
     <td><code>ext</code></td>
@@ -4430,6 +4462,71 @@ This appendix serves as an index of specification changes across 2.x versions. T
   </td>
   </tr>
 </table>
-
-
+
+# Appendix C. Cookie Based ID Syncing <a name="appendixc"></a>
+Cookie syncing (also known as user syncing, user matching, cookie matching) is the process by which one party learns another party’s user IDs, and thus is foundational to availability of IDs in the cookie-based web environment. Since cookies are domain-specific, the sync process is necessary for one party to know the other’s IDs. 
+
+
+Cookie syncs are established between any two parties in the ecosystem that need to send user IDs to each other. Classically, however, cookie syncs are established between DSPs and exchanges/SSPs, and between DSPs and DMPs.
+
+In the cookie sync process, one party stores the relationship between their user IDs and the other party’s user IDs in a match table that knows that cookieID123 from party A is the same user as cookieID789 from party B. 
+
+When the sync pixel loads, the party reads their cookie (or sets a new one) to learn their user ID, and then issues a 302 redirect to a URL provided by the other party, to pass them that user ID. When the other party’s URL loads in the browser, they will be able to read their cookie (or set a new one), thus establishing the relationship between the two user IDs, which can then be stored (in a server-side data store of some sort, or simply by using a cookie to store it client-side if feasible).
+
+Most commonly between DSPs and exchanges/SSPs, the exchange holds the match table, but it can be done either way. When the exchange holds the match table, it is used when generating the bid request to send to the DSP. The exchange observes its cookie when the browser makes a request to it, looks up its user ID in the match table, and finds the DSP’s user ID. The exchange them puts that DSP user ID in the “buyeruid” field in the bid request.
+
+The details of cookie sync implementation will vary from integration to integration and should be discussed between the two parties. However, this section describes how cookie syncs typically work at a high level
+
+Cookie Sync Example (Exchange-Hosted)
+In this example, the exchange is holding the match table.
+
+The DSP provides their sync URL to the exchange. This might look something like..
+
+https://ads.dsp.com/sync?exchange=29
+
+The exchange provides their sync URL to the DSP, in which they will indicate where the DSP’s user ID should be placed. This might look something like..
+
+https://platform.exchange.com/match?dsp=12&dsp_user_id=<USER ID HERE>
+
+The DSP arranges such that their sync URL will redirect to the exchange sync URL, populating the DSP user ID into the appropriate location.
+
+The exchange then causes the DSP sync pixel to be loaded in users’ browsers, perhaps when the exchange is serving ads or at other opportunities. The DSP observes its’ user ID cookie. For this example, assume the user ID is “6b9a9765-697e-4c44-b393-dbb00ae7ac6b”. The DSP servers cause a 302 redirect to:
+
+https://platform.exchange.com/match?dsp=12&dsp_user_id=6b9a9765-697e-4c44-b393-dbb00ae7ac6b
+
+And thus, since the exchange now has the opportunity to examine their cookie, the exchange has the mapping between the exchange’s cookie ID and the DSP’s. Outbound bid requests to the DSP can now include the DSP’s ID in “buyeruid” when the corresponding exchange cookie ID is present. The DSP acts on it for audience targeting, frequency capping, measurement, etc.
+
+The DSP may also elect to directly drop the exchange’s sync pixel at opportunities it has, for example with the DSP’s pixels/tags for audiences and conversions.
+
+Cookie Sync Example (DSP-Hosted)
+In this example, the DSP holds the match table.
+
+The exchange provides their sync URL to the DSP. This might look something like..
+
+https://platform.exchange.com/match?dsp=12
+
+The DSP provides their sync URL to the exchange, in which they will indicate where the exchange’s user ID should be placed:
+
+https://ads.dsp.com/sync?exchange=29&exchange_id=<USER ID HERE>
+
+The exchange arranges such that their sync URL will redirect to the DSP sync URL, populating the exchange’s user ID in the appropriate location. The DSP finds opportunities to drop the exchange’s sync pixel in browsers, initiating syncs. The exchange may also elect to directly drop the DSP’s sync pixel in the browser at opportunities it has. For this example, assume the exchange’s user ID is “0cc175b9c0f1b6a831c399e269772661”. When the exchange’s sync pixel loads, the exchange observes their cookie. They then serve a 302 redirect to:
+
+https://ads.dsp.com/sync?exchange=29&exchange_id=0cc175b9c0f1b6a831c399e269772661
+
+Now that the DSP’s sync pixel is loaded in the browser, the DSP can observe its cookie, and store a mapping between its user ID and the exchange’s. Since it does not touch the user browser until serving an ad, it’s necessary in this case that the DSP stores this in a server-side data store.
+
+When the exchange sends bid requests, it includes the exchange’s cookie ID in the “id” field in the user object. Since the DSP is hosting a match table relating the exchange cookie IDs to the DSP’s, it can and does perform a lookup to determine the DSP’s user ID. The DSP can then proceed with audience targeting, frequency capping, measurement, etc.
+
+Other Considerations and Best Practices
+As user IDs can be considered personal data under some privacy regulations, implementers are advised to consult with their counsel and apply appropriate measures for compliance. As examples, however, the following practices are considered customary:
+Inclusion of query string parameters for GDPR, US Privacy String, GPP, etc. per the relevant Tech Lab specifications
+Based on information like GDPR consent string, a party might gate whether or not they fire a given sync pixel on whether they believe the consent string indicates the appropriate consent for the party
+Based on information like a GDPR consent string, a party might elect to treat the event as a no-op — for example, if their sync pixel is fired, the user is in Europe, and consent information is not provided, the party might elect to simply immediately return 204 No Content and take no actions, since user consent is not known
+
+There are several best practices that implementers can follow to ensure the match rate and coverage between parties is maximized:
+Cookies have a limited lifespan typically, so it is customary to limit match table retention to some period of time like 14 to 60 days. Parties are suggested to arrange their sync behavior to ensure that the match for a given user is refreshed (if they are still observed active) before expiring out of the match table.
+There are frequently a long list of parties necessary to sync. For example, an exchange, for each user, needs to trigger syncs with each and every DSP they work with. Thus, it’s suggested to take all available opportunities to deploy sync pixels, such as when serving ads, when serving tracking tags, etc.
+It's also helpful if both parties deploy sync pixels when possible, as this increases the number of opportunities to perform sync for a given user.
+Sync pixels fire in the user’s browser, and thus sync activity creates overhead when web pages load. To avoid blocking page loads, parties are advised to load sync pixels in a non-blocking manner, such as in a hidden IFRAME. Additionally, parties might wish to limit the number of sync partners deployed in a given instance to a modest number.
+For example, a reasonable strategy would be to sync up to 5 partners on each occasion, and record that this has occurred and when. Then, on the next occasion, the next 5 partners can be synced, and so on. Once all partners have been rotated through and syncs established for a given user, it’s not necessary to fire any more sync pixels for a while. Keeping track of the timestamp of performing each sync enables the party to trigger another one shortly before they expect that the ID will expire out of the match table.