Your Digital Media Has Never Looked So Good

 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 9:30 am

We're seeing an issue where the ad pods returned from RAF.getAds() do not match the VMAP in the ad URL provided to RAF via setAdUrl().

Background: we're using using SSAI in a RSG app.

Details:
When we look at the VMAP for the ad URL, we see, for example, two midrolls, with timeOffets:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<vmap:VMAP xmlns:vmap="http://www.iab.net/videosuite/vmap version="1.0.1">
    <vmap:AdBreak timeOffset="00:05:35.368" breakType="linear" breakId="1">
        <vmap:AdSource>
            <vmap:VASTAdData>
                <VAST version="3.0">
                    <Ad id="19585946" sequence="1">
                        <InLine>
                            <AdSystem>FreeWheel</AdSystem>
...
   </vmap:AdBreak>
    <vmap:AdBreak timeOffset="00:11:00.994" breakType="linear" breakId="2">
        <vmap:AdSource>
            <vmap:VASTAdData>
                <VAST version="3.0">
                    <Ad id="19585946" sequence="1">
                        <InLine>
                            <AdSystem>FreeWheel</AdSystem>
...



However the ad pods returned from RAF.getAds() shows (generally) only one preroll. 
e.g.
<Component: roAssociativeArray> =
{
    ads: <Component: roArray>
    backfilled: true
    duration: 30
    rendersequence: "preroll"
    rendertime: 0
    slots: 0
    tracking: <Component: roArray>
    viewed: false
}

Note that sometimes the returned ad pods contains both ads, with the correct render times.

This is an outline of our workflow, running in a player task node:
adInterface.setAdUrl(adURL)

adPods = adInterface.getAds()

adInterface.stitchedAdsInit(adPods)

...
while keepPlaying
  videoMsg = wait(500, port)
  curAd = adInterface.stitchedAdHandledEvent(videoMsg, { sgNode: videoNode, port: port })
  ...
end while


This is a problem for us since the RAF's ad handling (e.g. "Ad 1 of 1") and player control blocking will occur at the wrong time.

Ideas?
 
tim_beynart
Posts: 141
Joined: Wed Jul 15, 2015 8:30 am

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 10:21 am

how are you providing a Freewheel URL when using SSAI? The results from 2 different ad requests can differ, right?
 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 10:30 am

Adobe Auditude is generating the ad URL for us -- this is what's provided to RAF via setAdUrl().
Auditude service is also stitching in the ads (correctly) into a new stream, which we're playing.

We are examining different ad requests (some that RAF correctly determines the ad pods from, and some that it doesn't) to try and spot the differences. But so far we haven't found any clues -- the VMAPs appear valid for both.
 
User avatar
RokuNB
Posts: 254
Joined: Fri Mar 31, 2017 2:22 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 10:34 am

acreskey wrote:
This is a problem for us since the RAF's ad handling (e.g. "Ad 1 of 1") and player control blocking will occur at the wrong time.

Have you accounted for this detail - that for SSAI, stitchedAdsInit() expects time offsets from the stream start and not the break start?
stitchedAdsInit() wrote:
... In particular, for server-stitched ads, all time-dependent tracking beacons (Impression and quartile beacons) must have a valid time data member set, with a value relative to the entire stitched stream. For example, if a 30-second ad starts at 10:00 within the stitched stream, its Impression beacons should have track.time = 600.0 and its Midpoint beacons should have track.time = 615.0, and so on. ...

Also, where do you get the VMAP from? If it's from source before the stitching server, consider that the stitching process introduces some delays/extra frames, so the break pauses would diverge from VMAP from a separate ad server.
 
tim_beynart
Posts: 141
Joined: Wed Jul 15, 2015 8:30 am

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 11:13 am

acreskey wrote:
Adobe Auditude is generating the ad URL for us -- this is what's provided to RAF via setAdUrl().
Auditude service is also stitching in the ads (correctly) into a new stream, which we're playing.

I get that, but the problem is that Adobe makes one FW request for their backend system, and you make another from the device. You could hit a situation where ad inventory is available for Adobe's request, then exhausted when the device makes the same request.
In our implementation of Adobe SSAI, we are provided with the VMAP response that Adobe gets from Freewheel and provide the data to RAF using stitchedAdsInit(). We never call setAdUrl() with SSAI.
 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 11:20 am

RokuNB wrote:
acreskey wrote:
This is a problem for us since the RAF's ad handling (e.g. "Ad 1 of 1") and player control blocking will occur at the wrong time.

Have you accounted for this detail - that for SSAI, stitchedAdsInit() expects time offsets from the stream start and not the break start?
stitchedAdsInit() wrote:
... In particular, for server-stitched ads, all time-dependent tracking beacons (Impression and quartile beacons) must have a valid time data member set, with a value relative to the entire stitched stream. For example, if a 30-second ad starts at 10:00 within the stitched stream, its Impression beacons should have track.time = 600.0 and its Midpoint beacons should have track.time = 615.0, and so on. ...


Also, where do you get the VMAP from? If it's from source before the stitching server, consider that the stitching process introduces some delays/extra frames, so the break pauses would diverge from VMAP from a separate ad server.


Thank you for the quick reply RokuNB.

Although I'm new to VMAP and VAST, it does appear that the time-dependent tracking beacons in the VMAP do have their time set relative to the entire stitched stream.
At least if RAF uses the 'tpos' field.
For example, here we have the AdBreak at 5:35, and I'm seeing <Impressions> and <Tracking> events with tpos=335 

    <vmap:AdBreak timeOffset="00:05:35.368" breakType="linear" breakId="1">
        <vmap:AdSource>
            <vmap:VASTAdData>
                <VAST version="3.0">
                    <Ad id="19585946" sequence="1">
                        <InLine>
                            <AdSystem>FreeWheel</AdSystem>
                            <AdTitle>....</AdTitle>
                            <Impression>http://bea4.v.fwmrm.net/ad/l/1?s=d001&amp;n=48804%3B48804%3B381963&amp;t=1499795079091200015&amp;f=&amp;r=48804&amp;adid=19585946&amp;reid=7250158&amp;arid=0&amp;auid=&amp;cn=defaultImpression&amp;et=i&amp;_cc=19585946,7250158,,,1499795079,1&amp;tpos=335&amp;iw=&amp;uxnw=&amp;uxss=&amp;uxct=&amp;metr=1031&amp;init=1&amp;vcid2=48804%3Af2c022b54b07596779cc00c4a7e26e49&amp;asid=-1&amp;ssid=1954993&amp;cr=https%3A//servedby.flashtalking.com/imp/8/78463%3B2547733%3B201%3Bpixel%3BTurner%3BTurnerConnectedTV301x1/%3Fcachebuster%3D700020434</Impression>
                            <Impression>http://ad.auditude.com/adserver/e?type=adimp&amp;a=342240&amp;w=17&amp;uid=0gCR6cUlSMWpsa74nrYlXQ&amp;s=2b595733&amp;t=1499795079&amp;u=ac217921a4a853e52310ebc459eef367&amp;z=131829&amp;cid=324172756&amp;br=1&amp;pod=id:1,ctype:l,ptype:p,dur:200,lot:1,cpos:1&amp;ax=0,0,0,0&amp;sq=1</Impression>
                            <Creatives>
                                <Creative AdID="19585946">
                                    <Linear>
                                        <Duration>00:00:30.030</Duration>
                                        <TrackingEvents>
                                            <Tracking event="creativeView">http://ad.auditude.com/adserver/i/;uid=0gCR6cUlSMWpsa74nrYlXQ;s=2b595733;t=1499795079;u=ac217921a4a853e52310ebc459eef367;z=131829;cid=324172756;br=1;pod=id:1,ctype:l,ptype:p,dur:200,lot:1,cpos:1;ax=0,0,0,0;sq=1;a1=105;a=342240;w=17/c0x0</Tracking>
                                            <Tracking event="start">http://ad.auditude.com/adserver/e?type=AD_PROGRESS&amp;a=342240&amp;a1=105&amp;ref=urn:asset:342240:105&amp;unit=percent&amp;progress=0&amp;uid=0gCR6cUlSMWpsa74nrYlXQ&amp;s=2b595733&amp;t=1499795079&amp;u=ac217921a4a853e52310ebc459eef367&amp;z=131829&amp;cid=324172756&amp;br=1&amp;pod=id:1,ctype:l,ptype:p,dur:200,lot:1,cpos:1&amp;ax=0,0,0,0&amp;sq=1</Tracking>
                                            <Tracking event="firstQuartile">http://bea4.v.fwmrm.net/ad/l/1?s=d001&amp;n=48804%3B48804%3B381963&amp;t=1499795079091200015&amp;f=&amp;r=48804&amp;adid=19585946&amp;reid=7250158&amp;arid=0&amp;auid=&amp;cn=firstQuartile&amp;et=i&amp;_cc=&amp;tpos=335&amp;init=1&amp;iw=&amp;uxnw=&amp;uxss=&amp;uxct=&amp;metr=1031</Tracking>
                                            <Tracking event="firstQuartile">http://ad.auditude.com/adserver/e?type=AD_PROGRESS&amp;a=342240&amp;a1=105&amp;ref=urn:asset:342240:105&amp;unit=percent&amp;progress=25&amp;uid=0gCR6cUlSMWpsa74nrYlXQ&amp;s=2b595733&amp;t=1499795079&amp;u=ac217921a4a853e52310ebc459eef367&amp;z=131829&amp;cid=324172756&amp;br=1&amp;pod=id:1,ctype:l,ptype:p,dur:200,lot:1,cpos:1&amp;ax=0,0,0,0&amp;sq=1</Tracking>
                                            <Tracking event="midpoint">http://bea4.v.fwmrm.net/ad/l/1?s=d001&amp;n=48804%3B48804%3B381963&amp;t=1499795079091200015&amp;f=&amp;r=48804&amp;adid=19585946&amp;reid=7250158&amp;arid=0&amp;auid=&amp;cn=midPoint&amp;et=i&amp;_cc=&amp;tpos=335&amp;init=1&amp;iw=&amp;uxnw=&amp;uxss=&amp;uxct=&amp;metr=1031</Tracking>
                                            <Tracking event="midpoint">http://ad.auditude.com/adserver/e?type=AD_PROGRESS&amp;a=342240&amp;a1=105&amp;ref=urn:asset:342240:105&amp;unit=percent&amp;progress=50&amp;uid=0gCR6cUlSMWpsa74nrYlXQ&amp;s=2b595733&amp;t=1499795079&amp;u=ac217921a4a853e52310ebc459eef367&amp;z=131829&amp;cid=324172756&amp;br=1&amp;pod=id:1,ctype:l,ptype:p,dur:200,lot:1,cpos:1&amp;ax=0,0,0,0&amp;sq=1</Tracking>
                                            


The VMAP is returned from the Auditude stitching server, so we are expecting it to be account for the extra frames. But the issue we're seeing is not that the Ad UI is rendered at a different time, it's that while we see two ad breaks in the VMAP, only one ad pod is generally found, and it's always rendered as a pre-roll.
 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 11:24 am

tim_beynart wrote:
acreskey wrote:
Adobe Auditude is generating the ad URL for us -- this is what's provided to RAF via setAdUrl().
Auditude service is also stitching in the ads (correctly) into a new stream, which we're playing.

I get that, but the problem is that Adobe makes one FW request for their backend system, and you make another from the device. You could hit a situation where ad inventory is available for Adobe's request, then exhausted when the device makes the same request.
In our implementation of Adobe SSAI, we are provided with the VMAP response that Adobe gets from Freewheel and provide the data to RAF using stitchedAdsInit(). We never call setAdUrl() with SSAI.

I see what you mean, Tim  - thanks for the reply.
So you're generating your own ad pod array from the original VMAP and feeding it directly into RAF.
That goes against our implementation guideline, so I'm hoping to avoid that.
 
tim_beynart
Posts: 141
Joined: Wed Jul 15, 2015 8:30 am

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 11:28 am

Actually we never see the original VMAP response, we get an Adobe-defined JSON file with all the ad break information and beacons. This is part of the Adobe SSAI API we use. 

But frankly I don't see how you will ever have accurate ad data if you are making 2 requests to Freewheel, so hopefully I am misunderstanding your problem.
 
tim_beynart
Posts: 141
Joined: Wed Jul 15, 2015 8:30 am

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 11:31 am

acreskey wrote:
That goes against our implementation guideline, so I'm hoping to avoid that.

I'm curious what guidelines you refer to. I've been using Adobe SSAI on Roku for over 2 years and your approach doesn't sound familiar.  We worked closely with them to implement SSAI.
 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 11:51 am

tim_beynart wrote:
Actually we never see the original VMAP response, we get an Adobe-defined JSON file with all the ad break information and beacons. This is part of the Adobe SSAI API we use. 

But frankly I don't see how you will ever have accurate ad data if you are making 2 requests to Freewheel, so hopefully I am misunderstanding your problem.

We're not making 2 requests to Freewheel -- one request to Auditude gives us the stitched ad stream, and a second (based on the first) supplies us with the VMAP (presumably the one that was used to stitch in the ads).
But our organization's guidance is to provide this VMAP to RAF to parse into ad pods. (Which I believe RAF should handle, according to the docs).
 
tim_beynart
Posts: 141
Joined: Wed Jul 15, 2015 8:30 am

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 12:04 pm

OK that makes sense. Our implementation is similar, but we do not get the raw VMAP XML from Adobe, we get a JSON translation. Which we then translate into the RAF-friendly ad pods format.
 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 1:52 pm

I did notice this log output from RAF when the ad pods are not returned:
RAF 2.0108; empty response: 

Roku_Ads_util_getStringFromUrl: requesting URL: http://pubads.g.doubleclick.net/gampad/ads?slotname=/82114269/rrafcs/bf/dev&sz=1920x1080&tfcd=0&url=http://roku.com&unviewed_position_start=1&output=vast&impl=s&env=vp&gdfp_req=1&ad_rule=0&description_url=http%3A%2F%2Fapps.roku.com&vad_type=linear&nofb=0&sdkv=roku&min_ad_duration=0&max_ad_duration=60000&rdid=971ccf63-9e60-53c3-b2ad-5403bb5f299a&is_lat=0&idtype=rida&correlator=1499806025110&scor=1499806025110&pod=POD_NUM&ppos=POD_POSITION&cust_params=genre%3DROKU_ADS_CONTENT_GENRE%26ua%3DRoku%252FDVP-7.70%2520%2528047.70E04093A%2529%26ai%3Ddev


Although I do actually get a response when I manually request that URL.
 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 2:33 pm

It looks like it's timing... if I call adPods = adInterface.getAds() after a small time delay, the correct ad pods are found.
Interesting!
 
User avatar
RokuNB
Posts: 254
Joined: Fri Mar 31, 2017 2:22 pm

Re: RAF not correctly determining ad pods from VMAP

Tue Jul 11, 2017 7:20 pm

acreskey wrote:
The VMAP is returned from the Auditude stitching server, so we are expecting it to be account for the extra frames. But the issue we're seeing is not that the Ad UI is rendered at a different time, it's that while we see two ad breaks in the VMAP, only one ad pod is generally found, and it's always rendered as a pre-roll.

That is a really strange thing if happening - mid-roll with a properly set offset (e.g. <vmap:AdBreak timeOffset="00:05:35.368" ...>) somehow turning into a pre-roll. I'd like to know more on this if indeed is happening. (Like capture the VMAP that does that - and btw for test purposes you can do raf.setAdUrl() to a local file, say in tmp:/ or pkg:/ - then you can print formatJson(raf.getAds()) )
 
acreskey
Topic Author
Posts: 14
Joined: Wed Nov 30, 2016 6:06 pm

Re: RAF not correctly determining ad pods from VMAP

Wed Jul 12, 2017 7:39 am

Thank you RokuNB for the debugging technique.

So what was happening was that Auditude provided me with a URL for the VMAP that wasn't actually ready. If I requested that VMAP immediately (i.e. the next line of code), it would most often fail.
So basically I was providing RAF with an invalid ad URL.

Because the default RAF ad prefs are set to backfill ads,  RAF was making its own ad request against the Roku default ad service (hence the "preroll" ad pod).

So I've disabled the backfill of ads and I have to poll the VMAP URL until it's valid.

Thanks for the help.

TL;DR: RAF did not actually have any issues in determining ad pods from a valid VMAP. If you provide an invalid URL the default behaviour is to backfill with Roku ad service ads.

Who is online

Users browsing this forum: No registered users and 5 guests