Skip to content
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

Improved support for interstitial ads #755

Closed
hhhjort opened this issue Nov 28, 2018 · 11 comments
Closed

Improved support for interstitial ads #755

hhhjort opened this issue Nov 28, 2018 · 11 comments
Labels
enhancement External API impact Tag for issues and PRs which affect the external API feature request needs docs Docs are required for this PR or Issue openrtb

Comments

@hhhjort
Copy link
Collaborator

hhhjort commented Nov 28, 2018

Typically interstitial ads are full screen ads. Typical screen sizes don't always map to common ad sizes. Currently the way around this is to include a list of acceptable dimensions in the format object. This is less than ideal as publishers will have to guess what sizes will be available with a high demand, and bidders may have to contend with a long list of sizes if publishers go with a shotgun approach in hitting a high demand size for their space.

A better solution would be to define a minwidth/minheight percent setting to pass on to bidders, which could then optimize their search for demand to cover the range of acceptable sizes rather than working off a list of sizes. This will save tuning the acceptable size list as interstitials become more common and device sizes proliferate, which will change the ad size landscape and optimal solutions over time.

@hhhjort
Copy link
Collaborator Author

hhhjort commented Nov 28, 2018

A couple of locations for these parameters would be bidrequest.device.ext.prebid.interstitial.minwidthperc/minheightperc or bidrequest.ext.prebid.minwidthperc. I suggest the device object so they can live in close proximity to the screen width/height they relate to.

It might also make sense to attach them under imp.ext.prebid since they are only relevant to interstitial impressions. However the minimum allowable percentage is unlikely to be a per imp setting, rather be consistent across a publisher or a site/app. Keeping it outside of the imp context makes config management a little simpler, as it will be associated with other publisher/site configs rather than the imp level configs.

@hhhjort hhhjort added enhancement feature request openrtb needs docs Docs are required for this PR or Issue labels Nov 28, 2018
@dbemiller
Copy link
Contributor

dbemiller commented Nov 28, 2018

+1 to request.device.ext...

Everything about this sounds great. Well-designed solution to a real problem.

@bretg
Copy link
Contributor

bretg commented Nov 30, 2018

Please help me connect the dots for how bidders + DSPs are supposed to utilize minwidthperc/minheightperc.

I see imp.instl in OpenRTB 2.5, but that's just a flag. From my reading of the standard, someone has to be responsible for actually defining sizes.

@hhhjort
Copy link
Collaborator Author

hhhjort commented Nov 30, 2018

The implementation is to say that any size between the min size and the screen size is a valid size for the auction. The savings on the bidder is that the validity check can simply be does the creative fall in the allowed range, rather than having a list of all possible sizes that fit in the range to be checked in turn. Saving on the publisher is that they don't need to revisit the list of allowed sizes as screen sizes and popular ad sizes changes change over time.

This may not always work out well for the bidders, depending on how entrenched the current logic for matching ad sizes is. But supporting ranges will likely be a good thing to support in the long run as I can see native taking advantage of size ranges for creative content.

@hhhjort
Copy link
Collaborator Author

hhhjort commented Dec 3, 2018

Open question: should a min-size-aware bidder base the size range off the first listed size in the imp format and minimum percentages, or always base off the screen size. My feeling is that we should use the first listed size if present, the screen size if no size format is provided. There may be a use case to tying the interstitial max size to something other than the native size, but also introduces more complexity into the size resolving logic.

@hhhjort hhhjort added the External API impact Tag for issues and PRs which affect the external API label Dec 3, 2018
@bretg
Copy link
Contributor

bretg commented Dec 3, 2018

Spoke with Hans about this. I'd like to see if we can fit the problem into where IAB is going with sizes.

See https://www.iab.com/wp-content/uploads/2017/08/IABNewAdPortfolio_FINAL_2017.pdf -- note that OpenRTB 2.5 supports the aspect ratio, but it's not until OpenRTB 3.0 that the 'small/med/large' feature is mentioned. It seems reasonable to add that to the ext field in 2.5, but seems unlikely an bidders would be looking for it.

@hhhjort
Copy link
Collaborator Author

hhhjort commented Dec 6, 2018

The main downside for flexads for interstitials is that interstitials scale off the screen size, which is a dynamic parameter and thus not really appropriate to hold in a stored request. So going forward with device.ext.prebid.interstitial.min(width|height)perc and adding support for PBS to resolve the requirements into a list of sizes to be sent to the adapters. We will still preserve the interstitial support signal so if bidders want to implement a better solution they can. A more complete spec will follow.

@hhhjort
Copy link
Collaborator Author

hhhjort commented Dec 6, 2018

Spec:
Additional support for interstitials will be enabled through the addition of two fields to the request:
device.ext.prebid.interstitial.minwidthperc and device.ext.interstial.minheightperc
The values will be numbers that indicate the minimum allowed size for the ad, as a percentage of the base side. For example, a width of 600 and "minwidthperc": 60 would allow ads with widths from 360 to 600 pixels inclusive.

PBS receiving a request for an interstitial imp and these parameters set, it will rewrite the format object within the interstitial imp. If the format array's first object is a size, PBS will take it as the max size for the interstitial. If that size is 1x1, it will look up the device's size and use that as the max size. Otherwise, it will also use the device size as the max size. (1x1 support so that you don't have to omit the format object to use the device size)
PBS with interstitial support will come preconfigured with a list of common ad sizes. Preferentially organized by weighing the larger and more common sizes first. But no guarantees to the ordering will be made. PBS will generate a new format list for the interstitial imp by traversing this list and picking the first N sizes that fall within the imp's max size and minimum percentage size. The value of N will be a server side configuration parameter. There will be no attempt to favor aspect ratios closer to the original size's aspect ratio. The limit of N is enforced to ensure we don't overload bidders with an overlong list. This is another reason that bidders may want to support the interstitial parameters natively, to open up all possible sizes if they can handle the overhead.

@hhhjort
Copy link
Collaborator Author

hhhjort commented Feb 7, 2019

This should now be working in the latest version. Will close the issue soon if nothing new happens.

@rtbdemand
Copy link

I am using prebid for inapp and I have following questions  which i couldnt find clarity1)When i use config id in simple way (part a) it always works but when i use expanded form part b) it many times fails and says invalid config id .part a)[ { "bidder": "appnexus", "params": { "placementId": 13144370 } } ]part b)below sometimes doesnt work{    "imp": [        {            "ext": {                "rubicon": {                    "accountId": 17054,                    "siteId": 193932,                    "zoneId": 945566                },                "appnexus": {                    "placementId": 16563659                }            },            "banner": {                "format": [                    {                        "h": 250,                        "w": 300                    }                ]            },            "id": "some-impression-id"        }    ],    "ext": {        "prebid": {            "bidadjustmentfactors": {                "rubicon": 0.7,                "appnexus": 0.9            },            "targeting": {                "pricegranularity": {                    "ranges": [                        {                            "max": 8,                            "increment": 0.01                        }                    ],                    "precision": 2                }            }        }    },    "tmax": 5000}2)I want to use Inapp for interstitial and did not find what is the best way to do soWhat config I should be using3)Is there any debug tool on Android to see how requests are going ReplyReply allForward   ReplyReply allForward    
  ReplyReply allForward
@stale
Copy link

stale bot commented Aug 8, 2019

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 stale bot added the stale label Aug 8, 2019
@hhhjort hhhjort removed the stale label Aug 8, 2019
@hhhjort hhhjort closed this as completed Aug 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement External API impact Tag for issues and PRs which affect the external API feature request needs docs Docs are required for this PR or Issue openrtb
4 participants