2.6-202405 Public Comment Feedback

[hillslatt]

Please comment on this issue with feedback on updates to the OpenRTB updates in Public Comment

OpenRTB Updates:

• Updated buyeruid attribute description in Object: User
• Updated ifa attribute description in Object: User
• New attributes (inserter, matcher, mm) in Object: EID
• Updated source attribute description in in Object: EID
• New Implementation Guidance with multiple Bridging Scenarios
• Added Appendix C: Cookie Based ID Syncing

Associated AdCOM List: ID Match Methods

[adamleslie]

Do we have any guidance on which of the "ID Match Methods" are frowned upon or preferred by either the SSPs or DSPs?

The perceived risk is that we set mm to a value which is bad/not preferred and this leads to bad outcomes in terms of the IDs being dropped/ignored resulting in revenue losses. Ideally we'd like to avoid such outcomes by receiving either guidance on preference or even ranking of all methods in terms of preference (or perceived accuracy).

Also, are no bid events/oRTB losses captured on the basis of such detail? I.e. bidder didn't respond due to mm field is prefiltered.

Such considerations allow a Publisher to diagnose the effectiveness or risk to their ID bridging solutions or tailor their solutions to meet market requirements.

[patmmccann]

It is very helpful to make a draft PR to put feedback on. Since I couldnt find one, I'll add it here. The https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/develop/2.6.md#appendix-c-cookie-based-id-syncing- document seems to be unaware of a very popular method for dsp - ssp syncing, which is for the ssp to write dsp cookies to the user storage to preserve their life. Here are four of many many examples

The appendix appears to invlidate this technique and needs modification to preserve it.

Here is a proposed change:

Change
"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."

to:
"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. Occasionally, these matches are replicated into browser storage by the exchange to enhance their longevity. The exchange then puts that DSP user ID in the “buyeruid” field in the bid request."

[hillslatt]

The provided screenshots look like the exchanges' storing the DSP's cookie ID in a third-party cookie under their domain. In other words, it looks like it is showing pubmatic storing DSP cookie IDs in cookie(s) under the pubmatic.com domain.

Is that the case? If so, this is already documented, but we could make it clearer. At present the text says...
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).

tagging @iantri to comment if the question was about caching the id in localStorage under a site's domain it gets potentially sticky depending on the ad tech platform's implementation.

[robhazan]

@adamleslie The spec doesn't take a position (and won't) on the match methods being good/bad or preferred/dispreferred. Ask several different SSPs/DSPs, and you'll get several different answers. It simply creates a way for sellers to provide transparency into the provenance of an ID.

It's not a question of setting mm to something preferred and going on your merry way. It's a question of honestly disclosing how you arrived at that ID, so that buyers can make an informed decision of whether they want to buy the impression or not based on that ID. If you have multiple IDs using multiple match methods, then include all of them in the eids array and let buyers decide how to buy.

Your question implies changing mm to something "preferred" to make your requests more attractive to buyers, and that is not an honest way to approach this.

[adamleslie]

I'm more concerned about setting mm honestly and it being used to blanket block/exclude my inventory w/ no way to proactively prevent that.

[iantri]

@adamleslie I am the VP of Product for Basis DSP, and was formerly responsible for supply/data integrations and inventory quality.

We consider current behaviours being practiced by some (but far from all) supply-side parties to be unacceptable. I'm speaking of the spoofing cookie IDs into the buyeruid field when the user does not actually have the cookie.

We fundamentally do not want supply-side ID bridging to occur for reasons I have discussed with industry press and due to the more fundamental principle that this has massive abuse potential; if the supply-side gets to choose how/what ID is presented in the bid request, this will obviously be exploited by some to make more money by presenting attractive IDs.

All cases of this currently occurring, affecting Basis IDs, was undisclosed, and is unrequested, and unwanted.

So, while this spec is with regards to a practice we do not want, at least it enables us to exclude the undesired IDs. Your remarks seem to indicate consideration of misrepresenting the nature of the IDs presented in the interests of revenue maximization.

Misrepresenting material details of a bid request in the interests of making more money would be fraud, and we will absolutely block supply from anyone who does so. We are currently in the process right now of blocking supply which is causing misrepresented IDs in the buyeruid field.

[mdavies-bidswitch]

re: Unless prior arrangements have been made between the buyer and the seller directly

Is it expected that the buyers and sellers would have that prior arrangement privately or publicly declared within the spec?

[patmmccann]

@hillslatt your proposed edit works for me

[robhazan]

re: Unless prior arrangements have been made between the buyer and the seller directly

Is it expected that the buyers and sellers would have that prior arrangement privately or publicly declared within the spec?

@mdavies-bidswitch No, it is not expected. But if the 2 parties want to agree on some convention for declaring it, nobody is stopping them :-)

[jon-caines-idward]

What provision is being made for ID-less audience signals? We propose that the current protocol although enabling ID-less audiences, such as Seller Defined Audiences, or more basically 1st Party key-value pairs in PMP deals, does not enable that audience signal to carry equal weight and thus DSP logic is biased towards the ID or UID sync when these are also present on the inventory. Whilst we appreciate that this may not be 100% the correct forum but we equally feel that there is an immediate need to address this elephant in the room and we will shortly be publishing a whitepaper to support this proposal. As I have not had sufficient time to absorb the whole aspect of his forum, it would be good to know if provision exists here or elsewhere for consideration.

[dkulakovsky]

DV360 TL here. While we generally agree with the spirit of this proposal which aims to bring transparency regarding the origins and nature of user identifiers within OpenRTB transactions, we believe it should be extended to also cover user.id field. In many SSP/DSP integrations, user.buyeruid and user.id are employed interchangeably, the only distinction being the party hosting the cookie match table: SSP in the case of user.buyeruid and DSP in the case of user.id. Restricting the scope of the proposal solely to user.buyeyuid, device.ifa, and user.eids fields without incorporating analogous mechanisms to describe the user.id field would result in the transparency objectives only partially achieved. More specifically, we propose:

1. Add language / examples indicating that the new mm and atype fields should also be used to describe user.id attribute, similar to how they are used for user.buyeruid.

2. Add clarifying language to user.id attribute description to stipulate that unless prior arrangements were made between the seller and buyer, the value is expected to come directly from a 3rd-party cookie, or be derived from an ID sync.

[iantri]

Hi @dkulakovsky,

I think I'm broadly on the same page as you, but could you clarify "Add language / examples indicating that the new mm and atype fields should also be used to describe user.id attribute, similar to how they are used for user.buyeruid"?

The proposed changes here actually don't indicate use of an "mm" or "atype" field associated to buyeruid, but rather clarifies that buyeruid is expected to be from a customary third-party cookie sync (unless you choose to arrange otherwise with a partner). So there is no "mm", "atype" for buyeruid, things that aren't customary third-party cookie sync go in eids instead.

[deepthivenkat]

When the IDs get translated by the SSP to a DSP identifier, we would like to propose that the matcher information is retained.
This is because when this translation happens, the graph vendor from whom this id got picked up gets dropped during the process. We want this information to be retained until the id reaches a DSP. Otherwise information about the entity through which the matching happens never reaches the DSP

"user": {
"buyeruid": "3d89748d-74bb-44f1-9908-298090dc2944",
"eids": [
{
"matcher": "graphvendor.com",
"inserter": "pub.com",
"source": "sspdomain.com”,
"mm": 3,
"uids": [
{
"id": "fac13741-0648-436a-88cf-aceafdf45c9a"
}
]
},
{
"matcher": "graphvendor.com",
"inserter": "sspdomain.com",
"source": "dspdomain.com”,
"mm": 3,
"uids": [
{
"id": "3d89748d-74bb-44f1-9908-298090dc2944"
}
]
}
]
}

[simontrasler]

I propose we add pseudo code to illustrate what's expected. I volunteer the following not as "the solution" but for discussion.

The use case is an SSP that has received a request, and is examining it to decide what to pass along to a DSP that does not want to receive any bridged IDs. (The value buyerdomain is the domain name for the namespace the buyeruid is in, i.e., the SSP's domain in this case.)

If buyeruid is not empty:
	// We need to verify it is a legitimate match
	If eids is not empty:
		Let explicit = false, found = false
		Foreach eid in eids:
			// Only need to check eids in my namespace
			If source == buyerdomain:
				Let explicit = true
				If mm == 1 or mm == 2:
					Foreach uid in uids:
						If buyeruid == uid:
							// This is a legitimate match
							Let found = true
							Break
		If explicit:
If found:
				// Legitimate match
Else:
				// No match with a desired method, ignore buyeruid
Else:
			// We cannot be sure of the provenance of the buyeruid, ignore buyeruid
	Else:
		// We cannot be sure of the provenance of the buyeruid, ignore buyeruid
Else:
	// Make a decision on what to consume from the EIDs array

[pm-harshad-mane]

Agree with @simontrasler , here is pictorial view of the same pseudo code proposed above...

graph TD;
    A[If buyeruid is not empty] -->|Yes| B[If eids is not empty];
    B -->|Yes| C[Let explicit = false, found = false];
    C --> D[Foreach eid in eids];
    D -->|source == buyerdomain| E[Let explicit = true];
    E --> F[If mm == 1 or mm == 2];
    F --> G[Foreach uid in uids];
    G -->|buyeruid == uid| H[Let found = true];
    H --> I[Break];
    I --> J[If found];
    J -->|Yes| K["// Legitimate match"];
    J -->|No| L["// No match with a desired method, ignore buyeruid"];
    E -->|No| M["// No match with a desired method, ignore buyeruid"];
    B -->|No| N["// We cannot be sure of the provenance of the buyeruid, ignore buyeruid"];
    A -->|No| O["// Make a decision on what to consume from the EIDs array"];

Loading

[dmdabbs]

Question regarding matcher.

Value	Definition
1	No Match The associated ID came directly from a 3rd-party cookie or OS-provided resettable device ID for advertising (IFA). No matching has occurred.
2	Browser Cookie Sync Real time cookie sync as described in [Appendix: Cookie Based ID Syncing]
...

On an un-perturbed, "traditional" web request (seller-hosts buyeruid from my cookie, 302-synced with seller), I am not clear which of these I should expect to describe buyeruid. No Match is probably the intended value. But if Browser Cookie Sync is intended for "traditional cookie syncing" then what is No Match's directly from a 3rd-party cookie covering?

An un-perturbed app request is unambiguous. I expect No Match.

[iantri]

@dmdabbs The "matcher" field is spec'd only for the eids object -- buyeruid is specified as "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 Appendix: Cookie Based ID Syncing)".

So in other words, unless you specifically and intentionally agreed to do differently with a supply partner, buyeruid is expected to be derived conventionally.

Ditto on ifa.

@simontrasler @pm-harshad-mane I think some of that may have to do with internals on your side and/or partnerships you've pursued. I get why you're specifically saying this for some specific details for your case, but I don't think it generalizes. As I see it, this is a non-issue:

The use case is an SSP that has received a request, and is examining it to decide what to pass along to a DSP that does not want to receive any bridged IDs.

.. so long as people do not stick things in buyeruid other from a conventionally derived cookie sync. In other words, the request to you should only contain buyeruid populated from conventional cookie sync. And similarly, the buyeruid you populate in a bid request outbound to, say, our DSP, should similarly only be populated from conventional cookie sync. (Derived from the cookie ID sent to you in buyeruid, if you are handling a request send S2S to you and can't look directly at your cookie). So then, there isn't anything needing to be done to determine what to pass to a DSP that does not want bridged IDs. That is, effectively, the default, unless something atypical is done.

For all other scenarios, use eids. In other words, if somebody is populating your cookie ID into requests using bridging, it should go in eids.

I don't think attempting to assess the "provenance of buyeruid" based on something from a different part of the request -- eids -- is the way to go. The concept of doing so only makes sense to me if buyeruid is being polluted by bridged IDs -- but I'm saying, it just shouldn't be -- then there is no problem, and no fancy flowchart needed. :)

DSPs that want the bridged IDs can just read them from eids. If you want to put a bridged ID in the request, put it in eids, and the DSP can read it if they want. Alternatively, since the spec does not dictate what consenting platforms do between themselves, if both you and the DSP agree to it you could elect to send the bridged ID to them in "buyeruid" if that's what they want.

Regardless of any variation on all of this (i.e. the version I'm saying here, or your flowchart version), it'll still be necessary to audit/verify that buyeruid isn't being tampered with, such as by checking reality based on what you see in your cookie when a pixel fires. Declarations are inherently untrustworthy when we're trading bytes for money. :)

EDIT: Consenting platforms can do what they want between themselves extends of course to upstream of you -- so you could agree to allow a bridged version of your platform's IDs to be put into the buyeruid field by the upstream party -- in other words, they populate your ID into buyeruid based on bridging -- but I don't recommend this, because then it leads to the complication of your flowchart/pseudocode. So, if you just insist that eids is used for it, any case where buyeruid population appears to be abnormal (based on verification of direct cookie observation at delivery) can be considered abuse/incorrect/invalid.

[dmdabbs]

Thanks Ian.

I was recalling a discussion about instances of sellers passing something in buyeruid because the DSP could only handle it that way. But that was a) IIRC a MAID in buyeruid and b) a thing between consenting adults, as the revised buyeruid description now calls out.

EDIT: Consenting platforms can do what they want between themselves extends of course to upstream of you -- so you could agree to allow a bridged version of your platform's IDs to be put into the buyeruid field by the upstream party -- in other words, they populate your ID into buyeruid based on bridging -- but I don't recommend this, because then it leads to the complication of your flowchart/pseudocode. So, if you just insist that eids is used for it, any case where buyeruid population appears to be abnormal (based on verification of direct cookie observation at delivery) can be considered abuse/incorrect/invalid.

From a buyer's perspective, in this scenario my buyeruid looked up by this platform has been indirectly bridged. Is there transparency for that?

[iantri]

I'm saying that it shouldn't be. Suppose publisher and SSP agree to use buyeruid in a "non-standard" fashion (bridged ID in buyeruid) -- it's still the SSP's problem to only populate buyeruid in the request they send to you based on conventional cookie sync, unless you've agreed otherwise.

I am suggesting that to maintain their sanity, SSPs should NOT use buyeruid in that fashion between them and pub, because they'll have a hard time untangling it in any event.

If this stuff stays cleanly in eids, everything will be so much simpler...

[iantri]

When the IDs get translated by the SSP to a DSP identifier, we would like to propose that the matcher information is retained.

@deepthivenkat I think that as written already, nothing precludes this? Could you elaborate on what the problem would be? What is getting "dropped" by whom?

[sbelov]

Can we provide more specific, clarifying examples for mm values of 5 (Property-Specific Authentication) and 6 (Property-Specific Inference)?

It's interesting that 5 (Property-Specific Authentication) lists SharedID as one of possibilities; I had thought, however, that the SharedID is not an authenticated ID in a sense of being associated with an individual end user – but a random first-party cookie, meaning associated with a given browser instance.

More generally, can we more precisely define the distinction between "Authentication" as a mechanism for the proposed match methods taxonomy (mm values 3, 5) versus "Inference" (mm values 4, 6)? Where would deterministic, but non-authenticated means (such as first-party cookies) fall?

[dmdabbs]

It's interesting that 5 (Property-Specific Authentication) lists SharedID as one of possibilities; I had thought, however, that the SharedID is not an authenticated ID in a sense of being associated with an individual end user – but a random first-party cookie, meaning associated with a given browser instance.

You're right @sbelov it's muddy. Perhaps SharedID/pubcommonid was included in that list when atype was proposed to be eliminated and there had to be a device-specific identifier accommodation.

From AdCOM
Property-Specific Authentication ID match pertaining to a user on a single web property (e.g. GUID, SharedID, user login or other hashed PII) or application (this may include session IDs) on a single device

But atype remains and can describe a browser-specific value, so I'd suggest we remove GUID, SharedID. The intent is to describe the "match" mechanism not the identifier itself, correct @hillslatt? An ID like SharedID - simple, random, unique device/site-specific value - should have no "matching." It is either present on the device/browser or it isn't.

So for that case I'm inclined to say they should be signaled as "No Match."

No Match
The associated ID came directly from a 3rd-party cookie or OS-provided resettable device ID for advertising (IFA). No matching has occurred.

How about changing "3rd-party cookie or" to "cookie, device storage, or"?

Here then is a suggestion for how a SharedID managed and read in a Prebid install would be signaled. @patmmccann the "inserter" should be the bid adapter that's reading the SharedID (versus 'prebid.org' who provides access via the userid module), right?

let eid = {

    "source": "pubcid.org",

    "uids": [
        {
            // An ID which is tied to a specific web browser or device (cookie-based, probabilistic, or other).
            "atype": 1,
            "id":"01ae3731-742b-4ea8-ad5b-9db72cdbf000"
        }
    ],

    ///////////////////////////////////////////////////////////////////////////

    "inserter": "openx.com",

    /* 
        Match method used by the matcher. Refer to List: ID Match Methods in AdCOM 1.0

        1  No Match 
        The associated ID came directly from a cookie, storage, or 
        OS-provided resettable device ID for advertising (IFA). 
        No matching has occurred.
    */
    "mm": 1,

    /*
       matcher omitted

       May be omitted when mm=0, 1, or 2.
       string Technology providing the match method as defined in mm.
       In some cases, this may be the same value as inserter.
       When blank, it is assumed that the matcher is equal to the source
    */
};

Revised for typo and to replace openx.com as illustrative "inserter".

[patmmccann]

Prebid.org would never be an inserter. it publishes software publishers are free to use and modify in anyway they see fit and doesn't warranty anyone on how it or its derivatives are subsequently used

[patmmccann]

We need to add a clarification to the appendix that partitioned cookie syncs are in scope, there seems to be a lot of suggestions in public that partitioned chips cookies cannot carry exchange identifiers. This doesn't seem to make any sense, chips cookies meet every criteria of the legacy sync yet are just partitioned. In a Dsp - ssp chips cookie sync, one would expect to find identifiers in subsequent win or impression or completion notifications to the same endpoint.

[patmmccann]

Where would deterministic, but non-authenticated means (such as first-party cookies) fall?

5 seems correct from the description and discussion to date and a relaxation of the word authenticated seems appropriate, perhaps substantiated, as people seem to be reading the word authentic to mean tied to a known and identifiable person through a login. My understanding was it meant to suggest complete certainty.

[sbelov]

But atype remains and can describe a browser-specific value, so I'd suggest we remove GUID, SharedID. The intent is to describe the "match" mechanism not the identifier itself, correct @hillslatt? An ID like SharedID - simple, random, unique device/site-specific value - should have no "matching." It is either present on the device/browser or it isn't.

So for that case I'm inclined to say they should be signaled as "No Match."

@hillslatt @dmdabbs Can we confirm – and if so, make that more explicit – that the intent of mm is indeed to only support use cases where a given ID provided in the bid request is derived through some form of matching / linking, and an appropriate value for IDs observed directly, without any linking, should indeed be "no match"? Initially, when reading the proposal, I was confused about the purpose of mm, especially due to values 5 and 6, as they seemed to potentially describe how an ID was generated or derived, as well as the scope of an ID, and not necessarily tied to the matching aspect.

Additionally, is there a suggested, standardized place in OpenRTB for distinguishing single-property from cross-property (cross-app or cross-site) identifiers, if mm is not the right avenue for that, and is solely focused on the matching aspect? For example, how can one distinguish SharedID or a publisher-provided ID (both of which are fairly common) from an authenticated cross-site ID (perhaps, email-based)?

[sbelov]

Where would deterministic, but non-authenticated means (such as first-party cookies) fall?

5 seems correct from the description and discussion to date and a relaxation of the word authenticated seems appropriate, perhaps substantiated, as people seem to be reading the word authentic to mean tied to a known and identifiable person through a login. My understanding was it meant to suggest complete certainty.

@patmmccann @hillslatt

If that is the case, should we consider changing the terminology, perhaps, from "authenticated" to something more general, e.g., "deterministic"? On a related note, do we think there may be value for the demand side to distinguish between authenticated versus deterministic but unauthenticated (e.g. random cookie) in this nomenclature?

[dmdabbs]

Additionally, is there a suggested, standardized place in OpenRTB for distinguishing single-property from cross-property (cross-app or cross-site) identifiers

If a value is an eid then atype=1 gets close, but does not address property scope:

AdCOM Agent Types:

Value	Definition
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.

[sbelov]

Additionally, is there a suggested, standardized place in OpenRTB for distinguishing single-property from cross-property (cross-app or cross-site) identifiers

If a value is an eid then atype=1 gets close, but does not address property scope:

Indeed, atype of 1 communicates that an ID pertains to a browser or a device, but doesn't seem to sufficiently capture its scope – whether it is a single-property or a single-publisher identifier. What does the group think about adding another standard field to capture the scope of an ID for these use cases (with options such as single-property, single-publisher (where a publisher might have multiple properties), or cross-property?

Admittedly, this is not directly related to the current match method transparency proposal, but seems useful in a world with a greater reliance on publisher first-party data.

[iantri]

IMO "atype" in it's current form doesn't make a lot of sense (values 1 and 2 overlap in meaning, and I don't know why #2 refers to "in-app impressions" when this is describing IDs, not impressions) and is ripe to be refined/replaced anyway.

[hillslatt]

@sbelov -

If that is the case, should we consider changing the terminology, perhaps, from "authenticated" to something more general, e.g., "deterministic"?

The group discussed using the deterministic/probabilistic language and decided against for a lot of reasons including but not limited to avoiding the value judgement implicit in that phrasing, the notion that complete certainty is possible (i.e. there are a lot of legitimate cases of authenticated users not being the ones who are actually viewing the content...think me watching a streaming app that uses my husbands email to authenticate, but in my profile).

On a related note, do we think there may be value for the demand side to distinguish between authenticated versus deterministic but unauthenticated (e.g. random cookie) in this nomenclature?

I'm open to adding an explicit enumeration for 1st party cookies if the community thinks that'd be helpful. @iantri @dmdabbs @patmmccann @pm-harshad-mane - please weigh in with your thoughts.

Can we provide more specific, clarifying examples for mm values of 5 (Property-Specific Authentication) and 6 (Property-Specific Inference)?

If you or anyone else would like to write a few, I'd be more than happy to get them vetted with the Commit Group and pushed alongside the production release (or at a later date if the timing doesn't work out it's not a material change).

@hillslatt @dmdabbs Can we confirm – and if so, make that more explicit – that the intent of mm is indeed to only support use cases where a given ID provided in the bid request is derived through some form of matching / linking, and an appropriate value for IDs observed directly, without any linking, should indeed be "no match"? Initially, when reading the proposal, I was confused about the purpose of mm, especially due to values 5 and 6, as they seemed to potentially describe how an ID was generated or derived, as well as the scope of an ID, and not necessarily tied to the matching aspect.

Additionally, is there a suggested, standardized place in OpenRTB for distinguishing single-property from cross-property (cross-app or cross-site) identifiers, if mm is not the right avenue for that, and is solely focused on the matching aspect? For example, how can one distinguish SharedID or a publisher-provided ID (both of which are fairly common) from an authenticated cross-site ID (perhaps, email-based)?

I don't understand this question. List: Match Method meant to answer three questions:

1. Has a match occurred? If no, then use mm=1, if yes - go to the next question
2. Was the match based on some kind of user authentication like an email/text auth/magic link/what have you, or not?
3. Does the ID in question pertain to multiple web properties or apps, or just a single one?

Can you clarify the confusion?

@dmdabbs -

But atype remains and can describe a browser-specific value, so I'd suggest SharedID be removed from that description. The intent is to describe the data used to make some "match" not the identifier itself, correct @hillslatt? An ID like SharedID - simple, random, unique device/site-specific values - should have no "matching." It is either present on the device/browser or it isn't.

Correct. We plan to remove all of the named examples when this goes to production. They were included for the sole purpose of facilitating exactly this discussion.

How about changing "3rd-party cookie or" to "cookie, device storage, or"?
My gut says we should keep 1st and 3rd party cookies separate to each other but I'm not married to that opinion. What does the community think?

@patmmccann

We need to add a clarification to the appendix that partitioned cookie syncs are in scope, there seems to be a lot of suggestions in public that partitioned chips cookies cannot carry exchange identifiers. This doesn't seem to make any sense, chips cookies meet every criteria of the legacy sync yet are just partitioned.

@iantri - want to weigh in on this one?

[sbelov]

Additionally, is there a suggested, standardized place in OpenRTB for distinguishing single-property from cross-property (cross-app or cross-site) identifiers, if mm is not the right avenue for that, and is solely focused on the matching aspect? For example, how can one distinguish SharedID or a publisher-provided ID (both of which are fairly common) from an authenticated cross-site ID (perhaps, email-based)?

I don't understand this question. List: Match Method meant to answer three questions:

1. Has a match occurred? If no, then use mm=1, if yes - go to the next question
2. Was the match based on some kind of user authentication like an email/text auth/magic link/what have you, or not?
3. Does the ID in question pertain to multiple web properties or apps, or just a single one?
   Can you clarify the confusion?

That's a lot of questions for a single field to answer!

I think understand (1) and (2). That seems to mean that mm is meant solely to indicate the method of matching, or linking, for deriving a given ID (either no match, or one of the types of matching).

I am not sure I have clarity about (3) the way you framed it. Does it refer to the scope of the ID that's being communicated (for example, mm value of 3 would mean that the given ID in Eids would be a cross-site identifier), or the scope of the mechanism that enabled the matching? IMO it should not be the former, as that's a fairly distinct concept that applies to IDs derived without any matching (mm value of 1), and it would be valuable to add a distinct field for the scope of an ID to the protocol, perhaps, as a separate proposal.

[hillslatt]

I am not sure I have clarity about (3) the way you framed it. Does it refer to the scope of the ID that's being communicated (for example, mm value of 3 would mean that the given ID in Eids would be a cross-site identifier), or the scope of the mechanism that enabled the matching? IMO it should not be the former, as that's a fairly distinct concept that applies to IDs derived without any matching (mm value of 1), and it would be valuable to add a distinct field for the scope of an ID to the protocol, perhaps, as a separate proposal.

@sbelov IGIN...so two lists to be used in conjunction with one another so List: Match Method would be No/Authenticated/Not Authenticated and then a distinct list for single or multiple properties/apps?

[iantri]

@patmmccann
We need to add a clarification to the appendix that partitioned cookie syncs are in scope, there seems to be a lot of suggestions in public that partitioned chips cookies cannot carry exchange identifiers. This doesn't seem to make any sense, chips cookies meet every criteria of the legacy sync yet are just partitioned.

@iantri - want to weigh in on this one?

My perspective is that the fundamental point is to have a cross-site identifier for cross-site tracking. Having "my" cookie IDs that are constrained to a single site (whether that is a result of some non-conventional method of persistence such as localStorage, or because of CHIPS, be that directly or indirectly through how exchange cookie IDs are persisted) makes them no longer meaningful or useful as "my" cookie IDs since they cannot be arbitrarily accessed across sites. Implicitly, a DSP cookie ID is expected to be a cross-site accessible identifier to fulfill intended purposes.

So I wouldn't welcome it. Regardless of what shakes out regarding the spec, I'll be updating our policies further to spell out that we will not accept it.

The essential purposes of cookie IDs for DSPs are:

• Targeting audiences (i.e. retargeting or 3P data)
• Cross-site frequency capping
• Conversion attribution and other measurement (i.e. reach/frequency)

When it's partitioned by site, it's not usable for any of these. So it doesn't fulfill the essential purposes.

In my view, the only thing that would be accomplished is to cause an {exchange, DSP} "cookie" ID to appear in the bid requests, thereby inducing bidding (by campaigns and/or entire bidders who will not bid when an ID is unavailable). However, not bidding when an ID is unavailable is an intentional behaviour because of the functionality that the DSP wishes to occur.

There are uses for a site-specific identifier, for example to enable the DSP to handle audience data for that specific site and [more likely] for f-capping on a single site. But that's precisely what things like SharedID provide for -- in other words, we'll read from that when we want to cause site-specific f-cap.

Causing a {exchange, DSP} "cookie" ID to appear when it cannot be used for any of the intended purposes would be missing the whole spirit of things from a DSP perspective, in my view.

As the CHIPS overview says:

Without partitioning, third-party cookies can enable services to track users and join their information from across many unrelated top-level sites. This is known as cross-site tracking.

Yes. And for advertising purposes, that cross-site tracking is the point.

[adammarkey]

Adding a +1 to Ian's comments here.

A partitioned cookie breaks the contract of how cookies were originally used in digital advertising. The buyeruid should be reserved for that original purpose. A partitioned ID fails the test for critical DSP functionality to an effective way to target audiences, control frequency across sites, measure marketing outcomes and optimize performance.

Let's please stick newly behaving identifiers into EIDs along with the appropriate metadata so we can find effective ways to consume these new signals.

If DSPs find partitioned IDs like this useful, we might want to add a different match method for these kinds of ID. What do you think @hillslatt ?

[patmmccann]

If @adammarkey and @iantri don't want to participate in chips cookie syncing, they can choose not to by simply not dropping chips sync cookies and not providing chips endpoints to ssps to sync with. I don't see that as a reason to prevent others from finding value there or banishing them into special arrangements land where the spec gives no guidance. However, I do support @adammarkey 's proposal to add chips syncing as an extra match method.