Hacker News new | past | comments | ask | show | jobs | submit login
HTTPS Results in 7% Google AdX Revenue Drop (rome2rio.com)
187 points by thomasfromcdnjs on May 30, 2016 | hide | past | favorite | 65 comments



I saw an instant 30% drop in revenue when switching my site to HTTPS in April. The implementation was done right, A+ rating from ssllabs, Google reindexed my main pages as HTTPS within a matter of hours, search traffic and overall traffic remained unchanged.

I poked around on my AdSense account to see where I was losing the revenue, since AdSense was still displaying the same number of impressions. It turned out I was seeing a 75% drop in CPC impressions, and AdSense was running low paying CPM impressions instead.

http://i.imgur.com/acy2k0u.png

That's a graph of daily CPC impressions on my account. It's obvious when I switched to HTTPS. That was over a month and a half ago. It hasn't bounced back.

I'm faced with a difficult decision now; whether to go back to HTTP and inform the community we're going to a less secure system for increased ad revenues, or I need to accept a 30% drop in my yearly income, and hope the situation improves as more networks switch to HTTPS.


>whether to go back to HTTP

If you do this, be careful of the HSTS header. You'll want to remove this from responses for a while before you flip everyone back to HTTP because their browsers will refuse to send HTTP requests during the specified period or until the next time they clear their browsing data.

If you don't have a lot of returning visitors, it matters less, but still something to be aware of.


Removing the HSTS header won't help, as your browser will store this data, and IIRC it's not stored in cache, so clearing won't help.

You can however send the HSTS header with max-age=0 which will start clearing it for existing users


Good tip about max-age=0! I didn't realize you could do that.


Thanks for the reminder, I know I'll need to keep this in mind if I make the switch back. I'm fairly certain I'll stay with HTTPS though, since the situation will only improve. It also helps to encourage the ad networks to make the change, and encourages other developers to use HTTPS on their projects as well.


I've seen the same, when my 2 from 3 sites went HTTPS-only page rank was dropped, from top3 to second page on Google Search, basically eliminating me from the market. In May I did a lot of changes to the sites and it's getting better, but the lie about https improving site rank was destroying.


I don't know a thing about AdSense, but I'm curious as to why the numbers depicted in the graph, while lower, shows a lot less random-looking fluctuations after the switch?


Can't you support both?


change the network.

google is big but not the only one.


Oh, trust me, I've tried all the major networks, along with every network dedicated to my niche, but they were all far worse, in both earnings and ad quality. There's a reason almost everyone is using AdSense when they're not selling ads direct.


there is a significant gap in typical earnings between adsense and a highly optimized display service.

the only way to bridge that gap really is expertise or consulting, typical website owners will have neither unless they are very large (think alexa top 1000).


How does this work (economically)? Based on this subthread: https://news.ycombinator.com/item?id=11804689 it seems that the mechanism is:

HTTPS site can't load resources over HTTP (due to security) -> only those advertisers who support HTTPS can place bids for HTTPS-only sites (and not all do) -> the smaller number of bids results in lower ad revenue

However, as also noted there, the advertisers who do support HTTPS should preferentially bid for impressions on HTTPS-only sites, since the price per view (or per click etc), is lower. Importantly, they should continue doing this (raising the price of adverts on HTTPS-only pages, due to the increased demand), until the price per click etc. is the same for HTTPS-only and "normal" sites. Why does this not happen?

i) The simple model above is overly simplistic, and I don't actually understand the situation,

ii) The marginal costs of serving HTTPS ads and HTTP ads are not the same (though why would that be — the server overhead for HTTPS is marginal) or the the revenue from HTTPS vs. HTTP ads is lower (but again, why?),

iii) The time-frame is too short(?),

iv) Advertisers are turning down free money (highly unlikely).


> Importantly, they should continue doing this (raising the price of adverts on HTTPS-only pages, due to the increased demand), until the price per click etc. is the same for HTTPS-only and "normal" sites. Why does this not happen?

> iv) Advertisers are turning down free money (highly unlikely).

One explanation: You are modeling advertisers' behavior similar to a control system having integral gain and/or bandwidth higher than the timeframe of the disturbance (HTTPS adoption rate). In practice, it may be that the market's optimization is using only proportional gain and/or lower bandwidth. Such a system merely reduces the impact of differing market sizes for HTTPS support, without eliminating it, or perhaps takes more time to eliminate it.


Isn't it simply a question of competition? If some advertisers can't support HTTPS, that means there are fewer bidders for HTTPS content. That should result in a lower price.

They are also bidding on what's presumably a shrinking pie of HTTP ad space. If the volume available to buy has dropped considerably, that may also be driving up the price of HTTP ad views.


Yes. But this very effect should drive https adoption for the advertisers. The grandparent comment was exactly wondering why this doesn't seem to be happening (enough).


I think this is b/c almost all ad tags are loaded via HTTP.

The browser won't hand over the refer(r)er information from HTTPS to HTTP!

This lack of information causes a lower valuation of the inventory b/c the third-party ad networks (which are determined via AdX by an auction) don't know what they are bidding for.

I'm not exactly sure about the precise causation but I think this is the reason for that drop.


If this is true, then advertisers have a temporary incentive to support HTTPS: it is currently relatively cheaper for them until more advertisers also support HTTPS.


can someone explain why ad networks seem to be lagging behind modern web best practices? For example, terrible flash ads, ads that break the site they're displayed on, lack of HTTPS, malware, etc? And also why a company with a better engineering team hasn't been able to successfully take advantage of these weaknesses and corner the market?


Having worked at a large and (within the industry) well known ad agency I think you're vastly overestimating the amount of knowledge the people making those decisions at ad agencies have regarding things like web best practices and security. For larger household name brands the ones doing the purchasing of ad space online are almost exclusively ad agencies. Even if the agency doesn't make the ad unit and the accompanying creative, they're still likely the ones negotiating the price and making sure everything gets trafficked on time. The level of client involvement varies, but it usually hovers between "none" and "too small to measure".

Frankly, the people in the agency world making the kinds of decisions about which ad network to use are not the most tech savvy people. They're typically two or three layers removed from anyone who actually understands the difference between HTTP and HTTPS. Until that changes (hint: not for another 20-30 years when the current crop of middle aged account executives is retired or dead) then ad networks won't receive any major pushback from the people who are their largest most reliable customers.

Even if every person in the agency world understood the harm of poorly made ad units tomorrow it would still take ages for any changes to occur because of existing relationships and contracts.


I agree and disagree to some extent. I think there is one piece though that could speed up the process. If Google, and other ad networks, put their foot down and said either ads are served via both HTTP and HTTPS (or just via HTTPS) or we will discontinue serving them, this would put pressure on the agencies to speed up change. In the current state though, like you said there is no incentive to change.


The venn diagram of people caring about web best practices and people running adblockers is a circle, so there's no reason for ad networks to change anything.


That's ridiculous, I'm sure there is overlap, but not that much. I am sitting near many people that care about web best practices but have never run an adblocker. And I know many people that run adblockers and don't give 2 cents about web best practices. Besides it would be very easy to get the ad networks to change, it's call money.


> The venn diagram of people caring about web best practices and people running adblockers is a circle, so there's no reason for ad networks to change anything.

More likely concentric circles.


I would not be surprised if sites running https have lower conversion rates per click.


Why? I can't see any way the protocol used to deliver the content would determine the amount of end users who click a link.


Sites targeting tech-savvy users are more likely to use HTTPS because they know their users will notice it, tech-savvy users are more likely to use ad blockers. More of a correlation than a causation. At least, I assume that's the theory. Seems like the effect would be small at this point though.


HTTPS requires 2 extra round trips, if your servers aren't close to the users, or the users are on a high latency connection anyway, https adds a real delay. HTTP/2 multiplexing and push /may/ help get some of that back, but I don't know if there's anything that does HTTP/2 push well in a non-custom server way yet?


If you configure your server to use TLS resumption and False Start there should only be one extra roundtrip, which can make a significant difference.

https://istlsfastyet.com


Apart for the other reasons provided by others, there is also the issue that sites using https are more likely to have savvier users and so may be less likely to purchase after clicking on a link. An advertiser is charged per click, but their return is the conversion rate on those clicks to sales.


To be fair, this ignores the thousands of software engineers in ad tech.


Having worked in ad tech, I didn't know anybody who wasn't running an adblocker in their primary browser.


I heard that Google had to rename some CSS names on their ad management portal (that understandably had names that began with "ad") to unbreak it when Google customers using adblockers were trying to manage their own ad accounts.


Whose bread is buttered by dark patterns.


Most of those engineers don't care much for privacy so I don't think they are to concerned with https.


It mostly comes down to poor engineering talent, different priorities and leadership that isn't interested in UX. Until recently, adblock, privacy, security and many of the performance trends were just not a big deal. Why fix what's broken when they can double the ads on the page instead?

* I've worked in adtech for years and now currently run my own company where we do this right.


> can someone explain why ad networks seem to be lagging behind modern web best practices?

Sites that use the ad networks to manage their advertising inventory are probably not going to go with a network that provides a better end-user experience, if it means the network doesn't have enough ads to fill the inventory or they're lower CPM -- if they have a significant interest in quality end-user experience, they're likely going to manage their inventory themselves.

> For example, terrible flash ads, ads that break the site they're displayed on, lack of HTTPS, malware

Advertisers love flash ads, love ads that takeover the whole damn site, don't care about HTTPS, and would like to have every page view counted with about 70 different beacon services -- that's going to be way slower if you have to negotiate a different tls session for each. Advertisers serving malware would like to serve it, clearly. An ad network needs advertisers, so there you go.

Also, an ad network needs to make sure they can show an ad everytime one is requested, so they'll backfill with other ad networks if they have to -- hard to maintain quality in that case. (Although personally, when I was involved in a website making money with ads, I was a lot happier with not showing an ad (and just moving the rest of the content up) when there was no quality ad available -- unseemly ads make my page feel unseemly; not all sites have the luxury to make that decision though)


Re: beacons, why hasn't someone created a service that beacons to all the beacons on a single call to the server?


There are no big incentives. Their large customers largely don't care or understand these issues. The few tech sites bugging them about https support aren't a critical mass.


>can someone explain why ad networks seem to be lagging behind modern web best practices? For example, terrible flash ads, ads that break the site they're displayed on, lack of HTTPS, malware, etc?

All of these seem like things that while bad, will make them more money. Not like things they don't have the know-how to move over from...


HTTPS also increases the page load time, and there's plenty research that shows the relationship between latency and CTRs.

I'd like to add a shameless plug by noting that I'm working on a project that renders performance and security much of a false dichotomy within native iOS applications. We hope to incentivize the capitalists in the room to secure their applications by coincidence of making them faster. Caffeine: http://www.caffei.net/


Maybe a significant percentage of ad clicks are fraudulent and "more sophisticated" technologies like https break malicious traffic? I couldn't come up with alternative plausible explanation.

I believe this situation also shows weird dynamics with fighting adfraud. In general too much fraud can crash ad click economy, but on micro scale a lot of actors indirectly benefit from it so they don't have incentive to fight with it strongly. Especially if most automated way of fighting bots will also affect legitimate traffic (e.g. captcha for real users).

I would say real world analogy is oil prices and OPEC. Or more classical analogy is prisoner's dilemma. Individual actor incentives are different than best solution for the whole ecosystem.


I don't think fraud is a driving cause here.

The real cause is downgrade protection. When your browser loads an HTTPS page, it will refuse to load (or at least warn when loading) any other resources over HTTP: js, css, iframes, etc.

This is to ensure that the icon you see in your URL bar is actually accurate: if a page loads over HTTPS, but consists entirely of a single HTTP iframe, that nice green lock is totally meaningless.

So when the OP switched their site to HTTPS-only, they lost the ability to ever display any from HTTP-only bidders. So the set of people bidding on their ad slots went down, the price went down, and their revenue went down.


That is an excellent and counterintuitive but logically sound market-response explanation for the behavior.

I'm trying to think of how Google can attempt remedying this, with the more obvious options being to either increase the non-HTTPS search penalty, or perhaps to buy up some of the ad stock itself.


This is the cause.


I read a while back that something like for every $3 in ad revenue, $1 of that was fraud.

Maybe https is just breaking some fraud bots?


I'm convinced that on what I spend, the fraction is way more than 1/3; I think it might be north of 2/3. The clicks on and off the page are just way too quick and consistently so for it to be a human. That said, I'm not sure that's what's happening here.


Au least on mobile, often I will accidentally hit an ad, and immediately back out as soon as possible


Yes- mobile is a disaster. I can't imagine anybody profitably advertising on mobile. I've asked this group before and basically nobody has ever deliberately clicked a mobile ad (one guy said he did once, iirc). I have a hunch that the people making money off of these ads know this, too. It might be good for branding, but in that case you should only consider CPM-- CPC is your enemy here.

As I gear up for an advertising campaign, I'm looking pretty closely at channels.


Has the same thing happened for ad revenue using Admob in iOS apps since Apple made https communication the default? I have noticed a drop in revenue, but I assumed it was just seasonal, maybe there is a technical reason. Cheers.


This has influenced me on my prediction for (http://www.metaculus.com/questions/164/).


Could some ad partners be holding out because http is getting them lower CPC for their customers or am I misunderstanding something?


Wait, I don't get it.

The blog post explains what's happening but not the why. How could HTTPS possibly lower ad revenue? What is the mechanism?


> We learnt that not all advertisers that place bids through the Google ads system support HTTPS, resulting in fewer ad impression bids and lower overall ad revenue.


I'm sorry, but can you walk me there? I know very little about how Google ads work.

If I buy an ad from Google, I supply my own URL, which can be http or https, and if my site is https it can't display the http ad?


No, its that sites served over HTTPS won't show HTTP-only ads. Google determines who gets the view based on a auction system. Limiting supply of ads limits competitive bidding.


So Google does not serve the ads from its own servers? Google just runs the programmatic auction and then lets the winning advertiser point to whatever slow, non-HTTPS ad server they like? I guess once Google gets paid by the auction winner, they don't care what happens next with the served ad. And serving it from their own servers would just be an extra cost.


No, they don't actually serve all ads. I imagine they know not to pass off a request from a HTTPS page to a HTTP-only server (mixed-content blocking would give a near-100% failure rate) but here is an example of Google's Doubleclick network being used to spread malware: https://blog.malwarebytes.org/threat-analysis/2014/09/google...


I think it can do both. Kind of like how Amazon sells products that ship both from its own warehouses, but also from the vendors directly. But just like with Amazon, there's probably an increasing amount of ads that come directly from the vendors.


This is what surprised me, I assumed Google ran all ads through their own servers.


Doesn't this translate into cheaper clicks for the savvy advertisers bidding HTTPS (only)?


It does sound like it. If the publisher is getting paid less for the same number of clicks that means an advertiser is paying less for those clicks.

It would be interesting to see this broken down from the advertiser side.


Browsers do not allow content that is delivered over HTTP to be loaded in sites that use HTTPS. If your site wants to display an ad, Google figures out who is willing to pay the most for the spot and includes content from that ad buyer in your site. If your site uses HTTPS, Google can only choose between ad buyers that provide their ads over HTTPS, since those using HTTP wouldn't be displayed.


Shouldn't the ads be served from the ad networks servers, rather than directly from the advertiser?


Why not offer both, HTTP (default) and HTTPS. Many websites work like that just fine.


Is there a way to get around this through a proxy endpoint on your server?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: