Welcome to Integrating Ads with iAd. Today, we're going to give you an overview of the iAd Objective-C framework. How to use is in your application and the best practices you want to keep in mind. We also talked about the business side of using iAd in your application. My name is Wil Turner. I am the iAd Framework Manager. So today's agenda, we're going to start of with an advertising overview. The advertising industry, how it works.

Then we will get in to the technical side of the iAd framework. Putting the ads in your app, what we call the banner view life cycle, how to support multiple interface orientations. So your apps already may support autorotation. You want the apps do the same thing. Then we'll talk about responding the actions that the user chooses to go into the ad, is there something your app should do in response? And finally, we will finish with the business side what it means to become a publisher.

But first, a little recap of why iAd. We think with iAd we can reinvent mobile advertising. Right now the status quo of mobile advertising is that things are somewhat interactive because it's web or some other kinds of dynamic content, but the ads usually exit the application which is a really poor user experience. And then there's television which is on the other side of things and it's fantastic. It can convey an emotion but there's not really interactive side, there's a captive audience.

With iAd rich media ads we think we can capture both of these, both the emotional and the interactive. The best of both worlds will provide media through audio and video and interaction through emotion and touch. The iAd rich media ads are built on HTML5. That means that audio and video are first class citizens in the web content. They're not provided by plug-ins and they execute natively.

We get interaction with CSS3 and Multi-Touch which is only on the iPhone. So WebKit provides extensions in the browser that allow us to do animated transitions and even keyframe animations. They are hardware accelerated. So no more JavaScript to animate something across the screen. This is happening down on the graphics hardware and the touches are exposed as DOM events by WebKit.

Finally, we're going to deliver an optimal user experience in the iAd rich media ads because the user will never leave the application. The background process we have is going to execute the ads so it's not in your apps memory space but it's going to be presented on top of your application and your Apple always remains foreground. The user dismisses the ads at any time and is returned exactly to the point in your application where they left off. So this will change the game.

Combining emotion and interactivity and we don't leave the application. So, let's talk about advertising a little bit. There are several common roles in the advertising industry. It starts off with the advertisers. These are the people, the companies with products and services that they're trying to advertise. The next piece in this chain are the ad agencies, they help create the advertising campaigns.

Now mobile and web advertising, we have this notion of an ad network which aggregates the advertisements and campaigns from the ad agencies and distributes them out to the publishers. So publishers is the term that harks back to the origins of advertising which is in print media. Newspapers, journals, magazines, sold space to advertisers. And so we still use the term publishers today. And then finally, the advertisement reaches the consumer who hopefully either chooses to make some purchase based on the ad. Today, we're really interested in two parts of this chain, the publishers and the ad network.

The publishers are you, the application developers, because you are the people with space that you can sell. And the ad network is iAd. Advertising has two basic moving parts. There are banners which are a finite amount of space that contain some kind of graphical called actions. When the user chooses to interact with the banner it leads them into what we call the ad action which is some kind of web experience usually.

There're also two common business models in advertising. The first is based on just viewing the banner. We call that an impression and advertisers will purchase some number of units of viewings. So they call that a cost-per-mille because they purchase these by the thousand. The other side is clicks. So they don't care about the user seen in the banner, they want to pay when the user interacts with the banner which they consider maybe more effective measure of how good the ad was.

So that cost-per-click method is the other approach. The iAd business model is a hybrid approach. It combines cost-per-click and cost-per-mille. And so you're paid, you, the application developer when the user views the banner in your app and also when they tap on the banner and the tap is weighted so it's a higher revenue rate.

So now, let's get in to the technical side of things. The iAd framework is an Objective-C framework. It's new in the iOS 4 and it makes it easy to embed ads in your application. It also promotes high-quality, rich media ads. We are going to talk about implementing this today. There are four sections. The first is just putting the ads in your app.

And, you know, maybe once you get that done you feel like your finished but there's a little bit to it. The next thing is what we call a banner view life cycle. So what that means really is whether the banner view that you put in your app at any given time has ad content in it or not. If you think about where ads come from, they're kind of come over network. So if you're not connected to the network, you might not get ads.

Finally, we're going to talk about supporting multiple interface orientations which is the autorotation part and how to respond to actions. So when the user does to choose to interact with the banner, what should your app do? Let's start off with putting ads in your app. So here's your app, you want ads. It's pretty simple really. You just make a little space and add a banner view, you're done.

The banner view is ADBannerView. It does all the heavy lifting for you. You added into a view hierarchy, maybe make one or two configurations to it and you're done. It's a core class in iAd framework. In fact, it's the only class that you'll see or interact with. It's just a view. Add it to your view hierarchy.

It does require to be part of a view controller's manage hierarchy. That has to do with how the ads present the action. We need to present this frontal view controller. So you can't just throw your banner view into an empty window. And the banner view manages the retrieval and the display of the advertisements which it gets from the iAd network.

When the user interacts with the banner view, the banner view takes care of how that interaction proceeds. Your App does very, very little. But what does it do? Well, it really comes down to placement. Placement is the most important decision you'll make when you use ADBannerView. We're balancing attention between providing a great user experience and effectively promoting the advertising materials.

And as we've seen over the years in the web space some people have, think-- have decided that it's effective for banners and ads to just kind of explode in your face and fly around the screen but that's not a great user experience. That is a very annoying user experience.

And as a result the user is really unlikely to want to interact with that, they're going to be hunting for that close button. Instead, you want to place the banners where they're visible, they're conspicuous, but they're out of the flow of what the application is supposed to do.

So we've determined there are two really great places to put banners, at the top of the screen or the bottom. That way your application maintains its integrity as a unit and the banners are very visible. If the user wants to interact with them, they have no trouble getting to it. It's not in such a great idea to put your banners into a scroll view or table view because they're going to fly by, the users going to have minimal visibility, and if they choose to interact it's a moving target.

And if it's moving, they might interact with it inadvertently and that's also not a good user experience. So to give you some insight into what this is like. We're going to take an existing application. SeismicXML is sample code in the developer reference library and we're going to modify it so that it uses ads. The banner view-- this application uses a UITableViewController.

And we have to make a few modifications to it, because we want the banner view to be a sibling of the table view not a subview of the table view. So that when we scroll in the table view, the banner view stays where it is. So we're going to take things apart a little bit, create a container view, add the table to that, and then add the banner at the bottom. So now, Juan Carlos is going to take you through a demo of doing exactly that so you can see just how a little work it takes to get ADBannerView up in your application.

As Wil said the application we're going to be modifying today is called SeismicXML. Let me show you what it looks like so we can talk about what we're going to be doing to it. As you can see, it consists of a table view with data that comes from an RSS feed that comes from the US Geological Survey.

Now, what we're going to be doing to this application is we're going to add a banner view to the bottom of the screen right here. It's important to note that the banner view will be a sibling to the table view. This way, if the user scrolls up or down the table view, the banner view will remain at the bottom. So let's get started.

The very first thing I want to do is I want to add the iAd framework to the project. Next, I'll go into interface builder and I'm going to add a general purpose view that acts as a container for both the existing banner-- the existing table view and the new banner view.

So I'll drag in the table view, make sure to resize it, and leave enough room for the banner view which in this case takes up 50 pixels in height. Then, I'll drag in the banner view. I want to make sure that I set the auto resize mask to let the banner view know that it's going to be placed at the bottom.

And now-- I mean, before I go into more details in the code, I want to talk about what I just did. Because I've changed the view hierarchy in such a way that the root view in this hierarchy is a UIView instead of a table view, I'll need to change my controller to reflect that change. So I'll change it into UIView controller.

But at this point, I've lost the reference to the table view. So we'll need to add a property to reestablish that connection. I'll go into the implementation file and make sure that I synthesize the property and that I release the table view. Now, I just have to go back into interface builder and reestablish these connections. So first, I want to make sure that the controller references the table view using the new property.

Also, I want to make sure that the controller references the container view using the original view outlet. At this point, if I run the application, you should see a banner view appear at the bottom of the screen. In this case, this is a fully functioning test ad. And that's really all there's to it. So just to summarize. What we did, is we added the iAd framework to the project. We modified our view hierarchy to leave room for the banner view and then we readjusted any other connections. It's that simple. Now, handing back off to Wil.

That's pretty great. You just add a view and boom you're making money. [Laughter] So you may have noticed when that banner view first appeared, it was an empty white frame. So that frame is something we provide that tells our users that this is an ad provided by the iAd network. And that's how we build trust with them because they realize that that frame means that if I tap on this, I'm not going to leave the application, I'll be right where I was when I'm done.

And you also notice that after slight delay, the ad appeared. So that leaps us into the banner view life cycle. What this means is we have to manage connectivity and inventory changes. That sounds kind of scary. Let's see what that means. So ADBannerView may not always have ad content in it. Content comes from the iAd server.

Network conditions as you all know are dynamic and the server inventory is also dynamic. It's constantly changing and things are targeted by the advertisers to reach certain audiences. So the banner view has two basic life cycle states. It's either loaded or not loaded. And let's look at a little diagram of what that might look like.

You start off, you create the banner view. There's no content. It makes a call to the server, loads its content. And then we cycle content automatically. At some point you, may run into a network or inventory error and then it later resolves itself and you start loading content again. And as we mentioned we cycle content. So you get that first ad and it's displayed and after a certain period of time we load a new ad for the user.

It's not something that you have control over. We just manage all that for your. So you really don't have to worry about the cycling. All you have to worry about is the state of loaded or not loaded. So the way we manage this is we implement the ADBannerViewDelegate protocol in one of your controller objects. Most likely, you'll implement it in the view controller that owns the banner view.

There are two callbacks that are associated with the content life cycle. The first is bannerViewDidLoadAd and you'll get that the first time it loads an ad and you'll get it every time we cycle a new ad in. And this just tells you that you've got ad content. On the other hand you'll get bannerViewdidFailToRecieveAdWithError and that means you don't have content. So network issues. These are mobile devices.

The user is always on the go. The network is changing. They may go into a subway tunnel, into a building with no connection, they may be still driving between cell phone areas and switch off one tower into the other and that interrupts the connection. Ads require a network connection so we have to get the ads from remote and then while the ad is running, it has to talk back to the server. So if there's a poor network connection or a change in network connection, the flow of ads may be interrupted.

The other issue is the inventory issue. So ads are targeted and the demographic or your application or filters you've set up to exclude things and I'll talk about that later. But these-- all these impact how the ads are targeted by the server and it's possible that at some times there will be an appropriate ad for you app.

So no ads. Errors? They're not really errors. Yes, we're using a callback mechanism that has the word error in it to communicate this message to you. But really, these are just part of normal operating conditions. It sort of like memory warnings on the iPhone and, you know, memory pressures are constantly changing and you have to be ready to release things and then load them backup on demand. It's just part of how things function on the device. So what matters is how you respond to them. And that's where you have control over things. So when availability changes, remember that space has value.

The way we arrived at this point in the first place is that somebody said, "Wow, I've got some space." And somebody else says, "Hey, I'd love to put some information on that space." Well, let's do a deal. So space has value. If you don't have ads, then you should put that space to good use. What does that mean? Well, there's a very simple pattern that we encourage you to adopt. Create your banner views offscreen.

Wait for the callback that says it's loaded and then animate it into position and then if you get another callback that says there's an error, just hide the banner view or move it offscreen again. Now, I say move it offscreen. Important to keep in mind that you don't want to take it out of its window.

Just adjust its frame so it's positioned somewhere that's not onscreen. If you take it out of the window completely, remove from super view, then we'll think that, "Oh, you're done with that. You don't' want to cycle ads anymore." Because we don't want to send ads down if they're not going to be visible.

So just move it offscreen but keep it in at super view. So, Juan Carlos is going to take SeismicXML again and he's going to update it so that it implements this pattern. So that when we first launched the app and there's no ad you won't see the space put to poor use.

OK. So now that we've covered the life cycle and the two delegate methods, I'm going to modify SeismicXML so that it only shows the banner view when the banner view has notified me that it's ready to go. So the first thing I'll do is I'll add the import-- I'll add an import for the iAd main header file and then a property to reference the banner view.

Again, I'll go into the implementation file and make sure that I synthesize the banner view and that I release it on the alloc. I also want to make sure that I reset the delegate to make sure that I don't have a crasher because the banner view is notifying my controller when it's released. So, I'll go back into interface builder and make the connections. So I'll make sure that the controller references the banner view using the new outlet and that the controller becomes the banner view's delegate.

OK. So now I'm ready to add the two delegate methods that Wil was just taking about. First, I'll tackle the delegate method that handles errors first. Now, for this, I'll add another method called moveBannerViewOffscreen. What I want this method to do is to calculate a frame so that it browses the table view to take up all the space available in the container.

Then, I'll make sure that I'll calculate a frame for the banner view so that it sits offscreen, in this case, below the table view. Finally, I want to set these two frames under respective views. And that should be all I need to do for this method. All I need to do now is call it from the delegate error callback.

Now this only takes me a part of way there. At this point, I'm hiding the banner view only when that the banner view has notified me that there's an error. I still want to make sure that I hide the banner view before it's ready to go. So I'll make another call to this method from viewDidLoadAd.

And now, I can look at the case in which the banner view has notified me that it's ready to go. So, I'll create another method called moveBannerViewOnscreen. In this case, I want to do the opposite thing. Here, I want to calculate a frame so that the banner view is able to sit at the bottom of the screen, taking into account the size of the container and the size of the banner view itself. Then, I'll calculate a frame for the table view to shrink it so that it leaves room for the banner view. Again, taking into account the size of the container and the size of the banner frame.

Finally, I want to set these two frames on their views, but this time I'm going to do it slightly differently. This time, I'm going to wrap those calls in an animation block so that the-- so that both views animate into their new frames smoothly and at the same time. And that should be all I have to do for this method. So now, I just have to call it-- oops, and launch the application. At this point, the banner view should slide up from the bottom of the screen when it's ready. That's all we need to do.

So just to recap, what we did is we registered our controller as a delegate of the banner view. Made sure that we also connected to the banner view and then we responded to the delegate methods accordingly so that we can hide the banner view when it's encountered an error and that we show it only when it's ready to go. Now, back to Wil.

OK so, we put the ad in the application and we've learned how to use this space wisely so that if there aren't actually ads visible, we use the space for some other purpose. But if they are visible, then we show them to the user. So to recap quickly about ADBannerViewDelegate, we can use the banner view delegate for managing the ad content state.

It tells you when you've got ad content and when you don't. And we recommend that you move your banner view on and off the screen accordingly. And as a note, before releasing the banner view, you should set its delegate to nil. This is a pattern you may be familiar with in your UIWebView.

And the reason for it is that the framework sometimes has to hold on to the banner view while it's off talking to the network. And if your controller object who is the delegate, releases it and then itself goes away. By the time we're finished with the network activity, we're still holding the banner view and we might try to access the delegate at that point because we don't know that it's gone away. So just remember, always set the banner view delegate to nil before you release it.

So now let's talk about multiple interface orientations. This is really a question of ad content sizes. So everything we've seen so far today has been in a portrait user interface. But there are several different ad sizes that are supportive. And ADBannerView manages the actual view size. The ad designers build their ad campaigns around fixed standard sizes. For portrait, we use 320 x 50. For landscape, we use 480 x 32. Both of these work out to be about 10 percent of the screen size.

So when you're using the banner view, the configuration you may need to do is tell it what kind of sizes it's going to be using. Now, if your UI is only portrait or only landscape, this is very simple. But if you're supporting both, it's still very simple. So the banner view needs to know all possible sizes that it would be asked to support because it's going to ask the ad server to provide it with content that can support both orientations. So that if the user changes the device, you can make a seamless transition from one content state to the other.

So we have a property called requiredContentSizeIdentifiers and this is a set. And we have some constants that name the specific sizes that are supported. And in this set, you just add all the ones that you want to support. So what you're seeing here is this has been set up for a UI that is going to support both portrait and landscape. If it were only portrait then it will just be a set with one object. And if it were only landscape, again, just a set with one object.

The other thing is the current content size. So you've told the banner view it might support both of these sizes but which one should it be supporting right now? That's the question. So we have a property called currentContentSizeIdentifier. And you'll set this to be one or the other of these constants.

It's worth noting that if you set the current content size to a size that isn't actually included in the required sizes, we'll throw an exception because you've told us to do something that's not possible. So set it up in front, configure the required sizes and then set the current content size. And when you autorotate, you'll change the currentContentSizeIdentifier to the new orientation.

So you see, when the application rotates, the main part of the app resizes and then the banner also resizes simultaneously. So view controller provides us very useful callback to its subclasses which is called willAutorotatetoInterphase. And what this does is this takes place inside the animation block which handles that entire transition. So anything you do, modifying your views, their properties, their sizes, their alpha, anything you do inside this becomes part of that larger animation block. So these animations will happen in sync.

So what we do is we just look at what the new orientation will be. We say, well, OK, we're going into landscape. We need to set the currentContentSizeIdentifier to landscape identifier or vice versa. So once again, we'll take up SeismicXML for the last time I promise and we'll see what it looks like to take this portrait-only app and not only support autorotation but support the ads with both interfaces.

All right so like Wil said, what we want to do first, is we want to set the requiredContentSizeIdentifiers over the banner view to a list that or a set that includes both sizes, in this case, 320 x 50 and 480 x 32. At this point, the banner view should be ready to go fetch over the network exclusively ads that match both of these sizes.

Now, what we want to do is we want to make sure that this application or this controller, accepts any rotations, any orientations. So I'll use this method here that you're probably already familiar with to return yes for any orientation changes. And then I'll use the method that Wil was mentioning earlier to make my decision based on the orientation in which we're moving. So in the case of portrait, I want to make sure that I set the banner view's currentContentSizeIdentifier to the constant that ends with 320 x 50.

Otherwise, I'll assume that the orientation is landscape. So I will set the currentContentSizeIdentifier to 480 x 32. At this time, I should be able to run the application and see the banner view resize itself when the orientation changes. Now, notice that there is a little space here between the table view and the banner view.

I am willing to bet that this is because I forgot something in interface builder, probably, the autoresize mask of the table view. And sure enough, here it is. The bottom margin of my table view is set to be a fixed bottom margin. So I am just going to make that into flexible so that the table view can resize freely once the orientation changes.

So let's try this again. This time, by changing the orientation, I should see the banner view and the table view be flushed next to each other in the right position. And that's all, really, there is to it. So just to summarize, the two things I need to do is I need to make sure that the banner view has its requiredContentSizeIdentifiers to a list that includes the values that match all the orientations that we are going to be displaying. And then finally, I want to respond to the orientation changes by setting the currentContentSizeIdentifiers of the banner view to a value that matches the orientation. And that's it. Back to you, Wil.

OK. So we've added the ads to your application, we have dealt with the content life cycles, so we're always maximizing our use of space, and now, we've learned how to support autorotation. So the final thing that we need to talk about from the technical side is how to respond to the actions. This is really a state management and resource consumption problem. Let's say problem, but it's really quite simple. So, in the ad action, this is where the user enters the rich media ad experience, they tap the banner, and they enter the iAd.

So if you've looked at the APIs during the developer seed, you may have noticed that it looks like there is some kind of actions that can be supported that would-- actually, would take you out of the application. The API allows that flexibility, but we're not using it at this point.

So right now, all the ads will still keep you in your application, and there will be the iAd-rich media experience. So let's recap what this do. They combine emotion and interactivity, and they don't leave the application. So when the user returns, they are right where they were when they started.

So your job is just to reduce activity. These ads are running in a separate process, so they're not polluting your memory space. But they may need resources if you are looking at a Nissan Video, or playing an interactive HTML5 game inside the ad, you're going to require some hardware resources, maybe some network resources.

You do not want your application to be in contention with the ad, because right now, the user is seeing the ad. The ad is on top, and while your app is still running, it does not need to be doing anything because the user is not looking at it. So you want to reduce your activity.

When the ad starts, you should pause any media you are displaying. And after all, the user's watching media in your app, they will probably prefer that you pause it so they can, it's-- you know, when they come back, they can pick up where they left off. If you are doing a big download, you should pause that as well because that is going to really hamper the ad's ability to get its resources from the network. And if you are doing graphic intensive work, you should pause that as well, because that is going to heat up the CPU and then the ad performance is not going to be as great either.

You are also going to save off some minimal state information. Now, this is not the kind of state information you save when you are being backgrounded, or if your apps is exiting, it is lightweight state. So it is just what you would need to return to some exact moment, given that your app will never stop running.

When the action completes, you resume all of the activities you paused. And based on the lightweight state that you saved, you will know exactly what to restore. So once again, we go back to ADBannerViewDelegate to give us some insight into this user interaction life cycle. When the user initiates the action, your delegate will get this callback that says, bannerViewActionShouldBegin. And then you will notice the second part of the method says, has this bit about willLeaveApplication. And that is going to be No, for now.

You app returns a Boolean from this method, because you do have the power to say, "No, I do not want to allow the action to begin." You should not do that, because you are saying, "No, don't give me money." OK. Sure, it is possible that your app may be doing some really mission critical thing at this instant that it cannot possibly allow the user to go into, and maybe it is OK just this once to say no, but I doubt it.

It is there, but I do not think you need it. OK. So inside this method we are going through, we are going to pause all of the activities we talked about. Now, the other side, when the user comes back, you will get this bannerViewActionDidFinish, and then you can resume. It is worth noting that all the UIApplication life cycle messages still take place.

So willResignActive, if the user hits the Lock button, or sets the device down and it sleeps, didResumeActive, willEnterBackground, etcetera. All of those life cycle messages are still delivered, both as notifications and to your application delegate. And that is where your heavier duty state saving should take place. In the bannerViewDelegateMethods, it is very lightweight. So now, we are going take a different application, and this is a media application. It is also from our sample code library. And Juan Carlos is going to show you how to handle the action appropriately.

OK. So this application, like Wil said, is an existing sample application called iPhone Multichannel Mixer Test. And I've modified it a little bit so that includes a banner ad in its interface. So let me show what it looks like. Now, for the purposes of this demo, we will just be looking at this Play Audio button.

And just to explain what it does, it plays an audio loop, toggles an audio loop on and off. Now, pretend that the user's interacting with this application, and they decide to click on this button. But immediately after that, they see the ad, and it catches their eye. And so, they decide to click on that.

So I do not know if you could hear it, but as I clicked on the ad, there was an audio loop playing. This is less than-- this a less-than-great user experience, especially if the ad had its own audio with a play. So I will make the changes on this application so that it handles this case more appropriately.

I have added all the delegate methods that we've covered so far, and I am going to be looking at the first one that-- of the ones that Wil just mentioned. In this case, what I want to do is I want to make sure that I store the state of the application so that I can pause-- so that I can resume when the ad comes back.

So in this case, this state really just consists of whether or not-- a Boolean that tells me whether or not the audio was playing before the ad loaded. Then I want to respond by pausing any activity that was going on. In this case, I just want to stop the audio. And finally, I want to return yes. I do not want to deny the user the request for interacting with the ad.

And so now, when the user dismisses the ad, my controller will receive the bannerViewActionDidFinish message. In this case, I want to do the opposite thing. The first thing I want to do is I want to look at the state of things before the banner ad loaded-- or I'm sorry-- before the ad actually went into full screen.

And then respond accordingly by restoring any activities that were going on at the time. In this case, I just want to start the audio playback again. So if I run the application now, I should be able to go through the same steps I did before. But this time, the audio should pause once I go into the ad.

I do not know if you could hear, but the audio is now paused. And if I click on the Dismiss button, the audio should resume. And that is really all we need to do in this case. So just to summarize, what we did is we made sure that implemented the two delegate methods, we stored the state before we went into the ad, and then paused any activity. The converse when the ad is dismissed, we want to look at the state and restore any activity that resulted in being paused before the ad loaded, and that's all there's to it. Back to you, Wil.

We had to work our imagination a little bit there to hear the audio, but I think you could see it from the state of the button, that things were changing as we went into the ad, and then being restored properly. So responding to actions, saving off some light state information, and pausing your activity, reducing your resource consumption while the ad is running, and then picking up where you left off when you return. So let's talk about everything we've looked at in using the iAd framework, putting ads in your app. You just add the ADBannerView to a view controller managed hierarchy.

Deal with the BannerView life cycle by implementing the ADBannerViewDelegate callbacks to know when you've loaded an ad, when you don't have an ad, and move your BannerView on or off screen appropriately, so you're getting the best view set of your screen. We support multiple interface orientations, we manage the size changes for you, you just tell us which current content size identifier to use, and configure your BannerView in advance so that it's set up to review requesting the right kind of ads. And finally, respond to actions by using the other ADBannerViewDelegate methods which tell you that the user has entered an action, and that the user has finished an action, and just pause your activity there, and resume it when they're done.

So let's switch our mental gears a little bit and get into the business side a little bit. Publishing with iAd. So we talked about publishers earlier because that's what you are, you're publishers. You have space that you're going to sell to the iAd network. It all starts in iTunes Connect. We've expanded the iTunes Connect portal to have a new iAd specific portal, and this is where you'll sign up to be a publisher, and then you'll manage each of your applications that's actually using ads.

Becoming a publisher has two steps, and they're very simple. The first is agreeing to the Paid App agreement, and many of you may have already done that. If you've only done free apps, the Paid App agreement is what sets us up to be able to cut you a check. I think that's important.

The other part is the iAd agreement, and this is specific to using iAd network, and it's just terms and conditions associated with displaying the ads in your application. And in the iTunes Connect, you'll be able to make both-- sign both of these agreements. And once you've done that, you're a publisher. And the next step is to configure your applications.

So, iTunes Connect is going to show you all of your current applications. Some of your apps may be live on the store, and some of them may be in production. And the interface lets you go in and see if they're seeing test ads, which is what ad-app center development will see, and lets you see what the revenue generation is like, and we'll talk about that a bit more.

Now, for any given application to be able to host adds, there's a little bit of configuration that you have to do upfront. You basically need to say, "I want this application to be eligible for ads." and then you get to tell us what the target audience is like.

We just need to know if that target audience for your app is under 17 or not, because there are certain ads that we want to make sure don't go to minors. The other thing you can do is what we call exclusions. So you might not want your closest competitors advertised in your app.

That might not be great. So we'll allow you to exclude advertisements based on keywords and URL's, and you can add as many of these as you want. But keep in mind, every exclusion you add will impact the inventory available to you. So you might not want your competitor's ads in your app, but you want to make sure you're still eligible for some ads. So don't get too crazy with the exclusions.

So summarizing, configuring applications tells about your target audience and set up any exclusions you want. And finally, the best part of all is monitoring the revenue. Sit back and watch the money roll in. So our interface will show you, and these are just some members that got mocked up for this. So don't necessarily rely on this. But our interface will allow you to see what kind of revenue you generate over the last seven days, even on a day-to-day basis, how hot the activity is in your application.

And we also provide you with a figure called the ECPM. So if you remember, CPM, that was the cost-per-mille, and that was if we were just going based on impressions, what you'd be making. And that's what the ECPM, it's the effective cost-per-mille. So if the business model were just a cost-per-mille model, ECPM is what you'd be making. And you'll notice that the revenue is higher than the ECPM, because we're paying you also for the clicks.

So everything we've covered today, integrating ads with iAd, it starts off with the iAd network which presents rich media, high quality ads and a great user experience. Using the iAd framework is easy. You just add the banners in, configure them, handle the action, and the content life cycles. And for the business side, we use iTunes Connect, which you're already familiar with. We just added one more piece to it. You go in, you register, configure your apps, and monitor the revenue. So for more information about iAd, you can contact Mark Malone.

He is our Integration Technologies Evangelist. And you can also go to our documentation. We've got some great documentation that talks about the framework, some conceptual overview, we have documentation for the publisher's side and the iTunes portal. And you can also go on our Developer Forums because our engineers are active on the forums, and we have a great community there for answering questions. So if you run into trouble, that can be your first stop.

We have some related sessions. Tomorrow, we're going to talk in two back-to-back sessions about creating the actual content of the ads themselves, and we provide a JavaScript framework called iAd JS which really makes it easy to create these incredibly interactive-rich ads. And there'll also be a session tomorrow, if you have questions or need to get more familiar with the iTunes Connect portal. That takes you through a lot of the aspects of using the portal. Thanks a lot everybody.