People often ask me if they have a GDPR issue when they display share counts on their social media buttons.
The answer is (as always): it depends.
Why could this be a GDPR issue?
On many websites (including mine) you see a share counter next to e.g. the Facebook share button. The counting of shares is done by the social media platform and the visiting website can fetch these numbers by calling a API endpoint (a special URL that will return the share count for a given URL). While fetching the share count by visiting in this example the Facebook API endpoint you are actually visiting the Facebook website unknowingly 'notifying' Facebook of your surf behavior: Facebook knows who you are (ip address), where you came from, what you are looking at, and probably a whole bunch of additional information.
So to be GDPR compliant you have to add to your Privacy Policy that you make use of these share counts and that third party websites will collect information to build a profile. or disable share counts altogether... But share counts do add value for your visitors so disabling them is not a decision you should take lightly.
Why does it depend?
There are two ways to collect the share counts: server side and client side.
Client side
When collecting share counts client side it is the browser of the visitor that does the look ups (via JavaScript). Advantage is that page rendering is as fast as possible because for serving the webpage the visitor doesn't have to wait for the API calls for the share counts to complete. The page is served and the share counts are fetched and 'injected' after the page has loaded: no delay and always up-to-date share counts. Down side is that it is the visitor of your webpage who does the lookup and who then unknowingly shares his information with the social media platforms. When a social media platform is unresponsive for whatever reason, the visitor will not notice this in page speed. The only thing he might notice is that the share count for that platform is missing.
Server side
When collection is done server side, the lookup of the share counters is done on the server and the share counts are shared together with the rest of the page. No additional calls need to be made by the visitor of the webpage. So the social media platforms are not able to collect any visitor information because it is the server doing to look ups. Downside here is that the page load time increases because every lookup (no matter how fast) of share counts takes time. Time that is added to your page load speed. When a social media platform is unresponsive or slow for whatever reason, the visitor will directly notice because the webpage will not load (the server is waiting for a response or for a time out on the API call to the social media platform). Most likely the visitor will abandon your site and do business somewhere else (because page load speed does matter!)
How does ochJSsocials handle share counts?
Starting with version 1.0.6 ochJSsocials handles share counts server side. Earlier versions (<= 1.0.5) handled share counts client side.
I have changed the implementation from client side to server side for two reasons:
- GDPR compliance, now you have a sure way to be compliant with share counts. Share counts do add value to your website!
- Facebook, changed their share counter API end-point. You can now only fetch share counts if you have a valid user access token (user authorization on Facebook)
Creating a User Access token for the visitor would involve either the visitor login in to Facebook and granting your website access, or creating a User Access Token on the server and sending this along with the webpage to be used. Both options are actually not an option. Users are not inclined to do authorization on Facebook only for getting share counts and sending a user access token along with the page will expose that token to everybody (and everybody can (mis) use this token for the time of its validity.
So Server side it is
ochJSsocials implements the share counts server side and uses smart caching to be as fast as client side look ups.
Because ochJSsocials is a content plugin, it will only run on page rendering on the server side. if you have enabled caching on your joomla site, the share counts are part of your page and are for that reason cached together with the content (com_content). When there is no cache (first visitor) or the cache expired, then a new page will be rendered and new API look ups will be done.
But not everybody has enabled caching on their Joomla site because caching only works for 'static' pages. E.g. on my websites I have disabled caching because I am using Kunena Discuss for comments. This will lead to unforeseen issues when somebody ads a comment and that comment is not displayed because it is not in the cache and the cache didn't expire.
Also caching is turned of for registered users. So if you have a membership site where the user is logged in, every page that they visit will (default) not cache and will always be rendered.
So what ochJSsocials does is give you the possibility (advanced config setting) to, regardless if caching is turned on or off on your site, cache the share count API look ups. That means that when your page renders, the share count numbers will be fetched from the plugin cache (plg_content_ochjssocials). Only when the plugin cache is not present for that requested page or when the cache has expired the actual new look ups will be done.
Doing it this way guaranties that your page speed is as fast as possible, the only downside is that share counts are cached and therefore they might not reflect the actual count. So you need to find a cache life time that suits your needs.
What share counts are available?
Twitter stops sharing the share counts when they revoked their API end-point in 2015: https://blog.twitter.com/developer/en_us/a/2015/hard-decisions-for-a-sustainable-platform.html
Linkedin stopped serving share counts in February 2018: https://developer.linkedin.com/blog/posts/2018/deprecating-the-inshare-counter
So currently there are three platforms that still deliver share counts (and that will show in ochJSsocials when enabled):
- VKontakte
What do you think. Do share counters matter?
Image by Gerd Altmann from Pixabay