Open dreamerdad opened 9 years ago
csinchok
commented
9 years ago 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
commented
9 years ago 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 notifications@github.com 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 https://github.com/theonion/videojs-vast-plugin/issues/56#issuecomment-62924333 .
Hugh Macken President
_VMR Communications LLC_Catholic Audience Network™, a division of VMR Phone: (715) 690-3033 Ext 700
csinchok
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago I've just been told that the Video.js player is not accepting the cookies that we are trying to set.
csinchok
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago He also told me "we are setting [cookie] with the set-cookie header."
csinchok
commented
9 years ago 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
commented
9 years ago 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
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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago The web developer of the site is embedded has confirmed that he is using https://github.com/dailymotion/vast-client-js https://github.com/videojs/videojs-contrib-ads https://github.com/theonion/videojs-vast-plugin
PidaPan
commented
9 years ago Perhaps #69 is part of this problem?
razor1907
commented
6 years ago Still a problem in 2018. Did anyone has a solution for this? @dreamerdad
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!