9 min read
This story originally appeared on Quora by Nasrullah.
For those who don’t know, Pring is a mobile social network that works like Twitter but is far better optimized for low-end devices which work over SMS.
At a very basic level, if I have a username Nash on Pring, you can start getting my updates via SMS if you text FOLLOW NASH to 9900 (or mobile number known as a shortcode).
Pakistan is a country where internet penetration is very low. At the time we launched in 2009 (Beta) and went public (2011) barely 9% users had internet access compared to mobile users which were 55%. For this reason, SMS-only mechanics are vitally important. Pring essentially creates a national conversation rather than just limiting to a few high-profile, smartphone-wielding, rich users.
Pring grew entirely organically. We’ve spent little or no money on marketing or user-acquisition. We started small and we wanted to grow smartly.
The Viral Loop
At Pring we’ve been very focused on how users use our service, how they discover our service and how they engage with it. We divided our user studies into these: Growth, Engagement, Propagation. I’m going to talk about Growth and what is known as the Viral Loop.
Most viral phenomenon can be modeled like viral outbreaks and lucky for us, community medicine or Epidemiology has already figured out how quickly can a disease (or in our case, a service) grow.
The key part is this:
a = How many people does an infected host get in touch with
b = How many of a get infected
k = a · b
Put in another way:
k = How many friends does a user invite · How many people respond to the invite
K is also known as the k-factor or the virality coefficient.
K = 1 (stable) means the user is replacing itself. The service will have stable growth (but active users will not grow)
K < 1 (shrinking) means the service is shrinking, every user is replacing themselves with less and less users
K > 1 (growth) these are truly viral services, this is where exponential growth happens. Very few services have a k-factor greater than 1.
Our job has been to make sure the k-factor is larger than 1
Basically, get more friends invited, make the invite compelling enough for more people to sign up.
Our First Viral Loop
The principle way Pring grows is via users inviting other users via SMS. The way this works is a user texts their friend’s mobile number to 9900 such as like this:
INVITE 0312-1234-567, 0312-1234-568
The invited users would then get an SMS from 9900 inviting them to joinPring. All the users had to do was to reply with Hello and they would start following the inviter. We kept on tweaking this, for example:
- We removed the need to write INVITE before the message
- We added tolerance for a large type of numbers: local, without any code, with code, with international code, spaces, commas, dashes everything.
- We added more context to the message by also sending the inviter’s name
- Finally, in this round, we also added the inviter’s mobile number to the message. The idea was that the inviter knows your mobile number, why shouldn’t you know their’s? This created a more trustful message.
But we still weren’t happy with the number of people joining in everyday
Viral Loop v2
Message Blindness
The problem in Pakistan is too much SMS spam. Everybody does it. It’s unethical. The result is that people suffer from message blindness where they receive a message from an unknown number or from a shortcode and they don’t bother opening it and they’ll delete it.
We fixed some of this by writing the inviter’s name and number to the top of the message so that the message snippet your mobile handset shows gives you some idea. That improved conversion but not quite as much.
SMS Masking
In our playing with the SMS Protocol (known as SMPP), we found that we could in some cases make change the sender (the from number) to anything we wanted. So, instead of a message coming from 9900, it could appear to come from the actual inviter’s number. This would solve the problem of message blindness. It would add an additional step, instead of replying to the message to join, the invited would have to send a message to 9900. This was a brilliant idea however, we didn’t get too much conversion from this. Our experiments point towards Mobile Operator’s spam filters which would block the messages in a number of cases.
Viral Loop V3
This was back in 2011, when we were doing a mobile based campaign for one of our clients: Nokia Pakistan. I created a system called social invite. In Pakistan, SMS forwards are very common. It’s very cheap to send 100s of messages thanks to SMS bundles (which account for 97% of SMS traffic). So, users forward SMS jokes to their friends, family etc. While thinking up social invite, my idea was to give each user their own unique mobile code. You would then forward that code on your own to your friends and ask them to forward it to 9900. This way, the invite message came from you, in your own language, from your own number so it had high degree of trust. When the user forwarded the code to 9900, we would connect the users together.
When we launched this idea first for a Nokia test audience of about 9,000 users, it blew up insane! Nokia’s friends and family group grew from 9k to 500k in less than three days. I wrote a patent for this later on. We were nominated for this campaign by for Effective Mobile Marketing by Mobile Marketing Magazine in UK (among 140 other campaigns in the world) and we were runner ups along with 7 others.
(50,000 users in 415 mins. Larger dots = more friends invited)
Viral Loop vN
There were countless other things we did as well, here are a few of them
SMS A/B Testing
A/B testing or multivariate testing is very common practice for Web, but it’s not been applied as rigorously as we did. Basically, whenever you join our service via SMS, you will get a different prompt from us. There’s a system in place that keeps learning responses and based upon the one that is getting the highest, it will automatically make it the “default” (80% traffic) for most users signing up.
Low Friction Entry
Initially, we designed our signup process in a brain-dead computer sciencey way: we would ask you your username. You would give us your username. We would be sorry that THAT particular username is not available. You would then supply another username. This would go on and on till you found a name that worked. We later on removed the requirement of having a username. Instead, we just had you follow whomever you wanted to follow no questions asked. A year later, twitter did the same thing with their SMS service, they called it Fast Follow.
Conversations, Not Questions
Whenever a user joins any service, there are a ton of questions you need to ask: what’s your name? Where do you live? Boy or a girl? You need all this data to give a better tailored experience to the user.
The problem is that most onboarding process come a little formal and robotic. In our A/B tests, we found that the highest responses we received were those which were conversations.
So, instead of “Please reply with your name” we changed it to “Great to meet you! What’s your name?”. Changes like these nearly doubled responses. People felt they were talking to a person not a system.
Please Talk Less
In our experiments we also found something interesting: For every word in your SMS, conversation is lost by one percent (1%).
Alternately, for every 6 characters, you loose 1% in conversion. We made sure that our messages were short.
Lazy Onboarding
Instead of asking a lot of questions upfront about the user. We delayed them to the last possible moment. For example, we only asked your name if you commented on an update or sent a message. So, in this way, you had already invested in creating the message and you had to give your name to have the message posted. Higher conversion.
Ask Less Questions
Somethings you can deduce on your own without asking the user. For example, you can determine the gender of a person from their name with 95% accuracy. We built a small ANN to triage names into male, female and unknowns. Reducing questions asked from the user.
Support For Fat Thumbs and Weird Accents
Like I mentioned before, to get updates from me, you need to text FOLLOW NASH to 9900. A lot of people would made mistakes with the name they wanted to follow. Writing mistakes are incredibly common when it comes to the small screen especially dumb T9 and multi-taps without autocorrect. We placed a system in place to accept an incredibly large number of errors.
We do fuzzy matching with the name given with all names in the database and if we were confident that we’ve found the user, we would complete your action. If not, we would suggest 2-3 alternatives.
Eventually, we dropped the need to even write FOLLOW as a command, you just text NASH to 9900 and you’ll get updates from me.
Language Matching
Though we initially started the service naively in English, we quickly defaulted to Roman Urdu. Our tests showed 75% people preferred Roman Urdu, 10% Nastaleeq Urdu and 15% English. We also found that 10% handset had trouble rendering Nastaleeq or Unicode Urdu.
Measuring it All
Internally, we had a metric called UIF: User Intent Fulfillment. What this meant was if a user sent a text were they able to get what they wanted in a single go? If Yes, the UIF for that interaction was 1. If it tool 2 or more exchanges for us to understand the request the UIF was 0. Initially, our UIF was barely 5-10% and by the end of the above changes, we were in the 95%. Users would get what they were looking for even if they made lots of mistakes. We made it our duty to make sure they got what they wanted.
