Category Archives: Blog

The official Vocanic blog

Are we killing another golden goose?

Facebook Inc. owns Facebook, Instagram and Whatsapp. The total number of monthly active users they can reach is a mind blowing 2.24 billion!  !  (source :  Facebook, TechCrunch and Instagram )

The Facebook ecosystem is now the most important marketing space for you and your brands. Unfortunately, most brands are not giving this area enough attention and budget.

Facebook’s  strategy was simple and elegant. Build functionality that users find compelling. Get a billion of them.  Evolve a symbiotic relationship with brands. Give them free space ( the Fan Page) and free media (the Newsfeed). Smart brands jumped on the opportunity and built large communities of fans.

Through dialogue, brands increased loyalty. They implemented business initiatives such as Social Loyalty, Social CRM and Social Customer Support. StarHub for example pioneered this in Singapore. Brands developed content strategies to exploit the free ride to reach their audience.

Source: Adweek

Source: Adweek

Like all innovations, things evolved. Brands killed the golden goose! Majority of brands pumped either below average content or regurgitated ATL material. Users perceived this content to be irrelevant. Facebook changed their algorithm leading to lower organic reach for non-engaging content. If we had a dollar for every time we were asked to post a TVC on Facebook, we’d be very rich indeed!

This is just a rerun of the last incarnation of Content Marketing. We knew it then as ‘email marketing’ and the ‘e-Newsletter’. Back in the days, consumers jumped into email as the new revolution. Brands built email databases and blasted marketing material to serve their own agenda. It got so bad that media providers like YahooMail, Hotmail, Gmail invested in technology to protect their users. This led to the birth of SPAM filters and the Junk Mail button.

People around the world are now spending more time online (smartphone + tablet + laptop) than watching TV. This has led to marketers shifting their attention to digital. We are in an era where this is the new mass media. Millions are spent on interrupting people on the internet. There’s banners, pop-ups, site take overs, pre-role video etc.  The mindless intrusion of unconnected ads has led to the growing threat from Ad blocking technology. Ad blocking technology is now reaching 10% (source : AdAge) .  10% may not seem much, but the rate of adoption is accelerating. This is often seen as the tipping point to mass adoption. Ad blocking usage has reached the point where the upcoming release of Safari on the iPhone will allow you to block an ad on mobile too. On the way the browser providers will make ad-blocking even easier for the layman.

As an industry, we have a history of abusing marketing platforms and consumer trust. Brands forget that the marketing world has advanced. It is now permission based unlike Radio, TV & Print. Audiences can choose to block them when they feel frustrated with constant endorsements. Marketers from an ATL only background are finding it hard to make the transition. So where does that leave brands?

Back to where some of them originally started. Refocus on delivering an experience that is good enough to earn a recommendation.  Create content and interactions that generate value for the audience. Become consumer centric and join the consumer’s conversation. And of course – never try to force your agenda on them.

 

 

 

 

 

 

Switch Your Sessions to Redis (Without Downtime)

By default PHP’s session management is to store them in temporary files on the file system. This doesn’t scale up if you are developing a web application to run on multiple machines. You could set up your load balancer to have sticky sessions – where a session is associated to a machine – but the major drawback here is to have sessions become “bad” when that machine is out of rotation – primarily due to an error.

The typical solution, then, is to store the PHP sessions in Database, or some such store. We, at Vocanic, started off by storing the sessions in MySQL, but then as our traffic went up, scaling that instance of MySQL became a headache and so we replaced it with a MySQL+Memcache solution, which was good enough for quite a while.

Recently, we saw a bigger problem – MySQL tends to be blocking if you are doing edits, and if the MySQL instance is shared between Sessions and any other data, then any major edit operation on the other databases also slows down the Sessions code and eventually blocks all the users out – since Sessions is the first module that needs to be loaded up for all of this to work.

So, we wanted to a non-blocking, fast, scalable store for our session management. These days, I am personally going through a Redis-Admiration phase and hence I decided to migrate this code to use Redis.

(Src: http://rethinkdb.com/blog/thanks-redis/)

The pseudo code for this is something like this:

class RedisSessionHandler implements SessionHandlerInterface {

public function open($save_path, $name) {
// Set up your Redis Connection
}

public function close() {
/* */
return true;
}

public function read($id) {
// GET '$id' // unserialize and return
}

public function write($id, $data) {
$wrapper = new stdClass();
$wrapper->id = $id;
$wrapper->access = time();
$wrapper->data = $data;
// SET '$id' serialize($wrapper);
// ZADD 'ALL_SESSIONS' $wrapper->access, $id
}

public function destroy($id) {
// DEL '$id'
// ZREM 'ALL_SESSIONS' $id
}

public function gc($maxlifetime) {
$old = time() - $maxlifetime;
// $keys = ZRANGEBYSCORE 'ALL_SESSIONS', 0, '($old'
foreach($keys as $id) {
$this->destroy($id);
}
}
}

$sessionDataHandler = new RedisSessionHandler();
session_set_save_handler($sessionDataHandler, true);

// Send any headers you want to

// Rest of the code

While this will just work for a new application, we wanted to ensure that your current sessions are migrated – so we wrote a compound session handler that wrote to both old session handler and the new session handler and compared the read results to ensure that we weren’t seeing anything inconsistent.

Once we ran it for a few cycles of “$maxlifetime” – ours was set at 1440 seconds, we were sure that the new handler was working as expected. Once that happened, we replaced it with code that was just the Redis Handler and we had the entire system shift to Redis.

At the moment, my nascent profiling is showing me that we are saving somewhere close to about 30ms savings in page views that uses Sessions.