5 ms·

It'd also be a big risk in that it'd be easier to cheat the ads as they'd all come from the same connecting IP. I doubt advertisers would appreciate that much.

cgriswald 10y ago
Indeed, proxying is basically pointless. At that point, it would be better for the site and for the advertisers (and users who don't block ads) for the site to simply self-report. At least then they avoid the extra overhead and load times (which might, btw, be detectable by ad blockers). Alternatively, advertisers could host a server on the site's domain. A subdomain or specific path would be easily blocked, but a random path wouldn't be, e.g. http://www.example.com/626164776F6C66/ http://www.example.com/626164776F6C66/ with identifier generated randomly. Plenty of existing content already looks this way.
- corford 10y ago
  Yeah, this is how I envisage it. Publisher gets a docker image (or whatever) from the ad-network and hosts it internally on their network. Then you just need to map a random path from nginx/haproxy. Client IP can be passed through too.
  - ultramancool 10y ago
    I can't see that working out well, it'd just be way too easy to cheat, you could fake any IP you wanted, pretend to be connecting from the regular consumer ISPs and generate fake hits, fake clicks and otherwise easily steal from the ad network. This will never happen, it's a non-starter. They have enough problems with fake clickers already. There's no way to pass it using a reverse proxy, docker image, whatever, where the hosting website doesn't have ultimate control over the data they provide to the ad network. Basically if this happens I'm switching my career to stealing from ad networks for fun and profit.
    - corford 10y ago
      True it would be an issue for CPC/CPM campaigns but less so for CPA. Not sure what the solution would be for CPC/CPM - off the top of my head maybe a random CNAME that pointed to an ad-server controlled IP so they could cross-audit client IPs via a JS drop in file? Presumably ad-blockers would easily pick that up though.

cgriswald 10y ago

Indeed, proxying is basically pointless. At that point, it would be better for the site and for the advertisers (and users who don't block ads) for the site to simply self-report. At least then they avoid the extra overhead and load times (which might, btw, be detectable by ad blockers). Alternatively, advertisers could host a server on the site's domain. A subdomain or specific path would be easily blocked, but a random path wouldn't be, e.g. http://www.example.com/626164776F6C66/ http://www.example.com/626164776F6C66/ with identifier generated randomly. Plenty of existing content already looks this way.

corford 10y ago
Yeah, this is how I envisage it. Publisher gets a docker image (or whatever) from the ad-network and hosts it internally on their network. Then you just need to map a random path from nginx/haproxy. Client IP can be passed through too.
- ultramancool 10y ago
  I can't see that working out well, it'd just be way too easy to cheat, you could fake any IP you wanted, pretend to be connecting from the regular consumer ISPs and generate fake hits, fake clicks and otherwise easily steal from the ad network. This will never happen, it's a non-starter. They have enough problems with fake clickers already. There's no way to pass it using a reverse proxy, docker image, whatever, where the hosting website doesn't have ultimate control over the data they provide to the ad network. Basically if this happens I'm switching my career to stealing from ad networks for fun and profit.
  - corford 10y ago
    True it would be an issue for CPC/CPM campaigns but less so for CPA. Not sure what the solution would be for CPC/CPM - off the top of my head maybe a random CNAME that pointed to an ad-server controlled IP so they could cross-audit client IPs via a JS drop in file? Presumably ad-blockers would easily pick that up though.