Jetpack: Sharing: Facebook counts differ for http and https URLs

[wjkowalski]

Before changing to the internal API for Facebook share counts, we would request both the HTTP and HTTPS counts from Facebook. After the revert back to using Facebook’s API, we only count the current URL. For sites that operate on either protocol or have switched, this results in a decent drop in their output. For example, all WP.com sites forced HTTPS recently, effectively resetting their Facebook counts.

[kraftbj]

cc: @aduth

[aduth]

Related: #2495

Reasons we shouldn't sum counts:

• More often than not, Facebook will report the same count for both protocols, resulting in a falsely doubled count (see #1560)
• We should avoid inconsistencies between the numbers reported by custom-style sharing buttons and official sharing buttons

Website owners should:

• Ensure that their website uses a single canonical URL. Serving both HTTPS and HTTP for a single domain is not a good practice -- in the same way that you should not serve both WWW and top-level domain, and instead redirect to one or the other.
• Submit feedback to Facebook that 301 redirects should be considered in share counts reported

One option we could pursue is to add a filter enabling developers to override the URL used in requesting share counts. Currently, this logic is almost entirely client-side JavaScript and is not friendly for developers to override. Noting this, I won't have the bandwidth to take a deeper look at this for at least a couple months.

[kraftbj]

Reading through the old tickets and testing:

1. It seems like if the item was shared/liked when a HTTP->HTTPS 301 is in place, Facebook automatically sums. e.g. Site A is https://example.com/post-slug/ and I share http://example.com/post-slug/ -- this will bump FB's share count for the https site. I assume FB respects the canonical and "assigns" the action to the canonical URL.
2. For sites that were canonically changed, e.g. WordPress.com changing all *.wordpress.com sites from http to https, Facebook does not pull both the http and https values—it just returns the canonical's value, which based on 1, has already been credited with http shares after the canonical was changed to https.

In other words, it seems that Facebook credits the canonical URL at the time of the action with the action. I suppose for Jetpack's users, that's one thing since that was their option to do so. Hurts more for WP.com users who didn't have an option (unless using a custom domain).

Filter(s) would be nice. Thinking aloud, that would let a developer write up code, knowing when the site changed canonical style, could dynamically determine when to sum the canonical URL with some other URL(s). In my case, I could write a filter if the post date is before May 1, sum my canonical with my previous URL structure, etc.

We should be able to backtrack—roughly at least—when wp.com was switched over and implement something similar.

It would be different behavior than the official buttons, but I'd argue this is better behavior, as long as we have it documented. :)

[aduth]

In other words, it seems that Facebook credits the canonical URL at the time of the action with the action.

Correct, and apologies that my previous message was unclear. Facebook does follow redirects when a share is made, but it will not retroactively consider share counts for redirects put in place after the initial share action.

[kraftbj]

Noting too that it seems like if the share was made with a HTTPS canonical, FB credits both.

Compare:
http://graph.facebook.com/?id=https://kraft.im/2015/06/fathers-day-truth/
http://graph.facebook.com/?id=http://kraft.im/2015/06/fathers-day-truth/
(both report 35 shares)
That URL has always been HTTPS with a HTTP->HTTPS 301.

http://graph.facebook.com/?id=http://kraft.wordpress.com/2014/04/02/put-down-the-phone/
http://graph.facebook.com/?id=https://kraft.wordpress.com/2014/04/02/put-down-the-phone/
(http reports 25, https report none)
The post was published when the canonical was HTTP. No likes/shares since the URL changed to https.

[kraftbj]

Letting this soak, but not a quick fix. Moving the milestone.

[timdream]

The post was published when the canonical was HTTP. No likes/shares since the URL changed to https.

Does Automattic has contacts to Facebook that could ask them to expose some kind of API allowing people to move their canonical URLs, at least from HTTP to HTTPS?

[kraftbj]

@aduth can weigh in on the current situation. I believe we explored various options with them, but been awhile now.

[aduth]

We've reached out to Facebook contacts multiple times in the past regarding this issue, and have tried to make a strong case for transitioning counts for redirects (or at least treating HTTP/HTTPS as the same), especially as the web continues to move toward HTTPS everywhere. They had seemed receptive to the idea, though we got the sense that it was not an active priority for any of their teams at the time. I'll see to following-up to determine whether any progress has been made or if we can push for it to become a focus.

[timdream]

@aduth Thank you very much for the update.

[aduth]

Oh, I had also meant to share a link to Facebook's documentation where they describe workarounds for preserving counts when a URL changes:

https://developers.facebook.com/docs/sharing/webmasters/crawler#updating

[jeherve]

Also reported here:
https://wordpress.org/support/topic/sharing-social-share-counts-are-gone/

[jeherve]

Also reported here:
https://wordpress.org/support/topic/lost-no-of-shares-on-my-blog-posts-on-moving-from-http-to-https/#post-8735767

[georgian29]

I had the same problem and I've found a fix here: https://cognitiveseo.com/blog/13431/recover-facebook-shares-https/

[kraftbj]

Thanks for sharing that @georgian29 !

Since this issue is, all in all, in Facebook's court to change globally and there's not a good way for us to do it on a massive scale, I'm going to close this issue. Please reopen if circumstances change.

[htdat]

New tix: 699175-zen

[kristarella]

Oh, I had also meant to share a link to Facebook's documentation where they describe workarounds for preserving counts when a URL changes:

We are now doing this on atomic sites (377-gh-atomic).

I wrote a plugin that will force the og:url to be HTTP and I'm pretty sure it fixes the issue for posts that were previously shared using HTTP (for other Jetpack sites not on Pressable):
https://gist.github.com/kristarella/e0efbac9011708f3c9ee34106b6f202a