Floodlight Tag vs Google Tag (gtag.js) vs Meta Pixel: Enterprise Conversion Tracking Architecture

1. What Each Tag Actually Does

The three tags are not competitors. They report to different buying platforms, and each exists because its platform needs a signal the others cannot supply. Treating them as interchangeable is the root of most measurement confusion.

Floodlight: built for impressions, not clicks

Floodlight belongs to the ad-serving world. When you buy programmatic display or video through DV360, most of the value is delivered by impressions nobody clicks. Floodlight exists to answer a question click-based tags cannot: did the people who saw this creative convert later?

Two distinctions matter operationally. First, Floodlight counts view-through conversions, attributing conversions to served impressions within a configurable lookback window. Second, it comes in two counting methods that behave very differently: counter tags, which can count every occurrence or one per session, and sales tags, which record transaction value and item quantity. Choosing "counter, count every" for a purchase event is a classic error that reports one conversion per page refresh.

Google Tag: one library, two destinations

The Google tag consolidated what used to be several separate snippets. A single gtag.js load can now feed Google Ads conversions and GA4 events from the same configuration, which removed a whole category of bugs where the two were instrumented independently and drifted apart.

Its identity mechanism is the click identifier. When someone arrives from a Google ad, the landing URL carries a gclid (or wbraid and gbraid on iOS), which the tag stores. On conversion, that identifier ties the action back to the click. When the identifier is missing or expired, Enhanced Conversions provides the fallback path by matching hashed first-party data instead.

Meta Pixel and CAPI: two paths to the same event

Meta's architecture is deliberately dual. The browser Pixel captures what only the browser knows — the _fbp browser cookie, the fbclid from the ad click, user agent and referrer. The Conversions API sends the same event from your server, where it cannot be blocked by an extension or truncated by a cookie policy, and where you have access to authoritative order data.

Run properly, the two are complementary: the browser supplies match signals, the server supplies reliability and truth about the transaction. Run improperly, they double-count. Which brings us to the mechanism that decides whether your numbers mean anything at all.

2. Technical Comparison Matrix

The rightmost column is the one to memorise. Each platform has exactly one field that decides whether a duplicate is recognised, and each is named differently. Getting this wrong is the single most expensive mistake in the list.

3. Deduplication: The Failure That Inflates Every Number

When you fire both a browser event and a server event for one purchase, the platform receives two messages about one thing. Deduplication is how it decides they are the same. Get it wrong and every conversion counts twice — which means your reported CPA halves, your ROAS doubles, and the bidding algorithm optimises toward a fiction.

// The order ID is the single source of truth for the dedup key.
// Render it into the page from the server so both calls use the SAME value.
const eventId = "order_" + order.id;   // NOT Date.now()

// 1. Client-side Meta Pixel
fbq('track', 'Purchase', {
  value: order.total,
  currency: 'USD',
  content_type: 'product'
}, { eventID: eventId });

// 2. Server-side Meta CAPI - same event_name, same event_id
await fetch('https://graph.facebook.com/v21.0/PIXEL_ID/events', {
  method: 'POST',
  body: JSON.stringify({
    data: [{
      event_name: 'Purchase',        // must match exactly, including case
      event_id: eventId,             // must match exactly
      event_time: Math.floor(Date.now() / 1000),
      action_source: 'website',
      user_data: {
        em: sha256(normalise(user.email)),  // lowercase + trim BEFORE hashing
        ph: sha256(toE164(user.phone)),
        fbp: cookies._fbp,           // forward browser cookies to the server
        fbc: cookies._fbc
      },
      custom_data: { value: order.total, currency: 'USD' }
    }]
  })
});

// 3. Google Ads conversion - transaction_id is Google's dedup key
gtag('event', 'conversion', {
  send_to: 'AW-102938475/abcXYZ',
  value: order.total,
  currency: 'USD',
  transaction_id: order.id          // same ID, different field name
});

Three details in that snippet are load-bearing. The event_name must match exactly, including capitalisation — Purchase and purchase are different events and will not deduplicate. The _fbp and _fbc cookies must be forwarded from the browser to your server and included in the CAPI payload, or the server event loses most of its matching power. And normalisation must happen before hashing, not after.

4. Identity Matching: Enhanced Conversions and Advanced Matching

Cookie lifetimes shrank, third-party cookies became unreliable, and click identifiers stopped surviving long consideration cycles. Both Google and Meta responded with the same idea: match on hashed first-party data instead.

You take customer data you already hold legitimately — email, phone, name, address — hash it with SHA-256, and send the hash. The platform hashes its own user records the same way and looks for a match. Neither side transmits readable personal data, and the platform can attribute a conversion to a signed-in user even when every cookie has expired.

This is a silent-failure feature. Skip normalisation and nothing errors — the payload is accepted, the hashes simply never match, and your match rate sits near zero while the implementation looks complete. Check the reported match rate in Google Ads diagnostics and Meta Events Manager rather than assuming it works.

There is also a governance dimension worth settling before launch rather than after: hashing is not anonymisation. A hashed email is still personal data under GDPR, and sending it requires a lawful basis and disclosure in your privacy policy. Confirm this with whoever owns privacy compliance before you ship it.

5. Consent Mode, Regional Rules and Modelled Conversions

Consent Mode changes tag behaviour according to what the user agreed to. Rather than blocking tags outright when consent is denied, tags send cookieless pings carrying no identifiers, and Google models the conversions those pings imply based on observed behaviour from consenting users.

Two parameters matter most. analytics_storage governs GA4 measurement; ad_storage and ad_user_data govern advertising cookies and the transmission of user data. Setting defaults correctly per region — denied in the EEA and UK until the user acts, granted elsewhere if your policy allows — is the part most implementations get wrong, usually by testing only from the country the developer happens to live in.

Modelled conversions are worth understanding rather than resenting. They are estimates, they cannot be reconciled to individual orders, and they will not appear in your database. That is expected behaviour. The reporting mistake is comparing a platform number that contains modelled conversions against a backend number that contains only confirmed orders, and treating the difference as tracking breakage.

6. Choosing the Right Architecture

Which tags you need follows directly from where you spend, not from what is technically interesting.

The order matters as much as the list. Instrument one platform correctly and verify it end to end before adding the next. Teams that deploy all three simultaneously spend the following quarter unable to tell which tag is responsible for which discrepancy. If you are also weighing how these signals feed downstream models, our guide to marketing attribution covers what happens after the tag fires.

7. Server-Side Tagging: What It Solves and What It Costs

Once you are running three or more vendor tags, the client-side model starts to break down in ways that are more than cosmetic. Every tag is a third-party script executing in your users' browsers with full access to the page. Each one adds weight, each one is a potential point of failure, and each one sees whatever the page exposes — including data you may not intend to share with that vendor.

A server-side container inverts this. The browser sends one request to an endpoint on your own domain. That container then fans the event out to Google, Meta, and anyone else, with you deciding exactly which fields each vendor receives. The vendor scripts no longer run in the browser at all.

The sequencing advice is firm: do not move to server-side tagging to fix tracking that is currently wrong. Get the client-side implementation correct and verified first, then move it server-side for durability and governance. Teams that migrate while their deduplication is broken simply relocate the bug somewhere harder to see.

8. The Failures That Do Not Throw Errors

Every item below has cost a team a quarter of misreported performance. None produces a console error, which is precisely why they survive so long.

A monthly reconciliation habit catches all six: pull platform-reported conversions and backend orders for the same period, expect a stable gap, and investigate when the shape of the gap changes rather than when a gap exists at all.

8. Verification Checklist Before You Trust the Numbers

1. Complete a real transaction end to end and confirm exactly one conversion appears in each platform — not zero, not two.
2. Check Meta Events Manager for the deduplication indicator on the purchase event; it should report events as deduplicated rather than separate.
3. Confirm the Enhanced Conversions and Advanced Matching match rates are non-trivial. A rate near zero means normalisation is broken.
4. Repeat the whole test from an EEA IP with consent denied, then with consent granted, and confirm the behaviour differs appropriately.
5. Navigate to the confirmation page directly by URL and confirm no conversion fires.
6. Verify currency is present on every value-carrying event.
7. Reconcile one full week of platform conversions against backend orders and write down the expected gap, so future drift is measurable rather than debatable.