The official Motribe blog, written by the founders
Motribe’s first month in review: early indicators, rapid growth and growing pains
Motribe is a month old today so we decided to share some of our experiences and statistics for those of you who are interested in our progress. This post is quite long but we have broken it up into sections to make it a little easier to digest. There are also some technical aspects to it that might come in handy for other people going through the same growth.
Written by Vincent Maher on October 13, 2010
Getting on the road is better than standing around wondering if the car will drive
One of the nagging worries for us during the pre-launch phase was that our assumptions about user-uptake may not be generalizable and that, for whatever reason, all our past experience in terms of projecting growth of these kinds of services might not actually hold true the one time we really want them to. These assumptions revolve around a two main axes: ongoing engagement levels and the rate and cost at which the user-base grows.
If the engagement is high and the cost is reasonable then you have a system that justifies using mobile advertising as a tool to promote growth. If the engagement is low then you’re simply wasting money and buying registrations, not users. The reason these two things were a worry before we launched is that the only way to know for sure is to actually do it and measure the results.
Engagement is a good thing to think about for the first month because it’s applicable to new users. As time goes by the measure of loyalty is going to shift into the prime position and in about six months time the overarching question of whether all of these users can generate revenue will be added to the mix. We have a lot of hurdles ahead of us but we are happy with the results of the first month.
Encouraging growth
At the end of the first month Motribe has 42 000 registered users with 4.5% - 6% of the entire base active over a 24-hour rolling period. Our sites were visited by just over 140 000 unique visitors which means that roughly 30% of all the users exposed to the service registered. Users have uploaded just over 4 000 photos, 4 300 blog posts, 10 000 comments on photos, 6 800 comments on blogs, 14 200 photo ratings, 65 000 friend requests and 140 000 chat room messages. The average time spent per visit is around 53 minutes for users that are logged in and they generate approximately 45 page views per visit.
These numbers are encouraging for the end of our first month and we expect them to grow over time. With this kind of growth comes all sorts of fun on the server farm.
Scaling fun
Fun is a relative term in this context because there have been a few scary moments and the occasional patch of down-time. Luckily or unluckily, depending on how you look at it, the problems were not all caused by anything we could control or plan for. As an example, during week three the hosting provider controlling our DNS was exposed to a massive denial of service attack from servers in China. Because of the rapid release of the platform there were a few loose ends, one of them being our DNS management and the lesson learned there was to keep your DNS management under tighter control because making changes can take hours to propagate and during that time the user experience is unpredictable.
We also ran into issues around high-volume counters on Cassandra that caused some inconsistencies in our analytics system. This is an issue that has been at the heart of much robust debate within the Cassandra development group and should be dealt with in future releases of the server. Our workaround was to use Memcached and Cassandra together to do the same job and this solved the problem for us in the short term.
As things heat up we’re learning some good lessons about Amazon’s RDS platform, which is what we use for our MySQL database. Deploying a high-volume database without using the multiple availability zone replication in place is not such a wise idea. Our database is currently averaging 152 queries a second so a large part of the scaling work is going to be to hand off more of that load to Memcached and Cassandra. As things stand now we are taking quite a strong NoSQL approach and there are only two queries across our entire system that require a join.
That being said we’re still well within our 99% up-time goal and we’re quietly confident that we can deal with problems quickly and effectively as they arise.
Content
With users creating lots of content there are certain challenges that require special attention. Nic and I have been well-exposed to the bloated underbelly of society and its manifestations on mobile media and we’re probably going to be involved in an on-going push-and-pull between allowing users to publish content in real-time and protecting users from people who abuse those freedoms. We ban users if they violate the terms and conditions or the general bounds of common decency and luckily that proportion of users is small. Normally a good public execution sets the tone and we make a point of telling the users in a network when we ban people so they can see where the line is that they should not cross.
What we have found, which is interesting, is that once a community begins to form it members take a more active role in policing the content themselves. Despite the assumption that we operate with a god-like omnipresence the reality is that we can’t be everywhere at the same time and it is really cool that our users help us out by pointing us to bad content or the occasional abusive behavior. With that kind of joint-curatorship we think things are going to stay under control and over time we will divest more of that power to our users.
User distribution and the Tower of Babel
Our current top 10 countries are India, USA, Nigeria, Ghana, Philippines, Indonesia, South Africa, UK, Pakistan and Kenya and we predict that we will remain strong in emerging markets for a long time because this is where we are focusing our efforts to some extent.
With the strong presence of Asian countries we’re well aware that language diversity is going to be one of our biggest challenges going forward and the difficulties are not around translation but about whether or not to segregate linguistic groups. This would not normally be a difficult choice but we have found that while on the one hand many of our Asian users want to meet and chat with users from the Western world the revert to their own language when they form a majority in a chat room. This poses an interesting problem for the odd English-speaking user in a chat room comprising mostly Hindi or Arabic speakers and Nic and I have debated this many times and never reached any solid conclusions about whether chat rooms need to be filtered based on language or not. The most likely outcome is that we will try it and if it fails then fall back to the cacophony of languages and try something else.
What do we think about all of this?
So far we are happy that things are going according to plan and that our results match the predictions in our business plan. Our main focus is to improve the results every month and keep our eye on the medium-term goal which is to expand the scope of the service, keep adding new features for network owners and try stay as agile as possible. As an example we have announced the beta release of mobile video hosting for our enterprise publishers today, which will allow them to deliver high volumes of video content to their users if they want to. Maintaining momentum is important for us as the founders and also for the business as a whole.
We also eat really well at our new offices, check out our food blog
blog comments powered by Disqus
One of the nagging worries for us during the pre-launch phase was that our assumptions about user-uptake may not be generalizable and that, for whatever reason, all our past experience in terms of projecting growth of these kinds of services might not actually hold true the one time we really want them to. These assumptions revolve around a two main axes: ongoing engagement levels and the rate and cost at which the user-base grows.
If the engagement is high and the cost is reasonable then you have a system that justifies using mobile advertising as a tool to promote growth. If the engagement is low then you’re simply wasting money and buying registrations, not users. The reason these two things were a worry before we launched is that the only way to know for sure is to actually do it and measure the results.
Engagement is a good thing to think about for the first month because it’s applicable to new users. As time goes by the measure of loyalty is going to shift into the prime position and in about six months time the overarching question of whether all of these users can generate revenue will be added to the mix. We have a lot of hurdles ahead of us but we are happy with the results of the first month.
Encouraging growth
At the end of the first month Motribe has 42 000 registered users with 4.5% - 6% of the entire base active over a 24-hour rolling period. Our sites were visited by just over 140 000 unique visitors which means that roughly 30% of all the users exposed to the service registered. Users have uploaded just over 4 000 photos, 4 300 blog posts, 10 000 comments on photos, 6 800 comments on blogs, 14 200 photo ratings, 65 000 friend requests and 140 000 chat room messages. The average time spent per visit is around 53 minutes for users that are logged in and they generate approximately 45 page views per visit.
These numbers are encouraging for the end of our first month and we expect them to grow over time. With this kind of growth comes all sorts of fun on the server farm.
Scaling fun
Fun is a relative term in this context because there have been a few scary moments and the occasional patch of down-time. Luckily or unluckily, depending on how you look at it, the problems were not all caused by anything we could control or plan for. As an example, during week three the hosting provider controlling our DNS was exposed to a massive denial of service attack from servers in China. Because of the rapid release of the platform there were a few loose ends, one of them being our DNS management and the lesson learned there was to keep your DNS management under tighter control because making changes can take hours to propagate and during that time the user experience is unpredictable.
We also ran into issues around high-volume counters on Cassandra that caused some inconsistencies in our analytics system. This is an issue that has been at the heart of much robust debate within the Cassandra development group and should be dealt with in future releases of the server. Our workaround was to use Memcached and Cassandra together to do the same job and this solved the problem for us in the short term.
As things heat up we’re learning some good lessons about Amazon’s RDS platform, which is what we use for our MySQL database. Deploying a high-volume database without using the multiple availability zone replication in place is not such a wise idea. Our database is currently averaging 152 queries a second so a large part of the scaling work is going to be to hand off more of that load to Memcached and Cassandra. As things stand now we are taking quite a strong NoSQL approach and there are only two queries across our entire system that require a join.
That being said we’re still well within our 99% up-time goal and we’re quietly confident that we can deal with problems quickly and effectively as they arise.
Content
With users creating lots of content there are certain challenges that require special attention. Nic and I have been well-exposed to the bloated underbelly of society and its manifestations on mobile media and we’re probably going to be involved in an on-going push-and-pull between allowing users to publish content in real-time and protecting users from people who abuse those freedoms. We ban users if they violate the terms and conditions or the general bounds of common decency and luckily that proportion of users is small. Normally a good public execution sets the tone and we make a point of telling the users in a network when we ban people so they can see where the line is that they should not cross.
What we have found, which is interesting, is that once a community begins to form it members take a more active role in policing the content themselves. Despite the assumption that we operate with a god-like omnipresence the reality is that we can’t be everywhere at the same time and it is really cool that our users help us out by pointing us to bad content or the occasional abusive behavior. With that kind of joint-curatorship we think things are going to stay under control and over time we will divest more of that power to our users.
User distribution and the Tower of Babel
Our current top 10 countries are India, USA, Nigeria, Ghana, Philippines, Indonesia, South Africa, UK, Pakistan and Kenya and we predict that we will remain strong in emerging markets for a long time because this is where we are focusing our efforts to some extent.
With the strong presence of Asian countries we’re well aware that language diversity is going to be one of our biggest challenges going forward and the difficulties are not around translation but about whether or not to segregate linguistic groups. This would not normally be a difficult choice but we have found that while on the one hand many of our Asian users want to meet and chat with users from the Western world the revert to their own language when they form a majority in a chat room. This poses an interesting problem for the odd English-speaking user in a chat room comprising mostly Hindi or Arabic speakers and Nic and I have debated this many times and never reached any solid conclusions about whether chat rooms need to be filtered based on language or not. The most likely outcome is that we will try it and if it fails then fall back to the cacophony of languages and try something else.
What do we think about all of this?
So far we are happy that things are going according to plan and that our results match the predictions in our business plan. Our main focus is to improve the results every month and keep our eye on the medium-term goal which is to expand the scope of the service, keep adding new features for network owners and try stay as agile as possible. As an example we have announced the beta release of mobile video hosting for our enterprise publishers today, which will allow them to deliver high volumes of video content to their users if they want to. Maintaining momentum is important for us as the founders and also for the business as a whole.
We also eat really well at our new offices, check out our food blog
Motribe is a simple, quick and cost-effective way to do what you want to do on mobile
Take the tour | Follow us on Twitter
|
Contact Us | About Us | Company Blog | Founders Lunches Terms and Conditions for end users | publishers © Motribe Mobile Networks (Pty) Ltd |