An open governance model for the AMP Project

Over the last 2 years AMP has grown from a tiny open source project with just 2 contributors to a much larger one with over 700 folks contributing over 10,000 commits running on many millions of websites. When choosing a governance model (a system that describes how decisions are made) for AMP,  we initially focused on agility. AMP has always been powered by the voices and feedback of the developers and organizations that use it; however, governance was centered around the tech lead (which is me, the author of this post 🤣), who ultimately decided what got executed and how.

While this works great for smaller projects, we’ve found that it doesn’t scale to the size of the AMP Project today. Instead we want to move to a model that explicitly gives a voice to all constituents of the community, including those who cannot contribute code themselves, such as end-users. The change we are proposing is based on months of research, through which we’ve decided to follow the lead of the Node.js project and move to a consensus-seeking governance model.

amp-contributions
AMP received contributions from 710 contributors overall, 22% from Google employees, 78% from other companies such as Twitter, Pinterest, Yahoo, and eBay. In the last 30 days alone over 350 contributions landed in AMP!

When creating this proposal for a new governance model for AMP the AMP team had a few goals in mind, including:

  • Encourage a wider variety of voices at all levels of contribution, including code contributions, setting the future direction of AMP and deciding which features and bug fixes should be worked on.  This also means ensuring that the voices of those who do not contribute with code, but are nonetheless impacted by AMP, get heard.
  • Make it more clear how an individual and a company can have a voice in AMP, from approving code changes to setting AMP’s technical and product roadmap.
  • Avoid slowing down day-to-day work on AMP due to the governance model.  The net effect of changes to the way people work on AMP should be neutral to positive in terms of productivity.
  • Learn from what’s worked and what hasn’t worked for other open source projects.  To this end the AMP team talked to people from projects such as Node.js and Kubernetes, looked at governance philosophies from places like the JS Foundation and reviewed a wide variety of other open source and web standards governance documents.

The proposal has full details but some of the significant changes proposed in the new model are:

  • The power to make significant decisions in the AMP Project will move from a single Tech Lead to a Technical Steering Committee (TSC) which includes representatives from companies that have committed resources to building AMP, with the end goal of not having any company sit on more than a third of the seats.
  • An Advisory Committee with representation from many of AMP’s constituencies will advise the TSC.
  • Working Groups with ownership over certain aspects of AMP (such as the UI, infrastructure and documentation) will replace the informal teams that exist today.  These Working Groups will have a clear mechanism for input and a well-defined decision making process.

One of our first tasks in working towards the new system is to complete the initial membership of AMP’s governance groups. If you are interested in being involved in any of these governance groups please let us know. This is real work, and we want to pay for it if it isn’t covered by your day job! If you need financial support, please let us know in the form. One area that we are particularly interested in is representation from folks with experience in consumer rights and protection. Meanwhile we’re excited to announce that we’ve talked to a few folks up front and they agreed to join the Advisory Committee including representatives from publishers (El PaĂ­s, Washington Post and Terra), e-commerce sites (AliExpress and eBay) and platforms (Cloudflare and Automattic) as well as advocates for an open web (LĂ©onie Watson of The Paciello Group, Nicole Sullivan of Google/Chrome, and Terence Eden).

Additionally, we’re exploring moving AMP to a foundation in the future, and we’ll seek the input of the TSC, the AC, and the community over the coming months. We see the governance changes as a first step in that direction.

We’re looking forward to working with the rest of the AMP community to refine the governance proposal, including at next week’s AMP Contributor Summit.  We encourage you to review and comment on the proposal and attend the design review that has been scheduled to discuss the proposal.  The review period for the proposal will end on October 25, 2018 with a goal of implementing the new governance model shortly thereafter.

We’re excited to see the AMP community take this next step, and hope you will join us in making the web a better place for users and developers alike.

Posted by Malte Ubl, Tech Lead for the AMP Project at Google

An open governance model for the AMP Project

Measuring user journeys across the AMP Cache and your website

“If you can’t measure it, you can’t manage it.” — Peter Drucker

As users demand better privacy controls, browser vendors have started responding with defaults that partition cookies. This means traditional approaches of relying on third-party cookies for measurement won’t work going forward.

AMP pages are often served from an AMP Cache and the ability to maintain a session by using a third-party cookie allows publishers to remember user settings and preferences even when users move between the AMP cache domain and the publisher’s domain.

AMP Linker

AMP Linker is a new feature in AMP that helps keep user session in sync. It works by decorating outgoing links from AMP cache with params such as AMP Client ID in a URL parameter. On the receiving side, your analytics provider consumes the parameter and writes it down as a first-party cookie.

The decorated link will look something like

https://destination.com/checkout?_foo=1*19eaxqc*bar*V2dj…eHZKYg

linker.png


Enable AMP Linker

AMP Linker works by including a config for your analytics provider. For instance, if you’re using Google Analytics you’d include something as follows:

<amp-analytics type=”googleanalytics”>
 <script type=”application/json”>
   {
     “linkers”: {
       ”enabled”: true
     }
   }
</script>
</amp-analytics>

If you already use the Google AMP Client ID API with Google Analytics, no additional tagging is required to take advantage of AMP Linker capability.

If you are an analytics provider, we welcome you to reach out to us to take advantage of AMP Linker.

Looking ahead

We’re hard at work to support non-traditional, yet important, user journeys where a user goes from non-AMP pages to AMP pages. Keep an eye out on our repo on Github for updates regarding those.

Happy measuring!

Posted by Jeff Jose, Product Manager, AMP Project at Google

Measuring user journeys across the AMP Cache and your website

Compare images on AMP pages with amp-image-slider

Earlier this month we announced the experimental release of <amp-image-slider>, an overlaid slider that allows you to compare 2 images that are superimposed on each other. We are now excited to fully launch this component in production.

amp-image-slider.gif


The benefits of using include:

  • An interoperable interaction model across all devices and platforms.
  • Built-in accessibility – like all of our components, we have designed the component with accessibility in mind. This means we have ensured the component is accessible to both keyboard navigation and screen readers.
  • Ability to customize the component to your site branding by modifying the hint arrows.
  • Ability to customize the interaction model of the component by setting the step size for keyboard navigation, adding labels on the images being compared, etc.

amp-image-slider (labels).gif


Check out the sample on
AMP by Example and the documentation to learn more, and please file any feedback you have as well!

Posted by Naina Raisinghani, AMP Engineer at Google

Compare images on AMP pages with amp-image-slider

Ensure Ad Density is equal on AMP & non-AMP pages

Editor’s note: The following was originally posted on Medium by Vamsee Jasti, AMP Product Manager at Google. This post is part of a larger AMP monetization series.

Avoid common pitfalls to ensure total area of ads is the same

Ad density doesn’t have to be as high as it is at Times Square

This is an easy optimization, but is important because it’s one of the most common mistakes and is easy to remedy.

A reasonable ad density strategy is to follow the guidance from the Coalition of Better Ads. It says that the total height of the ads on the page / total height of the content on the page should be < 30%. This is of course the worst case scenario and often publishers have percentages lower than this.

During my publisher interviews, three common misconceptions came up when inquiring why some didn’t have the same ad density on both AMP and non-AMP pages:

1. “I didn’t realize I needed to manage ad density”

When probing further, the AMP model was being confused with Facebook Instant Articles’ approach to ad density where there is an automated ad insertion offering. AMP doesn’t directly offer publishers a way to automatically manage ad density but it makes APIs available that allow auto-ad insertion to the 100+ ad networks natively integrated in AMP. Individual ad networks can choose to take advantage of those APIs, similar to howAdSense does. For most ad networks, including DoubleClick for Publishers (DFP), such auto placement is not available and publishers must manage ad density themselves.

2. “I thought there were restrictions on the number of ads I could place”

Turns out, they were mixing AMP up with FIA’s approach, where they have apolicy to replace manually placed ads if the ad density is greater than 20%. AMP has no such restrictions. AMP delegates the responsibility to the publisher and the individual ad network they choose in order to eliminate any AMP-specific idiosyncrasies related to ad density management.

3. “We didn’t optimize our AMP pages after the initial AMP launch 3 years ago”

A lot can change over 3 years and some publishers had undergone architectural changes but their engineering teams may have forgotten to include AMP pages in the re-architecture. It’s important to keep both sets of pages at parity not only to earn the same revenue from your AMP pages but also helps you understand how your AMP pages are performing.

A specific area to call out is to ensure parity on recirculation promotions that allow users to consume related content. Not having these on your AMP pages may have a negative impact on your bottom line because anecdotally these lead to 1.2 or 1.3 times session lengths. AMP supports various 3rd party recirculation providers too.

In summary, regardless of what strategy you use on your non-AMP pages, ensure you translate that strategy over to your AMP pages. There are no restrictions in AMP that would make a publisher have fewer ads on AMP pages than on non-AMP Pages.

Ensure Ad Density is equal on AMP & non-AMP pages

Are you leaving revenue on the table with AMP?

Editor’s note: The following was originally posted on Medium by Vamsee Jasti, AMP Product Manager at Google

I’m a product manager working on AMP and we strive to make advertising better on the web while helping publishers thrive. I’m writing this to give you some background on design choices we made for advertising in AMP and then follow up every week with specific optimization recommendations to help you take maximum advantage of AMP pages.

Make the most of your AMP page revenue by optimizing them

Bottom line first: If you are publishing AMP pages, please at least make sure they are monetizing well. It’s possible, if one invests in them.

When AMP launched, it was important for us to help publishers make revenue from your AMP pages just the way you did from your non-AMP because ads are still a big source of revenue for many publishers. After numerous interviews with publishers, I’ve seen some not take full advantage of their AMP pages and therefore leaving a lot of revenue on the table.

Issue

We worked with a number of publishers to get feedback around AMP monetization and used to hear that there were many ad features that needed support in AMP but that feedback volume has decreased after we launched a number of features over the last year. There is always more work to be done but since AMP’s launch, we’ve launched a number of features and closed almost all gaps now.

There are publishers out there who have not only reached revenue parity but exceeded revenue from their AMP pages compared to their non-AMP. For some publishers who receive close to 50% of their traffic to their AMP pages, this can be a million plus dollars per year!

Solution

If you are a publisher who is in the business of developing an audience (visitors who choose to come to your site often) and not traffic (visitors who visit based on one-off click baits or by purchasing traffic on platforms) you probably already consciously balance a tradeoff. The tradeoff between the user experience of the site to the revenue you generate from ads. To take an extreme example: one could easily show 3 successive pop-up ads before the article which would generate a lot of revenue but it would also either lead users to immediately leave the site or negatively associate the publisher brand in a way the visitor thinks twice before going to the site.

Principles behind advertising in AMP

When it comes to this tradeoff, with AMP, we took a balanced stance to prioritize user experience over anything else but re-imagined how ads could still earn very good revenue with features that are hard to implement on non-AMP pages for legacy reasons.

Here are a few of them:

1. Get ads out of the critical path of rendering the page

Unlike regular pages, AMP pages make the ad requests on the page as early as possible in the lifecycle of the ad. This allows us to parallelize rendering the page, while also letting the ad server run its auction to pick the best ad. Chances are, by the time the ad comes back, the page has already finished loading and therefore the ad can also immediately render which leads to ads having better viewability and click through rate. We’ve gathered data that shows that AMP performs really well on these measures. A win-win for both publishers and advertisers by simply orchestrating the ad request sequence. We call this “Fast Fetch” and you can read all about the improvements here. Following this change we have had great results with users seeing a lot fewer blank rectangles.

Fast Fetch vs Delayed Delayed Fetch Ad Requests

Contrast this to delayed fetch, where the ad request isn’t made until the browser encounters the ad tags, therefore delaying making the ad request and subsequent rendering.

2. Don’t allow user visible reflow but support multi-size ads

How often do you visit a site and start reading content and out of nowhere, an ad appears and pushes the content down, causing your thumb to do a micro-dance so you can continue reading as it loads? We think this experience is clearly bad for the user which is why AMP made an early tradeoff to ensure that doesn’t happen. Therefore, every ad must have a predetermined primary size, so AMP can reserve the space for the ad but continue to render content all around without ever reflowing content.

AMP reserves a primary ad size so there is never user visible reflow

But we know that multi-size ads lead to better monetization since it makes the ad auction demand pool larger. AMP introduced a way for publishers to define a primary size and also pass along secondary sizes which allowed resizing the ad to the returned size as long as the ad was below the viewport or was smaller than the primary size, if in the current viewport. Publisher feedback has shown that this was a healthy tradeoff giving publishers > 90% chance of serving the ad size that earns them the most revenue. I’ll go into more detail in a future post, but here is the launch blog post.

3. Prefer ad formats that users can easily dismiss or scroll past

Let’s admit it. A majority of users visit your site for content, not ads. So some design choices were made in AMP to never show an ad that would “cover” content. Which means no pop-ups (interstitials) that cover content. Interestingly, the industry as a whole is rejecting such ad formats. Instead we supported all ads within fixed layouts, including all Rich Media Ads.

AMP prefers ads that can be easily dismissed by users

In addition, AMP launched some native ad formats like sticky ads and flying carpet ads. We plan to support even more richer formats that publishers tell us they’re interested in while ensuring a great user experience. With any ad format, users should be able to tap the dedicated close button on the ad or could simply scrolling away.

OK, show me the money?

Don’t get me wrong, nothing is as easy as flipping a switch. You constantly optimize, try new things out, experiment and settle with an ad setup that gives you the most revenue while adhering to good UX principles.

But the good news is that such optimizations are fairly straight forward in AMP. Plus, you only need to do a handful of things to ensure that your AMP pages generate maximum revenue.

Over the next few weeks, I’ll dive into each of these topics:

  1. Ad Density
  2. Prefer Viewability over Views
  3. Multi-size ads & fluid
  4. Traffic your direct sold ads (formats & single request architecture)
  5. Header Bidding & AMP
  6. Video monetization using AMP IMA Video
  7. Auto Ad Refresh
  8. The future with AMPHTML ads
Make a change & earn the revenue from AMP

With AMP, we believe in providing you with flexibility in implementing where you source your ads from and what vendors to work with. You don’t lose a slice of your rev share just for using AMP. There are over 100 ad networks that are natively integrated with AMP pages and many more supported via header bidding (using AMP RTC) and server side exchanges.

The AMP team strongly believes in the open web and strive to help publishers build a sustainable business on it whether it be paywalls or advertising.

Stay tuned for more in the coming weeks and we look forward to your feedback on this series or anything else about AMP. In case you can’t wait to get started, check out the summary of monetization best practices and implement away!

Are you leaving revenue on the table with AMP?

WorkerDOM: Concurrency for JavaScript programming with the DOM

We are happy to announce the alpha release of WorkerDOM – a JavaScript library that makes the Document Object Model (DOM) available to Web Workers. This allows web developers to take advantage of pervasive multi-core processor architectures when programming their web pages to make them more performant. While the WorkerDOM library is designed for general web programming, we plan to use it in the AMP Project as well, which we will detail more below.

The underlying Web Worker API has been available to web developers for almost a decade, but it hasn’t seen widespread adoption. One of the reasons was that the primary API for manipulating web pages, the DOM, was not available inside of workers. WorkerDOM changes this, thereby enabling developers to more easily port their existing applications. We hope that this will spur renewed interest in multi-threaded programming on the web, and lead to much better experiences for users down the road.

Our research has shown that single-core CPU performance for low-cost devices has not significantly increased over the last years. As a result, from a single-core point of view, mobile devices have gotten cheaper but not faster. There is significant opportunity to take advantage of the extra cores that even the least expensive CPUs provide that aren’t available to JavaScript programming by default. To make web performance truly competitive with that of native platforms, we should try to unlock this extra bit of performance to provide better and more modern experiences across the whole range of devices people use.

Screen Shot 2018-08-21 at 10.45.37 AM
Not all mobile devices are created equal.

WorkerDOM aims to provide a full representation of the DOM inside of Web Workers. In the ideal case this means that scripts can be used unchanged inside of the worker environment. At the heart of the library is an efficient transport mechanism written in TypeScript. It hydrates server rendered DOM and then proxies mutations as an application makes changes to the page, such as reacting to user actions or running animations. For more details about the inner workings of the WorkerDOM library and possible use cases, please check out the slides from our presentation at JSConf US 2018.

As announced at the AMP Conf 2018, the AMP Project is working on a long-term effort to make JavaScript programming available to AMP page authors. The WorkerDOM library is central to this initiative and we’re excited to incorporate it into AMP later this year. WorkerDOM is compatible with frameworks such as React, Preact, and Svelte — and more are on the roadmap. We’re super excited to see all of these frameworks used in creating AMP pages in the future!

Today’s release is an alpha release. WorkerDOM is ready for experimentation but not yet ready for widespread production use. We’d love to collaborate with framework and tool authors to ensure compatibility and great developer experience when using WorkerDOM in as many places and contexts as possible!

Kristofer Baxter, Software Engineer at Google

WorkerDOM: Concurrency for JavaScript programming with the DOM

AddThis is Now Available for AMP

Editor’s note: the following was originally posted on AddThis’ blog by Chad Edmonds, Sr. Marketing Manager, AddThis

AddThis AMP Share Buttons

Just because AddThis is now free, doesn’t mean we’re slowing down on pushing out more great features and functionalities! We recently rolled out AddThis Inline Share Buttons for AMP and it is ready for you to integrate into your AMP compatible site.

A bit of background: AMP project (spearheaded by Google and others) is a new open source initiative that stands for Accelerated Mobile Pages and is meant to improve the mobile web browsing experience by speeding up ensuring web pages are fast and smooth loading. There are also a few other advantages to setting your website pages up for AMP, like additional traffic from platforms that link out to AMP websites like Google and Twitter. Learn more about creating your AMP page here.

We’re excited to be joining the initiative to improve the content ecosystem and we believe users should still have the same functionality on AMP that they have on other platforms. That is why we’re one of the first third-party plugins to be available as an AMP component.

Ready to get started? Visit our Academy article or YouTube video to learn how to install AddThis Inline Share Buttons on your AMP site!

In the coming months, we will be rolling out more AMP capabilities as well as more robust support documentation. In the meantime, if you have any questions or feedback about the plugin, please do not hesitate to reach out to our support team.

Posted by Chad Edmonds, Sr. Marketing Manager, AddThis

AddThis is Now Available for AMP