Skip to content

Commit 41cf23f

Browse files
mkomorskiMarcin Komorski
andauthored
add allowVastXmlOnly (prebid#6491)
Co-authored-by: Marcin Komorski <marcinkomorski@marcins-mbp.home>
1 parent f059dec commit 41cf23f

1 file changed

Lines changed: 14 additions & 2 deletions

File tree

dev-docs/publisher-api-reference/setConfig.md

Lines changed: 14 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1153,10 +1153,11 @@ pbjs.setConfig({
11531153

11541154
### Client-side Caching of VAST XML
11551155

1156-
When serving video ads, VAST XML creatives must be cached so the
1156+
When serving video ads, VAST XML creatives are commonly cached so the
11571157
video player can retrieve them when it's ready. Players don't obtain the VAST XML from
11581158
the JavaScript DOM in Prebid.js, but rather expect to be given a URL where it can
1159-
be retrieved. There are three different flows possible with Prebid.js around VAST XML caching:
1159+
be retrieved. If your player can render VAST XML directly, you can set `cache.allowVastXmlOnly`
1160+
to bypass the cache requirement. There are different flows possible with Prebid.js around VAST XML handling:
11601161

11611162
* Server-side caching:
11621163
Some video bidders (e.g. Rubicon Project) always cache the VAST XML on their servers as part of the bid. They provide a 'videoCacheKey', which is used in conjunction with the VAST URL in the ad server to retrieve the correct VAST XML when needed. In this case, Prebid.js has nothing else to do. As of Prebid.js 4.28, a publisher may specify the `ignoreBidderCacheKey` flag to re-cache these bids somewhere else using a VAST wrapper.
@@ -1173,6 +1174,7 @@ be retrieved. There are three different flows possible with Prebid.js around VAS
11731174
| cache.timeout | no | number | Timeout (in milliseconds) for network requests to the cache |
11741175
| cache.vasttrack | no | boolean | Passes additional data to the url, used for additional event tracking data. Defaults to `false`. |
11751176
| cache.ignoreBidderCacheKey | no | boolean | If the bidder supplied their own cache key, setting this value to true adds a VAST wrapper around that URL, stores it in the cache defined by the `url` parameter, and replaces the original video cache key with the new one. This can dramatically simplify ad server setup because it means all VAST creatives reside behind a single URL. The tradeoff: this approach requires the video player to unwrap one extra level of VAST. Defaults to `false`. |
1177+
| cache.allowVastXmlOnly | no | boolean | When `true`, allows rendering VAST XML without requiring use of a cache. Useful for players that can consume VAST XML directly. Defaults to `false`. |
11761178
| cache.batchSize | no | number | Enables video cache requests to be batched by a specified amount (defaults to 1) instead of making a single request per each video. |
11771179
| cache.batchTimeout | no | number | Used in conjunction with `batchSize`, `batchTimeout` specifies how long to wait in milliseconds before sending a batch video cache request based on the value for `batchSize` (if present). A batch request will be made whether the `batchSize` amount was reached or the `batchTimeout` timer runs out. `batchTimeout` defaults to 0. |
11781180

@@ -1200,6 +1202,16 @@ pbjs.setConfig({
12001202
});
12011203
```
12021204

1205+
If your player can render raw VAST XML and you do not want to require caching, you can set:
1206+
1207+
```javascript
1208+
pbjs.setConfig({
1209+
cache: {
1210+
allowVastXmlOnly: true
1211+
}
1212+
});
1213+
```
1214+
12031215
As of Prebid.js 2.36, you can track client-side cached VAST XML. This functionality is useful for publishers who want to allow their analytics provider to measure video impressions. The prerequisite to using this feature is the availability of a Prebid Server that supports:
12041216

12051217
* the /vtrack endpoint

0 commit comments

Comments
 (0)