Proposed Prebid.js Module Rules

[bretg]

The Prebid Code-of-Conduct sub-committee has drafted an enhanced set of rules governing what bid adapters, user ID sub-modules, and other types of modules can and can't do. We're doing this to preserve the trust that publishers have in Prebid as an important part of the independent ad tech stack.

The rules include old favorites like endpoints being HTTPS, but many new rules as well.

Here's the process:

1. Community comment period. That starts now. Adapters and modules doing "unusual" things should pay special attention. e.g. recording loss-events, loading external files, loading a creative render script, etc
2. After being ratified by Prebid and the community, the rules will be documented on prebid.org and enforced from that point forward for new and changed modules.
3. Several rules will require changes in existing adapters/modules. A timeline will be set for each rule, probably something like "All adapters must adhere to this rule in 5.0 or it won't be allowed in."

We're looking forward to your comments, and especially your thumbs-up.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bretg]

As a result of a recent review, added one more:

Each module must include maintainer information with a group email address for Prebid.org to contact for support or maintenance.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Slind14]

Thank you for putting this up for community comments.

We are cutting out wasteful requests to specific bidders and want to integrate this on the adapter level. The classification is using machine learning. For optimal performance, this needs to run client-side where the model can be cached since it is doing a unique prediction for every single request.

The model is loaded from a CDN, the entire size is 10-20KB, the code is minified, the model is changing at least once per hour. The predictions happen in nanoseconds. The model only returns true/false and doesn't impose any direct risk.

This is directly tied to the adapter and its internal bidding behavior.

The proposed rules, would not allow this, yet it is improving efficiency.

[bretg]

@Slind14 - this was an anticipated usage of the 'real-time-data' module architecture -- the ability to optimize which bidders participate in a given auction given location, refresh count, number of bids, etc.

RTD modules may cache bid metadata for analytics and optimization purposes. They may use those bids to optimize future auctions for which bidders and adunits take place. They must not re-use specific past bids in an auction -- that functionality is restricted to Prebid core.

The idea is that an RTD module could listen to the beforeRequestBids event and modify the AdUnits based on the desired optimization algorithm.

The proposed rules, would not allow this, yet it is improving efficiency.

Where were you thinking the rules wouldn't allow it?

[Slind14]

Yep, I understand that. From an SSPs side it is difficult to get all publishers to integrate the module.

So it would help a lot if it was allowed to be done inside the adapter where it is enabled by default.

Ofc. it could be done server-side which would be allowed per the terms but the performance and also cost is a lot worse in this case.

[bretg]

done inside the adapter where it is enabled by default

Please elaborate a little more on what the vision is.

As I understand it, the part about "cutting out wasteful requests to specific bidders" is clear and wonderful. We want to support that ability.

"difficult to get all publishers to integrate the module" -- also totally agreed, but that's the nature of Prebid.js -- pubs are already wary of the overall PBJS package size. There's little chance we're going to add a feature like this to core. It's clearly an optional module.

So it would help a lot if it was allowed to be done inside the adapter where it is enabled by default

It would be fine for each bid adapter to agree to some kind of convention.

[Slind14]

Most SSPs and exchanges we talked with directly jumped to the best way of implementation being within the bid adapter. This ensures that nothing changes for the publisher and that it is automatically live with the next update.

By implementing it in the adapter, the prebid package size barely increases. It is just 5 lines of code.

It would be fine for each bid adapter to agree to some kind of convention.

Can you elaborate on what you mean here?

[bretg]

Let's step back. I don't understand what you're trying to do and how it breaks the proposed module rules.

What specific proposed rule are we talking about?

[Slind14]

Number 4 of the bid adapter rules or would you consider this to be part of the auction request?

[bretg]

Trying to piece all this together, I've reverse engineered that the real request here is that some SSPs want to throttle incoming requests and can't handle this themselves like other SSPs do on the server-side.

I think there needs to be a broader discussion about the problem and possible solutions. Maybe the industry can solve this another way without affecting users and publishers. e.g. one of the SSPs could build out an infrastructure and share it with the others, charging them a fee to do so. Or perhaps it's not really so hard to get publishers to include a real-time-data module, especially if the affected SSPs made it a requirement for using their adapter.

But if those options don't work out, Rule 4 already has a built-in exception procedure:

4. Bidder modules must not() make requests to endpoints for functionality other than auctions without:
   a. Disclosure
   b. Ability for the publisher to control the additional functionality.
   c. If the publisher turns off the additional functionality, their auctions must still be operable. i.e. bid adapters may log certain analytics events, but if a publisher turns it off, the auction should still happen.
   d. If a bidder would like to incorporate an external data fetch that would influence the auction, they must() build a Real-Time Data sub-module that obtains data in a way that can be utilized by other bidders as well.

So if a group of SSPs wanted to build something like this, they could do so with appropriate disclosure and control options. In order to facilitate the process, I recommend at least one of the parties join Prebid.org and discuss in detail with the Prebid.js team.

But at this point I don't see a need to change the module rules because we already recognized that some bid adapters might want to do things we hadn't anticipated.

[GLStephen]

We've built Prebid deployment infrastructure around this at PubWise pre-RTD. Would be happy to work with SSPs that seriously want to explore leveraging it.

[Slind14]

Yes, most do it server-side. We do as well. But doing it client side as well is a lot more efficient in terms of traffic and infrastructure.

[bretg]

The committee approved the module rules this week. Will be posting them on the web site in the near future. Will then add a link here and close this issue.

[GeneGenie]

@bretg I also propose to add 1 more must to bidder adapter:
"While adding new or updating existing bid adapter, you should add 100% filling test params to the adapter documentation. To guarantee ease of integration on a publisher side. Making sure everything works as expected in dev environment"

[bretg]

Going to close this issue -- Module Rules are published and the request for bidders to provide test params is at https://docs.prebid.org/dev-docs/bidder-adaptor.html#required-files already.

Bidders don't always provide them, and not all reviewers catch them. Will send another reminder to the reviewer team.

But even if test params work at the time of initial acceptance, they could stop working anytime.