L.facebook.com Referral
Roy Dassow
The privacy and security measures are great for the user, however, it skews your data. The extra letter on the URL from splits your facebook visits across multiple referrals which makes the analysis harder. Fortunately, there is an easy way to fix this:
Whilst reviewing traffic sources on Google Analytics last month we discovered a new source of referral traffic called l.facebook.com which had never been displayed before and yet had managed to receive a significant number of sessions. We were intrigued to find out what this was so that we could ease confusion amongst fellow Google Analytics users.
We trawled through a countless number of web pages to try and discover what this could possibly mean but it seemed that everyone was in the same situation and utterly clueless as to what it could be. Further investigation lead us to what appeared to be a new addition to the family of Facebook sources which currently includes facebook.com (standard) and m.facebook.com (mobile).
The l.facebook.com is a form of traffic that has been redirected through Facebook through what is known as a link shim. A link shim is a tool that was created by Facebook in 2008 and protects Facebook users from malicious URLs.
Essentially, people who have vanity URLs for their personal Facebook profile often end up unintentionally releasing personal information. A vanity URL is when a URL displays a unique URL that is specifically related to your company name, brand or person i.e. facebook/companyname as opposed to facebook/hfg?iu90835khgssiref=ts.
Rather than Facebook releasing personal information on their subscribers they have enforced this new traffic code which provides the user with anonymity. In addition to giving visitors anonymity, it gives the site that they are about to visit the ability to record the traffic as if from Facebook, where as in the past it would have simply showed as general direct traffic on Google Analytics.
There is another source of referral traffic within the Facebook family called lm.facebook.com which is of the same nature as l.facebook.com but highlights whether the traffic is sourced from a mobile device with the use of the letter "m".
Keep in mind, every user who clicks on an external link on Facebook, is temporarily redirected to a link shim page, before being sent to the final URL. This is because Facebook needs to rewrite referrer data for security reasons.
Like mentioned before, Facebook is able to run a check at the time of a click (i.e. when a user clicks on an external link) and if they detect a malicious website, they will give you a warning.
For example, it removes usernames from referrer URLs, before web browsers send you to external websites so that your 3rd party analytics tools (Google Analytics for example) are not able to reveal who it is that clicked on the link (meaning the owner of the 3rd party website will not know your name when you click on their link).
It was a problem for Facebook because there was a huge number of users using the platform over HTTPS and lots of 3rd party analytics tools were not able to correctly record traffic coming from Facebook.
Facebook solved this problem by routing the click through the link shim page that is a non-HTTPS page. Users will stay on the temporary link shim page a few milliseconds before being redirected to the desired web page. This is why you see an anonymous Facebook referrer rather than a referrer from an unknown source (direct / none) in Google Analytics.
P.S. Again, these prefixes are added to the referral in Analytics because every user who clicks on an external link on Facebook, is temporarily redirected to a link shim page, before being sent to the Final URL.
If you have Edit permission at the view level, you can only apply existing filters to or remove them from that view, but cannot create new filters or edit existing filters.
P.S. You can also combine only specific Facebook referrals as well if you want. For example, if you only want to combine lm.facebook.com, l.facebook.com and facebook.com sources together, you can use these strings:
P.S. Google Analytics filters do not work retroactively on past data already collected in a View. Filters will start working only from the moment they are created and they are not going to change your historical data. You can use segments or table filters in Google Analytics to combine historical data.
Feel free to share this guide with your friends as well who might be struggling with the same problem. If you have any questions about the topic, please post them in the comments section below.?
If you use Facebook to drive traffic to your site, and Google Analytics to analyze those visits, there is a good chance that you have come across multiple referrals including m.facebook.com, l.facebook.com, and lm.facebook.com.
All these different referrals are just how Facebook handles their links internally, but they don't add any value to your Analytics, quite the opposite, they only split your data, making it harder to analyze your Facebook campaigns and posts.
Note: You may get the message "This filter would not have changed your data" don't worry the filter will still work, this happens when there is no match in the small sample data used by this feature.
Now, don't worry!, most of the time when you see an l.facebook.com it is just for privacy reasons. But if you want to make sure you are not flagged, just open one of your links from Facebook, if you don't see any warning then it's OK.
Starting in April 2014, you may have noticed social referrals from Facebook coming into Google Analytics (GA) as source/medium lm.facebook.com and l.facebook.com. These referral visits from Facebook were being reported as visits from an unknown source until Facebook implemented the link shim. The link shim is designed to protect the personally identifiable information (PII) of users, and to warn users with an interim page when they are at risk of being redirected to a spammy or malicious website.
Here is a screen shot of lm.facebook.com and l.facebook.com referral sessions reported in the GA interface. m.facebook.com is mobile, and l.facebook.com and lm.facebook.com are referrals from Facebook via the link shim system.
Before the link shim, visits from users operating on a secure server network came in as unidentifiable. This is because when a user is on a secure network, the referer header is not passed along. Basically what this means is that when a user clicks on a hyperlink and lands on a webpage, that destination webpage has no information about where the user came from.
Facebook has a list of websites that they deem dangerous in some way. The list is refreshed on a regular basis. When a user is on Facebook or accessing Facebook through their email and they click on a link, Facebook cross checks the link with their database and warn the user if the site they are going to be redirected to is flagged as malicious.
In short, the link shim is a great system for both digital marketers and users. Digital marketers can report the ROI of Facebook more accurately. Users can rest assured that their identity is secure, and that they will not end up on malicious websites if they click on a link from Facebook.
The best way to describe how the l.facebook.com referral shows up in Google Analytics is to think about when you post or share on Facebook. If you were to write a Facebook post that included a link to your website, shared it to your feed and someone clicked on that link, the click and resulting traffic to your website can result in the l.facebook.com source to show up in your Google Analytics account. The same thing can happen if you write and publish a post, but then a connection shares your post and someone else clicks on the link, the same thing can occur whereas l.facebook.com (technically in this scenario lm.facebook.com) will show up in your reporting.
There really is no difference. These are simply different ways that Facebook has sections of their website and service operating on different servers, tracking link clicks and attributing behavior to their own systems.
Again these are all basically the same with the exception of the business.facebook.com subdomain. That one is specific to the Meta Business Suite product that can be used to better manage a Facebook Page, users, permissions, ads, apps, etc.
If Facebook detects that the clicked link is malicious, then it redirects the user to an intermediate page, which warns the user of the malicious website ahead and gives them the option to return to Facebook:
The link shim tool is actively used to rewrite Facebook referrers, in order to hide personally identifiable information like removing user IDs from referrer URLs, before web browsers send them to external websites.
In order to fix this problem, Facebook started using an internal redirect script, that first redirects a visitor to a non-HTTPS page (which creates its own referrer data) before sending the visitor to the actual URL on an HTTP website.
Facebook uses onmousedown handler that modifies the link (into link shim link) after a user has clicked it. So your web browser sees the link shim link first before it is redirected to the destination link. All of this happens so fast, that as a user, all you see is the URL of the final destination page.
Have you have noticed that you have traffic from l.facebook.com and lm.facebook.com? Traffic which is coming from mobile link shim is reported as lm.facebook.com and traffic which is coming from desktop link shim is l.facebook.com
These prefixes are added to the URLs before being sent to the final URL because Facebook temporarily redirects the external link on Facebook to their link shim page. But make sure that both the l.facebook and lm.facebook are Facebook referral traffic only.
c80f0f1006