Adl+ - Admob sdk

JAN-FELIX SCHMAKEIT: --Google + this week. This week we have a special guest talking to us about the AdMob ads SDK. But, as you can see, something happened to [? Anchor ?] last week. I'm not sure what happened. So he's not with us today. But we have Tony with us. So, Tony? TONY CHAN: Hey. I'm Tony. I'm from Hong Kong. I'm also a developer of [? SDK. ?] How are you guys? JAN-FELIX SCHMAKEIT: And we have Raj, our special guest joining us today from Mountain View, I believe? RAJ PARAMESWARAN: Yes. Hey, I'm Raj. I'm from Mountain View. I work as part of the AdMob developer relations team. JAN-FELIX SCHMAKEIT: Cool. I guess we can get started straight away. So the Google AdMob ads SDK, Raj, take it from here. RAJ PARAMESWARAN: Sure. So, like I said, I'm part of the AdMob developer relations team and I'm going to be talking about the AdMob ads SDK today to you guys. Next slide. Oh. So let's start at the very beginning. You've just written your Android application, now what? There's lots of apps out there and sometimes they're really hard to distinguish. So how do you pull users in to your app? One option is that you can promote yourself by setting up an ad campaign through a network to advertise on tens of thousands of apps. These are the kinds of ads that you typically see that take users right into an application's Play store page, where they can download the app from there. Next slide. So now let's say that you've already got users and they're using your application. Of course, one of the ways to monetize here is to make your application a paid app. But the reality is that people really love free apps. Advertising is a great option here. It can give you the ongoing revenue stream that continuously comes in. It's also generally easy to implement, no matter how big your application is. Next slide. And this is what AdMob comes in. So let's start with the basics. AdMob's a mobile app advertising network that allows you to monetize your app and allows advertisers to promote their content. How does this work? Advertisers provide AdMob ads to run on its mobile network. AdMob relies on you, the mobile app developer, to serve these ads in your apps. We also recently announced AdWords advertisers, which are in the millions, can actually buy inventory from AdMob. This means that if you're an AdMob ad developer, you've also got access to these millions of advertisers. So on the left side of this picture, you can also see that you as app developers can actually become advertisers and promote your app with mobile advertising. Next slide. So let's touch on the promotion aspect of this for a bit. So promoting with AdMob lets you set up an ad campaign and advertise on a plethora of apps. You can target based on different factors such as device, country, platform, or even demographic such as gender, age, and other things. There's a number of benefits for doing this. If your advertising gets you in to the top 50 in the app store, for example, you're likely to enjoy even more organic downloads from people browsing the store. Cross-promotion is another way to get users into your apps. Once you build a loyal user base for one of your apps that you've built, you can actually leverage this to promote another app. Your loyal users will probably be more willing to try other apps as well. House ads specifically allow you to promote any other app in your portfolio. So this can even be used to actually promote apps beyond mobile. So that's definitely a thing to think about as well. Next slide. So now back to the monetizing side. Monetizing with AdMob is super easy. All you need to do is include the Google AdMob ads SDK in your app, create a banner view within your application, and load ads into it. Ads from Google advertisers are then displayed in your app and users click on the ads that they deal. You get paid every time a user clicks on ads in your application. An ad-based business model is a continuing stream of revenue coming in to your app. It scales as you grow. So as your app gets bigger and you get more users, you have much more opportunities to monetize. Next slide. So let's break down how the numbers work here. So using the AdMob SDK, you're actually going to make requests to AdMob's server for ads. In this particular example, let's say that your application makes 120,000 requests to AdMob. AdMob typically can't fill all of those requests. A number of factors play in here, inventory is one of them. If we say that 83% of those requests gets filled, you've got 100,000 impressions. An ad impression is actually reported whenever an individual ad is displayed in your app. CTR, or the Click Through Rate, is a ratio that shows how often people who see your ad end up clicking on it. Of course, a higher CTR is a good thing. It's a good indication of whether users find your ads helpful and relevant. In this example, we've got a CTR of 1.5%. When you factor in your impressions, this turns into 1,500 clicks. AdMob actually pays out on a cost per click basis. So your app earns money based on the number of actual clicks that are received. Exactly how much you make per click can actually vary substantially based on a number of factors. These include the type of app, your user base, and general market conditions. We actually operate an ad marketplace, so the price of a click at any given moment is determined by the bids that are being placed by the advertisers. If we assume a CPC of $0.10 here, for the sake of simplicity, it's really easy to calculate what your revenue is going to be at the end. Next slide. So we tried to make getting started with the AdMob Android SDK as easy as possible. You can check out our step-by-step tutorials as well as documentation on developers.google.com. If you've got any issues with it, me and the rest of the developer relations team are always willing to hear you out. You also need to sign up for a publisher account on AdMob.com. AdMob.com is the front end where you'll be controlling things related to actually serving ads within your application. To get up and going with the Android SDK, you've got to at least compile against Android 3.2, but we've got support all the way down to 1.5. Next slide. So the first step to getting up and going is setting up your manifest. You've got to declare an ad activity in your manifest. We've bolded out the two things that you've got to do there. At the bottom you see declaring the ad activity. You've also got to make sure to declare the internet and access network state permissions of course, because ad requests are going to require these. We also give you the ability to handle your own config changes, so the ad won't be refreshed when some of the config changes occur. Next slide. So let's look at the code to create your Adview. This also is very simple. You've got to import the necessary classes from the [INAUDIBLE] ads package. Here we're declaring an Adview instance. And you're going to have to specify an ad unit ID there. This is the ad unit ID that you get from AdMob.com when you sign up for a publisher account. You can actually add the view into the UI and load it with an ad by giving it an ad request object. When you're developing though, we ask you to make sure that you're in test mode to avoid being disabled for clicking on your own ads. Next slide. So one of the things to keep in mind is that before being passed to Adview dot load ad, which we saw in the previous slide, an ad request can be customized to allow Google to actually better target those ads. So you can use the ad test device method during development to avoid generating false impressions by requesting test ads for specific devices or your emulator. You can add any devices that you've got there. [INAUDIBLE] should actually help you out in this. It should print the device's [INAUDIBLE] five hashed ID for convenience. You can also specify location and demographic targeting information. However, out of respect for user privacy, we do ask that you only specify the location and demographic targeting info if it's already being used in your application. Next slide. You can also track ad life cycle events like request failures or click throughs by implementing ad listener in an object you passed through to the Adview dot set ad listener. This interface can be implemented by either your activity or any other object. These allow you to do certain things in your application if an ad is received or an ad request fails. You can also stop or pause things in your app if an ad click is going to take a user out of an application into the Play store, for example. Next slide. So an important thing we tried to encourage users to do is use the right ad format for the device that the users are on. We saw that the Adview constructor earlier takes a primer which lets you specify the type of format that you want. In our core examples case earlier, it was ad size dot banner. So notice how on the example on the left we've requested an ad that is way too big for this screen. This is actually our medium rectangle format. We recommend that people show this only on tablets. It's not a great user experience when an ad is taking up 50% of your screen real estate. On the other hand, on the right side, we've got a custom format that looks way too small. You can't actually even tell what it is. So at that point, the user experience is suffering again. The format we typically recommend for phones are 320 by 50 banners, which is the one we've got in the middle there. Next slide. So the most popular banner size that we have is the 320 by 50 banner, which you can use on both phones and tablets. It's mainly used on applications developed for phones though. For tablet ops, we do offer some larger sizes such as the 320 by 50 medium rectangle, which we saw in the previous slide, and a 728 by 90 leader board ad. However, the smart banner format is a new format we introduced back in April. These span the entire width of the screen and have variable height depending on the screen size. Next slide. So these smart banner ad units, which we introduced in the 6.0 SDK, I believe, actually render screen-wide banner ads across any screen size for different devices in different orientations. So what these do is they help deal with the increasing screen fragmentation across different devices by detecting the width of the phone and it's current orientation and making the Adview that same size. This also solves another problem of requesting the right type of format for the screen mode, so this is whether the screen is in landscape or whether it's in portrait. And requesting a smart banner ad is super easy. We've got a smart banner ad size constant that you just pass through to your constructor. Next slide. So we've also got some guidelines on where your applications should be placed in your actual app. Where your ads should be placed in the actual application. I've outlined some bad placements on this slide. So we can start with the one on the left actually. Needless to say, don't make your ads transparent or cover touchable areas with your ads. That's generally a bad thing. The middle example deals with something sort of similar. Ads shouldn't be placed where users will randomly click or place their fingers on the screen. In this example, if you're playing this game, you're very likely to slip up and click that ad erroneously. Another example of something like this could be if you got a children's app, for example, where bubbles are randomly appearing on the screen and you're popping them. You probably don't want to ads on a screen like that. The example on the right doesn't necessarily cover a touchable area, but it is very close to the buttons. So don't place the ads close to or underneath the buttons or any other object which users may accidentally click on. You don't want users to click on the adds without knowing. Essentially, try not to put ads anywhere where you may get erroneous clicks. Ultimately it leads to a bad user experience and bad reviews for your app typically. Next slide. So let's talk [INAUDIBLE] Another important facet of AdMob ads are the filters that we've got set up. So the filters tab provides a huge amount of control over the ads that show up on your inventory. We've got URL, text, category, and language filters. URL filters-- pretty simple, they prevent ads leaking to a specific URL or domain from appearing in your app. Text filters prevent ads containing or matching text phrases from being shown. Category and site filters prevent certain categories of ads from being displayed. An example of this is you can prevent image ads from being displayed, which would prevent any type of image boundaries from being displayed in your app. You can also enable age-appropriate ads. So age-appropriate ads are actually disabled by default. What enabling these allows you to do is display ads that are rated as age-appropriate, so not necessarily suitable for all audiences. Examples of these are gambling and personal ads. AdMob actually doesn't accept ads that promote any adult products or services. For the language filter, you can prevent ads of certain languages from being displayed on your app. Although we do recommend that you make sure that none of these languages are relevant to your user base. TONY CHAN: Raj, I just wanted to interrupt a little bit. So in general for our policy regarding ads on Android, I just wanted to add on top of-- RAJ PARAMESWARAN: Sure. TONY CHAN: So one thing a developer needs to remember now is that ads are really part of the entire application experience. So as a policy, the content of the ads is really part of the application itself. So if you use other advertising networks, make sure you pay attention to that because you may actually violate some content policy on the Android phone if you're using ads that do not comply with our general content policy. RAJ PARAMESWARAN: No, definitely. No matter what ad network you're looking at, it's something that you should make sure that you're reading very explicitly. TONY CHAN: Cool. Thank you. RAJ PARAMESWARAN: Yeah. So going on, we actually usually tell advertisers to be as permissive as possible using all these filters, just because this does maximize the amount of ads that are available to run on your inventory and ensures that you're generating the highest revenue potential that we can offer as an ad network. Next slide. So similarly, there's some other things that you can actually do to optimize your ad settings. You can also increase your fill rate by taking advantage of Google certified ad networks inventory. So with this option set, we will actually attempt to fill your ad request with not only ads from AdMob, which explicitly target mobile apps, but also ads from Google certified ad networks and general keyword targeted ads. So enabling these provides a great opportunity to increase your fill rate and your revenue. No code changes are actually needed here. We conduct a pretty thorough certification process before we let any network in for third party ad survey. But you have to remember that at this time you can't actually apply any of your ad filters to these Google certified ad network ads. Just something to keep in mind. It's also important to know that you need to set your refresh rate at the right amount. An ad that refreshes way too often can definitely adversely affect your CTR. It doesn't give users a chance to view the ad and decide if they are interested in clicking it. We usually recommend that users set their refresh rate between 45 and 60 seconds. This can all be managed within the AdMob's front end interface actually. Next slide. So AdMob's great, but what if you want to use a different ad network to actually maximize your fill rate and your revenue. We actually offer a free mediation service which developers can use to integrate multiple ad networks into their application and make service site decisions on how to distribute their requests among those ad networks. So ad network ECPMs actually usually vary over time, that's why your seeing that graph right there. ECPMs are just your effective cost per 1,000 impressions-- how much money you're making. When you're using mediation, you can actually find tune your mediation configuration so that the ad network that performs the best gets the most requests. If you keep track of how each of your networks are performing and tune your request distribution accordingly, you're essentially optimizing your ECPM to make the most money. So keep in mind that some ad networks do perform better in certain markets. AdMob mediation provides the ability to enter regional and country level settings that override the default ad network distribution centers. Next slide. Getting set up with mediation is super easy. Just add your mediation ID, which you can get in AdMob's front end, and you're all set. You don't need any additional coding and you can even send special targeting parameters to specific ad network adapters. Remember though that if you are adding third party networks to mediation, you'll also need to include their SDKs and adaptors in your projects. Next slide. That's it for me. JAN-FELIX SCHMAKEIT: Yeah, fantastic. That looks really easy to get started with. A lot of opportunities out there for developers. Fantastic. Thank you very much. RAJ PARAMESWARAN: You're welcome. JAN-FELIX SCHMAKEIT: So, Tony, do we have anything on the moderator for this week? TONY CHAN: Yeah, so let me take a quick look. Yes, I think we got two questions on moderator. So let me read the first one out. The first one is from [? Eric, ?] so what are the benefits of using AdMob over iAds or Millenial Media. So I guess, Raj? RAJ PARAMESWARAN: So iAd and Millenial Media are competing ad networks and they differ in a number of different ways-- fill rate, ECPM, CPC are just some of these factors. What I'd actually recommend is that you can get set up with all of these networks using mediation and see what works best for you on your specific conditions. And that way you can best optimize your own revenue. TONY CHAN: Cool. OK, so the next question is from Simon. The question was, I want to use Leap Bolt and AdMob. How can I do it? RAJ PARAMESWARAN: So mediation is I guess the answer here again. So with mediation, we actually do have out of the box support for a number of ad networks, which means we've got adaptors for them. If there's an ad network that we don't have some specific support for, you can actually write something called a custom event. So what custom events allow you to do is integrate custom code in to the mediation flow so that they behave like any other ad network that participates in mediation. We've got docs with this up on developers.google.com, feel free to check them out. TONY CHAN: Thank you, Raj. I think that's all we have on the moderator, Jan-Felix. JAN-FELIX SCHMAKEIT: Yeah, fantastic. Thank you very much. So I think that's all we have for this week. So thank you very much, our special guest from Mountain View, Raj. Thank you, Tony. And yep, see you next time. RAJ PARAMESWARAN: Cool, thanks a lot guys. JAN-FELIX SCHMAKEIT: Bye.