Under the Bridge

Integrating Burstly

So we’ve been half-heartedly tracking ad network monetization options for a while, and you might have noticed that those folk over at Burstly (“Make More Money. Gauranteed.”) caught our attention repeatedly, particularly since we like their usage policy:

Burstly is 100% free to developers. There’s no charge to serve ads and we don’t take any cut of your earnings with any ad network using our Open SDK. It’s also free to use our powerful in-app purchase API. You can even sell direct to other developers in the built-in Marketplace. If you’d like to advertise your app directly to other developers in the Marketplace, there’s a 10% transaction fee. That’s it. No hidden costs or commitments of any kind.

… and today we’re finally getting around to the job of putting ads into one of our very first, extremely simple, contracts; and as they requested both cross-promotion house ads and filled ads, we do need some kind of management structure, and hey that’s a fine excuse to check out Burstly, and make walkthrough notes along the way for you, Dear Readers.

First off, baseline from the 2.0 SDK (yep, that old) last released build: Executable — 30,576 bytes; Application — 5,508,896 bytes. Bringing that rather trivial codebase up to a standard-architectured build with our current coding practices and the 4.0.2 SDK expands it to 52,688 bytes; the application, 5,527,993 bytes.

Alrighty then; let’s just jump in and see how good their quick start documentation is, shall we? Off to the downloads page, where we grab

Full Ad Serving iOS 4.0 SDK (iAd, AdMob, Mobclix, Google AdSense, Millennial Media, Greystripe, Smaato, Flurry Appcircle, and Burstly)

which is a 27 meg download expanding to … a 76.4 MB static library and a handful of header files. Woah. (And there’s a couple sample projects there too; or you could just go to Burstly-iPhone on github where they’re hosting all the goodies.)

First step: Add the SDK download to the project. Plop.

Next step: add a whole whack of frameworks. Plop, plop, plop.

On to Add an OAIAdManager to your view:

In your ViewController.h file, just import OAIAdManager.h and OAIAdManagerDelegateProtocol.h, declare an instance of OAIAdManager, and have your view controller conform to the OAIAdManagerDelegate protocol.

OK, there’s only three required protocol methods; but they need a “publisher id” and a “zone id” from the website. (The third is returning the host controller in the explanatorily named -viewControllerForModalPresentation). So off to find those IDs then.

Had we actually created an account before? Ah yes, we did. But not actually set it up or anything. So we add a new app, nothing complicated there (although you’ll need a custom URL if you want to use Burstly for in-app purchase); that gives us the “publisher id”. On to adding an “ad slot”, which we’ll make a standard size banner at the bottom, optimize for 100% fill, and leave all the various filtering options (alcohol, gambling, political views, adult content, …) checked for now; and that gives us our “zone id”. Good, that’s all the required setup apparently. Which took all of about ten minutes.

Next, they suggest that you automate ad refreshing every 20 seconds, which requires one more protocol method and a post-initialization call. And there’s two more protocol methods to control resizing behaviour of the ad view. Pasting in the provided samples appears fine for that; and … that’s it? Run it and … why yes indeed, that is all there is to it, ads are showing up! Just a little adjustment to the xib to move a couple buttons out of the way, and there’s our ad-displaying version all looking pretty.

OK, that was surprisingly easy to get off the ground, about a quarter the time to actually implement as it did to type out this post so far. Let’s see how big the distribution build is now … 4,946,384 bytes of executable, and 10,421,685 bytes overall. Well, since the wireless download cap is 20 MB these days, that’s not a worry in our case.

Now, the next question is, where are these 4 ads we see rotating here coming from, since we didn’t enter any credentials for any ad network? Ah, there we go, they were picked from people who signed up for Burstly’s PPI marketplace. If we want to add other ad sources, then we follow the instructions here. Note that the list of networks there is not exhaustive, a more complete parameter list can be found here.

The two networks we have credentials with (that we can remember offhand, anyways) are iAds and Flurry; so we create campaigns for those two, add them to our app’s ad slot, reading over the tiers and weight configuration stuff just enough to figure to put each in a different tier, run it, and …. why yes, there’s our Flurry ads popping up. Doesn’t want to serve us any iAds, though. Which could be because we just enabled them for this app in iTunes Connect, or it could be because we’re in Canada; we’ll email Burstly support and see how quickly they get back to us on that.

[EDIT: Burstly support was back to us at 9:14 AM the next morning, and the problem wasn't them apparently; our own ADBannerView returned "no qualified ads found for this request" instead of the expected test ads as well until ... wait for it ... we ran the app in the Simulator. And it continued serving up test ads as expected once we built for the device again. Black voodoo magic like that always makes us profoundly nervous; but hey at least whatever the deal was appears unrelated to using Burstly...]

Lastly for now, we’re to add some house ads to this as well; so we create one following the instructions, with a 320×50.png and a link to the App Store; add it at the highest tier, and … there it is, link works, ex-cellent.

So we’ve got a little reading up to do to sort out these tier and weight things to get the rotation working the way we want, and signing up for a few more networks would be a good idea no doubt; but hey, from what we’ve run through so far here, we do believe that we can give Burstly our pretty well unqualified stamp of approval for your advertising management needs … just as long as that five meg it adds to your executable isn’t a dealbreaker!

1
  • Matt

    Interesting to see someone else going through this as well. I also just installed the SDK yesterday and was surprised how easy it was. I can’t say the same, however, for the web interface, which feels slow and clunky. I often got server-side errors, too. I’m going to try 3rd party SDK integration next but I’m glad to see it gave you little problems.