Meet the Measurement Team

Based in our brand-new Berlin office is the Measurement Team, a cross-discipline team who focus on one of Brandwatch’s key use cases, The Measurer.

A Measurer wants hard numbers to gauge the success of their projects. They need to be able to check the success of their campaigns over time, and determine their project’s share of voice against that of their competitors.

Measurers include brand and campaign managers, but anyone working in social media monitoring will use measurement metrics as part of their role, from verifying the success of a tweet from its retweets, or a Facebook post from its likes, through to determining key influencers to engage with based on their profile.

 How we do it

To cater to these individuals, the team here in Berlin work on various projects, such as Brandwatch Analytics’ Channels features, custom components and visualizations that show metrics and insights from two of social media’s titans, Facebook and Twitter.

We work across the entire stack of Brandwatch, from collection of data via the aforementioned platforms’ APIs, then on to provision of that data via Brandwatch’s API, and finally display via custom components.

More recently we’ve started work on one of our clients’ most frequently requested features: shareable reports. Many clients have expressed a desire to be able to share Brandwatch data and visualizations with their colleagues, without those people needing a login to Brandwatch Analytics.

Clients have asked for reports in different formats, from Powerpoint to PDF, but the common theme is that a report should be easily shareable and good-looking.

Fulfilling this requirement brings with it a host of new challenges, including:

• Rendering: Brandwatch Analytics is a Thick Client JavaScript app, and we’ve farmed out the rendering of visualisations to the front end. For shareable reports we’ve needed to bring this back to the server, so have been hard at work creating a new suite of visualizations that work at the back end, this time using d3 and Vega, instead of our old ally, Highcharts.

• Scalability: We’ve decided to produce HTML reports for our Minimum Viable Product, and then offer PDF reporting in a later iteration. HTML allows us to iterate quickly, harnessing the years of experience of our team, and also to choose from a wider variety of visualisation solutions. One downside of providing reports as web pages is that we need to consider scalability, as a public report might have thousands (or hundreds of thousands) of hits. So, we’ve created new NodeJS applications that link together using a job-based architecture, based around Bull, in order to be able to scale better and provide the best experience to our users.

What’s coming next?

In upcoming posts we’ll look more at the technology choices behind the shareable reports feature, and dive into how we’ve solved some interesting (and tricky!) problems along the way.

Until then we’ll be getting our heads down and continuing to work on the MVP – we’ll keep you posted.