OK. Hello everybody. My name is Dave Wilson. I'm on the iAd team, and I'm here to talk to you about optimizing your earning power with iAd. For those of you who don't know somehow, iAd is Apple's digital advertising platform. This is what's used - you may have seen it in other apps you've used on iOS. If you use iTunes Radio at all, the ads that you see in iTunes Radio are driven by iAd. So that's what iAd is.

There's two parts to this presentation. We're going to be talking first about monetization: how you can use iAd inside your apps to drive revenue for your apps. And the second part is promotion: how you can use iAd to get more downloads of your app to get more users of your app - to get your app out in everyone else's hands.

So let's start off with monetization. I'm going to start off with a few different pieces we're going to talk about here. Talk about some developer benefits, what iAd can do for you. Talk about some core concepts, sort of an advertising 101. We'll talk about improving performance, how you can sort of best use iAd and get the most out of it.

We'll talk some details about the actual code you have to write to integrate iAd inside your app, which is fortunately pretty simple. We'll talk a little bit about testing iAd and making sure your integration is actually working before you get out in the App Store and then just get bugs So let's start off with developer benefits.

First of all, iAd provides rich, engaging ads. This is a platform that values great ads to go into the great apps that you create. They're high production values. There's rich media apps, and there's rich media ads involved here. These are things that involve video. They involve animations. They're immersive.

These are sometimes entire games presented inside ads. There was an Intel ad recently that was literally a game once the users tapped on it. This is the other things that your users are actually interested in engaging on, interested in tapping on, which is great for you as a potential advertising publisher here. These are award-winning ads. These are not just fly by night, you know, one off apps - or ads with link tags in them that are going to annoy the heck out of your users. These are carefully crafted ads that actually look good as part of your app.

OK? In addition, Apple is providing this SDK. As a result, the same care that Apple takes with respect to privacy and power efficiency on the rest of Apple's system, Apple invests in iAd as well. That means that we take care of all of the power and privacy considerations for you so you don't have to worry about them. You don't need to worry about obeying the limit ad tracking switch. You don't need to obey about - don't need to worry about location permissions or making sure that your users' privacy and personal data is protected properly.

In addition, because this is an Apple-provided SDK, it's part of the iOS SDK. Integration is simple. There's nothing else to install. There are no static libraries to include. There's no third-party headers to drop into your project to clutter things up. It's all there to begin with. You can be up and running with minimal code. As we're going to see later, it's about two lines of code to get banners in your app.

In addition, along with the rest of the code that other - along with the rest of the SDK that Apple provides, there's great documentation and great sample code available to you on the websites. iAd has global reach. We're in 14 countries now. We're constantly expanding. This a larger list of countries than we showed up here last year. And that means that you're going to get ads in all of those countries inside your app. So as soon as you get your app in all those countries, you're going to be able to get revenue in those countries as well.

Just like the actual app purchase and then In-App Purchases as well, you're going to get 70 percent of the advertising revenue from iAd inside your app. Apple takes its 30 percent share, and everything else goes to you from whatever we take in from the advertisers who are producing these ads to run inside your app.

It's very easy for you to get into the iAd ecosystem. There's an iAd contract on the itunesconnect.apple.com site that you have to sign. That's pretty easy. You integrate the iAd framework; that's what the rest of this talk is going to be about. And then, you submit your app for review, and that's really all you have to do.

OK. So that's sort of what iAd can do for you. Let's talk about some core concepts. These are some fundamental basics of advertising and some terminology that you're going to see, especially on the iTunes Connect website once you've integrated iAd and are trying to track the progress of you getting revenue from iAd inside your app.

First of all, there's an ad request, and you're going to see this come up again. Later, you'll see this in metrics. What is an ad request? It's a network request. It goes from the device, through the iAd framework. It's going to go out to the iAd servers up in the cloud. And hopefully, ads will come back down to you, assuming there are ads available for your particular app in the current situation of the user. You know, again, if the user is in a country we're not in, you're not going to be able to get ads there, unfortunately.

Once you've started getting ads from the - if you get an ad request, you want to look at your fill rate. This is the ratio of ads delivered by the ad server to the number of requests that you actually make to the server. This is, again, going to be determined by where your users are located, what type of app you have, how well your app has done with iAd in the past. And we'll get to that in a little bit - a little later, as to how that can be really important in driving your fill rate.

Once you've gotten ads, you've gotten your fill rate and you've shown ads to the user, there's a constant called the tap-through rate. This is the number of the ads that your user has actually tapped on, and this does not count accidental taps. So if the tap - if the user just taps on it and then closes it because they didn't really mean it, that doesn't count.

This is the number of taps that the user actually meant to have happen relative to the number of ads you displayed to that user. This is something you want to attempt to maximize inside your app. Again, though, accidental taps don't count. So trying to play games is not a good idea. Ad engagement.

Obviously, you need to display the ad. If you're not displaying the ad to the user, it doesn't matter how many of them you request from the server, you're not going to get paid for them, and you might as well not have bothered. Once you do that, make sure it's actually fully visible as well. The fact that it's onscreen and only one pixel of it is showing because you've got it covered up with something else, that doesn't really count either. You want to make sure that the ad is visible for as long as possible.

Leave it onscreen. Again, if it shows up and it flashes for two seconds, no one really saw it. It doesn't matter. You want to make sure that ads are onscreen. This is - has two benefits. One, it's not distracting to your user. You're not annoying people by flashing things on and offscreen all the time that people really don't want to see.

In addition, the user has time to interact with it. They have time to see it. They have time to see its message. They have time to say, "Hey. You know, I'd actually like to tap on this and engage with it and see what's going on under the hood." That leads into allow interaction.

It's really easy to put something onscreen and accidentally cover it up, especially accidentally covering it up with something that blocks user interaction. If you put a banner onscreen, you cover it up with something that is, say, a transparent view that does not allow user interaction, the user can't tap on the banner under the hood.

That's not a good situation for the ad. The user is going to be trying to tap on it, nothing's going to happen. It's going to be a bad experience. In addition, again, you're not going to get the revenue you're hoping for in this sort of situation because the ad wasn't really onscreen.

OK. So there's some sort of core concepts. Talk a little bit about what you can do to improve the performance of iAd once you've actually integrated it inside your app. First of all, revenue starts with your app. If you don't have a great app, it doesn't matter how many banners you show, it doesn't matter how many ads you show.

No one is using your app, and you're not going to make any money. So the number one thing you can do to drive revenue via ads in your app is to start off with a great app. And that's what the rest of WWDC is about, but a couple of sort of small things we can mention here. First of all, app engagement time.

If your - if you have an app that's - you're trying to drive revenue by showing ads, you need to make sure that your have sufficient engagement time for your users to actually do this. If it's a utility app that the user is going to pull up, it's going to be onscreen for about three seconds, and then they're going to close your app again, that's not enough time to actually show ads to the users and allow interaction and to get interaction from those users. So you need an app that actually is going to be onscreen and that people are actually going to engage with. Again, once you've done that, you want to make sure that the ad is placed carefully within that app.

Think about what the user is doing on the various screens of your app. Make sure the ad is placed appropriately within the app. If you have a game, for instance, and the user is tapping and swiping and slicing constantly, maybe that's not a great place for a banner where they're going to be accidentally tapping. The ad will pop up over the top of everything. You're going to be annoying your users, and you're going to be harming your app more than you're helping it with the ads.

OK? Pulling back into app engagement time: user loyalty. You need to come - you need your users to come back to the app repeatedly. That's how you get more screen time, that's how you get more ad time for those particular - for showing ads to those users. In addition, user loyalty is what drives ad - or app engagement and what drives app downloads.

The sort of network effects that you may have heard of before. The more people are using your app, the more they want to use it, the more they're going to tell their friends about using it, the more downloads you're going to get. Therefore, the more eyeballs you're going to get looking at ads within your app. OK? I mentioned that iAd is in 14 countries. That means that your app should be in 14 countries if you want to get as most - the most revenue from iAd as you can.

Market your app to the countries where iAd actually is. If you're - if you've spent the time to integrate iAd into your app, you want to make sure that your app is in all of the places that iAd is so you have the largest reach possible to potentially get the most users possible for your app. A big part of that is localizing your app.

If the only thing you've done is write your app in English, and you're trying to get it in all 14 of these countries, you're going to have a hard time in countries where English has a small presence. Make sure you take the time to localize your app appropriately to drive users in those countries.

And back into ad placement a little bit, because this is a piece I'm going to keep coming back to. Ad placement is extraordinarily important within your app. You will recognize high-use areas inside your app, and you want to make sure you put banners inside those areas. Those are the places where users are going to be looking at the screen for a long period of time. They're going to have the opportunity to see the app - the ad. They're going to have the opportunity to engage with the ad.

At the same time, as I mentioned, avoid accidental taps. Accidental taps are bad for your user, and they're bad for you. They're going to annoy your user, and iAd doesn't like accidental taps either. So you want to make sure that you are using the framework in a way that does not encourage them because your app will ultimately end up being penalized for this.

User context is really important. You want to take advantage of different types of ads based on what the user is doing at any given time. Say the user is on the menu screen of your game. Maybe that's a great place to put a banner at the bottom of the screen. They're looking at the menu. Maybe they notice the app - or the ad at the bottom. Maybe they tap on it and engage with it.

At the same time, if they tap to go into the first level of your game, and you immediately pop a full-fledged ad and interrupt their experience once they've done their first action inside the game, that's just going to annoy them. You're going to drive users away. Users aren't going to want to engage with the ads. That's what you want to try to avoid. So be very careful about where you're putting the ads within your app.

Once you've integrated iAd and you can start looking on the website, you'll start getting reports about your revenue. One of the things you're going to notice, everyone always notices this and brings this up, is that revenue will fluctuate. This is perfectly natural. Consumer spending is seasonal. Advertiser spending is also seasonal because consumer spending is seasonal. You need to be aware of this and watch for it. You can also take advantage of this. Market your app accordingly.

Start of summer, back to school, holiday season - these are the times when users are going out to get new devices, they're going out to get new apps, and advertisers are going out to get eyeballs inside those apps. So that's when you want to try and get - try and put all of your money into pushing your app out there.

OK. We've talked about ads. We've talked about impressions. We've talked about tap-throughs. We've talked about fill rate. This is a virtuous cycle. OK? You're going to get ads to begin with. They're going to lead to impressions. Impressions are going to lead to tap-throughs. The more tap-throughs you get, the more ads you're going to get from the ad server, the more impressions you're going to get. OK. So that's performance. Now that we've done that, now we can go into some actual details about how you actually go about integrating all of this stuff, sort of the meat of this talk.

There's four ad formats. There's banner, there's interstitial, there's medium rect, and there's a pre-roll video ad. We'll talk about each of these four in turn. As I mentioned earlier, you're going to want to choose the correct ad for your app in the various contexts within your app. So all four of these types of ads are important for many, many apps.

We'll start off with banner. OK? So what is a banner? It's a slim device width view. It's placed at the bottom of your content. It continuously loads ads. You may have used other iAd SDKs or ad SDKs where you've got to make a specific request. This isn't that. You create a view.

It's going to show up at the bottom of the page and will continuously load ads over time as new ads are downloaded from the ad server. There's nothing you have to do to manage that. Once the user taps on it, it's going to go into some sort of full-screen ad experience - and supported on both iPhone and iPad. It has been since the beginning of iAd.

Integrating banners in your app is about the simplest thing that you could do. There's three steps to this. You're going to link the iAd framework. You're going to import the iAd header, which is the first line that popped there. And you're going to configure your view controller, which involves setting the .canDisplayBannerAds property to yes on your view controller.

That's it. If you've done that, you've got a banner inside your app. OK? So what does that look like? OK. Loading an ad. You've got your view. The moment you set the .canDisplayBannerAds property on it, we're going to do something under the hood to your view controller. Your view is going to turn into original content view. We're going to move your view over to original content view, and we're going to take a review on your view controller.

So it's very important for you to remember if you're subsequently attempting to access your view on that view controller. We're then going to make a request up the ad server. It's going to come back and hopefully a banner is going to load. And at that time, we're going to move the banner onscreen and we're going to resize your original content view appropriately and with the appropriate animation to move the thing onscreen so the user can actually look at it.

Once it's been onscreen for a while, hopefully the user is going to go ahead and tap on it. And at that point, the full-screen ad experience is going to pop up. When that happens, there are a couple of things you need to do. First of which is to pause activity in -viewWillDisappear:. Your app is probably doing things in the background while that banner is onscreen.

When the user wants to engage with the ad, you want to get out of the way. If you're playing music. If you're running a game simulation. If you're doing anything else that's potentially intensive or distracting, you're going to pause that activity in -viewWillDisappear: so that it gets out of the way of the ad.

Eventually, the user will be done interacting with the ad. They'll dismiss it. You'll get a -viewDidAppear:. Resume all that activity. Once the ad's gone, you want to start the music up again. You want to start your game simulation, etcetera. Eventually, say the user goes out of network connectivity or something, you may not have an ad available anymore. When that happens, the banner is going to be moved off of screen. The original content view will resized and that - and you can, you know, wait until it hopefully reloads again.

In addition to waiting for the network connectivity to just move the banner back off of screen, you can control the banner visibility whenever you would like. If something happens within your app that you would like to move the banner offscreen temporarily, you can go ahead and so. Just go ahead and set .canDisplayBannerAds to no. Just don't forget to set it back to yes when you want to re-enable it. Make sure you put the ad back onscreen whenever you actually need to.

OK. So that's banners. Let's talk about interstitials next, which is the sort of second major type of banner - type of ad here. Very different than banners. Rather than something being permanently onscreen, they're immediate full-screen display. They immediately take over the entire screen when you want to present them. The user is immediately able to interact with them. OK? They've been on iPad since iOS 4.3, and they were introduced on the phone in iOS 7 last year.

There's two major ways to handle interstitial presentation. The first is automatic presentation. Just like banners, it's pretty simple to configure here. Rather than setting .canDisplayBannerAds, you're going to set .interstitialPresentationPolicy to ADInterstitial PresentationPolicyAutomatic. What that does is tell the iAd framework, hey, this is a great view controller to show ads on, and whenever you, as the iAd framework, think is a great time to show ads, go ahead and do so.

At the moment, that means that we're going to show ads when this view controller first moves onscreen, when it appears. I'm going to take that as an opportunity to show an interstitial ad if one is available. So to do that, just take your view controller, push it onscreen, make it - push it into your navigation stack, or however you want to put it onscreen.

That moves in, and we're going to pop an ad up over top of it. When the user is done interacting with it, it'll come back off. In addition to automatic presentation, there's manual presentation. Just set the presentation policy to ADInterstitial PresentationPolicyManual, and instead of us automatically presenting it whenever the view moves onscreen, you can call - request interstitial ad presentation to attempt to display it whenever you think it's an appropriate time for an ad to pop up over top of your content.

Next, preparing for presentation. Because interstitials don't have something onscreen, something sitting there requesting ads, attempting to display things at all times, you want to notify the iAd framework that you would like to present interstitials in the future so we can go ahead and make an ad request and have an interstitial waiting for you when that time comes.

To do that, you're going to want to call UIViewController prepareInterstitialAds inside something early in your app's life cycle. ApplicationDidFinish LaunchingWithOptions is a good opportunity here. If you're doing a lot of other work at that point, maybe defer it a little bit. But you want to call this prior to your attempt to present an interstitial for the first time. That gives the iAd framework enough time to go out to the network, request an ad, and have everything ready to present by the time you want one to be presented. That will prevent you from missing ad opportunities.

OK. So that's banners and interstitials. We're going to go from here into a quick demo just of the APIs I just went over. So we'll switch over to my demo machine here. What I'm going to start off with here, I'll just draw up my little app, is a very simple master detail app here. Just shows some news articles. I can click on one of these news articles and bring it up. And what we'd like to do is take this app and add some ads to it, monetize it with iAd.

So if I can quit the simulator again here. What do we want to do here first? The first thing we're going to do is add a banner to the bottom of the MasterViewController, the bottom of that article list. So inside our MasterViewController here, we're going to import the iAd header.

Do that like this. And then, inside, awakeFromNib, all we're going to do is call - set self.canDisplayBannerAds to yes, and that's really all we have to do. Oh, one more thing. We need to go in here, development phases, and ensure that we link against the iAd framework. Make sure the APIs are actually available to us, so we go back to MasterViewController here. Go ahead and run.

And we'll see that with two lines of code and one link, we have banners at the bottom of our screen that are automatically in line with our view controller. Now, we only set that on the MasterViewController. That means that when we go into an article, there's no ad there, which is a little bit unfortunate.

So the next thing we want to do is take advantage of the other type of ad that we talked about, interstitials, to present an ad to the user prior to them actually being able to read the article. So once they've tapped on the article title, we want to add the popup over the top of the screen before they can actually see the article.

So let's go ahead and quit this again. And this time, we're going to, down here, inside our prepareForSegue function, we're just going to set up the DetailViewController that shows the actual article. We're going to grab this destination.interstitial PresentationPolicy ADinterstitial PresentationPolicyAutomatic so that we can say that on this DetailViewController, the thing that's showing the article, we want the iAd framework to manage presentation of interstitial ads over top of this view controller.

Once we've done that, that's going to get interstitials shown over that view controller. However, we want to make sure that the iAd framework knows to go out and look for interstitials before the user taps on an article for the first time. So to do that, we're going to go over here.

We're going to get to our AppDelegate here, and we're just going to grab UIViewController prepareInterstitialAds. Make sure we import the header as well. That tells iAd, hey, go prepare interstitial ads so they're ready for our user here. So I'll go ahead and save this. Run our demo again.

Once again, we've got the article view here. We've got a banner loaded at the bottom that happened. Now, once the user taps on this, the interstitial ad is going to pop up over top of the article. Once the appropriate time is expired, the user is done interacting with this, they can go ahead and close that, and the article is behind, and they can go ahead and start reading their article. So that's basically how easy it is to integrate banners and interstitials to your app.

So we'll go back to the slides. OK. So that's banners and interstitials, which are the first two major types of ads for iAd. They were also the first two types of ads that iAd had. Those were the ones that were sort of available pretty much from the beginning of iAd. There are a couple of newer types that we've got. The first new type, it's - talking about banners and interstitial a little bit more, sorry.

First of all, use .canDisplayBannerAds and .interstitialPresentationPolicy on your controllers as much as possible. We talked about ad engagement. We talked about the user having the opportunity to see the ads, leaving them onscreen, the user having the opportunity to engage with the ads. Setting these properties is a big part of that. In addition, remember to use .originalContentView when you actually use .canDisplayBannerAds. It's very important that once you set .canDisplayBannerAds, you realize that you have given over control of view to the iAd framework, and .originalContentView is yours to continue using.

Pick the right transitions for interstitials. Think about what your user is doing at any given time when they're transitioning from view controller to view controller. And make sure that .interstitialPresentation PolicyAutomatic is set on the appropriate view controllers for an ad to show up when they first pop up.

For instance, in the news demo that we just showed you, having that show up on the main article list is probably not appropriate. That would just be distracting and annoying to users. Having it on the article view controller, on the other hand, just gives a gating function to allowing the user to actually use your content. That's sort of the appropriate use for the interstitial.

Be consistent throughout your navigation stack in your use of these. This is particularly important for navigation controllers, in particular deep navigation controllers. What I mean by this is, in particular with .canDisplayBannerAds, if you have a deep navigation hierarchy, you want to attempt to set .canDisplayBannerAds on as many of the view controllers that you're going to be pushing into that hierarchy as possible to ensure that the ad remains onscreen as the user navigates throughout that hierarchy.

Otherwise, you have the possibility of the ad popping up onscreen for a second. The user taps on something; the ad goes back away. They tapped to something else. Maybe the ad comes back. That's distracting to your user. At the same time, it doesn't allow the ad to stay onscreen long enough for the user to actually engage with that ad.

OK. So now, we're done talking with banners and interstitials. Let's talk about medium rect, which is then next major type of ad that iAd provides to you. What is a medium rect? It is an International Advertising Bureau medium rectangle; it's a standard ad type. It's positioned inline with your content.

It's a standardized size; this is the same size that you may have seen when you're browsing the web. You see this sort of square or rectangular ads positioned inline with the web content. This is the same type of ad that we've got. Just like banners, they automatically cycle over time.

So you put them onscreen, new ads will be loaded out of the iAd framework - feels appropriate - and will automatically manage making a request and putting ads in here for you. And just like banners, there's a full-screen ad experience once the user taps on and engages with this banner. They were introduced in iOS 6 on iPads and happy to announce that in iOS 8, we're adding this to phone as well.

OK. So what's the medium rectangle life cycle look like? Because these banners are not managed by the iAd framework, you have to do a little bit more work to put these onscreen. OK? You need to create the banner explicitly rather than just setting a property on your view controller.

You need to configure a delegate, which is going to allow us to tell you when certain things happen, and we're going to get into the code for this in the next slide. Implement the delegate protocol so you can actually take notice of these events and move the thing on and offscreen as the banner loads and unloads. You're going to show the banner when you receive the -bannerViewDidLoadAd: property - or delegate callback.

You're going to pause activity in -bannerViewActionShould Begin:willLeaveApplication:. This is analogous to getting the view will disappear message from interstitials or banners. And you want to resume activity in -bannerViewActionDidFinish:, analogous to view will appear. You're going to hide the banner in -bannerView: didFailTo ReceiveAdWithError:. This is important. This indicates that your banner no longer has an ad loaded and it should no longer be taking up space onscreen. So what does this look like? First of all, creating a banner. You're going to import the iAd header at the top. You're going to implement ADBannerViewDelegate on whatever object you would like to actually be managing this particular banner.

Then you're going to create the banner view. You can do that with initWithAdType: ADAdTypeMediumRectangle, and then you're going to set the delegate to the object that's implementing the delegate protocol. So what does that delegate protocol look like? Well, first how does a medium rect actually load and unload? It's going to start out unloaded. When you first create it there's nothing in there. We haven't made an ad request. There's nothing to put onscreen yet. So don't put it onscreen when you first create it. It's just going to be a blank slide, and we're going to send you an error.

Once you get a -bannerViewDidLoadAd:, that's your cue that there is an ad available inside your medium rect, and you should move it onscreen. You're going to leave the banner onscreen as long as it has an ad. Remember, too, that this is something that's supposed to be positioned inline with your content.

When you move it onscreen, when you leave it onscreen, make sure that it's within the rest of your content. If you have an article and you put the medium rect onscreen with the article, text should flow around it. It should be inside a scroll view and scroll with the rest of your content. That's what this type of ad is intended for.

You're going to move the banner back offscreen in bannerView:didFail ToReceiveAdWithError. Again, once you move it offscreen, it's your responsibility to reflow your content to fill the hole that was just left by the ad. At that time, it's going to move offscreen. You reflow up your content. This is what banner loading and unloading is going to look like. You're going - there's two important delegate callbacks here.

BannerViewDidLoadAd, in which case you're just going to put the banner onscreen, rehandle all of your layout. And bannerView didFailToReceiveAdWithError, you're going to remove it from the super view. You're going to do the converse. You're going to, again, layout, reflowing your content around the hole that was left by the banner view.

So some best practices for medium rectangle. Again, this is great for reflowable content. This is the sort of thing that you're going to put inside a scroll view, within the rest of your content that may scroll up and down along the device, may go on- and offscreen. It's sort of static with the rest of your content - flows around it, fills a hole with inside the space on the screen.

It's got a full-screen ad on tap, remember that. Pay attention to the delegate callbacks for willBeginAction, didFinishAction so that you can pause and resume activity. Pause it in bannerViewActionShouldBegin. And resume activity in bannerViewActionDidFinish. So that's medium rectangle. A little bit more complicated than the banner because you have to manage positioning yourself, but still fairly simple to implement. OK, the fourth type of ad that we're going to talk about here is the pre-roll.

What is a pre-roll? The video pre-roll is a short video that plays between - before your own media content. It's full-screen ad on tap, just like the other banner types. It was added in iOS 7. And in iOS 7 we added it on MPMoviePlayerController. And new in iOS 8 we're also adding it on AVPlayerViewController, new AV kit APIs that are introduced here at WWDC.

This is available on both iPhone and iPad and has been since the initial introduction. I want to sort of circle back to the very first bullet here, the short video plays before content. This is really important. This is not an interstitial-style ad. This is something to be played before your content, so you need to make sure that you actually have a video to play after it. We don't want - it's not supported for you to attempt to use this just to play a random ad at a random time. Make sure that you have content to follow it; that's what the API is designed for.

So setting up and playback, also fairly straightforward. You're going to start off by linking the MediaPlayer and iAd frameworks. Import Media and iAd headers. You're going to create a player. You're going to tell it to play the pre-roll video, and then you'll play your content video. Very straightforward. Basically almost all those except the iAd vids and the play pre-roll you already have to do if you've got your own content. This is just a few tiny additional lines. So what does that look like? First import MediaPlayer and import iAd.

You're going to create your MPMoviePlayerController. You're going to initWithContentURL as you already would. You're going to add that MoviePlayer into your view hierarchy so that it's onscreen. Call layouts, you redo your layout for it once it's there as well. And then you're going to call playPrerollAdWith CompletionHandler. You're going to call this instead of immediately calling Play. This tells iAd, "Hey, try to put a pre-roll video in there if you've got one.

Play that first." This takes a completion handler. It's going to return an error possibly if something went wrong. Inside the completion handler is your cue to start your content. You want to make sure you don't automatically play your content. You want to pause your content until this actually begins playing, or until the pre-roll finishes playing and you want to begin your own content then.

For AVKit it's almost identical. You're going to create an AVPlayerViewController instead. You're going to import the AVKit headers. And you're going to call, again, playPrerollAdWith CompletionHandler. It has identical semantics to the MPMediaPlayerController ones. Inside the completion handler, you're going to call player play to start your own video content afterward. This is new in iOS 8.

Just like interstitials, because this is something that is going to happen at some point and you want to have iAd prepare it for it you need to tell the iAd framework, "Hey, I'm going to want to play pre-rolls in the future." That allows us to have the opportunity to go out to the ad server, grab ads, and be ready for your request to play pre-rolls so that we can actually play one when the user does something that requires it.

To do that, just like interstitials you don't want to miss these early impressions, so you're going to want to start ad requests early by calling MPMoviePlayerController preparePrerollAds. Again, probably an application did finish launching with options or some other early in your app's life cycle period, so we haven't had an opportunity to go get ads for you before you call the APIs. If you're using AVKit it's almost identical, AVPlayerController preparePrerollAds instead. Going with best practices for video then: Don't play content until the ad completes.

If you've called playPrerollAd, and then half a second later you call play before we've called your completion handler, we're going to interrupt it. You know, notification handling is a very common case for this. This is going to interrupt playing of the pre-roll ad. It's going to immediately skip. It's going to go to your content. And it's like the ad never played except that it's a poor user experience for your user. You'd like to try to avoid this when possible.

So make sure that you wait until our completion handler is called to call play. For notifications, this frequently means just recording the fact that your content is ready. If you're already calling play in these notifications, instead of just calling play, record that fact, and inside the completion handler check for that fact, and then call play.

Similarly, defer UI customization. Many of you may be doing UI customization on top of the MediaPlayer controller to present custom controls or present custom UI around it. Wait to do that until after we've called your completion handler. The pre-roll already has custom UI, and you don't want to interfere with that custom UI with your own customization. That's, again, going to provide a very poor experience for your users. OK, so now that we've got that, let's go back to our demo machine here. I've got a quick demo setting that up as well.

Let's close - yep - that. I can pull up quick little demo of this as well. Can run this. This is a very simple little app, just provides a few quick little video clips here. I can click on one of these and we've got a quick video. Now what I'd like to do is, now that I've got this video content that my user would like to engage with, I'd like to monetize this by playing a pre-roll ad prior to the user actually being able to view my clips. So let's go ahead and quit this and see what we have to do to get that done.

We can start off here - the very first thing we need to do is, as for interstitials, we want to make sure that we tell iAd, "Hey, I'm going to be playing pre-roll ads, go fetch them early." We'll start off in our app delegate here, and we will import iAd, and we'll import the MediaPlayer so we have the appropriate classes for our APIs. And we'll go ahead and call preparePrerollAds on MPMoviePlayerController.

Once we've done that, we need to actually go ahead and call preparePrerollAds, so we'll go to our View Controller here, which is doing the actual display, and we're going to scroll down to - at the bottom here, collectionView didSelectItemAtIndexPath. This is what happens when the user actually taps on it. At the moment, all we're doing is creating MPMoviePlayerViewController, setting the content URL, and then calling presentMoviePlayer to have it start playing automatically.

We want to sort of interrupt that briefly, and instead we're going to go ahead and call playPrerollAdWith CompletionHandler. And again, inside the completion handler to that, that's where we're going to call mpvController.moviePlayer play. Go back up to the top here, and ensure that we are importing iAd as well, so we get the iAd APIs available. Go ahead and save that. We can run again. No. This is what I knew I was going to do. Once again, we got to go in here, make sure that the iAd framework is linked.

Now we can run it. OK, and we got our ad up - our app up here again, same quick little videos. We can go ahead and click on one of these now. And before the video content actually plays you see that we've got an iAd workbench ad that comes up instead. The user can view this ad content. Once they're done with it they can decide to go ahead and skip ahead of it, and we go immediately back to the video content for the app itself.

And that's pretty much all that's involved in implementing pre-rolls once you've already got MediaPlayer content for that pre-roll to play in front of. OK, so those are the four different types of ads that we have for integration with iAd inside your app. Once you've started using them, let's talk a little bit about testing.

First of all, there are a couple of things we add - we've added to the developer settings on the phone to help you test the integration of iAd within your app. First, you can adjust the fill rate. This is inside the apps that you have when you're testing them on the device - you can adjust how frequently you're going to get ads. This allows you to test error conditions. It allows you to test always working conditions and make sure that your app handles those conditions appropriately.

In addition you can adjust the refresh rate for things like banners and medium rects. This is going to adjust the frequency with which new ads come in. In addition, in combination with the fill rate this allows you to rapidly test error and nonerror conditions moving things on- and offscreen.

Most importantly there's a switch called Highlight Clipped Banners. If you're using the .canDisplayBannerAds, this isn't going to affect banners very much, but this is very important for medium rect. It's very easy to accidently occlude part of the medium rect with some other UI element. If you do that, that's a part of the medium rect that may not be seen by your user. It's a part of the medium rect that you - that the user may not be able to tap on and interact with.

This will detect that. You turn on the Highlight Clipped Banners button. We're going to provide a green or a red overlay over your medium rect, or banners, or instructions for that matter, that will show when the user can actually tap on all parts of this banner, when it is officially onscreen and visible.

You want to make sure that any banners that you show inside your app are always green. Remember this only affects your apps, your developer-mode apps that you have run from Xcode and deployed onto your device. So no, you can't just fill right to zero for all the other iAd-using apps on your device.

This only affects developer-mode apps. OK, so that's monetization. That was sort of the first major portion of the talk. Let's talk next a little bit about promotion. This is the other half of the iAd ecosystem. This is how you can use iAd to drive downloads of your own app.

So there's three major parts that we're going to talk about here. First I'm going to do a really quick intro to iAd Workbench. There's another session on that tomorrow if you get more in detail. So this is just a quick overview. And then there are two new APIs that we're introducing in iOS 8, one for app attribution and one for app audience retargeting. And we'll talk a little bit about those new APIs. Let's start off with iAd Workbench. What is iAd Workbench? iAd Workbench is iAd's self-servicing advertising platform. It's basically a web app on the apple.com, iadworkbench.apple.com. This is how you can manage being an advertiser on iAd.

OK? You can create mobile ads. You can upload your own banners. You can use built-in templates. You can also use iProducer to create your own iAd assets. Once you've done that, you can use this to reach the users who are most likely to actually download your app. iAd is an iOS advertising platform. You're going to reach a whole bunch of users who are on iOS who are already using apps on iOS and who are, therefore, highly likely to engage with the ad that is advertising your app and download your app.

You can also manage your campaign performance here. This is where you're going to see how many people have seen your ad, how the campaign is doing, tap-through rates, etcetera, for your particular advertising campaign. So that's Workbench. Again, there's going to be another session tomorrow going into more detail.

Next important part to talk about is some new APIs that we've got for app attribution. OK, what is app attribution? App attribution allows you to track app downloads of your app that originated from iAd. OK? This is going to let you measure the effectiveness of your campaigns that you've created in iAd Workbench that you're running to actually promote your app.

OK, the APIs were available in iOS 7 - or iOS 7.1, rather. And we've enhanced them a little bit in iOS 8 as well. So there's a new one in iOS 8. So what does the API actually look like? It's very simple. Again, you're going to include iAd/iAd.h, as everything starts with for iAd. And then you're going to call ADClient sharedClient. And on that you're going to call lookupAdConversionDetails.

OK? Inside that you can use the two dates that are provided with completion handler to determine whether or not this particular installation of the app was due to iAd. OK? These dates are going to give you two things. The first is the app purchase date - the date at which the user actually made the purchase of this app.

And then the date of the impression, the date that the user saw and interacted with the ad prior to them purchasing the app. OK? If both of these dates are there and true, that's going to indicate to you that as far as iAd is concerned this was a installation of your app directly attributable to the user interacting with and seeing an iAd promoting your app.

It's very important to remember that these dates are going to be nil if they are not attributed to iAd. They'll also be nil if the user has Limit Ad Tracking enabled. So regardless of whether or not this is an iAd-driven installation, the user has Limit Ad Tracking enabled; they don't want their ad browsing data to be tracked or shown to various apps. These are going to be nil. We're not going to give you this information in those cases. So you should be aware of that if you're trying to use this for any sort of analytics.

In addition, you want to avoid lookups of this data on every launch. It's probably very tempting to add this to appDidFinishLaunching, lookup your conversion details, set some state flag, and do something on every single launch on the app. Try to avoid doing that. There is some cost to actually doing this lookup. You want to defer doing this lookup until you actually need to and then cache the data afterward.

OK, so that's app attribution. The next thing we can talk about is the app audience retargeting APIs. These are new APIs in iOS 8. So what is app audience retargeting to begin with? Audience retargeting allows you to group the users of your app, that particular audience, into various categories depending on their activity within your app or things that you know about them from their use of your app. This might be frequent in-app purchases. It might be a very high usage rate relative to other users within your app. It might be dormant users, users who used your app a while ago but you haven't seen in a while.

You can then use this information to target new ads in iAd Workbench directly at specific subgroups of your users to reach specific audiences within the users of your app. Each group defines what we call a segment. That's terminology that's going to come up in the next couple of slides. That's important to know. A specific group of your users is a - with a specific name is a segment.

So why would you want to use this? Let's say you're a game app developer. You want to promote the new iAd version of your app to all your iPhone users. You want to go back and reach those specific users and say, "Hey, I've got a great new iPad version of it. Come try it again. Come back to this app, maybe redownload it." If there's new features that affect specific subsets of your app, you can use this to reach those specific users.

That's going to ensure that the ads you create are going to reach precisely the audience you're attempting to target with those ads. Similarly you can reengage dormant users. If you've got users that you haven't seen in a while you can craft a message specifically designed to try to pull those people back into your app to reengage those users who may not have used your app in some time.

If you're a retail app instead, there's similar reasons to use this. It can remind users who may have abandoned a shopping cart in your app, segment those into something, send them a message, "Hey, you abandoned your shopping cart. Maybe you should come back and reengage with this app.

Maybe you still want to purchase those things." If you've got loyal customers, maybe you want to send them a special offer. Maybe you want to send them a gift for being a loyal customer. You can do that with an ad as well. You can retarget specific ads to specific segments of your users.

If they've - you can group customers into specific categories based on their previous purchases. You can promote sales based on their previous purchases. All these are done by segmenting those users into specific groups and recording that so that you can reengage with those users with specific ads. So how does this actually work? First thing you're going to do is you're going to go on iAd Workbench, and you're going to create segments.

And you're going to tell iAd Workbench, "Hey, I'm going to group these people into 10 different segments. Please give me some segment identifiers to use for that." It's important to notice that you do not create segment - specific segment identifiers; iAd Workbench does instead, and this is partially for privacy reasons. We manage the specific segment identifiers.

Once you've done that, you're going to go ahead and update your app and take advantage of the new APIs, so you can actually associate specific segments with specific users. And that goes up to the server so we can actually record that information. Once that's done, you go back to iAd Workbench, and you create your new Workbench campaign to retarget those customers with some specific ad message.

OK, so how do you actually do this? Actually very simple on the client side. You're going to include iAd. You're going to create an array of segments, and these are segments - the segment identifiers are what you've already gotten from Workbench. If you attempt to send random segment identifiers up to iAd, we're just going to ignore them, so you want to make sure you're using the ones that you've already created and set up inside Workbench. So maybe you decided you know Segment A is loyal users, Segment B is frequent purchases, and you want to associate the current user with those two segments. And you go ahead and create a segment array with those segments in it.

And you're going to call ADClient sharedClient, addClientToSegments, replaceExisting. This is by default with replaceExisting:NO going to add these segments to the current user. If instead you'd like to say, "Hey, these are all of the segments I'd like to associate the user," which might also allow you to remove old segments from the user, you can just update that replaceExisting to yes to just completely replace the old set with the new set.

OK, so that's basically iAd for promotion, the new APIs that we've added in iOS 8. So what did we learn? First of all, there's some best practices for using iAd. There are four different types of banners that we've talked - four different types of ads that we've talked about. There's a banner.

There's an interstitial. There's a medium rect. And there's a pre-roll, and they all have their place. You want to take advantage of the different ad formats that we've given to you, think about where they belong in your app, and make sure you use the appropriate ad for the appropriate context.

As part of that, consider the user when you're placing ads. Yes, ads are very valuable for generating revenue from your app, and iAd can help a lot with doing that. But great revenue and great apps start with great users as well. If you're going to alienate all of your users by poor ad placement, by poor ad choice, you're not actually going to have a net win here. You want to really make sure you have a user-centric focus to where you're picking to put ads and which type you're choosing to put there.

In addition, there's a cycle here between monetization and promotion. OK? Optimize your ad's performance to begin - your app's ad performance to begin with, that's going to generate revenue from it. But don't forget to take advantage of iAd Workbench and repromote your app. It's important to continue to get new users for your app if you want to continue to get revenue from your app. The two feed into each other. You want to generate revenue; you want to spend some of your revenue to readvertise your app and acquire new users.

OK? So those are some sort of best practices for iAd. For more information beyond this, we've got Mark Malone is our iAd Technologies Evangelist. You can reach him at the email address above. There's an iAd Programming Guide online along with the iOS STK developer information. There's some Apple developer forums that we monitor.

If you've got questions, you and other developers, and us will be monitoring those to answer questions, hopefully help you out. There are a couple related sessions here at WWDC. Unfortunately you already missed "The New iTunes Connect," which talked a little bit about iAd. That was yesterday. You can watch the video.

Tomorrow morning at 9:00 in Nob Hill there's "What's New in iAd Workbench," which is going to go into a little bit more detail about the app attribution and the audience segment retargeting that I talked about at the end of this presentation. And that's it. Thank you very much.