Hacker News new | past | comments | ask | show | jobs | submit login

Also unlikely because AMP supports many other trackers as well (https://www.ampproject.org/docs/reference/extended/amp-analy...).



The docs explain that "AMP analytics is specifically designed to measure once and report to many". Google's not trying to drive out other players, they're making sure they run the table.

This way they see every request, and learn a lot about their rivals.

Note also that the AMP ad spec warns that there are major changes to come.

https://www.ampproject.org/docs/reference/extended/amp-ad.ht...


My point elsewhere in this thread is that Google already knows all about their rivals. They're already seeing every HTTP request via Analytics, DoubleClick, Chrome, etc. They're already seeing which of their competitors are in use on which pages via the crawl. While I didn't know of any project to join & analyze this data while I was at Google (indeed, joining log sources required high-up approval because of the privacy implications), doing so would be technically trivial. They certainly don't need to launch a whole new product to get it.


I take your point.

I also believe the stated reasons for the project—to make the mobile web faster–are genuine. I believe that is the sincere motivation of many of the engineers working on it.

But the ultimate purpose of this project is to preserve the status quo around ads and tracking. Bloat has made the current situation on mobile devices untenable, and people are turning to blockers as a solution. AMP is a way to get rid of the bloat without getting rid of the surveillance. Google bets (correctly, in my opinion) that people won't care about being monitored if the performance problems go away.

Controlling the platform that does this will be useful to Google in the long run. For example, Google will be able to blacklist ad networks that don't meet their specifications. And Google can be sure theirs will always be the fastest game in town.


I think this is a completely unfair characterization of AMP.

AMP's speedup doesn't come purely from blocking tracker JS, AMP acts like a framework, like any other, to allow people to leverage best practices for fast rendering, managing all resource loading asynchronously, preventing relayouts during rendering, etc. Most frontend developers, especially at many small publishers, simply don't adhere to good HTML/CSS/JS practices.

If the future is a future where everyone runs blockers, then you get some of the benefits, you also likely break legitimate websites as we have already seen, and you make the blocker vendors themselves into surveillance platforms that sell analytics and extract profit from those who want to punch holes in the blocker. Who do you trust more, Google or AdBlock, Inc? But if the future instead, is that people don't even use Web browsers to read web sites, but used silo'ed Facebook or Apple readers, then how does that benefit anyone? Prior to AMP, the mobile web itself was facing a crisis of bloat.

AMP allows publishing to stay federated and work in browsers, delivering performance that makes it less likely people will leave the Web. I don't see how it's any different than say, Twitter Bootstrap in that regard. If this effort gets people to trim down their mobile pages in order to get better search ranking, by drawing attention to it, we may finally get some traction on an issue that's gone mostly under the radar.

It is in Google's best interest to ensure the open web continues to be viable, as Google Search won't even exist if there is no mobile web to index and everything is published on Facebook or iTunes. Google's overall goal over the years has been to increase web usage, as it's core service relies on it. I compare the Web to logging a forest. You need to keep planting trees and be a good caretaker, else the forest may die out. Many other good projects have been released purely for improvement purposes (e.g. Pagespeed Insights).


But regardless, Google still gets to track it because it goes through their CDN.


I have to imagine that it's more better accurate to get raw numbers at the transfer point rather than browser-reported ones. This also allows them to get stats for no-js browsers, too.




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

Search: