Amy Collins on Data: 5 Exciting Announcements about our Facebook Data

Authenticating with the Page Admin account is now simple. It features an invitation system leveraging a powerful 1990s era technology called email, so it works even if the Facebook page admin is in another office or if you’re an agency, one of your clients.

Furthermore, if you have one user that is the admin of all your pages you don’t have to keep inviting them over and over as you configure all your channels; inviting them once will be enough, we’ll unlock the higher rate limit on all the other pages you own too.

2. Non Owned Channels – Helping you to maximize data coverage

Many organizations want to track Non-Owned channels too. They want to benchmark against their competition and monitor what they’re saying. We heard you – this capability isn’t going away.

However, since you don’t own the page, we can’t use the page admin token that we use for owned pages. We can, however, get regular users to authenticate. This gives us increased API capacity that we can use to pull down the data on channels you don’t own. In the past, this has been a clunky process.

Today we’re rolling out the email invite system to allow you add users from across your team or the wider organization to boost your Facebook coverage.

By the way…. if you don’t use email to communicate, no problem. As you can see above, you can copy a unique auth link and just then paste it into a Slack channel, Skype chat or print it out and send it by carrier raven. However you communicate: We’ve got you covered.

And there’s a super friendly landing page to explain what they’re doing when they connect to improve your coverage:

3. Feedback on Channel coverage

We also heard from you that you wanted more transparency about what was required to get the best possible coverage.

So we’ve also added a new interface to show the Brandwatch admin for your company how many channels have tokens:

4. SLAs

This whole conversation started nearly a year ago. I asked one of the engineers what would be required to have a more predictable, explainable system for our customers.

I was told we didn’t have enough API capacity. So we agreed we’d solve that problem through the authentication system (above).

I was then told, we need far more compute power, so we agreed that they could build a shiny new infrastructure.

At the end of that conversation, we agreed that if they could have those things, they’d provide a service that operated within a Service Level Agreement. We agreed some really low targets for the SLA, but they committed to delivering a system that would do the job reliably.

However a month or so ago, the engineers came back and said: “You know those SLAs…? …actually we think we can do better”. I’m really pleased with what they proposed.