live from China::Hong Kong S.A.R. (中国::香港特別行政區)

Building a Company Targeting Consumers versus Targeting Businesses – From an Online / Social Media Perspective

2012-03-28, on 13:56 | In work | No Comments | Dieser Artikel in Deutsch

A couple of years ago when we started building mobile apps for BlackBerry® smartphones the majority of BlackBerry® users were business people. They used their devices because they got them from their employer. The biggest BlackBerry® app buyer group back then were businesses who wanted to improve their business processes and bring more functionality to mobile. Obviously, we could have gone the way of building applications and services for those companies. As we weren’t the best B2B sales people, we were in not in the best physical location (Kunming, PRC) to meet up with business decision makers and we couldn’t be bothered to nurture business relations and attend ‘networking events’; we chose the path of targeting consumers directly. In a sense, it’s more fun anyway.

By targeting consumers we have to focus on moving at a faster pace. We need to bring updates of products very frequently, we need to publish new products often and we have to hit the sweet spot of what people really want, and so on. On top of that we have to establish a proper relationship with our users. This includes multiple communication channels like email, direct instant messaging, Twitter, Facebook, etc. Since the launch of S4BB’s Facebook page back in October 2011, we could grow our fan base to over 120,000 fans in less than 6 months. Most recently, we are pushing this a bit more and are seeing tremendous interest. To our marketing interns: Great job so far!

Building a huge fan base is usually one of the main goals of consumer companies when it comes to social media like Facebook for example. Every marketer you might want to hire, keeps telling you: you need a huge base (newsletter subscribers, Twitter followers, Facebook fans, feed subscribers, etc.) and later on you just need to “activate” them to sell products and services to them. That does sound good in theory, but let’s be honest here – what’s happening in the real world? In fact most companies spent a lot of money on building up huge online / social media properties with Facebook pages and communities way bigger than our S4BB Apps. Yet, most of those brands utilize their social media presence in the traditional “one-way direct marketing” kind of sense by kicking out a discount voucher once a week and publishing news about their products. Hoping these initiatives pay off. Yes, we do that too and yes, everything can be tracked to ensure proper ROI. But the truly big thing is: social media actually allows us to have a direct bi-directional communication with our brand’s audience. “Social Media Gurus” can talk you to sleep about that topic. Yet, nobody has an answer on how to manage bi-directional conversations with hundreds of thousands of fans and followers who have different views about different topics, products; speak different languages, live in different time zones and countries, and could all talk at the same time — to you.

At S4BB Ltd. and Skylab Mobilesystems Ltd. we are building products for consumers in a large scale. We target global audiences in any country in the world with any mobile platform they prefer. At TreeCrunch Ltd. we are actually building a platform for companies which have huge online properties with many customers, followers, fans; simply users, I like to call them. TreeCrunch’s direct customer-engagement platform allows us to overcome these challenges in communicating with our audiences at S4BB and Skylab, but it also allows any brand like yours to do the same. Is your company up for that?

More to come. Stay tuned and subscribe to my RSS feed.

Related posts:

Scaling a Web Server to Serve 165 Million Ad Requests per Day

2012-03-14, on 15:17 | In work | 3 Comments | Dieser Artikel in Deutsch


I am usually not the kind of guy who likes to boast with numbers, but in this case I believe it helps to put things into perspective. For over seven years I am in the mobile app business targeting consumers directly. Over the years we have created thousands of products, most of them paid, some completely free and some with ads.

For years, I did not believe in monetization of apps through advertising. Even today, I am still very skeptical about that because you need to have A LOT of ad requests per day so that any significant income can be generated from that. At the moment, our few (around 10) mobile applications that sport ad banners, generate up to 165 million (165,000,000) ad requests per day. That makes up to 5.115 billion ad requests per month. If you compare that to a fairly large mobile advertising company like Adfonic with their “35 billion ad requests per month” (src: About Adfonic) we are doing quite alright for a small app company. We are using a mix of different ad networks depending on what performs best on which platform. Besides that we are breaking it down into country/region to use appropriate ad provider that is best for that region. Part of that also involves ad providers who do not support certain platforms natively. So built server-side components to handle such ad requests in a “proxy” kind of way that still allows us to get ads shown in apps on a certain platform that is not officially supported by the ad provider. Basically, we have a mini website that just shows an ad; and we can have hundreds of thousands of mobile devices accessing this website from all over the world at the same time.

Using cloud service providers like Amazon AWS, Rackspace, SoftLayer, Microsoft Azure, or others any can serve a virtually unlimited number of requests these day. It all depends on your credit card limit. There are obviously usage patterns of programs of applications and over the course of the day, we have ups and downs. For example, at midnight GMT most people all over the world like to use our applications and therefore they request more ads. Five hours later, we experience the lowest traffic. Depending on application store release schedules, promotions, featured listings, user notifications, external promotions like on blogs or elsewhere, unexpected sudden spikes in traffic can occur any time. “Automatic Scaling” in combination with “Load Balancing” seemed to be the magic solutions for this.

After months of running a bunch of server instances behind a load balancer we were quite happy with the performance. It was easy for us determine usage patterns and see how many servers we need to serve the average maximum number of requests without our service to fail. We didn’t think that much about cost-optimization because our cloud computing bills weren’t that high; so we didn’t really work on such auto scaling components. That had two main disadvantages: Firstly, we spent more that we needed to as we probably didn’t need half of the server that were running while we had low traffic. Secondly, we were not prepared for sudden massive spikes in traffic. With TreeCrunch on the other hand, we are building a scalable system from the ground up.

So early this week I took three hours and looked into how to implement such auto-scaling. Actually, it took me two hours to install the tools properly. However, as you can see in the above charts, the current systems works in a way that if we hit a maximum amount of average traffic per server, a new server is being created and added to our load balancer — it then immediately starts serving ads. If the average traffic falls below a certain threshold, a server is being terminated and therefore stops serving ads. To minimize server load, we run really tiny PHP scripts that are extremely optimized just for the purpose of requesting an ad the desired ad company and delivering such ad to the client (mobile app). As web server we are currently using lighttpd which is very lightweight indeed. Interestingly, we noticed that there is not really a problem with “normal” system resources to handle a lot of requests. Our CPU usage is fairly acceptable (constantly around 50%), we don’t need any hard drive space as we are just proxy’ing requests and we don’t even run out of memory. The first limitation one of our ad servers hits, is the maximum number of used sockets which is by default around 32,000 (or something like that) on Debian-based linux. That’s more or less an artificial limitation by the operating, but we didn’t play with adjusting that one yet.

Summary: In a fairly short period of time, we managed to set up a proper auto scaling policy that allows to scale up to virtually unlimited numbers of ad requests. With fairly low budgets companies nowadays can setup proper data centers, serve millions of users and maintain their infrastructure with a few very talented people and without purchasing any hardware that would be obsolete a year or two later.

I love the time I am living in. Every single day something new and exciting pops up.