How To Track App Install Conversions for Facebook Ads

We started experimenting with Facebook Ads for some of our apps, including Lilly Sleep. But how do we know if the ad actually leads to a purchase?

Facebook has a really good how-to to get this done.

The how-to describes a simple 2-step process:

  1. Add the Facebook iOS SDK to your Xcode project and add a few lines of code
  2. Create a Facebook app to associate with you iOS app and fill out some forms.

We are submitting this new code together with an upgrade for iOS7 in the near future. I will write a new post about how to use this feature to optimize your Facebook Ad for app install conversion, once we have it running and collecting data.

#lillyLeaf stats in cohorts 1.expo-01

Payment services available in Norway

Is your work any good? You know when your customers pay you.
Is your work any good? You know when your customers pay you.

This is a summary of payment services presented or mentioned at The Mobile Meetup Oslo on Wednesday 24th of September.

In general, there are two types of payments services:

  1. The ones with cool APIs that let developers make seemless integrations. The customer stays on your page, but the transaction-information and other sensitive data is handled by the payment service.
  2. The ones that redirects the customer to their own page to complete the payment and then send them back to you when the payment is complete (or canceled or rejected).

Continue reading Payment services available in Norway Payment services available in Norway

async.js: Elegant Asynchronicity

In our #lillygram application cloud backend we have a bunch of async tasks that need to happen in strict sequence. This blogpost explain why we chose the async.js Node.js-library for our asynchronous tasks.

With a few thousand lines of JavaScript currently on our hands in the Lilly Apps enterprise, we are ready to take a step back and learn from our mistakes. JavaScript allows you to write working code extremely fast, but if you are not aware of the lurking dangers, your code may soon turn on you like a black widow. One challenge we faced was maintaining readable and stable code with a lot of asynchronous tasks.

A common pitfall, which we also fell into, is to nest function calls into callbacks, and let the inner-most callback be responsible for what to do once all calls have completed. In an attempt to keep things tidy we tried to declare and assign all callbacks to named variables before nesting the calls. This helps a little bit, but still leaves the code messy and unintuitive. But it starts to feel a little irky when we decide to change the order of calls. Should we also change the order of the declarations?

In the end, it seems that the best way to go is to throw a reference to each function into a list, iterate over this list, and call each in turn. In fact, that’s what async.js, does with its ‘series‘ method.

Intermediate handling in async.js is left to the individual function. In order to maintain flexibility, we persist the outcome of each function within the scope the async tasks, allowing functions down the chain to access the data it needs.

Here’s a highly simplified example implementation of async.js

 [CodePen height=475 show=js href=FguLr user=testower ]

* { Box-sizing: Border-box } FTW

The css box model has been a pain in the ass for me when working on the layout of #lillygram-letters. I have never liked it, but trying to make a print layout I was going crazy.

So i got very exited when I came over this article by Paul Irish: * { Box-sizing: Border-box } FTW. With box-sizing: border-box, padding and border no longer ads to the width and that just feels right!