Over 9000: unobvious difficulties of working with counters of social buttons (+ task)

One of the most popular functions of the social buttons "share" is the counter of perfect actions. A small number of likes and sherov can talk * about the "poor quality" of the material; large numbers, on the contrary, serve as a kind of social proof and force others to share content.

In a situation with large numbers, separate counters become relevant for each social network button icon. However, even the simple conclusion of such a counter is not always easy to organize - from a technical and visual point of view. Simply put:
')

• the counter may fall off at the most inopportune moment;
• some social services do not provide repost data in principle;
• and others are not always able to ensure the correct transmission of this information.

As developers of our own service of ready-made social buttons uSocial.pro, we know that more than half of the users ** set up separate counters for each button. Therefore, it was important for us to make sure that the numbers on the counters suddenly did not disappear and did not lie. We did not find ready-made tools for solving this task, so we had to develop our own - we will tell you about it today.

1. What can go wrong with social network counters?

It would seem that it may be easier to show how many people shared content, liked it or added it to your favorites? To do this, just need to analyze the list of social buttons installed on the site and send requests to each of the services, and then beautifully display the answer. But even here a number of problems may arise, there is no simple ready-made solution.

1.1 There is simply no digit

First of all, there may be no counters for buttons of a certain social network at all - as decided by the social network itself. For example, Twitter does not give data about the "share" on their buttons. As a result, you could observe a picture with different push-button services, in which for all social buttons there are numbers, and for tweeted they are missing:



It looks weird.

1.2 "They fell off"

Social networks pride themselves on high uptime, but it is clear that the servers responsible for the operation of certain services may periodically “fall off”. Therefore, there may be an awkward moment when the values ​​for several buttons may not be loaded in time. In terms of perception - again, not good.

1.3 "My eyes"

So, someone got over9000 reposts in all possible tapes. This information on the counters should be neat, understandable, and beautiful. But if the numbers are large, they need to be reduced - and these reductions may look very strange.

For example, the G + social network, all repost values ​​exceeding 9999, is abbreviated as> 9999:



Google’s main Russian competitor, by the way, is also not always sinless in such situations. For example, he can cut 496 letters to 99+. The meaning of this is not clear: the information is incorrect, and the same three characters are used to display it.

2. How we solved these problems.

Almost in no case did we manage to find the “magic pill” in other scripts and designs. I had to work by myself. They decided to start with the main thing - the lack of data on the number of rassharivaniy for some popular social networks.

2.1 Shares for Twitter and LJ, which were not there before

If a certain resource does not store statistics on the shares, or does not provide data to it through the API (as LiveJournal), then we store such information in ourselves.

MySQL is used for this with a shared table that stores the hash of the URL and the number of shareings on Twitter and LiveJournal. Under all conditions of work, this number is simply increased by one (incremented).

In addition, the database has separate tables for each social network, which stores the correspondence between the URL hash and the users who share content. In order to optimize performance and in order not to carry out additional checks, these tables contain a unique index for two columns - the URL hash and user ID. This allows, among other things, to protect against cheaters cheers one and the same user.

//      try { $shareInsert = $share->insert([ 'url' => $urlHash, 'usocial_user' => isset($content->usocialUser) ? $content->usocialUser : "" ]); } catch (QueryException $e) { //   ,  ,    url  usocial_user  , ..   //        . if ($e->getCode() !== '23000') { throw $e; } } //     if (isset($shareInsert) && $shareInsert) { $curUrlShares = SharesCount::where('url', '=', $urlMd5); //   URL   ,   if ($curUrlShares->count() === 0) { DB::table('shares_count')->insert([ 'url' => $urlHash, 'url_original' => $url, $content->provider => 1 ]); } //   URL  ,    else { $curUrlShares->increment($content->provider); } } 

In uSocial, users themselves create a set of “Like” and “Share” buttons for their sites, some of which may not include the Twitter and LiveJournal buttons in the set. In this case, we load the information only on the necessary social networks.

And to increase the download speed, when viewing a bar with buttons on the site, we display information from the cache, and not from the database - this has a very positive effect on speed.

2.2 What to do if nothing can be done

But rassharivaniya in Twi and LJ turned out to be seeds in comparison with Pocket. Its developers give data only when installing their widget on the site. At the same time, attention (!) Is given to the frame, in which quality even its creators are not sure. Here is their own description:

  <! - 
		 Please do not scrape this for the Pocket count. 
		 It is not a change. 
		 Contact us at api@getpocket.com for an official API. 
		 Thanks! 
		 -> 

We began to negotiate access to the API - but the guys from that side after each answer disappeared for a month. What to do?

They found out that the Japanese developer-enthusiast under the nickname ktty1220 implemented the method of receiving data from Pocket via Yahoo Query - it really works, but its reliability under severe load is not yet clear. So we still have Pocket only in the “Like” button sets:



And we still will solve a problem with rassharivaniye. The Pocket guys got in touch again in August.

2.3 Everyone has 0, and Facebook has 100,500 ...

Mapping problems may arise in more popular and familiar social services. For example, you may encounter a Facebook cache error.



The page was shared 0 times, and all the counters show this, except Facebook, which cached the value from the main page.

Where does 20 come from? It turned out that the site administrator visited a page with social network buttons that was closed to guests, a request went to Facebook, but the social network did not receive an answer about the accessibility of the page and recorded the number of reposts from the home page of the site (via redirect) to the cache.

Subsequently, this cache is not updated for a very long time - and only self-resetting the cache through the Facebook debugger helps here. A similar problem can occur with VK. To make it easier for users to debug, we finally released a debugger for two social networks at once.

2.4 Fighting fallen social networks

Since the indicators of most of the meters do not depend on our actions in any way, but are formed using the answers from social networks, we load all the counters asynchronously. By the way, from this link, you can view request formats for getting sherov of most popular social networks.

At the same time, if we do not receive a response from the server - what happens when the same “Vkontakte” and “My World” drops, then 0 will be given as the value, and while waiting for the answer, the user will see the counter pre-decoder.

2.5 Solving the problem of the counting curve and the design of native counters

As is clear from the example of G +, standard social services solutions are far from always appealing and simply understandable to users. To bring the appearance of the counters to a single standard, we started optimizing the display of abbreviations.

When a lot of people share material and the figure on the meter can go off-scale for over9000, it’s better to reduce it for beauty.

Here is how we do it externally:



And so - technically . First, we check if there is a common counter at all. If it exists, the responses arrSocCounter[id][iconName] from social networks are recorded in a dynamically created object arrSocCounter[id][iconName] , where arrSocCounter is an object, and id is the URL of the page we charm, iconName is the name of the social network (it is the name of the icon).

With the help of the data-url parameter, the required set is obtained, and by the data-item we will find out which social networks still remain. Then the cycle goes through the social arrSocCounter[dataUrl][dataItem] icons and summarizes the necessary values ​​from the previously obtained arrSocCounter[dataUrl][dataItem] .

And here we come to circumcising large numbers. Before you add the result to the counter, you must translate it into a format understandable to the system — serialize it. Then we count the number of elements in a row to see if we are dealing with a million, a thousand or ten sherahs. It does not make sense to check whether an integer or decimal number came in response in this case (20.5 people cannot share the article), so you can immediately proceed to counting characters in the string.

If the number is in the range of 4 to 6 characters, inclusive, then the value is converted to a floating point and rounded to decimal: parseFloat(value / 1000).toFixed(1) . In principle, this could be stopped, but then the value would be inaccurate - it does not suit us, so we convert the value to a string and cut off the last two characters, for example 1001:

 var val; val = parseFloat(1001 / 1000).toFixed(1); console.log(val) 

After performing these steps, we get a floating point number 1.0. Then it should be “overtaken” back to the line and cut off the last two characters, adding the letter “K” to the final result:

 var valOutput; valOutput = String(val).slice(val.lenght, -2) + 'k'; console.log(valOutput); var val,valOutput; val = parseFloat(1001 / 1000).toFixed(1); valOutput = String(val).slice(val.lenght, -2) + 'k'; console.log(valOutput); 

Conclusion and unsolved problem

Even such a not very difficult at first glance task, like creating a high-quality service of social buttons, is associated with certain difficulties. And there is a problem that we could not solve beautifully.

http = / = https

An interesting and non-obvious point is that social networks and their API often perceive the number of sherov for sites with http and https differently. That is, they consider that there are two different sites in front of them - and if earlier the resource owner switched over to https, he had to mentally prepare for the number of shareings on all his past materials.

So far we have found a way out: add a data-url = " site.com " and pass the URL parameter without http - if you really want to save the indicators.

But perhaps the community has ideas for a more beautiful solution.

***

That's all, thank you for your attention, and we will be happy to answer questions and discuss the problem http / https comments. And next time we'll talk about one more hitch - working with sharing buttons for messengers and other interesting buttons like “bookmarks”.

* Nielsen 's research on the role of likes and shera on perception of articles.

** Statistics on the installation of share sets with individual counters for each icon.