Frequency capping with raw HTTP/VAST ads

[John Kelvie]

Our system calls DFP directly and programmatically via HTTP. We use these calls to serve VAST ads to mobile devices. We chose not to use the IMA SDK because we work with app developers ourselves (we provide our own SDK), and we did not want to burden them with bringing in another SDK in addition to ours.

Everything works well, though we have run into one issue - frequency caps do not seem to work.

We call DFP using a URL that looks like this:

https://pubads.g.doubleclick.net/gampad/ads?gdfp_req=1&sz=400x300&url=http://xappmedia.com&env=vp&output=xml_vast2&iu=<AD_UNIT>&correlator=<TIMESTAMP>&impl=s&unviewed_position_start=1

The values for ad unit and timestamp are both substituted for appropriate values.

It all generally works well - we receive well-structured VAST payloads for our line items.

The one issue we have run into, though, is that frequency caps do not seem to work. And the issue is not that they do NOT take effect (i.e., serving ads all the time), but instead they seem to prevent any ads from being served at all. 

We've read the documentation on calling HTTP VAST directly that is here:

https://support.google.com/dfp_premium/answer/1068325?hl=en

And specifically these notes:

*If you aren't using the Google IMA SDK: When you generate tags in the DFP UI, be aware that the tag generator inserts the url and correlator parameters as macros, for which you'll need to insert the appropriate information. (If you're using the Google IMA SDK, the SDK automatically inserts the information for these macros.)

And:

A random number, typically the timestamp of the page view, that's shared by multiple requests coming from the same page view. If you're not using the Google IMA SDK, see note below.* Correlator is used to implement competitive exclusions, including in cookieless environments.

 

At the same time, if we take the exact same URL that we use to call DFP programmatically and just put into a browser, it works correctly. We receive ads in reply, and according to the constraints set by any frequency caps.

Based on the fact that the calls work in a browser and not programmatically, as well as the notes cited above, we believe the issue is the absence of cookies in our programmatic call.

So our question is:

1) Is our understanding of everything stated above correct?

2) Is there any remedy for this? 

We are contemplating creating a programmatic cookie but we are not quite sure how to do it and it also seems a bit hacky (as our programmatic client is meant to be stateless).

Any guidance and/or insight is much appreciated.

-John

[Vu Chau (IMA SDK Team)]

John,

Thanks for reaching out.

This forum is only for support of IMA SDK implementations, so I'd recommend you to contact your DFP account manager.  They will be able to assist you more effectively.

Vu Chau

IMA SDK Team

[John Kelvie]

Is there any group where I can post these items?

I've asked questions like this in the DFP APIs section and been told to post them here. 

We can always reach out to DFP support, but it seems a shame there is no public group related to this aspect of DFP.

-John

--
You received this message because you are subscribed to a topic in the Google Groups "Interactive Media Ads SDK" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ima-sdk/urwxPgmvqPU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ima-sdk+u...@googlegroups.com.
To post to this group, send email to ima...@googlegroups.com.
Visit this group at http://groups.google.com/group/ima-sdk.
For more options, visit https://groups.google.com/d/optout.

[Vu Chau (IMA SDK Team)]

Hi John,

We don't have a public group for DFP in the general sense - for this we recommend reaching out to DFP support.

Vu Chau

IMA SDK Team

[Scott Paradis]

We ran into this is as well recently. Posting an update in case others run into this.

Presuming you are calling DFP from a browser using javascript and AJAX, you need to set the `withCredentials` flag of the of the XMLHttpRequest. This allows the google cookies which are used for frequency capping to be transmitted to and from DFP cross-origin. It's those google cookies that dictate how frequency capping works with DFP. This approach works for all modern browsers that support CORS and IE10+.

See: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials

[Felix]

Hei there.

Just wanted to come back to this thread and say THANK YOU, as it helped me to finally get the Frequency capping and other functionality working based on the last comment.
Eventhough it is already several years old...

Best,

Felix 

[IMA SDK]

Hi Felix,

Please don't hesitate to reach out for any IMA SDK related concerns. We're happy to assist.

Regards,

IMA SDK Team

ref:_00D1U1174p._5004Q2kqURZ:ref