What is RTC? How does this help you implement header bidding? And, can you use a wrapper? Let’s dive in to find the answers.
Why implementing header bidding on AMP differs?
As the usage of content on hand-held apparatus has been skyrocket, optimizing for speed has become a priority for the open web. Publishers, irrespective of traffic volume, experimented with many frameworks and approaches to double/triple the page load speed on mobile. With the rising demand, Google finally launched’AMP’. Accelerated Mobile Pages (AMP), in its essence, is about changing the way publishers designing webpages for mobile internet.
While it’s good to have a common, widely-accepted frame to design faster pages, publishers are facing a new set of issues — audience monitoring, measurement, and above all, monetization. As you are here, we assume you understand that monetizing AMP pages is not a straightforward procedure. Why?
Well, AMP eliminates third-party JS tags in the pages and instead, uses its own library documents.
So, can not we monetize AMP pages in any respect? Needless to say, we can. But less you monetize regular (non-AMP) pages. In this post, we will clear all the queries (comments are always available for more) and allow you to setup header bidding for AMP pages.
Actual Time Config (RTC)
AMP wouldn’t be embraced by nearly all the open web if there is no way to efficiently monetize the page views. After all, publishers would not want to exchange their mobile ad revenue for incremental pageviews eased by Google.
Soon, AMP Created Actual Time Config, shortened as’RTC’ to measure up AMP monetization. RTC is an easy way to call 5 unique vendors to request bids over the period of a second. It enables publishers to link to 5 distinct header bidding partners to market their AMP pages. That having been said, RTC has its limitations — which makes it a second option.
Limitation of RTC
It is possible to use RTC, in its highest capacity, to send bid petition to only 5 demand partners. Usually, publishers would experiment with over seven bidder partners to find the perfect setup and ensure the greatest possible CPMs. In actuality, a Prebid research proves that page loading time for ten bids vs five bids does not differ as much as we believe. Moreover, user sync can be done for only one of the five need partners as AMP allows only one non-visible iframe.
Since RTC call outs are limited, you can use a maximum of five sellers and that includes viewability seller, DMP, audience monitoring vendor, etc.. Thus, you can not send bid petition to five demand spouses, should you will need to use DMP or a viewability vendor.
Usability and Reporting:
To be precise, we’re pushed back to an era — in which a wrapper or container does not exist. You require a programmer to add or eliminate demand partners into your AMP pages, raising the odds of errors. Further, there will be no dashboard or some other reporting that you analyze and optimize.
According to AMP Job GitHub directory, just the next demand partners can be predicted via RTC execution: AppNexus, APS, Criteo, IndexExchange, Lotame, Media.net, PubMatic OpenWrap, Purch, Rubicon, Salesforce, and Yieldbot.
Header Bidding on AMP — Via Wrapper
Yes, you may use a header bidding wrapper to market AMP pages. A wrapper can help you overcome all of the limitation of RTC. From connecting to multiple need partners to manageability to reporting, you can do everything via a wrapper interface and dashboards.
Apparently, the wrapper should encourage AMP and use server-side bidding to conduct auctions seamlessly. Many prebid-based wrappers take advantage of prebid server to execute s2s auctions.
So, how header bidding wrapper works with RTC?
You may specify the AMP advertisement element and send one call to the wrapper’s server (as an example, prebid server) using RTC. Here’s an example:
The server then conducts the auctions (server-side header bidding) and yields the key-value targeting into the AMP runtime*.
*AMP runtime is a part of JS loaded in the mind of every AMP webpage to offer the implementation for custom AMP components (such as AMP ad components ), handle and prioritize resource loading.
The best part is, as a writer, you do not need to take care of any of the dev. And implementation work involved with putting together a header bidding wrapper. Needless to say, if you have your own wrapper and an in-house staff, it is on your head. Most handled header bidding suppliers will look after the setup and execution for you.
Now, what about ad server (Herewe refer to the writer’s primary ad server. For Example, Google Ad Manager) installation? It is basically the same.
By the time, you must have heard about’fast fetch’. Quick fetch is an AMP feature introduced in the mid-2017 to render advertisements quicker to the users. Fast fetch separates advertisement requests from the remainder of the content and in reality, makes them earlier in the lifecycle of the page, rather than traditional ad requests where advertisement request and rendering are done in exactly the exact same time.
In any case, fast fetch will just render advertisements once the advertisements are likely to be seen by the consumer. If you’re knowledgeable about header bidding wrapper, you can connect this to asynchronous requests and lazy loading.
RTC is one of the qualities of fast fetch.
Header Bidding Wrapper Vs RTC
Like everyone, you’ll be confused with which one to go with — header bidding wrapper or RTC. Contrary to client-side and server-side header bidding, here the advantages of wrapper clearly precede over that of RTC.
RTC can be considered for a small publisher who would love to only get bids from a couple of demand partners. If you want coverage, easy manageability, and extreme competition, header bidding wrapper is the one to opt-in.
Video advertisements on AMP Pages
It isn’t straightforward to run video ads on AMP pages. The extensions were published last year and thus it (movie monetization) is very much in the growing stage. AMP has specific extensions that will assist you run equally in-stream and outstream video advertisements.
Instream video advertisements can be implemented via
— AMP Components:
A publisher can use expansion to define where to source the advertisements and where to source the video content with various attributes. It has all of the basic features including auto-play, docking on scroll, and analytics.
— Using players incorporated with AMP:
Some of those video players on the industry service AMP and run in-stream advertisements on AMP pages.
Outstream video advertisements can be left using the element. You may check this postto find out more on video ads.
If you are new to AMP monetization and wish to know the best route, opt-in for header bidding wrapper. As we mentioned previously RTC would not help you to see anticipated revenues typically. AMP monetization, as a whole, remains a developing feature. If you want to experiment video ads (that we do not recommend at this stage — especially with no in-house staff ), start slow and scale afterwards.