Written by ContentPowered.com
As of about a week ago, you may have noticed something a little distressing. All of your new content is reporting 0 shares on Facebook. Your share buttons are either zeroed out or they have a blank spot where a number should be. You might be frantic, looking for reasons why people suddenly don’t like your posts. Is a link wrong? Is it trying to report data on something that doesn’t exist? You can check, and your posts on Facebook actually do have shares, so you have to wonder where the problem actually is.
The problem, as it turns out, requires a little understanding of how third party social plugins work.
How Plugins Work
Plugins pull their data from one of two sources, depending on the plugin. You can label these sources “good” and “bad” if you like. Those of you who know what scrapers are and what an API is can skip to the next section.
Bad sources are scrapers. These are plugins that load the page as normal, seeing all the content a user would normally see. They look for a specific piece of information on that loaded page, copy it, and use it for their application. This works, but it puts a lot of strain on the servers, because it’s loading a full rich page rather than just the information it needs. It also tends to have bot views recorded in analytics, which causes issues all around. As a consequence, these sorts of applications need to be updated constantly, because it’s a fight between the site and the plugin creator over security. A site like Facebook or Google will add countermeasures like user agent filtering and captchas for bots, and the plugin will add captcha breakers and rotating proxies. It’s an arms race with no winner, and it makes your data inconsistent.
Most sites, like Facebook in particular, avoid this by providing what is called an Application Programming Interface, or API. An API presents certain pieces of data in a plaintext format, easy to read and parse using a programming language. Rather than loading the entire site with scripts and CSS and all the rest, it sends a tiny set of bytes containing exactly the data you call for and very little else.
I would show you an example right now, but API calls require an authentication token generated from an app, which means you wouldn’t be able to see it. Suffice it to say, rather than loading multiple megabytes of page, it’s probably under a kilobyte of data. In the case of Facebook share counts, it’s a very small amount of data, just some basic information and the share count number.
Facebook’s API is called the Graph API. It governs a lot about how Facebook works in third party apps, everything from Insights hooks to shared counts to embedded content. The thing is, there are a lot of different versions of the Graph API. If you look at the changelog, you can see that the Facebook Graph API is up to version 2.7 currently.
Each new version of the API changes some things around, as detailed in the changelog. It’s not a complete rewrite of the API, but it is significant enough that a good portion of the apps and plugins that use Facebook’s Graph API will need to adjust to keep up to date. However, Facebook updates their API every few months. You can see the introduction dates for the last few versions: 2.3 was March of 2015, 2.4 was July, 2.5 was October, 2.6 was April of this year, and 2.7 was July of this year.
Rather than force everyone to keep on top of every API change, Facebook takes an understanding path. They recognize that it would eat up a lot of developer time to be that responsive. To make things nicer for apps and plugins, Facebook actually maintains a number of different versions of the API at any given time. If an API call changed in 2.4 and your app uses the 2.3 version, it still works for both the old and new format.
That’s why the table in that changelog page has both a “date introduced” column and an “available until” column. Currently, versions 2.1 through 2.7 are active, with 2.1 falling off in October of 2016.
The Root of the Problem
You may have been able to intuit the cause based on what I’ve written so far, and if so, good for you. The cause, as it turns out, is that every method of pulling the share count of a post on Facebook comes from the 2.0 version of the Graph API. This version was made unavailable back on August 7 of 2016, but there was a bit of a grace period, and the data didn’t completely stop working until closer to the 17th.
What this means is that, all of a sudden, all of the Facebook social share buttons stopped working at the same time. Yet, if you go looking for information on why, you won’t find much. The change happened all the way back in 2014, so there’s no recent documentation about it. Everyone has simply been clinging on to the old way until there was no choice left.
That’s why sites like SharedCount are shutting down; they tried and failed to find another way for the API to provide them the data they wanted for their service. Since they could not create a workaround and no replacement API has been created, they were forced to close their business. HowManyShares, meanwhile, still shows data for Google+, StumbleUpon and LinkedIn, but their Twitter and Facebook data is gone.
The change has been a long time in coming, but developers held out hope that they would be able to find a different way to provide social sharing information from Facebook. Updates to the API came and went, however, with no new added way to provide share count data. As such, social sharing buttons and third party apps no longer function.
The Twitter Footnote
Facebook is not the first platform to make this change, and I’m guessing they won’t be the last. Twitter was the first, as seen in this announcement.
Twitter’s case was a little different, and a little more akin to scraping rather than using an API. The “Twitter API” used for tweet counts was not actually an API, it was an unverified JSON call that wasn’t actually officially sanctioned. Twitter allowed it to continue, despite changing the format of the URL a few times, right up until the end of last year when they changed their base site architecture from Cassandra to Manhattan. If those names mean nothing to you, don’t worry; it’s not important for this post.
The fact is, Twitter removed their share counts and didn’t see much of a negative impact besides a lot of whining about it. They have a placating edit in their post about how they’ll use feedback about the removed counts in their development in the future. A lot of people expect this means they’ll eventually roll out a tweet count API officially, but I’m not so sure. I suspect they’re just waiting until it all blows over, people get used to not having the data, and life moves on.
The fact that Facebook has removed these counts is interesting. It’s not some precisely timed move, though; it’s a coincidence that Twitter removed theirs before Facebook. In fact, while Twitter counts are completely gone, there’s one remaining source of shared count data from Facebook; the official sharing buttons.
That’s right; Facebook’s official sharing button still includes the share count. It simply pulls data from a source that you can’t see as a standard user. APIs, as mentioned, require an authentication token to access. There’s no such token for you to use to get this data anymore.
Rationale
So why did Facebook decide to remove the share count API data? I believe it’s part of a slow push to move away from share counts as a specific metric. A lot of marketers blindly chase numbers, and you can see that throughout the history of marketing. PageRank is one big former offender, and the blind chase is why Google decided to stop updating PR in their toolbar. Klout, Alexa ranking, and other such metrics all fit the same bill. Share counts are just the most modern blind number chase.
There’s nothing wrong with striving to get more social shares, just like there’s nothing wrong with trying to get links from sites with high PageRank. The problem is that people don’t understand the value behind these numbers. Social shares are only as good as the people sharing it. Links are only as good as the sites they come from. Context is very important.
I think removing share counts is one small step on the way towards minimizing the blind chase for numbers, and encouraging sharing for the sake of value. Facebook is still going to encourage sharing, they’re not removing the function from their site entirely. Ads will still focus on getting shares and other forms of engagement. The only difference is, they’re making it harder to use contextless high numbers as badges of honor. Anyone can buy 10,000 shares from Fiverr and claim their content is great, but it fools no one. Now, it will be harder to use as a source of value.
Alternative Options
Now, I know you didn’t all come here just for my theories. If you’ve read this far, it means you’re looking for suggested alternatives to the Facebook share buttons that no longer work. I’ve come up with four options.
Option number one is to simply go without a count. With Twitter removing their share count, a lot of sites have started to switch to an entirely count-free layout. This is simply more encouragement to do so. The buttons still function as sharing buttons, but if you want to use a numerical indicator of value, you can use something else. For example, Business Insider uses their own “fire” metric, displayed at the top of each post. Mashable has their velocity graph, showing trends with social sharing ups and downs.
This may require a small change in your website design, or at the very least checking a different option on your social button plugin, but it’s not a very difficult change to implement. It’s more difficult if you want to use a derived separate metric like BI or Mashable, but that’s something you’ll need to talk to your developers about.
Option number two is to use the official Facebook share button. As I mentioned offhandedly above, Facebook still shows the share count in their official button. The thing is, that button is goofy and small, can’t be skinned, and generally doesn’t fit with other social sharing buttons. It’s pretty similar to Twitter’s buttons, though Twitter buttons no longer show tweet counts, so even having them side by side will stand out. The official Facebook button works, but it will probably look tacked on unless you have a dedicated tray for individual site plugins, rather than one unified social plugin. It will also probably be slower than an optimized plugin using a bunch of specific API calls.
Option number three is to find a plugin or share button that works using a scraper technique, or utilizing Facebook’s new API. I don’t know of any such buttons right now, but it wouldn’t surprise me to find that they exist. Feel free to look, though recognize that they will be in a constant battle to keep accurate data, and they may go down at any time.
Option number four is to use embedded feeds to simulate showing engagement. You can create a post about your blog article and embed that post in your article, at the top or bottom. You can do the same with a tweet. This allows people to click a “share” button that’s actually sharing that post, and you can see the numeric shares right there. It’s a little goofy and a lot slower than a nice API call for a small number, but it’s likely going to look a lot better than Facebook’s sharing button.
Regardless of which option you choose, you need to choose something, because a button displaying 0 looks bad. Make a change sooner rather than later; you can always adjust your design later for something better.
You can use the Facebook Sharing Debugger to fix this.