Your social login is f*** up your conversions in Google Ads and Google Analytics.

7 min readApr 29, 2020

If you’re using Facebook, Twitter or Google logins on your website and care about correctly attributing the conversions then this post might be for you.

TL;DR; Social login breaks a Google Analytics session into 2 so that one visit becomes two. This breaks your initial referrer and conversion tracking among other things

Few years ago I’d launched a platform for peer to peer sharing/renting called Sharemos.com. It was kind of like Airbnb for all kinds of things people had to rent or needed. You could rent a camera, a snowboard or the famous drill. It was the sexiest project I’ve ever started and worked on. It was that one project that was making the world a better place. It didn’t go well.

Along billion other things that I’d learned working on that project as a founder/product manager/developer/designer/intern/CEO was one really important, but probably often overlooked thing that is messing up your data.

Like many other sites this one had the Facebook login aka the social login that allows singing into a website using the Facebook/Twitter/Google third party login.

The typical user flow when using one of these goes something like this:

User clicks on the Facebook login on your website
The button redirects the user to Facebook where they accept to share some data with your website (name, email…)
After few Next>Next clicks… user is redirected back to the website
This is where you save the data provided by FB into your DB and you consider the user registered. Good.

Now, what you’ll notice in your Google analytics or Mixpanel data is that you have a high number of visitors landing (starting their journey) on your success login page. If you dig deeper into that traffic you’ll see that the initial referrer is Facebook and not whatever the real initial referrer was. What?! How?!

What’s going on here is that Google analytics (and other tools I believe) resets the session when a referrer of the request changes.

Here is why…

When a visitor lands on your website coming from, let’s say, Google search a new session is started and the initial referrer is Google. But… After they login with Facebook and do the whole redirect thing Google analytics detects that the referrer changed from yourwebsite.com to Facebook and restarts the session. This user’s sessions count is now 2.

And here is what that looks like..

0. User searches on Google.com and clicks on your link in the SERP

The initial referrer would be… Hopefully by now you guessed it… google.com. And in Google analytics you would see this:

1. website.com/blog/landing-post (referrer: google.com) — session A starts
2. website.com/shop/product-1 (referrer: website.com)
3. website.com/registration (referrer: website.com)
4. User hits Login with FB and gets redirected to www.facebook.com
5. www.website.com/private/login-success-page (referrer: www.facebook.com) — session B starts
6. www.website.com/shop/product-1 (initial referrer: www.facebook.com)
7. www.website.com/shop/checkout-success (initial referrer: www.facebook.com)

If I didn’t lose you by now you’ve probably noticed that in the 5th step the referrer suddenly changes from google.com to facebook.com and that that starts a new session. The 1st session starts when the user lands on your blog post and the second starts when Facebook redirects back to your site. Oh, and now Facebook.com is the initial refer which means it’s facebook this visitor comes from ¯\_(ツ)_/¯

This wouldn’t be a huge a problem if you weren’t obsessed with correctly attributing your traffic and knowing where your users are really coming from.

Where this especially becomes a problem is when you start paying for your traffic and not knowing that info costs you money. Please tell me you do calculate the CPC, CAC, LTV… Please!

Google ads and Facebook login. Conversions not tracked at all.

I’m now working on this new brilliant idea — Pinabox.com. It’s a storage on demand service. Storages 2.0 if you like. I mean like real storage; not for files, videos, photos, but for boxes and shit… Not as sexy as the previous one, but this one is working great when it comes to less important things in life such as LTV, profit margins, ROI etc.

Pinabox.com is running Google Ads. We’re spending money to bring customers. More and more every day. I love it. It’s like shopping addiction, but for geeks. We’re also using the Facebook login. Hmmm… Guess what… The problem I described a min. ago also affects Google Ads attribution. The user comes by clicking our add, does some stuff on the website and then logs into using the Facebook login. Since the session is reset everything after that moment that we track doesn’t get traced back to the Google ads. Google charges you that click, but you have no idea whether that user fired any goals / conversion after the login.

After spending hundreds of euros we’ve noticed an obvious correlation between the higher traffic (cpc/paid) and the goal conversions. In Google Ads and Google Analytics I’d see a peak in traffic and also a peak in conversions we’ve decided to track, but weirdly enough only 10–15% of those conversions were attributes to Google ads we were running.

Digging deeper we’ve noticed that 80% the converters are coming from Facebook and their landing page was our success login page… Hmmm… Sounds familiar…

Google’s income is 85% ads based and this little ubiquitous problem is mentioned nowhere. I mean lots of Google Ads customers don’t even know that some of their expensive clicks are, in reality, converting.

Note: We are importing Google Analytics Goals into Google Ads to track conversions. I’m not sure if the problem I’m describing is affecting other setups they offer.

Solution(s)

Let me start with a solution that can be found on the web that is so bad that I simply had to mention it with the sole objective of warning you not to do it

Referral Exclusions

In Google Analytics you can add Facebook (and Google, Twitter for that matters) to your referral exclusion list. By doing so after your user logs into your website using any of the social login solutions Google Analytics will ignore the “new” referrer so it won’t trigger the new session. Thus, it will keep the initial referrer intact, conversions and so on.

So, why is this such a bad idea? Well, this would also mean that your legitimate visitors coming from Facebook (correct referrals) would be counted as direct/none in Google Analytics. We don’t really want that

Please note that some social logins such as Google use a separate subdomain accounts.google.com for their social login service so in this case you could add it to the exclusion list without affecting the traffic coming from Google.com

Overriding the Referrer

The correct option. Not the simplest one, but the correct one…

It consists of manually overriding the referrer when you know that the referrer is Facebook register/login redirect.

It looks like that if you override the referrer facbook.com/auth/xxx back to your http://website.com Google Analytics won’t trigger the new session.

To fix this you have 2 options…

Option 1 — manually adding the code

You can do this manually by adding some code and deploying it. Simply add the following code before anything else that you’re sending to Google Analytics on the page where your user lands after the redirect:

ga(‘set’, ‘referrer’, ‘https://website.com');

This code is telling Google Analytics to override the referrer and set it back to your website and since the the referrer is the same domain the session stays intact..

Option 2 — Using the GTM

In our case we’re using the GTM and the solution has more steps, but there is no extra code deploys and everything is centralized in the GTM.

The solution consists of reading the {{Referrer}} variable available in the GTM and when the value corresponds to Facebook’s oauth service we overwrite it with our domain. This way the session is not restarted and the User’s visit is still considered as a one single unit.

Step by step guide

Open your GTM https://tagmanager.google.com/#/home and go to your container
Open Variables in the sidebar menu
Find User Defined Variables and the button New to create your own
Click on Choose a variable type… and when it opens select Custom Java Script
Paste the code I provided below
Save the code (variable) with a meaningful / semantic name. Mine is “My FB Register Ref. Override”
Save and hit Preview in the top right corner
Open your website and open the console. You should see in the console that we’re not overriding the Referrer
Hit Register/Login with Facebook and you’ll see that the referrer is being overriden

The code:

function(){   var re = new RegExp(“facebook.com.*dialog/oauth”);   if(re.test({{Referrer}})){
      console.log(“Rewriting the referrer"); //remove it
    try {
      if(document.location.origin){
         return document.location.origin;
      }else{

         return “https://www.yourwebsite.com”
      } 
     }catch(error) {
         return “https://www.yourwebsite.com"
     }
   }else{
      return {{Referrer}}; 
   }
}

Few notes about this code:

If the referrer is facebook/oauth/dialog this code will try to set the document.location.origin as the referrer. As a fallback it will use the hardcoded string https://www.yourwebsite.com
You can remove console.log once you are sure it’s tested.
It’s only overriding the referral when the user registers with facebook for the first time. Subsequent logins are not overriden.
If you start adding more URLs, please refactor the code to use an array of referrals or something more scalable
the try / catch block is there for browser compatibility

Facebook Oauth path

Not sure why, but Facebook login uses different paths when you’re logging to your website with Facebook for the first time vs. subsequent logins.

In other words when you register using Facebook the referrer is https://www.facebook.com/v3.2/dialog/oauth/read/, but if you logout from your website and hit Login with Facebook the referrer will be https://www.facebook.com/

That’s why the code I provided will override the Referrer only in the first case which to be honest is not a problem if what you’re tracking are the first registers, first purchase etc.