And Now for Something Totally Different… Real-time, In-app Marketing Automation Powered by MarkedUp Analytics

When we first started MarkedUp, we did it with the goal of making it easier for software publishers to focus on making great products, rather than worrying about how to market and sell their wares.

Our long-term goal is to automate as much of the sales and marketing process for online products as possible, regardless of the operating system or software platform.

So today we’re taking our first step in that direction by introducing a brand new service built on top of MarkedUp Analytics: MarkedUp In-App Marketing Automation.

MarkedUp In-app Marketing allows app developers to improve user retention, time spent in app, conversion, and revenue through targeted campaigns of push notifications that are delivered instantly to end-users based on their behavior inside the app.


Once you’ve installed MarkedUp into your app, you never need to update your application again in order to create new campaigns, new messages, or target new groups of users – you can do all of this on-the-fly from your MarkedUp dashboard.

In-app Marketing?

Even if you’ve never heard the term before, in-app marketing becomes part of your life the moment you release a piece of software to the public, whether it’s in the form of trying to get people to pay for a licensed version, write a review in the app store, invite their friends to your service, and so forth.

In-app marketing is how you use the features and design of your software itself to achieve these business outcomes, and with MarkedUp In-app Marketing we’ve just given you a powerful new suite of tools that make it really easy to test, improve, and create new in-app marketing tactics specific to your application on the fly.

Here’s how MarkedUp In-app Marketing works in relation to our other services and your app:

How MarkedUp In-app Marketing Works

You deploy the MarkedUp SDK along with your app, start sending session events, and then create campaigns which are delivered directly to end-users via push notification.

What’s revolutionary about this idea is the integration between MarkedUp Analytics and In-app Marketing. The same session events, navigation events, and demographic data that MarkedUp Analytics collects is what you use to target your campaigns to specific groups of users.

In fact, you should really just see how easy it is to create a MarkedUp In-app Marketing campaign.

Real World Use Cases

Here are some ideal use case where MarkedUp In-app Marketing can help app developers of any shape or size:

  1. Re-engage users who’ve stopped using your application;
  2. Help new users get more familiar with your application so they become lifelong users;
  3. Drive app store ratings, reviews, and social recommendations;
  4. Promote other titles, updates, or new features;
  5. And drive sales or upgrades with targeted offers.

All of these use-cases revolve around the idea of targeting users based on their actual behavior inside your app, which is obnoxiously difficult to do even with platforms like MixPanel and Urban Airship.

MarkedUp In-app Marketing is the first service that makes this type of targeting mind-numbingly easy, using our session events API and other data we already collect for each user.


Want to see what MarkedUp In-app Marketing looks like, end-to-end with a live desktop application? You’ve got it. Check out the video below – it’ll take less than five minutes.

Want to give MarkedUp In-app Marketing a try? Sign up or request a demo!

MarkedUp In-app Marketing is currently only available for Windows Desktop applications. If you’re interested trying In-app Marketing for your Windows Store or Windows Phone application, sign up here.

Azure Mobile Services: For Those Who Just Want to Code

If you follow Azure news on the web you might have noticed a new Azure service being offered in preview form called Mobile Services.

In this blog post we’ll be doing a high level overview of what Azure Mobile Services is and what it gives you. In subsequent posts we’ll dive deeper into how to get your hands dirty and actually use the thing.

With this initial preview the Windows 8 app development scenario has been enabled. We’re likely to see other platforms such as iOS and Windows Phone (my personal favorite) come on board as the Azure mobile team develops the new service.

Why should I Care?

The idea behind mobile services is to provide is quick and easy way to bootstrap client app development by providing a supporting backend. If you want to write client apps and don’t want write all of backend web service logic yourself from scratch then you should take look at mobile services.

So here’s what we get out of the box mobile services:

  • Data storage
  • Authentication
  • Push notification

Like any other Azure service you also get a nice dashboard that shows a graph of your mobile service activity. In this case you’re able to see how the number of API calls, CPU time and data going out that service has made over time.

Data Storage

The data service is particularly interesting as it’s backed by Azure SQL Server and uses the JSON version of the OData protocol to communicate on the wire. One of the more interesting features of the data service is dynamic schema support which automatically updates the tables that backs the model as it changes. This makes it extremely easy to get up and running quickly as you no longer have to setup a database schema ahead of time, you can just let the service take care of creating the columns and choosing the appropriate data types in SQL server. Note that before you go into production you should turn off dynamic schema support to ensure that the schema can’t be changed outside of development.

The notion of dynamic schemas should by familiar to those who play with NoSQL document databases such as Mongo and RavenDB. The development experience is also very similar to that of entity framework code first if you ever used that before.

The C# primitives that mobile services is able to map out of the box include the following:

  • Integer types (int, long, etc.)
  • Floating points (double, decimal)
  • String
  • DateTime and DateTimeOffset

For any other data type like TimeSpan or a custom type you will need to convert to string or provide a client side converter that implements IDataMemberJsonConverter and handles the JSON serialization for that type to simple JSON types.


One really nice thing about the mobile service is its client authentication support. To set it up all you need to do is register the web service with Windows Live, drop in your client id and secret with the mobile service and call a few methods on the client app and hey presto you’ve got authenticated calls going though.

The authentication service in mobile services is backed using Microsoft Accounts or Windows Live accounts if you haven’t got the branding memo yet. In order to make use of authentication in the client app you will also need the Windows Live Connect SDK. The Live SDK is responsible for displaying the sign in UI and eventually giving you an authentication token which you in turn hand over to mobile services client so it can perform authenticated requests to the backend. The code for this is actually simpler than it sounds.

And that’s all the code it takes to authenticate with our mobile service backend on Azure.

Push Notification

Last but not least we have push notification support which helps us to do push notifications back to our mobile client. The way push notifications work in the mobile services preview today is that they are created using server side scripts that are authored by the developer in the Azure mobile service portal. These scripts are written in JavaScript which get executed on the server when create, read, update and delete (CRUD) operations occur on data in the mobile service.

These scripts are responsible for creating push notifications will comprise the core of your server backend logic as well. They are responsible not only for creating push notifications but for validating and modifying in coming requests and performing authorization logic based on the incoming authenticated identity.

Under the covers, these scripts are actually being executed by node.js, Azure mobile services exposes a small subset of node modules that can be used by the scripts to do their work. We’ll go into more details in another blog post on how to use these scripts and what you can do with them. This is a pretty big topic in and over itself and a simple blub wouldn’t do the topic justice.

Anyways, now that we know where push notifications get created on the server we need to know the how. In order to leverage push notifications on the server the client app is responsible for obtaining the push notification channel URL from the PushNotificationChannelManager from within their app and uploading it to the service. Typically this gets saved as property on the model that you use to save data to mobile service.

The code for this would look something like this:

Once the notification channel is saved to the mobile service the server side scripts will then be able to use that push notification channel url to send push requests back to our app.

Hopefully this post gave you a good overview of how Azure mobile services work. In future blog posts I’ll be doing some deep dives on using specific pieces of the Azure mobile services like scripts, push notifications and the data service.