The Facebook Login ID (fb_login_id)
Sending the Facebook Login ID is a pro feature. Get the pro version here
The Pixel Manager can send Meta's Facebook Login ID with your Conversions API events. It is one more identifier Meta can use to match an event to a real person, and it is available for every customer who signed in to your shop with their Facebook account.
You do not need a new plugin from us to get it, and the Pixel Manager does not add social login buttons to your shop. Instead it reads the identifier out of the social login plugin you already use. If you use one of the seven supported plugins, the identifier is one setting away.
What the Facebook Login ID is
When a visitor signs in to your website with Facebook, Meta hands your website an identifier for that person. It is unique to that person and to your Facebook app, which is why Meta calls it an app-scoped ID.
That identifier is interesting for tracking because it is deterministic. Most of the customer data you send to Meta is probabilistic: you send a hashed email address and Meta looks for an account with the same hashed email. That works well, but it depends on the customer using the same address at your shop and on Facebook. The Facebook Login ID skips the guessing. It came from Meta in the first place, so Meta knows exactly whose it is.
Meta accepts it in the Conversions API as the fb_login_id parameter, and it is one of the few customer parameters that is sent unhashed.
What it does for your Event Match Quality score
Meta scores every Conversions API event with an Event Match Quality (EMQ) score from 0 to 10. The score reflects how much usable identifying information the event carries. More identifiers, and better identifiers, mean a higher score, and a higher score means Meta can attribute more of your conversions and build better audiences from them.
The Facebook Login ID raises that score, and here is the honest picture of by how much.
What it adds. With Advanced Matching enabled, the Pixel Manager already sends Meta a substantial set: the hashed email address, phone number, first and last name, city, state, postcode and country, plus the click ID (fbc), the browser ID (fbp), an external ID, the IP address and the user agent. The Facebook Login ID is an additional, deterministic identifier on top of that set. For customers who signed in with Facebook, their events become as identifiable as they can be.
What it does not do. It will not rescue a low EMQ score on its own, for two reasons:
- It only exists for customers who actually signed in with Facebook. Customers who checked out as guests, or who signed in with an email and password, or with Google, have no Facebook Login ID. On a typical shop that is the large majority of orders.
- The email address and phone number already do most of the work in the score. Adding a further identifier to an event that is already well matched moves the number by less than adding the first one did.
So the honest order of operations is this. If your EMQ score is low, the Facebook Login ID is not where the points are. Set up the Conversions API and turn on Advanced Matching first, because that is what puts email, phone, name and address into your events and that is worth several points. Once those are in place, the Facebook Login ID is a genuine, free improvement on the events it applies to.
And if you are choosing whether to offer social login at all: offer it because it removes friction at signup and checkout, which is a good reason on its own. The better match quality is a real bonus that comes with it, not a reason to add a login flow you did not otherwise want. On a shop where most people check out as guests, do not expect the score to jump. On a membership site, a subscription shop, a course platform or a B2B store where customers routinely sign in, the share of events carrying the identifier is much higher and so is the benefit.
Supported social login plugins
Every plugin on WordPress.org that offers Facebook login was reviewed. These seven store the Facebook identifier in a way the Pixel Manager can read, so all seven are supported:
| Plugin | Notes |
|---|---|
| Nextend Social Login and Register | The most widely used option, and a good default choice. Facebook login is in the free version. |
| miniOrange Social Login and Register | Supports a long list of providers besides Facebook. |
| UsersWP Social Login | An add-on for the UsersWP membership plugin. |
| Super Socializer | No longer available for download from WordPress.org, but still supported for shops that already run it. |
| Wapu Auth | |
| Heateor Login | Facebook only. |
| Easy Social Login |
Whichever one you pick, you configure it with your own Facebook app, following that plugin's own setup instructions. The Pixel Manager never asks for Facebook credentials and never handles the login itself.
Important: the Facebook app and the pixel must belong to the same business
This is the one requirement that catches people out.
The Facebook Login ID is scoped to the Facebook app that issued it. Meta can only match it to your pixel data if the Facebook app you configured in your social login plugin is in the same Meta Business Manager as your pixel.
If the app lives in a different business, the identifier is meaningless to your pixel. Meta will not report an error and nothing in WordPress can detect it. The events simply will not benefit. So when you create the Facebook app for your login plugin, create it in the same Business Manager that owns your pixel.
Plugins that cannot be supported
If you use a social login plugin that is not in the list above, it is for one of these reasons.
The plugin does not keep the identifier. Some plugins use the Facebook identifier during login and then discard it, storing only which provider the customer used. There is nothing left on your site for us to read. This applies to Wp Social, Login & Register Forms, Happy Social Login, Ventra Connect, Login Me Now, Titan Social Login, SocialAll, TomS Social Login, Rundiz OAuth, Social Login by BestWebSoft and WP Social AutoConnect.
The identifier belongs to someone else's Facebook app. Some plugins route the login through the plugin vendor's own Facebook app rather than yours. The identifier they receive is scoped to the vendor's app, so Meta could never match it against your pixel, no matter what we did with it. This applies to OneAll's Social Login.
If you would like your social login plugin supported, the requirement is simply that it stores the Facebook user ID against the WordPress user, and that it authenticates through the site owner's own Facebook app. Get in touch and we will take a look.
What about Google login?
There is no equivalent for Google. Google Ads matches conversions on a hashed email address, and the Pixel Manager already takes the email address from the order, so a Google sign-in adds nothing that we were not already sending. Google does not offer a deterministic login identifier that Google Ads accepts the way Meta accepts fb_login_id.
This is worth knowing if you are choosing which providers to offer: for tracking purposes specifically, only the Facebook button adds an identifier.
How to enable it
- Install and configure one of the supported social login plugins, with a Facebook app that belongs to the same Business Manager as your pixel.
- Make sure the Meta Conversions API is set up in the Pixel Manager, and that Advanced Matching is enabled. The Facebook Login ID travels with the Conversions API events and follows the Advanced Matching setting.
- Enable Meta (Facebook): Send Facebook Login ID in the Pixel Manager settings.
The setting is off by default. When a supported plugin is detected, the Pixel Manager also surfaces this as an opportunity in the admin, so you do not have to go looking for it.
Checking that it works
In Meta Events Manager. Open Events Manager, go to your pixel and open the Test Events tab, then place a test order while signed in to your shop with Facebook. The event should list fb_login_id among its parameters.
In the Pixel Manager debug info. The debug info has a Social Login (Facebook Login ID) section reporting which supported plugin was detected, whether the setting is on, and whether an identifier could be resolved for your own user account. If you linked your own Facebook account to your admin user, that line is the quickest confirmation that the reading side works.
Give the score time. The EMQ score is calculated over a rolling window of recent events, so it will not move the moment you save the setting. Compare it after a few hundred events have come in.
Troubleshooting
The parameter never appears. Work through it in this order: is a supported plugin active, is the Conversions API set up, is Advanced Matching on, is the Facebook Login ID setting on, and did the test customer actually sign in with Facebook rather than with an email and password. The debug info section answers the first three at a glance.
It appears, but the EMQ score did not move. The most likely cause is that the Facebook app of your login plugin is in a different Business Manager than your pixel, which makes the identifier unmatchable. The second most likely cause is simply that too few of your customers sign in with Facebook for it to show up in an average across all your events. Check what share of your orders come from customers who signed in with Facebook before concluding something is broken.
Only some events carry it. That is expected. Guests and customers who signed in another way have no Facebook Login ID, and their events carry the email, phone and address identifiers as before.
Privacy note
The Facebook Login ID is personal data. It is not treated as a special case: it travels inside the Conversions API event alongside the rest of the Advanced Matching data, so it is governed by exactly the same rules as the email address and phone number you already send. Whenever an event is suppressed because the customer did not consent, the identifier goes with it, because the whole event is withheld rather than individual parameters being stripped.
Two settings widen that, and they widen it for all Advanced Matching data, not just this identifier. If you have enabled Always Send Server-Side Events, events are sent regardless of the consent state. And an order that carries no consent snapshot at all is sent by default, unless you opt into requiring one through the pmw_s2s_require_consent_snapshot filter. If you operate under an explicit consent regime, review both of those.
The identifier itself is stored on your site by your social login plugin, not by the Pixel Manager, so when you describe in your privacy policy where the data comes from, name that plugin.
