A client running mostly top-of-funnel traffic came to me with a stubbornly low Event Match Quality — hovering around 5. Their CAPI was firing fine, purchases and leads were flowing, but Meta just couldn’t match many of the events to real people. The reason was simple once I looked: most of their traffic wasn’t logged in, so email and phone were blank on the majority of events. Meta had almost nothing to match on.
We added one parameter — external_id — and within a couple of weeks the score climbed past 8. Nothing else changed. We just gave Meta a stable anchor for the users we couldn’t identify any other way.
External ID is one of the most overlooked customer-information parameters in the whole CAPI setup, and it’s quietly one of the most valuable. Here’s what it does, how to implement it in GTM, and the one trap that silently undermines it.
What external_id actually is
external_id is a unique identifier you assign to a user — your own customer ID, a loyalty membership number, or, most commonly for anonymous traffic, a first-party cookie value you generate and persist. It’s part of the user_data object Meta uses to match a server event to a profile in its graph.
The power of it is that it works when nothing else does. Email and phone are the strongest match signals, but you only have them for identified users. For the anonymous visitor who adds to cart before ever logging in, external_id might be the only durable identifier you can send. And because it persists across a user’s sessions, it lets Meta stitch multiple events to the same person over time — the view, the add-to-cart, the eventual purchase — instead of treating each as a stranger.
The golden rule: the same value on the pixel AND on CAPI
This is the single most important thing to get right, and it’s where most setups quietly fail. For external_id to do its job, the browser pixel and the server CAPI event must send the exact same value. If your pixel sends one ID and your server sends a different one, Meta can’t reconcile them, and you lose both the matching benefit and clean deduplication of your user signal.
The way you guarantee they match is to store the ID in a first-party cookie that both the browser and the server can read. Generate it once, drop it in a cookie, and have every event — pixel and server — pull from that same cookie. That’s exactly what the implementation below does.
The GTM implementation
Here’s a Custom JavaScript variable for GTM that generates a persistent external_id, stores it in a cookie, and returns it so you can feed it into both your Meta Pixel and your CAPI tag:
function() {
function generateUUID() {
var d = new Date().getTime();
var d2 = (performance && performance.now && (performance.now() * 1000)) || 0;
return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
var r = Math.random() * 16;
if (d > 0) {
r = (d + r) % 16 | 0;
d = Math.floor(d / 16);
} else {
r = (d2 + r) % 16 | 0;
d2 = Math.floor(d2 / 16);
}
return (c === 'x' ? r : (r & 0x3 | 0x8)).toString(16);
});
}
function setCookie(name, value, days) {
var expires = "";
if (days) {
var date = new Date();
date.setTime(date.getTime() + (days * 24 * 60 * 60 * 1000));
expires = "; expires=" + date.toUTCString();
}
document.cookie = name + "=" + (value || "") + expires + "; path=/";
}
function getCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i];
while (c.charAt(0) == ' ') c = c.substring(1, c.length);
if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length, c.length);
}
return null;
}
var urlParams = new URLSearchParams(window.location.search);
var externalIdFromUrl = urlParams.get('external_id');
var externalIdFromCookie = getCookie('external_id');
if (externalIdFromUrl && externalIdFromUrl !== '') {
setCookie('external_id', externalIdFromUrl, 365);
return externalIdFromUrl;
}
if (externalIdFromCookie && externalIdFromCookie !== '') {
return externalIdFromCookie;
}
var generatedUUID = generateUUID();
setCookie('external_id', generatedUUID, 365);
return generatedUUID;
}
The logic runs in a deliberate priority order:
- URL parameter wins. If the page URL has
?external_id=..., it uses that and writes it to the cookie. More on why this matters below. - Then the existing cookie. A returning visitor keeps the same ID they had before — that persistence is the whole point.
- Otherwise, generate a fresh UUID, store it for a year, and return it.
Once this variable exists, reference it in both places: as the external_id in your Meta Pixel’s Advanced Matching, and as the external_id in your server-side CAPI tag. Same variable, same value, both sides — matching intact.
The URL override trick (connecting known users)
That first branch — reading external_id from the URL — is quietly powerful. It lets you upgrade an anonymous cookie ID to a known one. Say you send a marketing email and append ?external_id=<your_crm_id> to the links. When that person clicks through, their random cookie ID gets overwritten with your actual CRM identifier, and from then on their events carry an ID you can tie back to a real customer record. It’s a clean bridge between your CRM and your ad tracking, and it’s especially useful for reconnecting a user across devices — the ID travels in the link, not just the cookie.
One caution: only pass an ID you’re comfortable using as an identifier, and keep it consistent with whatever you store server-side.
The trap: this cookie won’t survive Safari
Here’s the catch that undermines a lot of external_id setups, and it’s the reason I always look at how the cookie is set. This variable writes the cookie with document.cookie — client-side JavaScript. On Safari (and iOS), Intelligent Tracking Prevention caps JavaScript-set cookies at seven days, regardless of the 365 you asked for. So on a big chunk of your traffic, your “persistent, year-long” identifier quietly resets every week.
That defeats much of the purpose. The whole value of external_id is durability — an anchor that survives across sessions so Meta can connect a user’s journey over time. A seven-day cookie on half your audience isn’t that.
The fix, and this is where server-side matters: set the external_id cookie server-side, as a first-party cookie from your own subdomain via your server-side GTM container, rather than from browser JavaScript. A server-set first-party cookie isn’t subject to the seven-day cap and can genuinely persist. On Stape, the Cookie Keeper power-up does exactly this — it can extend that identifier toward the full lifetime instead of losing it weekly. The client-side version above is a perfectly good starting point and works fine for getting external_id flowing; just know that for real persistence on Safari-heavy traffic, the ID needs to be set from the server.
Don’t confuse external_id with event_id
A quick clarification, because people mix these up constantly. event_id is the deduplication key — it stops your pixel and CAPI from double-counting the same event. external_id is a user matching parameter — it helps Meta identify the person. They do completely different jobs, and you need both: event_id (ideally your order ID) for dedup, external_id (this persistent cookie value) for matching. Sending one doesn’t cover the other.
A note on hashing
external_id is customer information, so it should be handled like the other match parameters — hashed with SHA-256. In practice, the Meta CAPI tag in GTM (and the pixel’s Advanced Matching) will typically hash it for you. What matters is consistency: whatever value and treatment you use, the pixel and the server must end up sending the same hashed result, or the two won’t reconcile. Feed both from the single variable above and you stay consistent by design.
Mistakes to avoid
- Different
external_idon pixel vs CAPI. The cardinal sin. Both must read the same cookie value or matching and dedup of the user signal break. One shared variable prevents it. - Setting the cookie client-side and expecting a year. Safari’s ITP caps JS cookies at seven days. For real persistence, set it server-side.
- Confusing it with
event_id. External ID matches the user; event ID dedupes the event. You need both. - Regenerating the ID too easily. If your logic creates a new UUID when it should have found the existing cookie, you lose the persistence entirely. Read the cookie first, generate only as a last resort — exactly the order above.
- Passing sensitive data as the URL
external_id. Only use an identifier you’re comfortable treating as a match key, and respect consent.
Final thoughts
External ID is the parameter that keeps your match quality up when email and phone aren’t there — which, for most businesses, is the majority of their traffic. The implementation is genuinely simple: generate a UUID, persist it in a first-party cookie, and feed the same value to both your pixel and your CAPI events. The only real subtlety is persistence — a client-side cookie gets cut down to seven days on Safari, so for durable matching on modern browsers, set that cookie from the server. Get it flowing, keep it consistent across both sides, and watch your EMQ climb on exactly the anonymous traffic that used to be invisible to Meta.