Proposal for RTB 2.6/3.0: Cross-device data in bid requests

[Curt Larson]

Hi all,

Wanted to surface a new idea/proposal for consideration for a future version of RTB.  As it is not breaking, it could go in an incremental 2.x release or in 3.0.

This proposal provides a way for the supply side to indicate the presence of more than one possible userid and/or deviceid match to the demand side.  With the proliferation of user devices (phones, tablets, laptops, desktops) a given user has a very fragmented identifier set, and the odds of a DSP having its best bid for any given one of them is low.  If the buy-side had visibility to IDs from other devices the user has it could better deliver to advertiser objects and improve sell-side monetization.

https://docs.google.com/document/d/1E550xv63KBVuVkGS2QWgSlQe0azPTyJqlhr5dU5TX3U/

The doc should be open for anyone to edit, so appreciate your comments here, in the doc, or in our future chats.

Curt

[Sam Tingleff]

Hey Curt, this is a great proposal, thank you.

We have a couple of use cases in which "vendors" are identified - for example the metrics object, and here. It would be great to have a consistent model for identifying vendors which all exchanges could share. Using domain name, for example ("sharethrough.com") would be one such model though I'm sure there are others.

I'd like to avoid a situation in which Vendor A is identified as "vendor-a" through Exchange 1 and as "Vendor A" through Exchange 2. Ideas on that?

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Curt Larson]

Quite agreed.  The domain model is simple, though not foolproof.  There is some effort around this on a wider level within the working groups, will defer to that.

Curt

--
You received this message because you are subscribed to a topic in the Google Groups "openrtb-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrtb-dev/-NzHyq1pMZw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Curt Larson - sharethrough - 415-781-9883 mobile -  cla...@sharethrough.com

[Pierre Nicolas]

Loving this.

 

One question: do you could we find a way to explicitly fit other identifiers in there or is the added complexity not worth it?

 

I’m thinking of identifiers that aren’t tied to a client type, so things like hashed email, CRM ID, etc. They wouldn’t be compatible with a required atype, and there would be a need for a way to “describe” them, but I’m wondering if there would be use cases that already exist or would be enabled by an addition to the spec?

 

--Pierre

 

De : <openr...@googlegroups.com> au nom de Curt Larson <cla...@sharethrough.com>
Répondre à : "openr...@googlegroups.com" <openr...@googlegroups.com>
Date : mercredi 8 février 2017 00:22
À : "openr...@googlegroups.com" <openr...@googlegroups.com>
Objet : Re: [openrtb-dev] Proposal for RTB 2.6/3.0: Cross-device data in bid requests

 

Quite agreed.  The domain model is simple, though not foolproof.  There is some effort around this on a wider level within the working groups, will defer to that.

 

Curt

On Tue, Feb 7, 2017 at 3:11 PM, 'Sam Tingleff' via openrtb-dev <openr...@googlegroups.com> wrote:

Hey Curt, this is a great proposal, thank you.

 

We have a couple of use cases in which "vendors" are identified - for example the metrics object, and here. It would be great to have a consistent model for identifying vendors which all exchanges could share. Using domain name, for example ("sharethrough.com") would be one such model though I'm sure there are others.

 

I'd like to avoid a situation in which Vendor A is identified as "vendor-a" through Exchange 1 and as "Vendor A" through Exchange 2. Ideas on that?

On Tue, Feb 7, 2017 at 2:23 PM, Curt Larson <cla...@sharethrough.com> wrote:

Hi all,

 

Wanted to surface a new idea/proposal for consideration for a future version of RTB.  As it is not breaking, it could go in an incremental 2.x release or in 3.0.

 

This proposal provides a way for the supply side to indicate the presence of more than one possible userid and/or deviceid match to the demand side.  With the proliferation of user devices (phones, tablets, laptops, desktops) a given user has a very fragmented identifier set, and the odds of a DSP having its best bid for any given one of them is low.  If the buy-side had visibility to IDs from other devices the user has it could better deliver to advertiser objects and improve sell-side monetization.

 

https://docs.google.com/document/d/1E550xv63KBVuVkGS2QWgSlQe0azPTyJqlhr5dU5TX3U/

 

The doc should be open for anyone to edit, so appreciate your comments here, in the doc, or in our future chats.

 

Curt

--

You received this message because you are subscribed to the Google Groups "openrtb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to a topic in the Google Groups "openrtb-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrtb-dev/-NzHyq1pMZw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openrtb-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

Curt Larson - sharethrough - 415-781-9883 mobile -  cla...@sharethrough.com

--

You received this message because you are subscribed to the Google Groups "openrtb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev...@googlegroups.com.

[Jim Butler]

I think we should also consider how often an exchange can even have access to real cross-device IDs and when we do if they're really willing to share such an asset directly.  Usually I've seen this this used to create a single user-level ID as a way of dipping into a supply-side DMP and then either sending that data or using that data to target deals.

:JB

--

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to a topic in the Google Groups "openrtb-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrtb-dev/-NzHyq1pMZw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

Curt Larson - sharethrough - 415-781-9883 mobile -  cla...@sharethrough.com

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "openrtb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

James M. Butler, Ph.D.

VP Engineering, Publisher Platforms | AOL Platforms

155 Seaport Blvd, 8th Floor, Boston MA 02210

+1.617.834.2125 | Mobile

jim.b...@teamaol.com

 

This electronic message transmission contains information from AOL Inc., which may be confidential or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this information is strictly prohibited. If you have received this electronic transmission in error, please notify sender immediately and delete all copies.

[David Dabbs]

One could use identifiers like URNs (https://en.wikipedia.org/wiki/Uniform_Resource_Name).

      urn:iab:vend:sharethrough.com

or for the 'generic' namespace

     urn:iab:std:md5email:....
     urn:iab:std:sha1email:....

If actual URNs are usedm, then IAB should register the iab URN namespace with the IETF.
One could avoid a registry within the IAB by using the vendor's TLD (e.g. sharethrough.com, baz.co.uk, &c), which would ensure uniqueness.

If one only uses urn-like values, then we could omit the (implied) urn:iab prefix mandated if the value isn;t a true URN needed for interoperability over the interwebs in XML docs, etc.

Documentation for range and interpretation of vendor specific values, &c is the provenance of the vendor.

Just my $0.02

David

David Dabbs

Sr. Product Manager, Bidding

Conversant Media

--

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to a topic in the Google Groups "openrtb-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrtb-dev/-NzHyq1pMZw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

Curt Larson - sharethrough - 415-781-9883 mobile -  cla...@sharethrough.com

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "openrtb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

[Curt Larson]

Jim - why would an exchange not want to supply this info?  Seems they are incented to give the buyer every opportunity to bid on the impression?  Or are you worried they'd be worried the buyer would slurp that data to build their own graph?

Curt

[Jim Butler]

True on both counts; the latter being the concern.

:JB

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Tingleff]

Isn't that between the exchange and the x-device vendor? It could be that the exchange is just a conduit and an agreement is required between the DSP and the vendor.

On Feb 9, 2017, at 11:50 AM, Jim Butler <jim.b...@teamaol.com> wrote:

True on both counts; the latter being the concern.

:JB

On Thu, Feb 9, 2017 at 2:38 PM, Curt Larson <cla...@sharethrough.com> wrote:

Jim - why would an exchange not want to supply this info?  Seems they are incented to give the buyer every opportunity to bid on the impression?  Or are you worried they'd be worried the buyer would slurp that data to build their own graph?

Curt

On Wednesday, February 8, 2017 at 8:28:04 AM UTC-8, Jim Butler wrote:

I think we should also consider how often an exchange can even have access to real cross-device IDs and when we do if they're really willing to share such an asset directly.  Usually I've seen this this used to create a single user-level ID as a way of dipping into a supply-side DMP and then either sending that data or using that data to target deals.

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James M. Butler, Ph.D.

VP Engineering, Publisher Platforms | AOL Platforms

155 Seaport Blvd, 8th Floor, Boston MA 02210

+1.617.834.2125 | Mobile

jim.b...@teamaol.com

<4F4D4F1A-90FA-4705-A72A-F106173CE0C2[1].png>

<D3BA8767-A681-499E-B972-53C85D3359EF[1].png> <B93B4A57-7B8F-4D9D-9968-E56CB54CBFFA[1].png>

This electronic message transmission contains information from AOL Inc., which may be confidential or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this information is strictly prohibited. If you have received this electronic transmission in error, please notify sender immediately and delete all copies.

--

You received this message because you are subscribed to the Google Groups "openrtb-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev...@googlegroups.com.

[boke...@gmail.com]

Curt,

I have a few concerns here:

• We have seen a lot of fraud from sellers around device IDs and device graphs. In some cases we have seen (across multiple requests) over 200 IDs mapped to the same user. This obviously increases monetization significantly, since you're increasing the cookie pool dramatically, but obviously isn't actually achieving advertiser goals. I worry that adding this to the protocol will make it easy for less-sophisticated buyers to get tricked into believing the data. You might say "well then don't trust every seller". We have been going down that path for a long time, and I don't think it's worked or will ever work. There are too many broken incentives in the system and opportunities for leakage.
• This feels to me like a major data leakage risk, which is called out in this thread around buyers building their own graphs, but it feels odd to build explicit data leakage into the protocol. From my discussions with publishers, identity is a key strategic asset, and there are entire business (LiveRamp and recent acquisitions as examples) that monetize this data for publishers without direct data leakage. That seems to me to solve this problem better than broadcasting to a bunch of bidders.
• This introduces major privacy risk at the heart of the protocol. I expect significant regulatory pressure on device IDs and cross-device mapping, for one thing, and also with GPDR we need to be careful about how identifiers cross borders.

On the whole, I suggest we keep device graphs out of the protocol.

[Pierre Nicolas]

Hi Brian,

 

All valid points, I agree on the issues but not on the solution (to keep away from the standard).

 

Regarding privacy:

-          I think it should start (and possibly end) with this objection, but if businesses are able to openly build and sell graphs, they will do so with or without OpenRTB; the problem might be at the heart of the protocol, but the protocol is far from being the heart of the problem

 

Regarding “user ID fraud” (to be all-encompassing):

-          This proposal neither deters nor encourages it

-          I don’t think it’s neutral either, but if you argue that it could enable fraudsters (give the idea to someone who otherwise wouldn’t have thought of it or blur language around identifiers), you must also consider that it would encourage prudence from buyers (wake them up to the sheer possibility of this kind of fraud or push to strengthen language in contracts)

-          Personally, I think OpenRTB should clarify language around user identifiers: currently you can say you use the standard, put any ID in the field and argue (plead even?) good faith if caught; this shouldn’t be possible and clearer language would legitimize cutting all ties with a player who does this (I would personally even want to publish this)

 

Regarding data leakage:

-          A lot of exchanges have language in their contract prohibiting to create audiences based on what URLs users visit, the same language could protect cross-device matches

-          There’s only a handful of publishers who 1° collect cross-device matches 2° sell them 3° sell them without an intermediary (= Liveramp), and they seem to all agree that contracts are the best safety net for data leakage, do we have signs from them that the current *cough* ridiculous-inflation-of -bid-requests-bouncing-around *cough* situation has weakened these protections?

-          (There were similar conversations around placement viewability as an independently monetized asset, and I feel like your exchange took the opposite approach (of including in bid requests by default), which helped “prime the pump” for the whole industry – that’s my read on how history unfolded, would love your view on it! J)

 

IMHO the current situation is this: if you want to share cross-device data you either must create a custom extension (and people loooove extensions J) or bend the protocol after a handshake and make the new behavior technically indiscernible from fraud. Experience says this business practice of sharing IDs won’t break out of the relative niche it’s in without a standard protocol change…

 

Cheers,

Pierre

 

De : <openr...@googlegroups.com> au nom de "boke...@gmail.com" <boke...@gmail.com>
Répondre à : "openr...@googlegroups.com" <openr...@googlegroups.com>
Date : mercredi 22 février 2017 12:24
À : openrtb-dev <openr...@googlegroups.com>
Objet : [openrtb-dev] Re: Proposal for RTB 2.6/3.0: Cross-device data in bid requests

--

[boke...@gmail.com]

Pierre,

Great points. I think they sum up to "people are going to do x-device anyway so why not standardize it". I think though your last point is the same as mine: Experience says this business practice of sharing IDs won’t break out of the relative niche it’s in without a standard protocol change. I am saying, let's keep it in that niche.

Why not standardize OpenRTB around something like the Digitrust ID? That would be huge on many levels; it's privacy-safe, it's opt-in, and makes the explosion of identifiers better not worse by removing the need for all of the cookie synching we see.

b

[Alex Merwin]

Brian - 

Completely agree on DigiTrust. SpotX is also committed to the standard and we should discuss how we'll pass it through to DSPs for signaling. 

Best,

~ Alex

Alex Merwin | VP, International

M: +44 (0) 7490 132 754 | LinkedIn  

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

[Sam Tingleff]

Here's the proposed DigiTrust extension. We've avoided proposing as a standard yet because AFAIK no publishers are live and it does not (yet) meet the "at least two parties conducting transactions" threshold I think should probably be a prerequisite for OpenRTB adoption.

https://github.com/digi-trust/dt-cdn/wiki/OpenRTB-extension

Though Digitrust is not going to solve x-device use cases any time soon if at all.

On Feb 23, 2017, at 6:46 PM, 'Alex Merwin' via openrtb-dev <openr...@googlegroups.com> wrote:

Brian - 

Completely agree on DigiTrust. SpotX is also committed to the standard and we should discuss how we'll pass it through to DSPs for signaling. 

Best,

~ Alex

Alex Merwin | VP, International

M: +44 (0) 7490 132 754 | LinkedIn  

<Screen Shot 2017-01-05 at 14.45.54.png>