Suggestion: FPD Compatibility #3444
Comments
|
Good to know that the metadata is useful @ourcraig . We don't have the ability to police the correctness of any individual metadata field, and rely on community feedback to correct things. In this case, fpd_supported was meant to indicate that the bidder supports ALL However, I see your point here... fpd_supported: true/false is not nuanced enough. But I don't want to get into the weeds about precisely what is support. How about a compromise. Something like:
If this seems ok, I'll update all the bidder.md files and the display code. Heads up to our friends at AppNexus (@jsnellbaker) and Ozone (@afsheenb) that you guys will be in the "custom" category until you align your code with the conventions. I'm sure there are others. We'll discuss at the next PBJS meeting when we're going to take the time to police all 250 bid adapters on this. |
|
Very happy with the compromise @bretg! I think that this will be a huge time saver moving forward 🙏 |
|
We discussed this in the Taxonomy meeting yesterday. The group agreed that there's lots of nuance in how vendors support FPD. The revised suggestion is that there are three values for fpd_supported:
To make these docs changes, all of the following bidders will need to confirm that these First Party Data details are described in their respective bidder docs: (1) support of ortb2.site, (2) ortb2.user, (3) adunit-specific FPD, and (4) which taxonomies are supported.
I updated the rubicon bidder First Party Data docs as an example of the kind of details publishers are looking for. This issue will stay open for a couple of months. At some point, I'll remove |
- Add required modules documentation
* - Add FDP documentation #3444 - Add required modules documentation * Fix line break Co-authored-by: François Maturel <[email protected]>
|
We're planning on enforcing this rule starting in April 2022. Heads up @braizhas, @AdmixerTech, @mikael-lundin, @ghguo, @nickjacob, @jsnellbaker, @kanchika-automatad, @jsalis, @jeans11, @HuddledMasses, @leonardlabat, @jmayor, @TheMediaGrid, @lbenmore, @zandree-owneriq, @ix-prebid-support, @bjorn-lw, @monisq, @JacobKlein26, @redaguermas, @luigi-sayson, @doelwit, @afsheenb, @pixfuture-media, @vincentproxistore, @pm-harshad-mane, @innay, @javadreamer, @JonGoSonobi, @mikhalovich, @wojciech-bialy-wpm, @nllerandi3lift, @PWyrembak, @winrdev, @ym-atsymuk, @asurovenko-zeta |
|
Ok, finally made this happen. Due to inaction on this issue, the following adapters have had the fpd_supported removed. Publishers should work with each of these to determine their specific FPD support, and encourage them to update the Prebid docs.
|
|
@bretg trustx adapter was deleted |
|
Hi Guys,
The adapter should not have been deleted – it’s supposed to be a carbon copy of TheMediaGrid’s adapter after v7.0, but still downloadable as a separate adapter.
Is that not the case?
PAUL WYREMBAK
TRUSTX<http://www.trustx.org/> | Head of Technical Operations
530 Seventh Ave, New York, NY 10018
+1 631.428.9992<tel:+1%20631.428.9992>
[X Logo]<http://www.trustx.org/>
From: Patrick McCann ***@***.***>
Date: Wednesday, June 8, 2022 at 4:20 PM
To: prebid/prebid.github.io ***@***.***>
Cc: PWyrembak ***@***.***>, Mention ***@***.***>
Subject: Re: [prebid/prebid.github.io] Suggestion: FPD Compatibility (Issue #3444)
@bretg<https://github.com/bretg> trustx adapter was deleted
—
Reply to this email directly, view it on GitHub<#3444 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGDOTOFKCFEDSXWTKAQGINDVOD567ANCNFSM5JNUW3SA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
FPD support flags removed in #3833 Affected adapters are welcome to re-add the flag as long as they add a section to their doc explaining how they support FPD: site, user, segments, per-imp. |
|
Pat,
I've been assured that despite this PR, TRUSTX's adapter would remain
available on Prebig.org, and existing publishers using our adapter would
continue to have support. TRUSTX ads.txt entries will still be relevant,
since requests from TRUSTX/TMG will contain TRUSTX's domain in the supply
chain object.
Do you see things differently? TRUSTX's intention was to utilize the TMG
bidder code, but to maintain our visibility in the marketplace as a
"virtual SSP".
Appreciate your thoughts on whether this can happen given the PR you've
referenced.
Thank you,
Paul
On Wed, Jun 8, 2022, 20:58 Patrick McCann ***@***.***> wrote:
Um
https://github.com/prebid/Prebid.js/pull/8321/files
—
Reply to this email directly, view it on GitHub
<#3444 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGDOTOE2UDX4XEQZ4NP35F3VOE6S7ANCNFSM5JNUW3SA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
PAUL WYREMBAK
TRUSTX | Head of Technical Operations
530 Seventh Ave, New York, NY 10018
+1 631.428.9992
|
* - Add FDP documentation prebid#3444 - Add required modules documentation * Fix line break Co-authored-by: François Maturel <[email protected]>
Bidders currently have
fpd_supported: true/falseunder their feature list, but some bidders (e.g. AppNexus) support FPD using bidder params only, whereas others (e.g. Ozone Project) have partial support for standardised FPD viaortb2.userbut appear to require site/contextual data to be pushed into bidder params instead.I would like to propose
fpd_compatibilityin place offpd_supported, where its values would give more of an indication as to the level of FPD support provided by the bidder. In the short term this would help to speed up publisher FPD integrations with prospective bidders and, by shining a light on any bid adapters using non-standard methods, it may help encourage greater FPD standardisation in the long term.Example values for
fpd_compatibilitycould be:ortb2.user,ortb2.site, bidder paramsortb2.user,ortb2.siteortb2.user, bidder paramsortb2.site, bidder paramsortb2.useronlyortb2.siteonlyThe text was updated successfully, but these errors were encountered: