Skip to content
This repository has been archived by the owner on Feb 13, 2019. It is now read-only.

Frequency Capping Not Working #56

Open
dreamerdad opened this issue Nov 13, 2014 · 19 comments
Open

Frequency Capping Not Working #56

dreamerdad opened this issue Nov 13, 2014 · 19 comments

Comments

@dreamerdad
Copy link

I am using a third-party video ad server as my video ad server. Frequency capping is not working. For example, when I set a frequency cap of 3 impressions per hour, that cap is ignored. If I refresh and play the video 30 times, the video ad will display 30 times instead of only 3. The ad serving engineer tells me that the reason for this problem is that the ad serving request is coming from this plugin and not from the browser. Note: I have tested the ad code using an OVA VAST inspector and frequency capping works just fine. Can someone tell me how to correct this problem?
Thanks!

@csinchok
Copy link
Contributor

Hi, how exactly is the frequency capping working from your server? Is it cookie based?

I'm confused by the statement "the ad serving request is coming from this plugin and not from the browser".

@dreamerdad
Copy link
Author

Chris - Thanks for your reply! My understanding is that the answer to your
question is yes, the frequency capping is cookie based. Is that
non-standard / atypical?

On Thu, Nov 13, 2014 at 10:49 AM, Chris Sinchok [email protected]
wrote:

Hi, how exactly is the frequency capping working from your server? Is it
cookie based?

I'm confused by the statement "the ad serving request is coming from this
plugin and not from the browser".


Reply to this email directly or view it on GitHub
#56 (comment)
.

Hugh Macken
President

VMR Communications LLC__Catholic Audience Network™, a division of VMR
Phone: (715) 690-3033 Ext 700

@csinchok
Copy link
Contributor

Not really, I was just curious. The question is if the server is expecting the player to take some action based on a cookie, and if so, what?

We use a custom VAST server currently, and we just have the server respond with a 204 whenever we don't want to serve an ad, so none of that functionality is in the player.

@dreamerdad
Copy link
Author

Chris - Let's say there is a frequency cap of 3 impressions per hour. Are you able to configure your video ad server to respond with a 204 if the frequency cap has been met to ensure, in this case, that the visitor does not see the ad for a 4th time? If so, are you able to do this without the use of cookies?

@dreamerdad
Copy link
Author

I've just been told that the Video.js player is not accepting the cookies that we are trying to set.

@csinchok
Copy link
Contributor

That seems odd. How are you "trying to set" the cookies? Are you sending something in the VAST file, and expecting that to set a cookie? Are you trying to run some Javascript?

@dreamerdad
Copy link
Author

Here is a quote from the ad serving engineer:
"As you can see http://prntscr.com/57ny3y we are sending cookies to the browser, however they are not set - seems like the player does not accept the cookies and, thus, the frequency capping does not work."

Are you suggesting that it is odd that the video ad serving is using cookies to accomplish this? If so, how does a video ad server typically acommplish this - frequency capping?

@dreamerdad
Copy link
Author

He also told me "we are setting [cookie] with the set-cookie header."

@csinchok
Copy link
Contributor

So, the player doesn't have anything to do with setting cookies. That's all just the browser.

However, I notice that in your screenshot, there are two Set-Cookie headers. I think that in the HTTP spec, there can only be one such header. If there are two, only the first one is used (in many browsers). Could that possibly be your issue?

@dreamerdad
Copy link
Author

Here is the response from the ad serving engineer:

"I think that in the HTTP spec, there can only be one such header.

No, its not: https://www.ietf.org/rfc/rfc2109.txt

http://prntscr.com/57wt9z

You may also put the vast tag to your browsers address bar and press enter, then refresh the page and you'll get empty tag - meaning that the cookies were set and the capping works."

@dreamerdad
Copy link
Author

Chris - I did test this tag
http://adxpro.net/vast.xml?key=3f3ae2d4d4618f18aa6510661b0d76d7
here:
http://epom.com/vast-inspector

And the frequency capping is working just fine when testing using this vast inspector.

This inspect appears to be using the OVA plugin where the player on the website where the frequency capping is not working does not use the OVA plugin. Perhaps that is the reason it is working?

What is different about the OVA plugin that allows the cookies to be set properly whereas they do not seem to be setting properly when using the video.js VAST plugin???

@dreamerdad
Copy link
Author

According to the video ad serving engineer:

The player needs to set the frequency capping cookies in the browser after the player receives the VAST response from the video ad server.

The player is not setting the cookies in the browser even though the VAST response from the video ad server includes a command to the player to set the cookies in the browser.

@dreamerdad
Copy link
Author

Also, from the ad serving engineer:

Me: "can you clarify how the cookies are showing in the browser response headers even though [the website where the player is embedded] is not setting the cookies in the browser? I guess I am confused over the meaning of "setting the cookies" in the browser. Evidently, being in the header response (as here http://prntscr.com/57ny3y) does NOT mean the cookies are "set" in the browser. Is that correct?"

Answer: "Yes, that's correct"

Me: "If so, how can we verify through dev tools whether the cookies are "set"?"

Answer: "No we can't - dev tools only show the headers sent by the server."

@csinchok
Copy link
Contributor

Hey, so here's the thing:

This particular repo doesn't actually do the VAST ad fetching—that happens in https://github.com/dailymotion/vast-client-js.

From what I can tell of that code, [https://github.com/dailymotion/vast-client-js/blob/master/src/urlhandlers/xmlhttprequest.coffee#L3](it's doing a simple XMLHttpRequest), which as far as I can tell, should handle cookies just fine.

Even if I could figure out what's going on with your issue, we couldn't fix it in this repo.

@dreamerdad
Copy link
Author

I'm not sure whether the site with the video players uses that dailymotion repo. I don't think they do. Can you tell from the source code of the site?
Also, if you think you can resolve this, would you be open to being compensated in exchange for resolving this or at least helping me to resolve it? I'm still not really sure what the problem is (is it the vast plugis being used on the site, something about how the plugin is implemented on the site, etc...) so if you could help me to definitively ascertain the problem, that would be helpful.

@dreamerdad
Copy link
Author

I've just asked the web developer of the site where the player is embedded to let me know if he is using
https://github.com/dailymotion/vast-client-js and
https://github.com/videojs/videojs-contrib-ads
Hopefully that will shed some light on this.
I'd like to determine whether the problem is the implementation of the plugin on the site or the plugin itself. I am guessing the problem is the implementation of the plugin on the site.
To that end, can I give you a VAST tag to test in a demo player to see if the frequency capping is working in your demo player? If so, here is the VAST tag:
http://adxpro.net/vast.xml?key=3f3ae2d4d4618f18aa6510661b0d76d7
The sample ad is for Orphan Sunday and the frequency cap is set for 3 impressions per hour.

@dreamerdad
Copy link
Author

@PidaPan
Copy link

PidaPan commented Mar 19, 2015

Perhaps #69 is part of this problem?

@razor1907
Copy link

razor1907 commented Mar 22, 2018

Still a problem in 2018.
Did anyone has a solution for this? @dreamerdad

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants