You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Investigating the issue for mobile SDK, we faced incorrect behavior of SDK in the first place and with the inconsistency of PBS in the second.
SDK sends the size of device's display in the banner.format.[0]. It leads to issues for some demand partners who expect the actual size of demanded creative in banner.format.
So we are going to fix it and send an empty banner.format for interstitial ads. This fix won't change the current behavior and will give a better experience since publishers can set the needed formats in the stored request. It is impossible right now because of the hardcoded device size in the client request.
According to the docs #1, #2 we can do it. And if banner.format in the bid request is empty, the PBS should:
get the banner.format from the stored impression
if the banner.format is still empty - use the device size for banner.format.[0].
We think that documented behavior is totally correct.
Current Behavior
However, the implementation is different.
If banner.format is empty in the both - bid request and stored impression, the initial request fails here:
returnfmt.Errorf("request.imp[%d].banner has no sizes. Define \"w\" and \"h\", or include \"format\" elements.", impIndex)
Expected Behavior
If the banner.format is empty but imp.instl is 1 - don't fail the bid request. Let it pass further to this point where PBS will place the device.w and device.h into banner.format.[0] respectively to the docs.
Known Workaround
We know that if we set the minSizePercentage properties, the bid request will work as expected. However, we believe that it is not a proper way because::
The display size as a default requested size for interstitial ad looks inappropriate
Publishers unable to customize the ad sizes via stored requests, which can be critical for mobile integration.
Steeps to reproduce
An example of a bid request:
curl -H "Host: prebid.openx.net" -H "accept: */*" -H "content-type: application/json" -H "pbmispbmrequest: True" -H "user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 PrebidMobileRendering/1.3.0" -H "accept-language: en-us" --data-binary "{\"app\":{\"bundle\":\"org.prebid.mobile.renderingtestapp\",\"ext\":{\"prebid\":{\"data\":{},\"source\":\"prebid-mobile\",\"version\":\"1.3.0\"}},\"name\":\"PrebidMobileDemoRendering\",\"publisher\":{\"id\":\"0689a263-318d-448b-a3d4-b02e8a709d9d\"},\"ver\":\"1.3.0\"},\"device\":{\"connectiontype\":2,\"ext\":{\"atts\":0,\"ifv\":\"CE75FC3E-58F9-4492-9256-89FFD7C1C1BF\"},\"geo\":{},\"h\":896,\"ifa\":\"00000000-0000-0000-0000-000000000000\",\"language\":\"en\",\"lmt\":1,\"make\":\"Apple\",\"model\":\"iPhone\",\"os\":\"iOS\",\"osv\":\"14.5\",\"pxratio\":2,\"ua\":\"Mozilla\/5.0 (iPhone; CPU iPhone OS 14_5 like Mac OS X) AppleWebKit\/605.1.15 (KHTML, like Gecko) Mobile\/15E148 PrebidMobileRendering\/1.3.0\",\"w\":414},\"ext\":{\"prebid\":{\"cache\":{\"bids\":{},\"vastxml\":{}},\"data\":{\"bidders\":[]},\"storedrequest\":{\"id\":\"0689a263-318d-448b-a3d4-b02e8a709d9d\"},\"targeting\":{}}},\"id\":\"FF2C5C3E-8DA7-4DA4-8906-7BF5FF0A4C62\",\"imp\":[{\"banner\":{\"api\":[3,5,6,7],\"pos\":7},\"clickbrowser\":0,\"displaymanager\":\"prebid-mobile\",\"displaymanagerver\":\"1.3.0\",\"ext\":{\"context\":{\"data\":{}},\"prebid\":{\"storedrequest\":{\"id\":\"623d65df-db31-4636-9c58-afdeb59e8175\"}}},\"id\":\"6AF2BC6A-3A35-4879-B4FD-A36F08C08918\",\"instl\":1,\"secure\":1}],\"source\":{\"ext\":{\"omidpn\":\"Prebid\",\"omidpv\":\"5.0\"},\"tid\":\"48B32EDF-F971-4ED8-8C0A-F2D6A4E93D80\"},\"user\":{\"ext\":{\"data\":{}}}}" --compressed "https://prebid.openx.net/openrtb2/auction"
Looks like the bug is in endpoints/openrtb2/auction.go:validateBanner(). We have the check:
hasRootSize := banner.H != nil && banner.W != nil && *banner.H > 0 && *banner.W > 0
if !hasRootSize && len(banner.Format) == 0 {
return fmt.Errorf("request.imp[%d].banner has no sizes. Define \"w\" and \"h\", or include \"format\" elements.", impIndex)
}
We need to add a conditional that instl is not 1, which will require passing that value into the function, as it currently just gets the banner object. Should probably also ad a test to make sure the above case is handled properly, and that the bug is not reintroduced.
Background
Investigating the issue for mobile SDK, we faced incorrect behavior of SDK in the first place and with the inconsistency of PBS in the second.
SDK sends the size of device's display in the
banner.format.[0]
. It leads to issues for some demand partners who expect the actual size of demanded creative inbanner.format
.So we are going to fix it and send an empty
banner.format
for interstitial ads. This fix won't change the current behavior and will give a better experience since publishers can set the needed formats in the stored request. It is impossible right now because of the hardcoded device size in the client request.According to the docs #1, #2 we can do it. And if
banner.format
in the bid request is empty, the PBS should:banner.format
from the stored impressionbanner.format
is still empty - use the device size forbanner.format.[0]
.We think that documented behavior is totally correct.
Current Behavior
However, the implementation is different.
If
banner.format
is empty in the both - bid request and stored impression, the initial request fails here:prebid-server/endpoints/openrtb2/auction.go
Line 586 in aff5f70
Expected Behavior
If the
banner.format
is empty butimp.instl
is1
- don't fail the bid request. Let it pass further to this point where PBS will place thedevice.w
anddevice.h
into banner.format.[0] respectively to the docs.Known Workaround
We know that if we set the minSizePercentage properties, the bid request will work as expected. However, we believe that it is not a proper way because::
Steeps to reproduce
An example of a bid request:
The stored impression for this request:
The bid response
The text was updated successfully, but these errors were encountered: