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
Copy file name to clipboardExpand all lines: dev-docs/publisher-api-reference/setConfig.md
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1153,10 +1153,11 @@ pbjs.setConfig({
1153
1153
1154
1154
### Client-side Caching of VAST XML
1155
1155
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
1157
1157
video player can retrieve them when it's ready. Players don't obtain the VAST XML from
1158
1158
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:
1160
1161
1161
1162
* Server-side caching:
1162
1163
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
1173
1174
| cache.timeout | no | number | Timeout (in milliseconds) for network requests to the cache |
1174
1175
| cache.vasttrack | no | boolean | Passes additional data to the url, used for additional event tracking data. Defaults to `false`. |
1175
1176
| 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`. |
1176
1178
| 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. |
1177
1179
| 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. |
1178
1180
@@ -1200,6 +1202,16 @@ pbjs.setConfig({
1200
1202
});
1201
1203
```
1202
1204
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
+
1203
1215
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:
0 commit comments