For everyone saying this ruins impression tracking, couldn't an ad-network just act as a "CDN" (e.g. client Not that any server owner should do this (giving over control of your website ultimately to the ad-network? fuck that), but as ad-tech becomes more desperate, shouldn't these types of MITM setups get pushed more?
Websites using SSAI (server side ad injection)
21–30 of 75 posts
Re: Websites using SSAI (server side ad injection)
#22Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. Otherwise, obviously, the server could just maliciously record impressions/clicks. Then, logically, if uBlock Origin doesn't remove the ad, but does successfully remove the mediator's scr…
That's not what native ads are. They are about following the form and behavior of the surrounding content and can have all the same complex interaction and conversion tracking as any other ad.
Also video players with embedded ads have been around for years. The technology is already more advanced this and is just starting to roll out. Despite what you might think, there are plenty of checks against fraud and any publisher that does such blatant video fraud will get caught very quickly.
Re: Websites using SSAI (server side ad injection)
#23I get the distinct impression, in the war of ads vs. consumer, that some people will not be satisfied until they've submarined advertising all the way down to sponsored content and we have to go way out of our way to notice that the Try Guys are always drinking Coca-Cola or something.
There will always be those fringe people who insist on content being valueless even though they consume hours of it.
The greater problem is that the ad industry is too unregulated and greedy which has led to a tragedy of the commons with malware and poor UX everywhere, leading to adblockers installed by many who otherwise wouldn't mind.
Re: Websites using SSAI (server side ad injection)
#24For everyone saying this ruins impression tracking, couldn't an ad-network just act as a "CDN" (e.g. client Not that any server owner should do this (giving over control of your website ultimately to the ad-network? fuck that), but as ad-tech becomes more desperate, shouldn't these types of MITM setups get pushed more?
What if Cloudflare acting as a reverse proxy, that would really complicate things.
Re: Websites using SSAI (server side ad injection)
#25The ML algo of Adblock Radio could be used to bypass those video ads. The case of radio ads is a typical example of server-side ad injection.
https://www.adblockradio.com https://github.com/adblockradio/adblockradio
(Disclaimer: I built this)
Re: Websites using SSAI (server side ad injection)
#26Earlier quoted context omitted.
> Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. I don't suppose I understand why clientside JavaScript is needed here. The serverside code could simply generate a unique hash for every visitor, and include that in the campaign link.…
The server could track it based on the fact it delivered the content to the end user with the same unique hash present, no?
You mean like a tracking pixel? The issue here is that all requests to the ad domain can be blocked by the ad blocker.
Re: Websites using SSAI (server side ad injection)
#27Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. Otherwise, obviously, the server could just maliciously record impressions/clicks. Then, logically, if uBlock Origin doesn't remove the ad, but does successfully remove the mediator's scr…
> Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. I don't suppose I understand why clientside JavaScript is needed here. The serverside code could simply generate a unique hash for every visitor, and include that in the campaign link.…
A couple leads to answer you :
- Video advertising is not happy with only impressions and clicks metrics. In general, advertiser will want to know if their video played while in view from a human (or at least in view on a screen), and for how long it has played (or at the very least a rough estimate, like say how much midpoints).
- The concept of "impression" itself is often not very well defined, but counting it at "the server served a request with the video payload" is really a too optimistic view of things which leaves big holes exploitable by fraudsters. Having client side javascript playing at least requires additional software running, aka additional costs (if minimal) for fraudster.
- You can't really "just" monitor the user on the campaign landing page, since it's different sites involved, it involves different cookies, and actually reconciliating them is doable, but it'd require some work that the advertiser may not be willing or able to do.
Re: Websites using SSAI (server side ad injection)
#28Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. Otherwise, obviously, the server could just maliciously record impressions/clicks. Then, logically, if uBlock Origin doesn't remove the ad, but does successfully remove the mediator's scr…
> Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. I don't suppose I understand why clientside JavaScript is needed here. The serverside code could simply generate a unique hash for every visitor, and include that in the campaign link.…
Threat models:
* The ad server outright telling lies to get paid for nothing.
* The ad server not being trusted to validate that views are legitimate.
Client-side JavaScript can probe the DOM and execution environment for abnormalities indicative of automation.
Re: Websites using SSAI (server side ad injection)
#29Earlier quoted context omitted.
> Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. I don't suppose I understand why clientside JavaScript is needed here. The serverside code could simply generate a unique hash for every visitor, and include that in the campaign link.…
Threat models: * The ad server outright telling lies to get paid for nothing. * The ad server not being trusted to validate that views are legitimate. Client-side JavaScript can probe the DOM and execution environment for abnormalities indicative of automation.
But why can't a malicious server also serve up some JS that modifies the behaviour of the JS served by the ad network?
Re: Websites using SSAI (server side ad injection)
#30Before anyone thinks this is a Eureka anti-ad-blocking technology: Clearly you still need client-side javascript, distributed by the mediator, to ensure that the impression is actually delivered and the click is actually registered. Otherwise, obviously, the server could just maliciously record impressions/clicks. Then, logically, if uBlock Origin doesn't remove the ad, but does successfully remove the mediator's scr…
> We are going full circle--that is, back to the beginning--of ad technology. I guess they will end serving ads and "content" from the same site, but this site will be controlled directly by the advertisers, not by the publishers.
AMP