-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Feature Request: Implicit schain node for AppNexus adapter aliases #8891
Comments
Hi @nickjacob I've reached out to a product manager colleague to review this request for the appnexus adapter. I wanted to share the understanding we had from our end about the use of aliases in regards to schain and sellers.json. If the publisher is using the aliased adapter, they’re calling that alias’ seat (on our ad-server system), and the schain will (or should) start from the alias member’s seat. They’ll be selling inventory on the publisher domain, so that’s where the sellers.json piece comes in. The fact that the publisher says the alias member can sell their inventory in their sellers.json, and the alias adapter calls the alias member seat - so this should complete the requirement. |
If it turns out to be necessary, Why not just set the bidder specific schain to have the extra node following #4465? |
@jsnellbaker the rule is supposed to be whoever is in the payment chain is in the schain, so if i understand correctly if dsp pays appnexus pays oftmedia pays publisher, the appnexus node should be added, if the dsp pays oftmedia directly, it isn't. However the appnexus node would be between the dsp and oftmedia, not between oftmedia and the pub. Are we saying the same thing? |
An alias adapter has to rely on the server to add a node am I thniking this correctly? As the alias rely on the main server technology (in this case Xandr) it should be xandr who adds this node for oftmedia? the flow is publisher->oftmedia->xandr->DSP. Since Xandr is now passing its schain when the request hits their server seems oftmedia node is not added. I could be worng though. |
@Alejo152 the request chain flow is not relevant the schain, the money flow is. Is the dsp's money sent along in the exact inverse of 'publisher->oftmedia->xandr->DSP. ' ? |
Patrick, Yes, that's the exact money flow. My concern is does Xandr needs to state the OFTmedia node as we are paying pubs but have no server instance to add our node ourselves? What I infere is that DSP now sees a schain with only xandr present but the payment flow has OFTmedia in it as we receive payments from Xandr and then pay publishers or keep the % of our O&O properties. |
It seems that following #4485 you could instruct your publishers to add the OFTmedia node to the Xandr aliased adapter via bidder specific schain configuration options. Xandr should then be adding their own node before they end the request to dsps, but that is server side behavior that should be addressed with them. |
If I recall correctly, Schain specs stipulates that intermediaries are prohibited from adding upstream intermediaries' nodes. Each intermediary is responsible to add its own node. As xandr, we will add our own node. If the request comes in with no schain information from an intermediary client, we will simply mark it as incomplete and start with our node. If some schain information is already present, we will forward the isComplete flag, existing schain nodes, and append our own. |
Original poster reports they are engaging AppNexus on server side behavior and no longer has a feature request |
Type of issue
Feature request/proposal
Description
The AppNexus bid adapter has a some aliases that historically didn't need an ads.txt line & schain node. Some of these (e.g. Oftmedia/152media) have sellers.json files -- because they pay the publisher, they're require to have their own ads.txt line (e.g. 152media.info).
AppNexus isn't adding an schain node to represent this relationship server-side (as far as I know). The publisher isn't necessarily aware of the relationship between AppNexus and the aliased adapter, so they won't know to include a custom schain-module configuration to represent the reseller/appnexus platform user.
This is a feature suggestion specific to the AppNexus bid adapter -- we could define the asi for each alias as part of the aliases configuration and then use it when building the schain to pass in the request (https://github.com/prebid/Prebid.js/blob/master/modules/appnexusBidAdapter.js#L211) this is assuming the seller ID could be derived from the bid parameters somehow..
If anyone from Xandr knows if there's already a way to handle this server-side via /ut please let me know & Ill close this -- I'm making this ticket because I was talking to the 152media team--from what they've heard this isn't possible/schain has to be passed client-side?
The text was updated successfully, but these errors were encountered: