Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| func getMediaTypeForImp(impID string, imps []openrtb2.Imp) openrtb_ext.BidType { | ||
| for _, imp := range imps { | ||
| if imp.ID == impID { | ||
| if imp.Banner != nil { |
There was a problem hiding this comment.
Consider this as a suggestion. The current implementation follows an anti-pattern, assumes that if there is a multi-format request, the media type defaults to openrtb_ext.BidTypeBanner. Prebid server expects the media type to be explicitly set in the adapter response. Therefore, we strongly recommend implementing a pattern where the adapter server sets the MType field in the response to accurately determine the media type for the impression.
| if imp.ID == impID { | ||
| if imp.Banner != nil { | ||
| return openrtb_ext.BidTypeBanner | ||
| } else if imp.Video != nil { |
There was a problem hiding this comment.
Consider this as a suggestion. The current implementation follows an anti-pattern, assumes that if there is a multi-format request, the media type defaults to openrtb_ext.BidTypeVideo. Prebid server expects the media type to be explicitly set in the adapter response. Therefore, we strongly recommend implementing a pattern where the adapter server sets the MType field in the response to accurately determine the media type for the impression.
| return openrtb_ext.BidTypeBanner | ||
| } else if imp.Video != nil { | ||
| return openrtb_ext.BidTypeVideo | ||
| } else if imp.Native != nil { |
There was a problem hiding this comment.
Consider this as a suggestion. The current implementation follows an anti-pattern, assumes that if there is a multi-format request, the media type defaults to openrtb_ext.BidTypeNative. Prebid server expects the media type to be explicitly set in the adapter response. Therefore, we strongly recommend implementing a pattern where the adapter server sets the MType field in the response to accurately determine the media type for the impression.
| return openrtb_ext.BidTypeVideo | ||
| } else if imp.Native != nil { | ||
| return openrtb_ext.BidTypeNative | ||
| } else if imp.Audio != nil { |
There was a problem hiding this comment.
Consider this as a suggestion. The current implementation follows an anti-pattern, assumes that if there is a multi-format request, the media type defaults to openrtb_ext.BidTypeAudio. Prebid server expects the media type to be explicitly set in the adapter response. Therefore, we strongly recommend implementing a pattern where the adapter server sets the MType field in the response to accurately determine the media type for the impression.
Code coverage summaryNote:
rtbstackRefer here for heat map coverage report |
static/bidder-info/rtbstack.yaml
Outdated
| @@ -0,0 +1,17 @@ | |||
| endpoint: "http://{{.Host}}" | |||
There was a problem hiding this comment.
Hello. We do not allow the domain name to be configurable due to security issues. Additionally, we highly discourage subdomains as they negatively affect the performance of maintaining connections to your bidding server. Please see our bidder development guide for further information: https://docs.prebid.org/prebid-server/developers/add-new-bidder-go.html
There was a problem hiding this comment.
Hi @bsardo,
Thank you for taking the time to review this.
Based on my understanding and by looking at other adapters (for example, Tappx), this approach has been used before, so we followed an established pattern. That said, I completely understand that the requirements or expectations may have evolved since then.
Our main goal is to keep the logic consistent between the Prebid.js adapter and the Prebid Server implementation. At the same time, we've already shared the current EndpointURL with a large number of publishers, so making a breaking change would be difficult and could negatively impact them.
With that in mind, I'd like to propose a possible compromise. On the Prebid Server side, we could use a static domain (for example, rtb-stack.com), while still allowing the subdomain and query parameters to remain dynamic via macros. This would move us closer to the current policy while minimizing disruption for existing publishers.
I'd really appreciate your thoughts on whether this could be an acceptable solution.
Thank you!
There was a problem hiding this comment.
Hi @bsardo,
I’ve updated this PR and adjusted the implementation based on the previous feedback. Could you please take another look when you have a chance?
There was a problem hiding this comment.
Hello @bsardo, hope you're doing well!
Could you please share an update on this PR? Also, it would be great to have an approximate ETA for availability, as our customers are waiting for it.
Thanks in advance!
…o rtb-stack-adapter
Code coverage summaryNote:
rtbstackRefer here for heat map coverage report |
Code coverage summaryNote:
rtbstackRefer here for heat map coverage report |
2 participants
Hi Prebid Team,
I'm Alexander, part of the RTBStack team within the Admixer ecosystem. We're excited to contribute our RTBStack adapter to Prebid Server, supporting multiple ad formats including banner, video, native, and audio for both site and app environments.
This adapter is built with full OpenRTB 2.x compliance and includes robust request/response handling, custom parameters, and sample test cases for various scenarios. We believe it will add valuable functionality for publishers and bidders integrating with the RTBStack platform.
We'd love your review and feedback to get this contribution merged. Thank you for maintaining such an awesome project!
Best regards,
Alexander
RTBStack / Admixer