So now we have a LinkShare clicksynergy link with our custom signature attached. Right? If not then go back and read the last post on setting this up. All that we need to do in order to start tracking clicks is to start using our links in strategic places. Some ideas on tracking data is to use custom signatures for links off of your website, links used in press releases, links you send out on Twitter, and of course ‘Buy Now’ links from within a Lite or Free version of your app. It is the later case that I’ll be using for this discussion. The astute reader may recognize that this could be an opportunity to explore pay-per-click advertising with Google Adwords or the like since the clicks can be tracked all the way to a sale (needed to monitor profitability). However, with the low price of most apps in the AppStore I have my doubts as to the efficacy of this approach.

You could start using the clicksynergy links directly and be able to get the needed data. However, a slight improvement in the method can give you some real-time stats to feed your need to monitor app activity. Quite simply you can plug the clicksynergy link into a url shortening service, such as bit.ly, that allows you to track clicks on the link. For example, I have created a signature for clicks from a Lite version of my app, Mathemagics, and plugged the link into bit.ly. I then use this shortened URL within the app itself. Whenever a user clicks on the ‘Buy’ link within the app bit.ly picks up on that click and tracks it immediately. No need to wait for the LinkShare report in order to get an idea of click-through activity for the day.

There are a lot of url shortening services out there these days and bit.ly is only one of them. Be sure to use one that allows you to track stats and even better has an API that you can play with. It should be noted that using a url shortening service adds one extra level of redirection into the path between the user click and showing your app in the AppStore. It also will ensure that mobile Safari is launched and then redirect to the AppStore for links within an iPhone app. It’s not absolutely necessary to use such a service but being the data junkie that I am it allows me to keep a close watch on activity with my apps.

Ok, enough about setting all of this up. Let’s get at the data. After you’ve been tracking stats for a while it’s possible to download the raw click and sales data from the LinkShare website. Simply login to LinkShare, click the ‘Reports’ tab, Advanced Reports, and then select ‘Signature Orders’ from the report type drop list. Also, be sure to set your desired date range. Here’s an example of what the data looks like:

The ‘Member ID’ column is actually the signature used in your link (in this case ‘mathemagics_lite’). There are other interesting columns in the report such as the transaction date, commissions, and sales. It would be great if the SKU was actually useful but it appears to be mostly the same for every transaction with only a few variances. Ideally, it would be the actual SKU of the product purchased (remember those mostly useless SKU’s that you entered in when submitting your iPhone app?). This is probably a good place to mention the Achilles’ heal of this whole methodology. You pretty much have to take it on faith that a purchase at the price point of your app is in fact a purchase of your app. This gets even more complicated if you’ve been changing around the price of your app. Keep records and you should be able to use the transaction date to sort it out. At the time of this report Mathemagics Lite was on sale for $1.99. So, I know that those sales for $22.95, $.99 et al are not for my app. I still get commissions off of the sales (yea!) but they need to be removed when analyzing the data with respect to my app.

To get the data and actually use it take a look at the bottom of the table and find the ‘Download’ link. You can download to Excel, as data, or as MHTML. I’ve been downloading ‘as data’ which gives me a file with a .csv extension. But a csv extension is about all I get since the data is actually tab delimited. A quick pass through “tr ‘\t’ ‘,’” and all is right with the world since I like to import the data into Numbers. One final bit of peculiarity with LinkShare is that the download link only grabs the data from the visible page. If you want all of the data from your entire report then you’ll need to navigate to each page, download the data, and then merge it all together. Draconian, I know. But, at least it can be had.

The final missing piece of the metrics puzzle is the total number of clicks on the link. This can be had via the same LinkShare reporting tool by running the ‘Signature Activity’ report over the same time period. Simply find the intersection of your signature and the clicks column. If you used a url shortening service you may also be able to get this data there as well.

In the next and final article I’ll present the above numbers from Mathemagics Lite for the month of March 2009 and calculate the Conversion Rate for sales of the full version as well as a few other stats for the app.

]]> http://shanecrawford.org/2009/145/tracking-appstore-conversions-part-2/feed/ 5 http://shanecrawford.org/2009/119/tracking-appstore-conversions-part-1/ http://shanecrawford.org/2009/119/tracking-appstore-conversions-part-1/#comments Tue, 31 Mar 2009 21:52:21 +0000 shane http://shanecrawford.org/?p=119 As developers we tend to live in our code bases. However, in order to make a living, so we can write more code, it is important to focus at least some of our time on the dreaded marketing side of app publishing. To be honest, just using some of the terminology weirds me out a bit. But if you’re going to make a run at app development be it iPhone, Mac, or whatever you need to get wet so why not dive in feet first.

If you’re like me you like optimizing things. Tweaking the sales of your apps upward is no different and can be accomplished through effective marketing (and a little luck). The key word here is “effective”. Without data to support our efforts we’re really just shooting blindly in the dark. In this series of posts I’ll outline a way that we can get raw data on the effectiveness of our online and in-app marketing efforts for iPhone apps. The technique to be discussed was originally mentioned on MobileOrchard and if you want a good overview of the process I highly suggest you take a look at the article. I’ll be doing a deep dive into creating the necessary links, obtaining the data, and finally analyzing it. We’ll start with details on collecting data and end with some real numbers for one of my iPhone apps.

Our ultimate goal, at least for this article, is to determine how many application sales result from a particular marketing effort. On the web this is fairly easy to do with the help from our friends at Google. However, on the iPhone the sales channel is obscured by the iTunes AppStore. Once a user clicks into the AppStore their actions enter a black hole and we can no longer determine if they bought our app. Or so we thought. There is in fact a way to determine if a particular user click resulted in a sale of our application. This mechanism is found in the iTunes affiliate program available through LinkShare.

If you haven’t signed up for the iTunes affiliate program through LinkShare go do it now. Not only will it allow you to track your app marketing efforts but you’ll get an additional 5% on each and every sale that you refer as defined by their program. This not only includes your own app but any other app, song, movie, or whatever the user purchases after clicking your link. Even better you will continue to garner 5% from all purchases of that user for the next 120 days or until someone else refers them back to iTunes (these are known as ‘Return Days’ in LinkShare terminology).

So the extra 5% is great but how does that help our marketing data efforts? LinkShare provides an additional mechanism known as ‘Signatures’ that thankfully Apple supports. Signatures are the missing link that will allow us to see into the iTunes AppStore and determine whether a particular user click resulted in a purchase of our application. This linkage will then allow us to calculate a Conversion Rate from which we can begin to understand how effective our marketing effort is.

It should be noted at this point that there are a few gotchas and the system is not perfect. In fact, due to some reporting peculiarities with LinkShare signature reports the data can really only be taken in aggregate over a longer period of time (say a month or more). From the LinkShare help manual, “Most reports are based on the transaction date—the date the transaction actually occurs. The Signature Orders report, however, is based on the process date —the date that LinkShare receives and processes the transaction data sent by the advertiser“. As it works out it happens to be the Signature Orders report that we’re looking to use. So, since the data slides slightly based on the process date we can aggregate the data over a longer period of time and any temporal issues should be minimized. With that being said I have observed that the data from Apple appears to be processed within a day or so (as in all things YMMV).

Now, it’s finally time to set up a LinkShare signature so that we can start collecting some data. It’s really pretty easy. The first thing to do is create the standard LinkShare referral link. Basically, all that you need to do is grab an iTunes link for your product and then paste it into the LinkShare link builder.

The LinkShare link builder is available after logging into your account on the ‘Links’ tab. From this tab I have been using the ‘Deep Linking’ feature to just plug in my iTunes URL, fill in a signature and generate the clicksynergy URL. If you already have clicksynergy links created never fear. All you really need to do is add a ‘&u1=<your_custom_signature>’ to the end of the url. You can also modify the signature value whenever you want without ever going back into LinkShare since it will get picked up and tracked automatically. The value of the signature parameter can be whatever you want but I do suggest making it meaningful since this is all you’ll have in the report to figure out what link was clicked on.

Well, that’s it for now. Next up we’ll get into using our clicksynergy link and getting at the data the signatures give us. Then after we know how to collect and process the data we’ll look at analyzing it. At which point I’ll show real metrics as gathered from one of my iPhone apps.

In most cases a UIView is as large as the iPhone screen or smaller. But, in a few cases you may want a view that is larger than the normal iPhone screen size. Such a case might be when using the view within a UIScrollView which is a view that can manage subviews of arbitrary size. Interface Builder makes it exceedingly easy to configure views in the majority of cases but in special cases it falls flat and specifically in the case of the views size. The issue arises when a UIView is associated directly to a UIViewController.

As you can see from the screenshot the view labeled ‘SampleView’ is shown in IB as a subview to a view controller. Interface Builder seems to like to treat a UIViewController as some sort of pseudo view which can contain subviews. This is fine from a conceptual standpoint but this pseudo view has no controlls for size, location, etc. What ends up happening is that the views size is locked into a maximum size of 320 x 480. Again this is fine for most cases but falls short for those times when you want a view larger than is standard. What’s worse is that the Inspector for a UIView will allow you that change the width and height of a view attached in this way but in reality it is limited. You can see this when running your application. This behavior also makes it impossible to design anything but the top 480 pixels of your view in Interface Builder since it will only display a view design window that is fixed to what it thinks is the maximum size. In short attaching a view as a direct ’subview’ of a view controller in Interface Builder can lead to some major limitations.

The solution to all of this is actually quite simple. Simply do not add your view as a subview to the view controllers ‘pseudo view’. Instead add your view as a standalone view in your NIB.

As you can see from the second screenshot my view is not listed as a subview of the view controller but rather as a standalone view in its own right. You can then associate your custom view with the ‘view’ outlet of the controller. Now, your view can be resized to any size that you want, you can design the entire view in IB, and it will show up with the correct size when you run your app.

I was floored. For however brief a second you can see it in the latest iPhone commercial titled ‘Read‘ or the one that featues the sweet book app Classics (also from tap tap tap). The Babelingo icon shows up at the very begining of the commercial as the hand swipes through the second screen of iPhone apps.

Update

Babelingo also makes a brief cameo appearance in the commercials ‘Fix’ and ‘Check’.

“However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software.”

Since I have been mainly focusing on iPhone development for the past few months my posts of Cocoa related development have fallen off. Now that it appears that we can write about released portions of the iPhone SDK I hope to be writing more about Cocoa Touch and of course Cocoa. I truly hope that the lifting of the NDA will help to build the iPhone developer community along a path parallel to that of the Mac developer community. I think that a golden opportunity has been missed to create the same sort of Mac developer goodwill and attitude in the iPhone developer community because of the NDA. Hopefully, now that developers are free to discuss the platform a rich and vibrant developer community will form with the same dedication to helping each other out.

This year for the keynote I stepped into line outside of Moscone at 5:30 am. As fortune or fate would have it I was just barely ahead of the same place in line last year when I had arrived at around 7:00 am. So, maybe that could be used as some sort of judgment on the size and enthusiasm of the crowd this year.

Why get in line so early and would I do that again? Yep, I think I would. Just being able to get up somewhat close to the stage for the big event makes it that much more exciting. Even more than that though you have some fun and make some friends as the line compresses and expands exposing you to different groups of people. If none of that matters to you though you can show up an hour or less prior to the keynote and watch it from one of the overflow rooms.

Unfortunately I can’t talk about the content of any of the WWDC sessions that I attended. However, I will say that, for me at least, most of the content seemed to be either way too high level (getting started) or way too low level (audio API’s). In any case, good info is there to be had and I picked up a lot of tips and got exposure to parts of the platform that I haven’t touched yet. Amazingly at every WWDC I have attended the speakers are first rate. They’re developers, managers, evangelists, and the like and I must say they all do an excellent job at presenting.

I spent a lot more time this year taking advantage of the labs that were available. The labs were divided out into major platform components and each had a dedicated area of the conference floor. Within each lab experts on a particular topic would be scheduled to be on hand during a particular time slot and all that you needed to do, in most cases, was just drop by and talk with them. Bring questions, code, or design ideas and it’s a good bet that you can talk with the guy or gal who actually wrote the code for some part of the system that your interested in. That in itself is worth the price of the conference ticket in my opinion.

Outside of the conference sessions, labs, and lunchtime speakers there are still plenty of Apple and non-Apple sponsored events. As for non-Apple events this is where your networking comes into play. Keep your ear to the ground because every night after the normal WWDC hours the real party begins. This year I made it to the VMWare party at ‘The Thirsty Bear’, the Cocoa Heads meeting at the Apple store (awesome), the Austin area Cocoa Coders get together at the ‘W’ (hi Jim!), and the Big Nerd Ranch party. Each and everyone was a lot of fun and I didn’t even scratch the surface of the events that I could have attended.

On the Apple sponsored events side of the coin you’ve got the ADA awards (not to be missed), Stump the Experts (which I did miss this year in preference to sleep), and of course the Thursday night beer bash. Apple’s beer bash is the ‘must do’ event of the week. The food and drink selection is a couple of notches above what you’ve had all week and, prior to the entertainment coming on stage, is a decent networking opportunity. I mean when you’re standing shoulder to shoulder its kinda hard not to meet the person next to you. This year the entertainment blew me away. I’ve always been a Barenaked Ladies fan and guess who stepped on stage? Yep, BNL! I was right down front just about center stage and managed to take this shot with my iPhone:

… tons of fun and the Barenaked Ladies were a blast as they talked and jibed about Apple.

All in all it was a great conference. I’ll definitely be back next year. Now to sleep for a few days and dream of that new code I’ll be writing.

I’ll be at WWDC again this year and I can’t wait. It should be a blast assuming that the sold out conference doesn’t take away from the overall experience. June is going to be one hectic month. I’ll be flying from Mexico back to Austin and then hopping on a plane 3 hours later for WWDC. A late arrival in San Fran will be followed by an early rise to sit in line for check-in and wait for the SteveNote. I’m a bit bummed that I’ll have to miss some Sunday night get togethers but c’est la vie. Post WWDC holds more travel as well but it’ll be more of a local nature.

If you’re going to be at WWDC drop me a line and maybe we can hook up for a beer or three.

Update

The latest Mac Developer Roundtable covers some really great tips if you’re attending WWDC for the first time (or even if you’re a veteran). Marcus Zarra,  Bill Dudney, John Chaffee and of course Scotty all provide some excellent insight into WWDC from an attendee perspective. Highly recommended.

So, does Java on the iPhone make sense to anyone other than a pre-supernova Sun? Mmmm… well, I’m sure that the thousands of J2ME application developers out there would be pumping for it. There might also be a few users who rely on some mission critical application. Anyone else? None spring to mind, certainly not Apple.

A post-apocalyptic JVM enabled iPhone would soon become a litter ground for the multitude of J2ME apps. Some of these apps, such as the ones developed by Google, are indeed beneficial and well done. They are, however, far from the norm. With Apple’s tight control over the platform any J2ME apps would surely need to be provisioned directly from the iPhone AppStore which might help to eliminate some of the cruft. But, a free for all iPhone application bonanza is not likely to happen in this universe and that includes J2ME apps.

As a fledgling iPhone developer I must also say that a massive influx of J2ME apps to the iPhone would severly dampen my enthusiasm for the platform. All those J2ME apps would immediately have first mover advantage in a lot of important application categories – thus castrating many native iPhone applications. One of the draws to iPhone development is that it is a green field… there are thousands upon thousands of apps that need developing and for the uninitiated that spells “opportunity”.

Java on the iPhone proponents see the iPhone as another smart phone market for J2ME applications. However, the iPhone is much more than just a smart phone. It’s a completely new platform and more than any other device that has come before it is a powerful computer in your pocket. In order to make full use of all that the device offers only native code can deliver. Witness this quote from Eric Klein, vice president of Java marketing at Sun (source ars technica),

“We’re going to make sure that the JVM offers the Java applications as much access to the native functionality of the iPhone as possible,” he said.

Why would we even settle for anything less than complete access to the native iPhone functionality? Do some J2ME apps not need all that the iPhone has to offer? Well, then they aren’t iPhone apps and users will know the difference.

So, why throw my vote towards native Objective-C iPhone apps rather than building on my already deep Java knowledge and J2ME? It’s simple. Hands down the best user experience will be had by witting applications which make use of the unique and powerful native iPhone API’s. As a developer with a user experience mindset I only want the best and adding J2ME to the mix only waters it down.