If you’re partial to a bit of content sharing, it’s highly likely you’ll have used GetSocial - without even being aware of it. Established in Lisbon in 2013, the company helps brands amplify their online presence through social media engagement. Each time you’ve clicked a ‘share’ button on a website (similar to the ones on the right of this post!), or subscribed to an email list, the chances are GetSocial was part of your online experience.
As users ourselves, we’re big fans of their social engagement tools. So I was delighted to have an opportunity to speak with their lead software engineer António Gorgulho, to talk about product development, scaling stacks and of course all things social:
Hi António, can you tell us a little bit about the story behind GetSocial?
When we first setup the company, GetSocial was focused on helping eCommerce companies drive revenue creation through social media. Like many early stage tech startups, our initial product offering didn’t generate the traction we desired, so we had to pivot. From the customer insights we’d built up, we recognized that there was an opportunity to help content publishers grow their web traffic through social engagement. So rather than throwing everything out and starting from scratch, we revamped one of the key features from our original product to cater for this demand.
What’s the process you’ve gone through to get to your current product set?
Changing gears required us to take a much more systematic approach to development, so we created a governance framework built on what we called ‘The Four A’s’ to guide our roadmap.
The first stage was about activation, which involved building the core features and functionality of the GetSocial toolset, getting users to test these, give us their feedback and help us understand the right monetization tactics from the ones we were testing. This phase ran for about three quarters into the middle of 2015, and at that point, we’d built a sizeable community of 90,000 registered users, with close to 1,000 paying customers.
Our analysis phase was about building insights into how the tools were being used, to better understand what our customers wanted from us. We engaged with a large proportion of our users, trying to understand their daily routines and interactions, and looked at where there were opportunities for us to tap. This was a really worthwhile effort as it ultimately led us to develop our content performance analytics platform, which solves a major pain point for customers frustrated by ‘Dark Social” (more on that later).
Currently we’re in our third phase, where we’re looking to automation to help us gather intelligence for our customers, measure the performance of content pieces, and help them understand how content is performing through actionable information. The idea is to change how publishers acquire, develop and monetize their audiences based on a deep understanding of how their content is being shared and consumed. This will then take us to our last stage of amplification, which will enable us to grow at scale.
You mentioned ‘Dark Social’ – can you elaborate on that?
Absolutely. One of our biggest product strengths is the ability to track 100% of a site's social activity. What we’ve found through months of monitoring behaviors, is most social sharing doesn’t actually happen as a result of an interaction with share buttons. Instead, people are sharing through copy & pasting links into private messaging channels. The problem with this approach is that these shares lose their referral information – what we call Dark Social, and end up being reported in web analytics as simply 'Direct Traffic'.
For audience development or social media teams, this can be rather demoralizing, as you're effectively seeing your hard work completely unattributed. In fact, one of the use cases we like to mention often is a customer who was able to understand that social (as a channel) was not generating 3% of their traffic, but actually 52% thanks to their ability to fully track their website's complete social sharing activity.
What made you choose Cloud 66?
We were looking for a technology partner who could help us with building our technology stack and discovered Cloud 66 through some content on Reddit. When you’re a small team growing fast, you don't always have the luxury of running DevOps in-house.
So we first tried Cloud 66 with a small stack to recreate our staging environment and were mesmerized with the results. There was no need for us to worry about infrastructure or deployment, no downtime while deploying, and overall it seemed like an excellent fit to help our team. From there we created our first production stack and when scaling requirements first started to appear, we found the magic button – aka the “Add a Load Balancer” feature, which easily allowed us to scale to cope with the increasing workload demand.
Talk us through your current infrastructure set-up.
We use Cloud 66 to manage our Staging, Production Stacks and Database Backups. Currently, we have three production stacks: a small rails stack for customer back office purposes that's composed of a rails server, a postgres and redis server (shared) for storing data and caching purposes, alongside a process server.
Our biggest rails stack, which handles 1500 req/s, is used to serve our customer websites with our social tools and to deliver analytics outputs. The stack consists of 15 rails servers, a haproxy load balancer, a postgres server for data storage, a redis server for caching, alongside a process server.
And the last one is our rack stack, responsible for handling analytics events and maintaining all customer website social interaction data. The stack is composed of 3 rails servers, a haproxy load balancer, a mongoDB replica set composed of one primary and two secondary servers, along with two process servers.
How do you think you’ve benefitted from using Cloud 66?
Cloud 66 has some great features we love, including the 'One-Click Deploy' with no downtime, automatic provisioning, management of our postgres and redis databases, together with security features such as automatic firewall configuration and brute-force protection. There’s no need for a Devops guys, which would be a much more expensive option compared with what we’re paying to use Cloud 66.
Having such a feature-rich product also means I don’t have to waste my time learning how to replicate my redis server or to build a load balancer. Instead, I can focus on building our product. Whenever our apps can’t handle our traffic demands anymore, Cloud 66 support is always there, ready to help us with solutions for the next stage of our growth.
Thanks António - we love having you guys as part of the Cloud 66 community. If you're looking for social engagement and analytics tools to understand how your content's performing and to amplify brand's reach, we recommend you check out GetSocial.io.