MarkedUp SDK v1.2 for Windows Store and Windows Phone Apps: Lets You Help Your Users Manage Their Privacy

People of MarkedUp,

Today we released MarkedUp Analytics SDK for .NET v1.2, and it’s the first of many planned updates to our SDK and reporting dashboard coming over the next couple of months.

This update is for Windows Phone 8 and Windows Store developers, and it has a number of important fixes and updates – I’ll start with the minor ones:

  1. Full support for logging nested inner exceptions and stack traces in C#;
  2. Fixed a bug with capturing the app version # from the wrong place in Windows Phone;
  3. Fixed some performance issues on Windows Phone, related to reinitializing tombstoned apps;
  4. And various other minor bug fixes and improvements.

Allow Your Users to Take Control of Their Privacy with Analytics Opt-Out

Within a day or two of our initial launch a year ago, the first feature request submitted to MarkedUp’s UserVoice page was a feature to enable MarkedUp customers to allow their users to opt-out of analytics.

Well today, we’re marking that issue as resolved. With MarkedUp v1.2, you can now use the built-in AnalyticClient.OptOut method to allow users to opt-out of tracking. Users can also opt-back-in at a later date using the same method if you wish.


We’ve also added a new chart that allows you to see how many users opt-out of MarkedUp Analytics, which you can find under Users –> Tracking Opt-Outs.


With this tool, you can now give your users control over whether or not you collect any information on them.

How to Use Opt-Out

If you’ve installed MarkedUp into your Windows Store or Windows Phone application, you just need to call one method to opt-out a user.

Users are tracked by default, so if you want to enable them to opt out you should add an “Opt Out of Tracking” option to your settings page.

Here’s the code you need to call to opt a user out of MarkedUp Analytics tracking:

WinRT and Windows Phone (C# / XAML)

WinJS (HTML5/JavaScript)

That’s it! Click here for more detailed instructions.

Privacy is a growing concern among native app developers and app consumers, and we heard your requests and feedback and provided you with a dead simple tool for allowing your app’s users to control their privacy.

If you have questions, reach out to us at or reach out to us on Twitter (@MarkedUpMobi.) We’re happy to help!


Track In-App Purchase and Trial Conversion Revenue like Never Before: New Commercial Reporting from MarkedUp

We’ve been working feverishly over the past few weeks to provide MarkedUp customers a radically better experience for tracking sales and revenue than before, and we’re proud to stand behind our latest release: introducing commercial reporting version 2.

commercial-reporting navigation

In our last major update to MarkedUp customers, we released verison 1.0.5 of the MarkedUp Analytics SDK and made some significant updates to how we track sales and revenue inside the app.

We made those changes in order to provide a better experience to customers who need to track sales and revenue from in-app purchases and trial conversions; this update is to make sure that you get excellent reporting to match.

So without further adieu, let’s show you what’s under the hood!

Break out Sales by Country, OS Version, App Version, Device, and More!

We’ve added over 24 new reporting views to MarkedUp in this update, and the biggest ones are the drill-down reporting for sales and revenue.


These reports help you measure important things like:

  1. Where your most frequent customers are located geographically;
  2. If one release of your app is more / less effective at converting users into customers than another;
  3. If there’s a disparity between your total installs on Device X and total customers on that same device; and
  4. How different operating systems and OS versions change the purchasing habits of your users.

Per-Product Sales Reporting and Top Performing Products

If you’re going to offer one in-app purchase, you might as well offer two – right?

For developers who are selling multiple products via the Windows Store or any other marketplace, MarkedUp offers the ability to break out all of the reports mentioned in the previous update by each product individually.

Moreover, we’ve added a new top-level report, “Top Performing Products,” that allows you to view the performance of all of your app’s products at a glance.

Revenue Reporting in Multiple Currenciescurrency-selector

Most companies standardize on a single currency, but since the Windows Store allows you to price your application in up in over 60+ currencies, we felt it necessary to make sure that you can record your sales in as many currencies as your business supports.

In all of your Excel® reports, we break out revenue by currency so you’ll always be able to keep them separate during accounting.

Microsoft Excel® Export for all Commercial Reports


As it commonplace throughout the rest of MarkedUp’s reports, all of our new commercial reports ship with the ability to export directly to Microsoft Excel® from day one.

Now you if want to perform any of your own analysis on revenue and transaction figures MarkedUp collects, you can download our data directly into Excel format on-demand.

Something New: “Users who bought” Report – Dynamic Search through Your Sales Transactions

The most powerful feature of them all is something special – the “Users who bought” report. This allows you to dynamically search over every sales transaction your app has ever recorded using MarkedUp version 1.0 and later.

Words don’t do “Users who bought” justice – you have to see it in action:

MarkedUp Analytics–Users Who Bought Report

If you sell in-app purchases or trial conversions inside your apps and aren’t using these features, take advantage of them now!

How to Get Started with MarkedUp’s Commerce API

Here’s how you can get started with MarkedUp’s Commerce API:

  1. Watch our tutorial video, “Using Commercial Transactions to Track In-App Revenue” [4:02]
  2. Read the MarkedUp Commerce API Overview in our documentation.
  3. Read our tutorial, “Tracking In-App Purchases and Trial Conversion Using MarkedUp Analytics.”

And as always, if you have questions, reach out to us at or reach out to us on Twitter (@MarkedUpMobi.) We’re happy to help!



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 

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.


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!



WinRT and Windows Phone 8 Code-Sharing Pitfalls

One of the things Microsoft promised and touted highly prior to and during BUILD 2012 was that it would be possible to share reams of code between your Windows Store and Windows Phone 8 applications.

From MSDN’s “Windows Phone API Reference” here’s what Microsoft made available, taken directly from the article:


The Relationship between WinRT and Windows Phone 8 APIs

The diagram has three distinct areas and these are described as follows:

  1. The set of Windows Runtime API not supported on Windows Phone 8. The API surface area of Windows Runtime is very large, with over 11,000 members. We’ve adopted a subset for Windows Phone 8 that allows you to build compelling phone scenarios. Area 1 in the diagram above represents the APIs that are not available on Windows Phone 8.

  2. The set of Windows Runtime API adopted for Windows Phone 8. This is represented by area 2 in the above diagram and consists of approximately 2,800 members. For some types, we have not implemented certain members. For others we have added additional members to support phone-only features. In both cases, these differences are noted in the API reference documentation.

  3. We’ve added key APIs needed to build great apps for the phone. These are represented by area 3 in the diagram and total about 600 members. For example, we have brand-new APIs for speech synthesis and recognition, VOIP, and other features. Creating these as Windows Runtime style APIs means you can use them regardless of the programming language you use for your app.

Naturally there are portions of code that can’t be shared easily, such as device-specific / sensor capabilities and user interface.

However, Microsoft promised that a significant number of WinRT APIs would be made available on WP8 and for a long time touted that “copy and paste” portability would be achievable.

MarkedUp’s SDK technology doesn’t interact directly with the UI or sensors on either WinRT or Windows Phone 8, so the majority of the APIs we use are ones you’d expect to work with both platforms, such as:

  • File system and storage;
  • Serialization;
  • Networking;
  • Globalization;
  • the Windows Store APIs;
  • Licensing;
  • Async and multi-threading; and
  • Unit testing with MSTest.

Our experience in porting our code from WinRT (C#) to Windows Phone 8 (C#) was largely good, although we found some nasty pitfalls along that way. In light of BUILD 2013 and all of the new features coming to Windows Phone and Windows 8.1, we thought it would be a good time to share these.


System.Net.HttpClient – By far the biggest and most vociferous WinRT & WP8 compatibility issue echoed from the development community is the fact that System.Net.HttpClient, Microsoft’s modern HTTP client that is built from the group up to work with async, advanced media types, RESTful APIs, and so forth. HttpClient is a huge boon to our productivity in the course of working with WinRT.

For reasons that I am not privy to, Microsoft did not include HttpClient in the core framework for Windows Phone 8, so MarkedUp uses System.Net.WebRequest wraps it with the appropriate async and error-handling decorators.

One of the major pitfalls of WebRequest is that it throws an exception whenever you receive an HTTP code that isn’t in the 200 (“Success) category. Trying to handle these exceptions asynchronously complicates things considerably, but it can be done.

It should be noted that HttpClient for Windows Phone 8 is available as a separate NuGet package. We can’t use any third party dependencies in our SDK but you are certainly free to use these inside your apps.

System.Net.WebRequest APIs are different across .NET 4.5 / Windows Phone 8 and WinRT – One strategy for dealing with the lack of HttpClient availability on Windows Phone 8 is just to use System.Net.WebRequest everywhere, including WinRT. This is something we tested since standardizing on a single HTTP layer helps reduce our QA overhead.

Our experience was that while vanilla .NET 4.5 and Windows Phone 8 have 100% reuse and compatibility when it comes to WebRequest, this is not the case with WinRT.

For instance, WebRequest does not have any directly settable ContentLength or UserAgent properties in WinRT; WebRequest has a different interface altogether for forming HTTP request bodies in WinRT. Additionally, the System.Net.WebException enum implementation in WinRT is missing a number of options that make it difficult to perform error-handling consistently across platforms.

We ultimately determined that it was less expensive to maintain two different network stack implementations for Windows Phone and WinRT than to try to work around all of the incompatibilities and different behaviors with WebRequest in WinRT.

File System

Windows.Storage.Search is not fully implemented on Windows Phone 8 – For most WinRT developers, Windows.Storage.Search is probably used for one specific purpose inside any given app: determining whether or not a file exists.

Since there isn’t an equivalent to File.Exists in the Windows.Storage namespace, most developers (us included) have to resort to something like this:

One issue that we ran into early on in our QA for Windows Phone is that not all search options which use a Windows.Storage.Search.CommonFileQuery enumeration are implemented in Windows Phone 8. For instance, CommonFileQuery.OrderByName will throw a NotImplemented exception.

However, you can work around most of these issues by just using CommonFileQuery.DefaultQuery if the ordering of the files returned isn’t particularly important.


CurrentApp.LicenseInformation doesn’t actually tell you if your Windows Phone 8 app is running as a trial or not – WinRT developers rely on CurrentApp as the single source of truth for all things Windows Store and licensing on Windows 8, and the class is available on Windows Phone 8 and is what developers use for executing in-app purchases.

However, for reasons unknown, the data returned from CurrentApp.LicenseInformation doesn’t have the IsTrial flag set in accordance with the actual licensing status on Windows Phone. Instead, you have to use the legacy API from Windows Phone 7, new Microsoft.Phone.Marketplace.LicenseInformation().IsTrial(), to get that information.

In order to make things more tenable for our x-platform development with WP8 and WinRT, we wrapped CurrentApp into a class called CurrentAppProxy and have it call the appropriate WP8-specific method when inferring licensing information.


CurrentAppSimulator does not exist for Windows Phone 8, thus there’s no built-in way to test in-app purchases – We depend on CurrentAppSimulator when testing anything that touches a trial conversion or in-app purchases, so we were a little shocked when we discovered that it isn’t included in Windows Phone 8.

Microsoft subsequently shipped their own mock in-app purchase library for Windows Phone 8, but since we have a shared testbed between WinRT and WP8 and can’t use any third party dependencies anywhere in our SDK we ended up writing our own. We will likely open source it on Github eventually.

No ListingInformation.CurrentMarket – One of the really handy features of ListingInformation in WinRT is the ability for it to tell you the current marketplace of any given user right off the bat using ListingInformation.CurrentMarket; this is important from an analytics point of view and really important if you manage your own commerce engine and want to localize prices in different currencies.

In Windows Phone 8, this method throws a NotImplemented exception. So how do you look up this information on WP8? Thanks to some smarties at StackOverflow, it turns out that System.Globalization.RegionInfo.CurrentRegion can’t be changed by the end user and is the culture reported by the phone to the store for any in-app purchases.


RegionInfo uses different constructor arguments on WinRT and Windows Phone 8 – in WinRT, you can construct a new RegionInfo object by passing along the two-character ISO country code that you might receive from a marketplace method. This works great particularly when coupled with CurrentApp.

In Windows Phone 8, you’ll get an ArgumentException every time – in WP8 RegionInfo only accepts the culture name itself, i.e. “en-US,” as the constructor argument, not the region name.

GlobalizationPreferences.HomeGeographicRegion does not exist in Windows Phone 8
when try to establish the local time and culture for a user in WinRT, GlobalizationPreferences.HomeGeographicRegion makes this a breeze if you need to account for local time or any other globalization preference. This API does not exist in Windows Phone 8, but because a user can’t change their region settings you just just use RegionInfo.CurrentRegion.


DataContractJsonSerializer doesn’t actually respond to EmitTypeInformation flags – one of the lesser-used features of DataContractJsonSerializer is its ability to control whether or not it includes type information in its outbound JSON payloads via the EmitTypeInformation property; this feature is really useful if you’re sending data to an ASP.NET MVC service and want to disable type hints so the model binder doesn’t fail.

Unfortunately, in Windows Phone 8 they never implemented the control flow that responds to this flag, so you get type information always whether you want it or not. Ultimately, we had to parse out type information using a regular expression upon serialization in order to resolve this issue for Windows Phone 8.

We hope this has been information – let us know if you have any feedback in the comments!

How to Install and Run the Windows 8.1 Preview in Hyper-V

The big announcement from //BUILD 2013 is the pending arrival of Windows 8.1, aka “Windows Blue,” and Microsoft made Windows 8.1 available for download immediately following the //BUILD keynote on Wednesday.

Like many developers, the MarkedUp Analytics team is naturally excited to try new things; that being said – we also don’t like having to wipe a dev machine and re-image it in the event that a beta release of Windows isn’t compatible with tools we use for doing our jobs every day.

So, we use Hyper-V or VirtualBox and run Windows 8.1 in a VM until it’s released to market.

Here’s how to get Windows 8.1 running in Hyper-V:

1. Download the Windows 8.1 Preview ISO

Download any of the Windows 8.1 Preview ISO images here. Pick whichever one best suits your needs. I’m going to use the English 64-bit .ISO.

2. Open Hyper-V and create a new virtual machine

If you’re running Windows 8 already, Hyper-V comes built into the operating system. Once the Windows 8.1 preview ISO is finished downloading you’ll want to create a new VM.

step1 - new VM

We’ll name our VM “Windows 8.1 Preview” and use the default storage location.

step2 - name VM

Windows 8 needs at least 2GB of RAM on a 64-bit system; I’m going to give this VM 4GB since I plan on running Visual Studio and some other RAM-intensive software on it later.

step3 - allocate RAM to VM

For now we’re going to leave the VM’s network as “Not Connected” – we’ll create a Virtual Network Adapter for it later.

If you already have a Hyper-V virtual network adapter that can share Internet connectivity with the host machine, use it here. Otherwise we’ll add one later after the OS installation on the VM is complete.

step4 - set VM network to not connected

Windows 8 needs at least 20GB of disk space on a 64-bit system. I’m going to give this VM 40GB and I’m going to use a dynamically expanding disk.

Dynamically expanding disks will be slow initially, but it saves room on the host machine in the event that you don’t occupy the entire VHD volume immediately.

If speed is an issue, you can create a fixed-size disk up front.

step5 - set VHD creation options for VM

3. Install Windows 8.1 Preview from ISO

Now we’re going to use the Windows 8.1 Preview .ISO file we downloaded earlier to install the operating system while we finalize our VM.

stp6 - install OS via Windows 8.1 ISO

This option will have you complete the Windows 8.1 Preview installation the first time the VM boots, using the .ISO file you downloaded earlier as the bootable media.

With all of those steps complete, you should now see the “Windows 8.1 Preview” VM on your Hyper-V list:

step7 - verify that Windows 8.1 VM is available in Hyper-V

Select the Windows 8.1 Preview VM and start it, and you should see the first “Install Windows” screen after a few seconds:

step8 - start the Windows 8.1 VM and install the OS

Click next.

You’ll need to enter in a product key for Windows 8.1 Preview during the first part of the installation process.

The product key for Windows 8.1 Preview is NTTX3-RV7VB-T7X7F-WQYYY-9Y92F, according to Microsoft’s official Windows 8.1 Preview installation instructions.

step9 - enter product key for Windows 8.1 Preview

If you see the following message and it asks you to choose between an upgrade and a custom installation, Select “Custom: Install Windows only.”

step10 - select custom install for Windows 8.1 Preview

Install Windows 8.1 on the VHD that we created earlier.

step11 - install Windows 8.1 preview on VHD created earlier

Let the Windows 8.1 Preview installation run to completion. And after 30 minutes or so you should be able to create a local Windows account and log in.

step12 - verify Windows 8.1 installation

4. If you don’t have one already, create a Virtual Network Adapter for Windows 8.1

If you didn’t have a Virtual Network Adapter ready during step 2, we’ll create one now.

First, shut down your Windows 8.1 Preview VM and turn it off – we’re about to make some changes to it.

step13 - shut off Windows 8.1 VM

Open up the Hyper-V manager and go to “Virtual Switch Manager.”

step14 - go Virtual Switch Manager in Hyper-V

Select “New virtual network switch.” Give the switch a name and make it an External Network. If you have multiple physical network adapters (i.e. ethernet and WiFi), use whichever one you use most often. Check the “allow management operating system to share this network adapter” box.

step15 - create new Virtual Adapter in HyperV

Apply changes.

Go back to your VMs and right click on the “Windows 8.1 Preview” VM you created – select “Settings,” then select “Network Adapter.”

step16 - Windows 8.1 VM network adapter settings

Change the Virtual switch to the new switch you just created; mine is called “Magical Switch.”

step17 - set virtual switch on Windows 8.1 Preview VM

Apply changes. Before we try starting the VM, let’s make sure that our switch was set up correctly – I often have trouble getting Hyper-V’s network adapters to behave properly the first time around.

Go to Control Panel and then to View Network Connections. Right click on the new switch you just created and select Properties.

step18 - verify virtual switch properties

Only the following properties should be set:

  • Client for Microsoft Networks
  • QoS Packet Scheduler
  • File and Printer Sharing for Microsoft Networks
  • Microsoft LLDP Protocol Driver
  • Link-layer Topology Discovery Mapper I/O Driver
  • Link-layer Topology Discovery Responder
  • Internet Protocol Version 6 (TCP/IPv6) and
  • Internet Protocol Version 4 (TCP/IPv4)

You will likely need to reboot your host machine in order to get the Internet working again. Go ahead and do that now.

5. Start Windows 8.1 Preview; Profit

You now should be able to start your Windows 8.1 VM in Hyper-V and connect to the Internet.

Install complete

Please give this guide a try and let us know if you run into any trouble!

Available Now: MarkedUp Analytics for Windows Phone 8

MarkedUp Analytics now available for Windows Phone

Windows Phone 8 support has been a long-requested feature for MarkedUp and it we’re pleased to announce that as of today, June 19th, MarkedUp Analytics fully supports Windows Phone 8!

If you install the latest MarkedUp Analytics SDK for .NET from NuGet, it will automatically work in any Windows Phone 8 application.

Here are some things you need to know about the MarkedUp Analytics SDK for Windows Phone 8:

1. The MarkedUp SDK for Windows Phone is virtually identical to the WinRT SDK for C# / XAML – you can port all of your MarkedUp SDK calls from any XAML-based Windows Store application to a Windows Phone 8 application with no changes. See the updated MarkedUp SDK Reference for more details.

2. The SDK maintains a slim file size (~200kb) so you don’t need to worry about it affecting your app’s download size from the Windows Store.

3. The SDK automatically enables the app capabilities it needs to run during your NuGet installation, so you don’t have to do anything. See the Windows Phone 8 App Requirements for more details.

4. You can now add Windows Phone project types to your MarkedUp dashboard. Click here to add a Windows Phone 8 app to your dashboard right now.

And most of all…

It only takes 3 minutes to install MarkedUp into your Windows Phone app and see live data.

Don’t believe us? Watch our tutorial video below.

How to Install MarkedUp Analytics for Windows Phone 8 Apps


We’re thrilled to make our services available on Windows Phone 8, and we’re always striving to do an even better job serving the needs of app developers everywhere. So if you have any suggestions for what we can do better, please leave us a note on our UserVoice. Thanks!

Introduction to Parameterized Session Events

One of the most commonly requested features for MarkedUp has been the ability to support parameterized session events, and as of the release of MarkedUp Analytics SDK for .NET 1.0 this feature is now publicly available to our customers.

Parameterized session events help you group and categorize related user events that occur inside your applications; this gives you the ability to maintain a high-level view of how people are using your application while also allowing you to expose more details if needed.

For example: I have a Hacker News Windows Store application that I’ve been working on in my spare time and I want to be able to track how many articles people actually view when they use it.

So, I embedded a standard MK.SessionEvent call inside my WinJS application to track how many people viewed an article:

And this allows me to see the total number of times someone has viewed an article using my app:

Hacker News application with a simple, unparameterized event

But what if I want more information – what if I want to know which articles users are viewing? Parameterized session events can help us with that.

I’m going to modify the call to MK.SessionEvent and include a new parameter: “ArticleUrl.”

“ArticleUrl” is the name of my parameter, and the value of this is the URL of whatever article a user is viewing. In C# / XAML you can just pass in an IDictionary<string, string> object for all of your parameters and values, but in WinJS you need to use a Windows.Foundation.Collections.PropertySet collection.

Once I’ve run the app with this custom parameter included, I can drill down into the ViewArticle event and see a new parameter:

Hacker News app with an ArticleUrl parameter for the ViewArticle session event

And if I click on the “ArticleUrl” parameter, guess what we see next? A list of all of the URLs for each event!


With that simple change, our ViewArticle event becomes much more informative and valuable – we can even use the date picker to see which articles were most popular amongst our userbase during each month or week!

Advanced Example: Distinct Session Event Parameters

Let’s take our usage of parameterized session events a step further. One of the features of my Hacker News application is the ability for it cache articles to the local filesystem in order to conserve bandwidth. I’m considering extending this capability to enable the app to run entirely offline – so my question is: how often do people really look at cached articles?

Parameterized session events can help us answer this question.

I’m going to move my MK.SessionEvent call from viewItem.js and into my caching layer – that way I can tell if the article I am serving is cached or not. Here’s my code looks like for that:

I have to different methods that are called by my app when we need to view an article – one that checks if the content is cached and serves it if it is, and another that downloads the content from the Internet.

Whenever we serve the content from cache, I pass in a ps[“Cached”] = true parameter and a ps[“NotCached”] = true whenever we don’t.

So after running the app a few times, it looks like most users don’t view cached articles very often:

Hacker News WinJS app - cached vs. uncached articles

I’m doing it this way so I can see directly at the ViewArticle view how many articles are served from cache versus those who aren’t without having to drill down any further.

But the choice is yours – parameterized session events are designed to be flexible and allow you to use them however you wish.

Make sure you check out our tutorial on using parameterized events with MarkedUp Analytics, and please let us know if you have feedback!

MetroAppSite: Free, Open Source Metro-Style Website Templates for Your Windows Store Apps

Getting customers to notice and discover your Windows Store apps is hard, but you can reach users who aren’t inside the Windows Store using simple websites designed to promote your apps.

In addition, if your Windows Store app requires access to the Internet you are required by Windows Store policy to publish and link to a privacy policy hosted online (section 4.1.1.)

We decided to make life a little easier for Windows Store developers and built MetroAppSite – a fully responsive Metro-style website that uses Twitter Bootstrap and other standard frameworks to help developers promote their Windows Store apps.

And like most of our customers, we’re a .NET shop, so we built an ASP.NET MVC4 version of MetroAppSite too!


Here are some of the great features that you get with MetroAppSite:

Metro theming and branding

Give your promotional website the same Metro look-and-feel that your users experience when they download your app from the Windows Store.

We even include a Microsoft Surface screenshot carousel for you to use to show off your Windows Store app’s look-and-feel.


MetroAppSite uses BootMetro and Twitter Bootstrap to give Windows Store developers an easy-to-modify, brandable template they can use to their own ends.

Fully responsive and touch/mobile-friendly

MetroAppSite’s CSS and design is fully responsive and touch-optimized out of the box. It looks great in full-sized web browsers and on mobile devices too!

Integrates seamlessly with third party services like Google Analytics and UserVoice

Unfortunately there isn’t a MarkedUp Analytics for websites yet, but in the meantime we made it dead-simple to integrate MetroAppSite with Google Analytics so you can measure your pageviews and visitors.


Additionally, we added hooks to integrate UserVoice directly into your app’s site so you can collect feedback and support tickets from users easily and seamlessly. UserVoice is what we used for our customer support at MarkedUp and we’ve had a great experience with it!

Templated privacy policy in order to make it easy for you to satisfy Windows Store certification requirements

Writing privacy policies can be a pain, so we made it easy for you to generate a privacy policy for your app using You can paste these right into MetroAppSite and meet Windows Store certification requirements easily and thoroughly.

Demo Sites

We created some simple MetroAppSite deployments for you so can see what they look like in production:


MetroAppSite is licensed under the Apache 2.0 license and is free for you to use in commercial or non-commercial projects.


We happily accept pull requests via Github.

Cassandra, Hive, and Hadoop: How We Picked Our Analytics Stack

When we first made MarkedUp Analytics available on an invite-only basis to back in September we had no idea how quickly the service would be adopted. By the time we completely opened MarkedUp to the public in December, our business was going gangbusters.

But we ran into a massive problem by the end of November: it was clear that RavenDB, our chosen database while we were prototyping our service, wasn’t going to be able to keep growing with us.

So we had to find an alternative database and data analysis system, quickly!

The Nature of Analytic Data

The first place we started was by thinking about our data, now that we were moving out of the “validation” and into the “scaling” phase of our business.

Analytics is a weird business when it comes to read / write characteristics and data access patterns.

In most CRUD applications, mobile apps, and e-commerce software you tend to see read / write characteristics like this:

Read and Write characteristics in a traditional application

This isn’t a controversial opinion – it’s just a fact of how most networked applications work. Data is read far more often than it’s written.

That’s why all relational databases and most document databases are optimized to cache frequently read items into memory – because that’s how the data is used in the vast majority of use cases.

In analytics though, the relationship is inverted:


By the time a MarkedUp customer views a report on our dashboard, that data has been written to anywhere from 1,000 to 10,000,000 times since they viewed their report last. In analytics, data is written multiple orders of magnitude more frequently than it’s read.

So what implications does this have for our choice of database?

Database Criteria

Looking back to what went wrong with RavenDB, we determined that it was fundamentally flawed in the following ways:

  • Raven’s indexing system is very expensive on disk, which makes it difficult to scale vertically – even on SSDs Raven’s indexing system would keep indexes stale by as much as three or four days;
  • Raven’s map/reduce system requires re-aggregation once it’s written by our data collection API, which works great at low volumes but scales at an inverted ratio to data growth – the more people using us, the worse the performance gets for everyone;
  • Raven’s sharding system is really more of a hack at the client level which marries your network topology to your data, which is a really bad design choice – it literally appends the ID of your server to all document identifiers;
  • Raven’s sharding system actually makes read performance on indices orders of magnitude worse (has to hit every server in the cluster on every request to an index) and doesn’t alleviate any issues with writing to indexes – no benefit there;
  • Raven’s map/reduce pipeline was too simplistic, which stopped us from being able to do some more in-depth queries that we wanted; and
  • We had to figure out everything related to RavenDB on our own – we even had to write our own backup software and our own indexing-building tool for RavenDB; there’s very little in the way of a RavenDB ecosystem.

So based on all of this, we decided that our next database system needed to be capable of:

  1. Integrating with Hadoop and the Hadoop ecosystem, so we could get more powerful map/reduce capabilities;
  2. “Linear” hardware scale – make it easy for us to increase our service’s capacity with better / more hardware;
  3. Aggregate-on-write – eliminate the need to constantly iterate over our data set;
  4. Utilizing higher I/O – it’s difficult to get RavenDB to move any of its I/O to memory, hence why it’s so hard on disk;
  5. Fast setup time – need to be able to move quickly;
  6. Great ecosystem support – we don’t want to be the biggest company using whatever database we pick next.

The Candidates

Based on all of the above criteria, we narrowed down the field of contenders to the following:

  1. MongoDB
  2. Riak
  3. HBase
  4. Cassandra

Evaluation Process

The biggest factor to consider in our migration was time to deployment – how quickly could we move off of Raven and restore a high quality of service for our customers?

We tested this in two phases:

  1. Learning curve of the database – how long would it take us to set up an actual cluster and a basic test schema?
  2. Acceptance test – how quickly could we recreate a median-difficulty query on any of these systems?

So we did this in phases, as a team – first up was HBase.


HBase was highly recommended to us by some of our friends on the analytics team at Hulu, so this was first on our list. HBase has a lot of attractive features and satisfied most of our technical requirements, save the most important one – time to deployment.

The fundamental problem with HBase is that cluster setup is difficult, particularly if you don’t have much JVM experience (we didn’t.) It also has a single point of failure (edit: turns out this hasn’t been an issue since 0.9x,) is a memory hog, and has a lot of moving parts.

That being said, HBase is a workhorse – it’s capable of handling immensely large workloads. Ultimately we decided that it was overkill for us at this stage in our company and the setup overhead was too expensive. We’ll likely revisit HBase at some point in the future though.


Riak One of our advisors is a heavy Riak user, so we decided it was worth exploring. Riak, on the surface, is a very impressive database – it’s heinously easy to set up a cluster and the HTTP REST API made it possible for us to test it using only curl.

After getting an initial 4-node cluster setup and writing a couple of “hello world” applications, we decided that it was time to move onto phase 2: see how long it would take to port a real portion of our analytics engine over to Riak.

I decided to use Node.JS for this since there’s great node drivers for both Raven and Riak and it was frankly a lot less work than C#. I should point out that CorrugatedIron is a decent C# driver for Riak though.

So, it took me about 6 hours to write the script to migrate a decent-sized data set into Riak – just enough to simulate a real query for a single MarkedUp app.

Once we had the data stuffed into our Riak cluster I wrote a simple map/reduce query using JavaScript and ran it – took 90 seconds to run a basic count query. Yeesh. And this map/reduce query even used key filtering and all of the other m/r best practices for Riak.

Turns out that Map/Reduce performance with the JavaScript VM is atrocious and well-known in Riak.

So, I tried a query using the embedded Erlang console using only standard modules – 50 seconds.

Given the poor map/reduce performance and the fact that we’d all have to learn Erlang, Riak was out. Riak is a pretty impressive technology and it’s easy to set up, but not good for our use case as is.


mongodb I’ve used MongoDB in production before and had good experiences with it. Mongo’s collections / document system is nearly identical to RavenDB, which gave it a massive leg up in terms of migration speed.

On top of that, Mongo has well-supported integration with Hadoop and its own aggregation framework.

Things were looking good for Mongo – I was able to use Node.JS to replicate the same query I used to test Riak and used the aggregation framework to get identical results within 3 hours of starting.

However, the issue with MongoDB was that it required us to re-aggregate all of our data regularly and introduced a lot of operational complexity for us. At small scale, it worked great, but under a live load it would be very difficult to manage Mongo’s performance, especially when adding new features to our analytics engine.

We didn’t write Mongo off, but we decided to take a look at Cassandra first before we made our decision.


File:Cassandra logo.pngWe started studying Cassandra more closely when we were trying to determine if Basho had any future plans for Riak which included support for distributed counters.

Cassandra really impressed us from the get-go – it would require a lot more schema / data modeling than Riak or MongoDB, but its support for dynamic columns and distributed counters solved a major problem for us: being able to aggregate most statistics as they’re written, rather than aggregating them with map/reduce afterwards.

On top of that, Cassandra’s slice predicate system gave us a constant-time lookup speed for reading time-series data back into all of our charts.

But Cassandra didn’t have all of the answers – we still needed map/reduce for some queries (ones that can’t or shouldn’t be done with counters) and we also needed the ability to traverse the entire data set.

Enter DataStax Enterprise Edition – a professional Cassandra distribution which includes Hive, Hadoop, Solr, and OpsCenter for managing backups and cluster health. It eliminated a ton of setup overhead and complexity for us and dramatically shortened our timeline to going live.

Evaluating Long-Term Performance

Cassandra had MongoDB edged out on features, but we still needed to get a feel for Cassandra’s performance. eBay uses Cassandra for managing time-series data that is similar to ours (mobile device diagnostics) to the tune of 500 million events a day, so we were feeling optimistic.

Our performance assessment was a little unorthodox – after we had designed our schema for Cassandra we wrote a small C# driver using FluentCassandra and replayed a 100GB slice of our production data set (restored from backup on a new RavenDB XL4 EC2 machine with 16 cores, 64GB of RAM, and SSD storage) to the Cassandra cluster; this simulated four month’s worth of production data written to Cassandra in… a little under 24 hours.

We used DataStax OpsCenter to graph the CPU, Memory, I/O, and latency over all four of our writeable nodes over the entire migration. We set our write consistency to 1, which is what we use in production.

Here are some interesting benchmarks – all of our Cassandra servers are EC2 Large Ubuntu 12.04 LTS machines:

  1. During peak load, our cluster completed 422 write requests per second – all of these operations were large batch mutations with hundreds rows / columns at once. We weren’t bottlenecked by Cassandra though – we were bottlenecked by our read speed pulling data out RavenDB.
  2. Cassandra achieved a max CPU utilization of 5%, with an average utilization of less than 1%.
  3. The amount of RAM consumed remained pretty much constant regardless of load, which tells me that our memory requirements never exceeded the pre-allocated buffer on any individual node (although we’ve spiked it since during large Hive jobs.)
  4. Cassandra replicated the contents of our 100GB RavenDB data set 3 times (replication factor of 3 is the standard) and our schema denormalized it heavily – despite both of those factors (which should contribute to data growth) Cassandra actually compressed our data set down to a slim 30GB, which provided us with storage savings of nearly 1000%! This is due to the fact that RavenDB saves its data as tokenized JSON documents, whereas everything is as byte arrays in Cassandra (layman’s terms.)
  5. Maximum write latency for Cassandra was 70731µs per operation with an an average write latency of 731µs. Under normal loads the average write latency is around 200µs.

Our performance testing tools ran out of gas long before Cassandra did. Based on our ongoing monitoring of Cassandra we’ve observed that our cluster is operating at less than 2% capacity under our production load. We’ll see how that changes once we start driving up the amount of Hive queries we run on any given day.

We never bothered running this test with MongoDB – Cassandra already had a leg up feature-set wise and the performance improvements were so remarkably good that we just decided to move forward with a full migration shortly after reviewing the results.

Hive and Hadoop

The last major piece of our stack is our map/reduce engine, which is powered by Hive and Hadoop.

Hadoop is notoriously slow, but that’s ok. We don’t serve live queries with it – we batch data periodically and use Hive to re-insert it back into Cassandra.

Hive is our tool of choice for most queries, because it’s an abstraction that feels intuitive to our entire team (lots of SQL experience) and is easy to extend and test on the fly. We’ve found it easy to tune and it integrates well with the rest of DataStax Enterprise Edition.


It’s important to think carefully about your data and your technology choices, and sometimes it can be difficult to do that in a data vacuum. Cassandra, Hive, and Hadoop ended up being the right tools for us at this stage, but we only arrived at that conclusion after actually doing live acceptance tests and performance tests.

Your mileage may vary, but feel free to ask us questions in the comments!

Microsoft Surface Adoption Worldwide

We made MarkedUp Analytics privately available to some Windows 8 developers in September, and thus we’ve had a chance to watch the Windows 8 ecosystem grow since well prior to its official 10/26 launch.

markedup-microsoft-surfaceAs many of you may have read this past week, Windows 8 sold over 40,000,000 licenses in its first month since release. That’s huge!

However, what about the Surface RT tablet Microsoft released on the same day? How well has it sold since?

MarkedUp Analytics was installed into some of the biggest apps in the Windows Store a month prior to the launch of Microsoft Surface; that puts us in a good position to use our data to make some educated inferences as to how well the Surface has really fared in the device marketplace.

Surface and the Windows 8 OEM Landscape

Before we jump into the specifics of Microsoft Surface, let’s consider the Windows 8 OEM ecosystem.

Since 9/28, MarkedUp has observed 307 distinct PC device manufacturers in our global data set for Windows 8 apps.

OEMs like HP, Dell, and Samsung still have a significant presence in the Windows 8 market, and the majority of it from devices that have been upgraded from Windows 7 and XP.

These traditional PC manufacturers also had a small, but statistically significant head-start over Microsoft in terms of total market share, because developers and big enterprises have had early access to the full verison Windows 8 since 8/15.

Windows 8 Market Share by OEM

This chart represents total market share by OEM across all devices that have used an app with MarkedUp installed in it since 10/26 until 11/24/2012, spanning roughly one month since Windows 8 and Microsoft Surface officially launched.

According to our data set, Microsoft has only one device in market – the Surface RT tablet. Our data set showed that Microsoft had statistically 0.0% market share prior to 10/26*, the day Surface and Windows 8 officially went on sale.

Microsoft’s 7.77% market share on this chart is represented solely by the adoption of the Surface RT tablet, and making Microsoft the 4th most popular OEM among Windows 8 users currently.

This number is also reflected in our analysis across all Windows 8 device models, rather than manufacturers:

Microsoft Surface Total Adoption v11-24-2012

MarkedUp has observed 11,385 distinct Windows 8 device models as of 11/24, and most of them are upgraded Windows 7 / Windows XP devices.

Microsoft Surface is by far the single most-used Windows 8 device from this cornucopia of hardware, occupying roughly 7.76% of the market.

The next most-used device model is the Samsung Sens Series laptop, like the Series 9 ultrathin notebook, with 3.31% market share, less than half of what the Surface RT has.

So with all of this market share data in mind, what’s the adoption rate for Microsoft Surface thus far?

Microsoft Surface Adoption Rate

So how quickly has the Surface RT tablet been adopted worldwide?

Well, we don’t have the absolute numbers since MarkedUp doesn’t have 100% market penetration across every unique Windows 8 device (working on it!) but we do have more than enough data to draw some inferences about the rate as which Surface RT tablets are being adopted.

The following chart shows the cumulative growth of the Surface RT’s installation base:

Microsoft Surface Daily Adoption v11-24-2012

As we mention in the callout on this chart, we decided that the best way to plot the growth of the Surface was to create an index and plot all of the cumulative growth relative to the index.

We set the index value 1 to be equal to the number of Surface RT tablets we saw activated on 10/26, the day it first went on sale. The final value on this chart has an index value of 120 for 11/24/2012, 29 days after the Surface went on sale initially – meaning that there were 120 times as many Surfaces activated by 11/24 than there were on 10/26.

So if Microsoft sold 10,000 Surfaces on day 1, then by the rate of growth on this chart they will have sold at least 1,200,000 units by 11/24.

Remember, this chart shows active devices that are being used and have consumed apps from the Windows Store, not devices that have been sold. The numbers on MarkedUp’s charts are effectively a floor for sales given that devices are sold before they’re used.

Microsoft Surface Adoption by Country

So we’ve shown you how quickly Surface RT tablets are being activated, but what about where they’re being activated?

Microsoft Surface Usage by Country v11-30-2012

MarkedUp has observed active Surface RT activity from users in 70 countries on 6 continents thus far, so the Surface is appears to be making inroads on Microsoft’s promise of broad international distribution for Windows 8 and Windows Store app developers.

In the chart above we broke out the percentage of Surface RT distribution by country including the 10 largest markets; the subsequent 60 markets all trail off quickly.

The United States has an overwhelming 68.52% share of all Surface RT tablets activated thus far with the UK coming in at a distant second with 9.10% share.

Our numbers across all Windows 8 devices are slightly different, but the US and UK both have dominate leads in those figures too.

One factor that may skew MarkedUp’s numbers towards the English-speaking world is that many app publishers forgo full international distribution in the Windows Store due to the fact that many parts of the world, including China and countries that have tighter content restriction laws, lengthen the Windows Store approval process and can even cause the app to be rejected outright.

So on that note, we strongly suspect that China in particular is under-represented on this chart given that it’s a massive market, but one that is more difficult for many app publishers to reach due to content restrictions.


Based on the data above, here is what we conclude:

  • The Microsoft Surface is the most heavily used ARM device in market for Windows 8 by a wide margin thus far and it is the single most-used device overall for Windows 8;
  • Surface’s growth appears to be strong, but it’s difficult to extrapolate the absolute number of units have been sold without knowing what the total day 1 sales were;
  • Surface RT is being adopted in primarily English-speaking countries, but has broad international reach; and
  • The majority of devices in market for Windows 8 are upgrades from previous versions of Windows, not new devices that came with Windows 8 installed; we’ll see how this changes as we collect more data from the Holiday season. The fact that the Samsung Sens Series made a strong appearance on our device model breakout shows signs of a growing ecosystem of net new Windows 8 machines from non-Microsoft OEMs.

Thanks for reading! If you’re a Windows 8 developer and would like access to the beta of MarkedUp Analytics for Windows 8, click here!


Here are some other interesting statistics from our OEM data set:

  • The remaining 24.48% OEM market share not shown on the OEM chart represents 296 long-tail, smaller OEMs including VMWare virtual machines and a number of motherboard manufacturers used in home-made PCs.
  • There are three different device architectures that Windows 8 supports: ARM, x86, and x64. Surface is the only major ARM device in market thus far, although there are more ARM (RT) tablets on the way. In our public Windows 8 launch data set, we’ve observed the following trend consistently since the Windows 8 launch on 10/26:
    1. x64, 64-bit Intel hardware, is used by roughly 70% of the daily active usersfor the entire Windows 8 ecosystem every day;
    2. x86, 32-bit Intel hardware, is used by roughly 20%; and
    3. ARM, the new architecture for lightweight tablets like the Surface, is used by the remaining 10% of daily active users.

*MarkedUp observed some Microsoft Surface RT devices appear as early as 10/18 in our data set, but not enough to be statistically significant. We suspect that they were preview devices given to select app partners, press, and others with early access.