Simplifying the MarkedUp SDK

Earlier this evening we released MarkedUp 1.0.5 into the wild, and this SDK includes some major changes – namely, we removed about 80% of the public methods from our SDK and completely redid the entire commerce system. You can read the full MarkedUp v1.0.5 release notes here.

I wanted to share with our users why we made the changes we made and why we ultimately think that these changes will improve your experience using our analytics services.

The Commerce APIs

Not to tip our hand here, but we’re not too far away from shipping a comprehensive set of reporting features and improvements aimed at helping native app developers better understand where their sales and revenue are come from and who their target customers really are.

So naturally, making sure that our SDK’s commercial features are in tip-top shape was a huge concern when we started this development sprint.

We design all of our products to be as automated as possible in order to provide developers who depend on our services with the best experience possible. With that in mind, here’s how we designed our original commerce APIs:

  1. Accept a ProductId (official unique identifier used to track an in-app purchase or paid version of an app on the Windows Store) and a human-readable product name for each MarkedUp.InAppPurchase[Complete or any other commerce method] and MarkedUp.TrialConversion[Complete et al];
  2. Talk directly to CurrentApp or equivalent API and load the pricing data directly from the Windows Store for any given user making a purchase, including current market and currency;
  3. Cache Windows Store values locally to avoid repeat lookups;
  4. Post successful transactions to MarkedUp’s Commerce system using data retrieved from Windows Store.

With the earliest versions of our SDK (v0.6.7 and earlier) we went to market with this method, but strongly suspected that there were some issues with this methodology. Given that we can’t test CurrentApp without running inside a live app that actually has in-app purchases, it was difficult for us to get a feel for what was going on inside our own SDK under the circumstances.

So beginning in SDK 1.0, the MarkedUp Analytics SDK created an error on your log browser every time it failed to retrieve pricing information from the Windows Store. And sure enough: we’ve had a steady ticket volume from customers who’ve seen those errors.

The root cause: for whatever reason, the Windows Store price-lookup APIs have an extremely poor success rate – over half our calls to look up the price of an item fail! We’re not sure why, but that’s not our problem. Making sure our customers can successfully report on their sales is what we care about.

The “right” way to do it.

So, we introduced manual, but extremely reliable methods for recording trial conversion and in-app purchase sales in the v1.0.4 version of the MarkedUp SDK and had a dozen or so customers deploy it in their live applications, and we were met with tremendous success.

Here’s what the updated commerce methods look like in v1.0.4 and v1.0.5:

//All of this data can be mapped from a ProductListing via the Windows.ApplicationModel.Store namespace 
var iap = new MarkedUp.InAppPurchase() 
{ 
    ProductId = "SampleIAP1", 
    ProductName = "Sample In-App Purchase", 
    CurrentMarket = RegionInfo.CurrentRegion.TwoLetterISORegionName, 
    CommerceEngine = "Windows Store", //or a third-party engine, like PayPal
    Currency = RegionInfo.CurrentRegion.ISOCurrencySymbol, 
    Price = 2.59 
};
MarkedUp.AnalyticClient.InAppPurchaseComplete(iap);

Pretty straightforward – all of the information needed to populate a MarkedUp.InAppPurchase or MarkedUp.TrialConversion object can be derived directly from the Windows Store, or you can populate it yourself with your own values. We may even open-source some extension methods to populate these objects from ProductListing and ListingInformation objects.

MarkedUp no longer cares if the in-app purchase or trial conversion exists on the Windows Store or not – and that’s a feature; we want to be able to support commerce that happens outside the Windows Store and this gives us the flexibility to do both.

Say “goodbye” to [TC|IAP]Cancelled, Selected, Shown, and Dismissed, methods.

We originally created the InAppPurchaseShown, Dismissed, Selected, and Cancelled methods as a way to help developers set up simple conversion funnels for their in-app purchase and trial conversion sales efforts.

While we haven’t launched conversion funnels yet, we had a number of customers asking us about where they could see data for these methods and whether or not they were necessary for tracking in-app purchase revenue.

We decided to gut these methods from the SDK entirely, as of v1.0.5, and they will not be coming back for the following two reasons:

  1. Session events are a much better tool for tracking conversion funnels and in-app behavior than a dorky built-in event and
  2. It’s simpler to use and makes it obvious to new MarkedUp users how to record an in-app purchase or trial conversion.

The Session Event APIs

As of today, all of the input form and search + share charm events have been removed from MarkedUp. We strongly recommend using session events to track these types of events; they’re the right tool for the job.

So why’d we remove these? Because frankly, they added a lot of bloat and things to dig through while using our SDK on any platform – and the search + share charm functionality was extremely specific to Windows 8 in particular.

Closing

MarkedUp is ultimately going to support every native platform, and one of the things that consistently attracts great reviews and testimonials from our users is the simplicity of our products and services. Simplifying the SDK was part of the natural order of things, and it will make it easier for us to add support for iOS and Android in the near future.

As always, please let us know if you have any questions!

Best,

-Aaron

×

Comments are closed.