Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transfer data from rtd provider to s2s adapter #6049

Closed
Niksok opened this issue Nov 30, 2020 · 13 comments
Closed

Transfer data from rtd provider to s2s adapter #6049

Niksok opened this issue Nov 30, 2020 · 13 comments
Assignees

Comments

@Niksok
Copy link
Contributor

Niksok commented Nov 30, 2020

Type of issue

Question

Description

Is it possible to transfer some data from any rtd provider via prebidServerBidAdapter to s2s adapter?
If on current time it is not possible may i make some pull request with changes in prebidServerBidAdapter to support this case?

@bretg
Copy link
Collaborator

bretg commented Dec 1, 2020

It is recommended that RTD adapters pass data to bid adapters using first party data conventions. See https://docs.prebid.org/dev-docs/add-rtd-submodule.html#getbidrequestdata

If they do, the data will be passed to Prebid Server and server-side adapters automatically. I don't think we need to support the "bidrequest.rtd.MODULECODE" scenario in the Prebid Server world because it requires adapter changes.

What specifically is your use case @Niksok ? Will First Party Data work?

@bretg bretg self-assigned this Dec 1, 2020
@Niksok
Copy link
Contributor Author

Niksok commented Dec 2, 2020

I would be happy with the option with fpd, but it seems that rtd providers set fpd in adUnit.bids, while prebidServerBideAdapter try to get fpd datafrom config or from bidderConfig but not from adUnit.bids. This concerns jwplayerRtdProvider and haloRtdProvider, other rtdAdapters do not use fpd as i see.

@bretg
Copy link
Collaborator

bretg commented Dec 2, 2020

Adding @karimMourra and @anthonylauzon to re-consider how their RTD modules are passing data.

If an RTD module wants to get data to Prebid Server adapters, it needs to be first party data. Unless someone can articulate a reason it makes sense to establish yet another path for data to get server side.

@karimMourra
Copy link
Collaborator

Hi @Niksok and @bretg there seems to be some confusion. The JW Player RTD module doesn't write to fpd. The publisher writes to fpd and we read from it. We read from both the adUnit's fpd and the config's fpd, and use the config fpd as a fallback (see https://github.com/prebid/Prebid.js/blob/master/modules/jwplayerRtdProvider.js#L147)

With regards to setting targeting data, we set our results to bid.rtd. https://github.com/prebid/Prebid.js/blob/master/modules/jwplayerRtdProvider.js#L257

I am not familiar with s2s adapter, but given the information I've provided, are you still blocked by JW Player ?

@bretg
Copy link
Collaborator

bretg commented Dec 2, 2020

we set our results to bid.rtd

Right - no confusion. This is the problem for server-side adapters. They don't get 'rtd' data. They only get 'fpd'.

The only way to get data to a server-side adapter is to set it as fpd. I'm not going to approve yet-another-parallel-openrtb-data-path unless someone has a killer-good reason. I can't think of any.

So basically, I think the Prebid-Server angle here makes the existence of bidRequest.rtd rather questionable. At this point I'm thinking we should just make all RTD modules set FPD.

@Niksok
Copy link
Contributor Author

Niksok commented Dec 3, 2020

So, @karimMourra , it will be great, if you update the JW Player RTD module so, that it will be write its result into FPD as well.

@karimMourra
Copy link
Collaborator

@bretg and @Niksok i disagree, our data is not first party data, and I suspect that most Real Time Data does not qualify as first party data. First party Data is data supplied by the publisher. We are not the publisher, we are a 3rd party service used by the publisher. I think the proper solution would be to add server side support for RTD. Using variables in a way that is misleading can cause problems further down the line and it's best to address ASAP.
Given the urgency to support prebid server I am willing to also support FPD in the short term, but suggest adding server side support for RTD in the mid term. The easy solution is not always the right solution.

@bretg
Copy link
Collaborator

bretg commented Dec 3, 2020

The good news is that this semantic labeling issue is going away. See #5795

We're going to stop calling it "first party data" and just lump it into the "ortb2" object. Cool?

@Niksok
Copy link
Contributor Author

Niksok commented Dec 10, 2020

Cool, but I have one more question - as I see there is currently no support on the s2s side for fields (ext.prebid.bidderconfig) where the prebidServer module passes fpd data to the auction endpoint. Is this a known issue or is this standard behavior?

@Niksok
Copy link
Contributor Author

Niksok commented Dec 15, 2020

@bretg , can you help me in this question?

@bretg
Copy link
Collaborator

bretg commented Dec 15, 2020

as I see there is currently no support on the s2s side for fields (ext.prebid.bidderconfig) where the prebidServer module passes fpd data to the auction endpoint

There is support for FPD in PBS-Java, but you're right, PBS-Go is currently missing:

  • bidder permissions
  • bidder-specific FPD
  • merging site.data to site.ext.data
  • alternate data types

This means that to get FPD through PBS-Go, it needs to be global:

  • {site, user, app}.ATTR
  • {site, user, app}.ext.data.ATTR

No bidder permissions or bidder-specific data. Adding @SyntaxNode to confirm whether there's a timeline on this support.

@SyntaxNode
Copy link

@bretg Correct. The Xandr team is currently working on implementing these FPD features for PBS-Go at the start of 2021.

@bretg
Copy link
Collaborator

bretg commented Mar 22, 2021

Closing this with reference to prebid/prebid-server#879

@bretg bretg closed this as completed Mar 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants