Log in
Table of contents
Blog How Do Social Media Analytics Tools Work? Planable CTO Explains

How Do Social Media Analytics Tools Work? Planable CTO Explains

Planable is primarily a planning, collaboration, and scheduling tool for social media content. For years we’ve focused on creating the best possible place for agencies and marketing teams to work together on content, but recently we embarked on a bit of a different journey to add social media analytics to our platform.

So today, I just want to share some of the insights we’ve gathered and some of the struggles we’ve been through during the process of building this intuitive (and honestly quite beautiful) analytics dashboard for you.

The two most common questions we have about Planable Analytics are:

  • How do you get the data from native social media platforms in the first place?
  • Why is the data from third-party applications sometimes different from the native platforms?

Well, let’s find out.

How third-party social media analytics tools work via an API

We get the data from each native platform through an application programming interface or API for short. Some of you might have heard about APIs and know what an API is, but for anyone unfamiliar, I’ll try to explain what an API is with two analogies.

An API is like a glue that sticks apps together. So, it’s a way for Planable or other third-party apps to communicate with the social media platforms themselves. This communication goes two ways and allows data to be exchanged.

Meta, TikTok, LinkedIn, and so on, all grant us a certain amount of access to the data from their platforms, which we can request from them.

For example, we can make a request to publish a post at a certain time. That’s how scheduling works. Now, with Planable Analytics, we can make requests to gather post performance data and page performance data.

Another good analogy would be to compare an API with a waiter at a restaurant.

Imagine that Meta is a restaurant. The waiter is the API and when you go to the restaurant, you can make a request to the waiter from the menu.

This is how it works for us. Each API has documentation, a kind of catalog, which you can think of as the menu at the restaurant. We can request data from what’s available on the menu. The API is the waiter, it takes our request and sends it to the kitchen – which is the back end of these platforms.

The request gets processed, and then the waiter delivers you what you ordered. In our case, that’s the API providing us with the data we requested. However, we are kind of limited by what’s on the menu. That means we can’t really get everything we want.

APIs and the limitations of third-party analytics tools

APIs do have limitations. The social media platforms themselves natively have access to the entire kitchen, so to speak. But we don’t have access to some of the deeper analytics, we can’t make very specific and exclusive requests – and that’s true for any third-party social media analytics tool.

There are some specific metrics like total reach, interaction metrics on Reels, and link clicks that you might not see in our dashboard because we don’t have any way to access that data.

Each platform sets other limitations too. Two of the main ones are how much historical data we can access, and how granular we can go when accessing data.

"APIs have some limitations" infographic listing three limitations: data not shared (total reach, interaction metrics), limited data granularity, and delayed feature availability.

Historical data

With historical data, each social network has limitations on how far back we can make data requests. In most cases, we can’t fetch years of data.

With Facebook, we can access two years of data, which allows us to show you a year-on-year trend in Planable Analytics. From the two years we get, we’re able to use the first year as a benchmark and then show your progress in year two. Then you, as the user, can see if the trends are increasing or decreasing.

On other platforms like TikTok, we only have access to two months of historical data. That’s a lot more limited but as soon as you connect your TikTok account in Planable, you do get ongoing from the date you connect to your page you’ll get the data forward

Granularity

When we talk about granularity as a restriction, there’s a big difference between what’s available natively and what we have access to via the API.

For example, Facebook’s audience insights provide you with very granular data. Natively, you can view the data in different formats, with details like the source of engagement and so on. But the API provides us with very limited data in terms of granularity.

That’s basically why the insights available on third-party analytics tools are more limited in this respect.

New features

As we all know, the various social networks like to introduce shiny new toys for all of us to play with. Whether it’s a new format, a feature, or a way to interact with content – these things are usually not available immediately via the API.

So, while you may see related metrics in the native analytics dashboards, it can take a few months for them to become available for us with the API connection.

Processing data natively vs via API

We’ve been working really hard to make sure that we always have the most accurate data available for you in Planable Analytics. We want you to see the same data that you see in the native dashboards.

However, this is a huge challenge because when we make the request to the API, the data we get sometimes shows differently from what you might see on the native platform.

Let’s explore why as we go through some of the biggest challenges we have for specific metrics.

Reach

One of the best examples is with reach. This is a really important metric for marketers – we all know that. So, let’s say you want to know how many unique users your content reached on Instagram.

"Processing the data natively vs via API" infographic explaining reach discrepancies: data is received per day/post, summing numbers isn't accurate.

We are actually able to get the rich data for this from Instagram, but it provides it to us in a different way than you see in the native analytics dashboard.

Through the API, we receive the metric per day, which means for each day in the calendar we can provide you with how many unique accounts your content reached.

Similarly, we can do that per post. So for each individual post, we receive the data for how many unique users saw it and then provide you with that data.

However, if you want to look at reach over a time period longer than one day, with a graph of how many new users have seen or interacted with your content – we can’t really provide you with that.

That’s because for us, if John Jones saw your content on Monday, he shows as a unique user. But then he sees your content on Tuesday, he will be a unique user again for Tuesday. The same goes for Wednesday, and so on.

In reality, over a longer time period like a week, John is one unique user. But because of how we receive the data from the API, John would show up as 7 unique users over a full week (assuming your content reached him every day).

That would result in wildly different metrics than you would see on the native platform, which knows to treat John as one user for the whole week.

This is a big struggle and we’ve been looking at ways to solve this, as well as how other tools are trying to solve this issue.

"Processing the data natively vs via API" infographic detailing SoMe tools' data processing: approximation, redefined as daily reach, partial display.

Some of them try to approximate this number. They take the post reach and the daily reach, then they apply some formulas or coefficients and try to estimate a number that’s closely related to what you might see in the native dashboard. But this approach will never be precise.

Other third-party solutions we’ve seen are simply renaming the metric to ‘Daily Reach’ or something similar. This is a more accurate name for the data they are able to give you, but you still have the same limitation in comparison to the native dashboards.

What I’ve noticed about the bigger third-party analytics tools is that they don’t show this metric at all. They know the data they can provide for ‘Reach’ is not precise, and that it’s not as useful to see it in a daily format. So, they just don’t show it anywhere.

Engagement

Working with engagement data is interesting too. In Planable Analytics, we calculate engagement by summing up the total number of shares and reactions. This is the classic formula, but there are other ways and some tools prefer to do it differently.

For example, assigning some sort of weight to each engagement. Maybe they think comments should be valued more than reactions, so they create a custom formula. Some tools and platforms use this kind of custom formula to measure engagement, which explains why you might see a different score on each.

"Processing the data natively vs via API" infographic explaining engagement metrics: comments, shares, reactions, custom formulas, LinkedIn includes page follows.

One thing we found on LinkedIn is that the platform counts page follows as engagement. So, if someone followed your page it counts as an engagement for that particular day within the native analytics.

This puzzled us for so long. We didn’t understand why our numbers were off. Then we realized it’s because LinkedIn counts page follows as engagement.

Stories

We’ve made it possible to publish Instagram Stories directly from Planable and there is actually a way to get insights on Stories with the API. However, Stories are not like posts in the sense that they vanish after 24 hours. So, the only way for us to get the data is to make requests within each 24 hour period.

If we don’t, there is no way to recall the historical data. For example, when you connect your page to Planable we can’t get any data or insights from the Stories that you published in the previous month.

Some of the data on Stories is also limited by location. Interactions on stories, for example, or replies made in Europe and Japan, are not available to us via the API.

"Processing the data natively vs via API" infographic explaining stories data: valid for 24 hours, no historical data, location limitations (e.g., Europe, Japan).

Number of posts

In Planable Analytics, we have a metric that we show you for the number of posts. Now, with this, we just want to show the posts published with Planable combined with the posts we’re able to sync from the native platforms.

But, sometimes there may be a mismatch with the number of posts due to how Facebook works.

That’s because Facebook also counts ads as posts. There might be other post formats that we currently don’t support in Planable, so we don’t sync those. This can cause the numbers to differ from what you might see in the native analytics dashboard.

"Processing the data natively vs via API" infographic noting that post counts can sometimes differ.

Always compare apples with apples

As a result of all the data and information that we went through while building Planable Analytics, we know two things for certain:

  • The data on native platforms versus what third-party tools have access to via the API is going to be different, so it’s very unlikely you will ever get exactly the same results from a third-party tool as you would get on one of the native platforms.
  • When it comes to third-party analytics tools like Planable, we have to come up with these formulas for engagement, and so on, simply because there’s missing data.

What that means is that it’s important to compare apples to apples. If you have a tool that you’re using for analytics, just look into that tool and check your trends and your growth in that tool. The formula within that tool is going to be the same every week, every month, so it’s going to be accurate about things like whether you grew or not.

But if you look at the metrics from one tool and then compare them with the native social platform, or with another third-party tool, you can expect a difference. One that can skew your view and your results.

Nick Gudumac

Nick is a Co-founder & CTO of Planable. With a computer science background, he’s previously worked in a digital agency and built innovative advertising campaigns using-cutting edge technology for big brands. Nick is also an alumni of Techstars and MongoDB Accelerator, and has been featured in Forbes 30 under 30 list.

Try Planable for free

I want to know more, Schedule a demo

image