-
Notifications
You must be signed in to change notification settings - Fork 753
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
DOOH support #2758
DOOH support #2758
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution!
Added some comments.
Just want to reiterate requirements
Adjust validation logic to verify that only one of app, dooh, and site are provided. - Done
Allow bidders to specify in their configuration if they support media types for a new dooh capability. - Done
Filter unsupported dooh impressions before calling a bidder, extending existing opt-in logic for app and site. - Done, unit test is needed
Add a new dooh channel type and auto populate to dooh when the value is not provided by a publisher. - Not sure where is this, can you please point to the code? Is it a part of setFieldsImplicitly
function changes?
When searching for the account id, check dooh.publisher in addition to app and site. - Done
Add support for dooh in the video endpoint data model. This endpoint is planned to be deprecated, but its strange IMHO to implement DOOH support everyone but here. - not done. This should be a simple change: just add DOOH object to BidRequestVideo
(similar to Site and App). No changes in endpoint are needed, it should be handled automatically by HoldAuction.
} else if isDOOHReq { | ||
labels.Source = metrics.DemandDOOH | ||
labels.RType = metrics.ReqTypeORTB2DOOH | ||
labels.PubID = accountId |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add unit test for this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not covered, please consider to add a unit test for these lines
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@VeronikaSolovei9 I really struggled with adding test coverage here.
The reason is, there's no testing for all of the other branches in this if-else group - so I had no easy way to simply add tests for this new condition.
I couldn't find a portion of the test suite that explicitly covers parseRequest()
- only tests for some of the other functions it calls.
I went down the rabbit hole of potentially adding metrics labeling tests by extending the json examples in endpoints/openrtb2/sample-requests
(something like expectedMetricLabels
to complement expectedReturnCode
, but the driver of the tests actually lacked access to the metric labels to assert on expected values).
Happy to hear any recommendations to pull this off reasonably, or punt for not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@VeronikaSolovei9 has a lot of good feedback. In addition to the few nitpick comments,
- Please add a DOOH
Channel
in config/accounts.go + exchange/utils.go - Add support in the RequestWrapper for doohExt alongside appExt and siteExt.
From feedback from PR prebid#2758
From feedback from PR prebid#2758
Thank you for addressing comments! From my previous comment:
Can you please answer this? |
From feedback from PR pull/2758
Hi @minaguib, if you don't mind, in the future could you merge with master instead of force pushing? Force pushing makes it hard for us to review the delta. Thanks! |
Scott commented earlier:
@minaguib please address these too. I don't see it's added. Mentioned channelType in config/account.go will cover my question about DOOH channel type. Please include it in func Please confirm DOOH FPD support and BidRequestVideo will be updated in future PRs. |
dooh: | ||
mediaTypes: | ||
- banner | ||
- video |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not part of this PR but, is the maintainer email at the top of this file real?
1 maintainer:
2 email: "some-email@domain.com"
3 gvlVendorID: 42
~/newgo/src/github.com/prebid/prebid-server/config/test/bidder-info-valid/stroeerCore.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. This is a test file.
@@ -1823,6 +1845,30 @@ func validateDevice(device *openrtb2.Device) error { | |||
return nil | |||
} | |||
|
|||
func validateExactlyOneInventoryType(reqWrapper *openrtb_ext.RequestWrapper) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is well covered by integration tests, but can we add a TestValidateExactlyOneInventoryType
anyways?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guscarreon Pushed requested test below
Just a friendly ping to make sure you are still working on this PR. |
Confirmed with @minaguib recently on the approach and that it's on his radar to finish up the last few items. |
Hi @minaguib. Friendly ping to make sure you are still working on this PR. On to of review comments, merge conflicts also need to be resolved. |
@guscarreon @hhhjort confirming I'm back on this and will be wrapping up outstanding items shortly. |
This is currently a bit clinical as no fields are expected, however it now exists for consistency with the others (site and app) to accomodate any future dooh.ext attributes
Thank you for the updates!
|
I believe all significant points raised in this PR are now addressed. Re BidRequestVideo DOOH support - I'm not convinced this will ever be necessary. From early discussions with Scott, I feel we should bake and launch, and through adoption see if it makes sense to add DOOH support there or not at a later point |
Thank you for updating to keep up with recent changes, and sorry for the moving target. That being said, there is a request from @bretg to update |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the changes, LGTM
Implements #2532 with minor deviations from proposal:
requests_without_cookie
label to existing requests metrics keys: