When discussing the metric set with customers as a base for creating meaningful reports, it is always about finding the metrics being closest to the actual success criteria defined by our customer. This sometimes involves intense discussion and having a close look at the definition of the available metrics to come up with the perfect set of metrics to tell the right story.

A typical report will cover both metrics for a customer’s owned channels and also those of competitors or similar businesses to classify if their performance is actually good or not in relation to other players in the same or similar market. Both parts are important to tell the full story.

This article focuses on how to build meaningful reports using Facebook Insights data to cover the owned channels perspective mentioned above. Similar challenges exist for other networks as well, e.g. Instagram, and it can be interpreted as a general advice to carefully think about what metric to pick for a specific use case.

Understanding the difference of metrics based on Page- or Post-level data

Pretty much every report covering the performance of Facebook Pages will include in-depth analyses about how many people have been reached. A very simple example might be showing how many people have been reached over the last six month, broken down on a monthly level.

Screen_Shot_2018-02-23_at_14.09.12.png

This metric named “Reach” can be found within our tool at:

https://app.quintly.com/discover/metric/24

While it seems to be very easy to read this chart at first glance, taking a closer look unveils a common challenge in reporting. It is about deciding whether to report on Page- or Post-level, or both. Following we will give definitions for Reach defined on Page- and Post-level to better explain the difference.

Definition of Reach on Page-Level:

The number of people who had any content from your Page or about your Page enter their screen. This includes posts, check-ins, ads, social information from people who interact with your Page and more.

Definition of Reach on Post-Level:

The number of people who had your Page's post enter their screen. Posts include statuses, photos, links, videos and more.

The first one defines Reach based on any content seen for the whole Page. The second defines Reach for a single post. Now take another look at the chart above and try to answer which of the following answers is correct:

  1. The chart shows how many people have seen any of your Page’s content within the last six months. (based on Page-level data)
  2. The chart shows how many people have seen any of your Page’s content published within the last six months. (based on Post-Level data)

The correct answer, in this specific case, is 1), because our default “Reach” metric is defined on Page-level. But this is not an obvious choice. There are fundamental differences:

  • A metric based on Page-level data assigns numbers to each of the intervals (months in our example) by looking at the time of the interaction (e.g. a user looking at a post in this example).
  • A metric based on Post-level data assigns numbers to each of the intervals (months in our example) by looking at the time when the post was published.
  • A metric based on Post-level data by definition can change in the future, because posts published in that time period can still build up further impressions.

Let’s take a look at the following illustration to explain this more visually:

Screen_Shot_2018-02-23_at_13.35.33.png

Start and End simply mark the time period we would like to analyze. The eye indicates a user seeing the post pointed towards with the arrow. It’s positioned on the time axis according to the time when the user is seeing that post (interaction time). The posts itself are positioned on the time axis according to their publishing time (post published time). Obviously posts can only be looked at after being published.

We are interested in the number of posts published and the Reach on Page- and Post-level for the time period specified by Start and End.

TABLE1.png

As you can see, Reach based on Page-level data is lower than Reach based on Post-level data in this scenario. This was just a simple example to motivate you to take a proactive choice whether to base your metric on Page- or Post-level data.

When to use Page- or Post-level data

Looking at our explanations before, you might wonder when to use Page- or Post-level data. The following table clearly indicates advantages and disadvantages of each approach and names potential use cases.

TABLE2.png

Using Post-level data without specific time period as a filter

The most common use case for metrics based on Post-level data (beside looking into the metrics per post as a table of posts) is measuring the performance of single campaigns. For now the only option we have been looking at is to set the time period to cover the posts belonging to a certain campaign. If it’s about measuring a campaign’s success, meaning looking at the performance of the posts belonging to that campaign, then why would we limit the time period at all.

Let’s take a look at another illustration:

Screen_Shot_2018-02-23_at_09.46.05.png

If we can simply tag posts with their campaigns, we could easily run analyses per campaign without a need to filter down based on time. To do so there is multiple options:

  1. Manually tag posts with their campaign names.
  2. Automatically detect the campaign a post belongs to by looking for characteristics specific to that campaign (e.g. specific hashtags or words being used).

Option 2) is always preferred over 1) as it can be fully automated. The only requirement is to have reliable characteristics uniquely identifying the related campaign.

Applying the same approaches for other social networks

While we have been using Facebook Insights data as an example for this article, the same underlying mechanics also apply to other social networks, like Instagram or YouTube.

In case you need help to apply this knowledge to your reportings, please let us know. We are more than happy to help you as a customer to find the best match for your specific use case.

Did this answer your question?