Personally, I really don't want to productize HB. I think it goes in the direct opposite direction of all our user experience efforts, and we need to double down on Jedi++ to make sure there's no business model that works in HB but not in our server-side solution. I also want to see us do the testing to establish how much HB hurts consumer metrics like latency, data usage, and battery; and advertiser metrics like viewability, CTR, brand lift, etc. We don't want anybody's HB to get an actual First Look ahead of everything else, because that puts GDN and DBM (and the AdX buyers) at risk. That is the concern about FAN or Amazon investing in HB — they could persuade publishers to say something like 'if we can pay you $10+, don't even bother checking with Google, just give it to us right away.' That makes HB the new yield manager. There will eventually be a limit on how many header calls a pub can send out without killing user experience. I still think the limit will be zero, but for sake of argument assume it's more like 3-5. That will push things toward server-to-server, but that could mean one HB company builds a more open Jedi than ours — more like Chris's 'Sith' product, where it's open season with no rules. Protecting reservations — yes, as long as we're the system of record for guarantees and guarantees are the most important part of publisher revenues, we will remain a must-call and HB has a limited ability to avoid calling DFP.