Way back at the end of August, webmasters started to notice something distressing with their social sharing buttons. Some brands may not have noticed right away, while others saw it immediately. Share buttons, specifically the Facebook sharing button, suddenly started reporting 0 for the share count on their content.
Why the disparity in noticing it? Well, if you’re used to you content only getting a half dozen shares, you might not notice when a few linger on zero a little longer than normal. For brands that regularly get hundreds or thousands of shares, though, the zero is frightening.
What do you do? Do you go check Facebook to see how many shares you actually have? You can, but it’s tricky to see the full number. Do you dig into your site code to see if something broke? I know more than a few people immediately tried to update their plugins, assuming something broke, when it wasn’t the plugin’s fault at all. However, it is a problem that requires a little knowledge of how social sharing plugins work.
On one hand, you don’t need to panic. On the other hand, you probably should have noticed and known about this some time ago, since the change that caused it took place in 2014. It’s just tricky the way Facebook went about it, and it’s not something anyone expected to linger, so we have to deal with the fallout now. Thankfully, there’s an easy solution. Before we get to it, though, I’d like to discuss the reasoning behind the problem and why it’s a problem in the first place.
Every plugin that pulls social media sharing information does it in one of three ways.
The worst of the three ways is a scraper. A scraper is, generally, a tool that looks at a web page and pulls out a certain piece of data. Scrapers powered by Google are what index your website. Scrapers that scan Google searches are what power link indexes and tools like BuzzSumo. Scrapers are not inherently bad.
However, a scraper that looks for social sharing counts is probably going to check each time a user loads the page, because it checks when the script is run. If you get a few thousand views on your content, that’s a few thousand loads of Facebook running the scraper to pull that data. Compound this by every brand trying to use a scraper, and every hit to a page using one of those plugins, and it puts an immense amount of stress on the servers of the site being scraped. Oh, sure, Facebook’s servers can probably handle it, but it’s still a lot of traffic that isn’t benefitting them, so it’s in their best interests to filter it.
Sites like Facebook and Google tend to use a variety of anti-scraper tech. They use captchas, they filter based on user agent, and the rate limit actions. They’ll see the scraping coming from certain IPs and might block those IPs. However, none of these are the issue at hand.
The second type of plugin is a scraper with caching. This gets around the issue of scrapers by scraping once a day, or once an hour, or whatever, and caching the result. This means the number on your plugin might not be 100% accurate, but it will be within reason, and it won’t put undue strain on the destination site, nor will it get your plugin banned.
The third type are the best, and these use what is called an API. An API is essentially a way for a site to present certain pieces of data with accurate, up to date information, in an extremely lightweight way. Loading a Facebook page might take several megabytes of data all to scrape one number. Loading an API interface might be only a few bytes of data. It’s generally the preferred way to call for data.
Facebook has an API, that they call the Graph API. This API has a ton of data available through different calls, and plugin creators used it to find the social sharing data for a given URL.
The Graph API is not just one API, though; it’s actually a rolling series of API updates. You can see the versions in the changelog. The current version is 2.8, but versions stretching all the way back to version 2.1 are all active. Each version has the date it was introduced and the date it will be made unavailable. For example, the 2.1 version was created on August 7 2014, and ceased to be available the day before Halloween this year. The current version, 2.8, was created October 5th of 2016 and is promised to be available at least for two years.
Each updated version of the API changes some data, adds some calls, and removes others. The reason for having so many different concurrent versions is so that if a change is made that affects a plugin or script, that plugin or script can be changed to work with the new version with a grace period before the old version is removed.
The problem, as you can probably imagine, lies in the API. But how? If there’s that much of a grace period, why don’t plugins simply update their code?
The root of the problem lies with Facebook, rather than with the plugins. Facebook has actually removed the shared count API from their public API. Much like Twitter before them, Facebook has made a change to make share counts less available. However, unlike Twitter, Facebook still shows the share count. Twitter removed it from their buttons altogether, believing it wasn’t valuable enough to keep around. Facebook has decided to use it as leverage instead. The share count exists, but is only accessible from the official Facebook button. Using a third party plugin means it has to make an API call, and can’t.
With no data coming in from the API, what displays is up to the plugin. Generally, they will either not display anything or will display a 0. In either case, it looks bad when all your other social networks have counts, except Twitter of course.
The interesting thing here is that Facebook made this change back in 2014. That’s when they rolled out the first new API without the share counter attached. So why hasn’t anyone done anything about it since then? My guess is that they simply hoped that Facebook would roll out a new share count API before the last one expired. As it turns out, Facebook doesn’t want to do that. They’re perfectly fine trying to encourage people to use the official button rather than a third party button.
The easiest solution would be for a plugin to hijack the code of the official Facebook button and essentially just skin the button over in their own code, which would work as a sort of janky pseudo-API. Unfortunately, this doesn’t work, since the button is made intentionally difficult to skin.
Why, then, did Facebook decide they want people to use their official button rather than all of the code they’ve been used to using for years? It can’t be a way to lighten load on their servers, because if everyone switched to the official button, it would actually be more strenuous. After all, you’d be loading an image and API call, not just an API call.
It seems likely to me that Facebook wants to increase adoption of their official button, but also they wouldn’t mind if webmasters started looking for something more than just share count with their content. Too many marketers simply use Facebook as a way to get shares, without any regard for engagement or community.
There’s a slow trend of social networks making it harder to chase pure numbers. Twitter’s share count is one such aspect of this trend, and Facebook’s is following suit. You’ve probably encountered another example as well; Google stopped updating their PageRank display for casual users. That number was another marketers blindly chased, and it’s another that has been hidden from the public eye.
This is also a way to combat bot sellers looking to abuse fake accounts to sell shares. Every social network has a problem with these fake accounts, and it’s difficult to stay on top of the issue through manual actions or algorithmic bans. Twitter and Facebook are attempting to make those business models fail, by removing the obvious results. Without the pure number to look at, businesses will have to look at elements like engagement and conversion, which will be very low or nonexistent because of the nature of bot sellers.
Of course, this throws all of the social buttons out of whack on most sites. You don’t want to use the default Facebook button because, well, look at it. It doesn’t float nicely in a tray, it can’t be skinned to match your site, and it’s an eyesore with modern design.
What can you do? You can, of course, revamp your design to use native buttons only. This will probably slow down your site, as it now has to make more calls to more networks, but it should be a relatively minor slowdown.
Another option is to go without shared counts. Most modern social sharing buttons have the option to turn on or off numbers. If you don’t want to have a few buttons displaying counts and a few not, you can just turn off all of the counts. You’ll have uniform, functional buttons, but they won’t have numbers.
Another option is to use an “alternative” metric. Mashable’s velocity graph and Business Insider’s “fire” are both examples of this. You can even get a version of Mashable’s graph with the Social Buzz plugin.
Both of these options are aggregate and abstract measurements. They aren’t shared counts exactly, they’re derived metrics made up of totals of traffic, engagement, shares, and other metrics. It’s meant more as a “hey look this post is doing really well you should share it” sign to your readers, rather than a precise indication of how well your post is doing on each social network.
You can choose to use embedded feeds and embedded posts to show the engagement and share rates for the specific instance of the post when your page shares it, but this is clunky and isn’t likely to play out well on most sites. There’s no real reason to opt for this option, when better options exist.
My number one most recommended option is actually another third party plugin. Remember how up above I mentioned scrapers with caching? That’s essentially what this plugin does. It combines calls to APIs, scrapers, and caches with a robust pile of settings, allowing you to customize what you show and when. You can even set thresholds so that numbers are only displayed after you reach a total that makes the post look good.
If you’ve read this blog before, you might know what I’m talking about. If you haven’t, you can read our review of the plugin in question over here. It’s called Social Warfare, and it’s probably the best option for most sites looking to use social sharing buttons.
Social Warfare is even pretty cheap; it’s just $29 per year, which is an absolutely trivial cost for even small businesses with right margins. Make one extra sale and you can pretty much afford it right off the bat.
Regardless of which method you choose, you’re going to need to do something. Nothing looks worse for your Facebook presence than a big honking “0” where your social shares should be. If you haven’t taken care of the issue by now, you’re behind the curve and need to spend some time getting caught up.