Blog · Floodlight and Google Ads
Floodlight vs Google Ads conversion tracking is a Campaign Manager activity, not an AW- send_to.
Floodlight vs Google Ads conversion tracking is two hits that both end up in a Google UI and do not share an identifier. A Floodlight activity tag is an image GET on doubleclick.net. Parameters ride on the path as semicolon pairs: /ddm/activity/src=123;type=conv;cat=purch;ord=987. src is the numeric Floodlight configuration id. type is the activity group. cat is the activity tag. The wrong cat is a silent wrong conversion, not a 404.
A Google Ads conversion is gtag event conversion with send_to set to AW-123456789/label, plus value, currency, and transaction_id when it is a sale. The image fallback is googleadservices.com /pagead/conversion/{conversion_id} with label on the query. View-through uses /pagead/viewthroughconversion/. Without label the hit lands on the account rather than a conversion action. An AW- id is not a Floodlight src. A cat is not a label.
Floodlight is not a conversion API. There is no event_time digit count and no SHA-256 email on the standard activity tag. Do not hash the path. Do not invent an event_id query because a CAPI playbook said so. Cache-busting is ord, and unique counting also wants num beside ord. Dedup is the activity counting method in Campaign Manager, not a shared UUID with the Google Ads tag.
ord=1 is an undercount, and a leftover macro never fired
src, type, cat, and ord are required on the activity. Unique counting needs num alongside ord. num without ord does not count uniquely. A live tag that still says ord=1 makes every impression the same GET, and the first cache hop wins. A timestamp plus a random, or a cache-buster expanded at serve time, is enough. Do not put an email in ord. Floodlight will not match a hash stuffed into the cache buster. Sales tags that want one ord per transaction are a different job from busting an impression cache, even though the parameter name is the same.
A fired URL that still contains [CACHEBUSTER] or an unexpanded GDPR macro never expanded. That is a template captured from trafficking, not a hit. GTM preview can show the macro as filled while the published container sends the bracket text. Confirm Network on doubleclick.net after publish. A filter on the word pixel misses this host.
Google Ads uses transaction_id to dedupe repeat fires of the same sale. Persist it. Do not reuse Floodlight ord as that id unless you meant them to be the same opaque token. The conversion tag should fire once, on the thank-you event, not on a URL pattern that also matches checkout. Purchase does not belong on the landing page.
Consent Mode does not fill the Floodlight TC string
Google Ads Consent Mode is ad_storage, analytics_storage, ad_user_data, and ad_personalization. Default denied, then update on choice. A conversion linker that never ran because storage was denied is how gclid dies before enhanced conversions can join. The linker writes first-party cookies so gclid survives to the thank-you page. Put it on every landing host. Floodlight on the same page still wants gdpr and gdpr_consent on the tag.
gdpr is 0 or 1. When it is 1, gdpr_consent has to be a TC string whose first six bits decode as version 2. gdpr_consent=1 and gdpr_consent=true are not that string. They can pass a loose alphabet check and still fail a decode. The same fields can be GPP and us_privacy on the Floodlight path. Consent Mode is not TCF. A green consent update in Tag Assistant does not expand the Floodlight macro.
Enhanced conversions hash email or phone after trim and lowercase, then SHA-256, on the tag or on the upload, not both for the same lead. The upload wants conversionDateTime as a datetime with a timezone offset, and one of gclid, gbraid, wbraid, or hashed user identifiers. That datetime is not a Floodlight ord and not a Meta event_time. Do not hash gclid. Do not put a raw email on either image URL.
Two URLs, two products
Illustrative. src, type, and cat come from Campaign Manager. send_to comes from the Google Ads conversion action.
Floodlight: https://ad.doubleclick.net/ddm/activity/src=123;type=sales;cat=purch;ord=1759010400123;num=1
Google Ads: gtag('event','conversion',{send_to:'AW-123/label',transaction_id:'order-1842'})Server-to-server Floodlight, if you use that Campaign Manager feature, still has to name src, type, and cat. It does not become a Google Ads upload because both are Google. The upload is a different API, a different id, and a different clock. Staging must use a staging Floodlight cat so QA purchases do not land on the production activity, and a staging conversion action so they do not land in the live Google Ads account.
Pixellint is not affiliated with Google. Validate the Floodlight URL with the Floodlight pack and the conversion URL with the Google Ads pack. One pass does not cover the other host. A 200 GIF is the start. The path still has to contain src, type, cat, and a real ord, or the query still has to contain label.
The loader is not either hit
googletagmanager.com/gtm.js or gtag/js loading a container is not a conversion. After it loads, Network still has to show the Floodlight activity on doubleclick.net or the Google Ads hit on googleadservices.com. A container that contains both tags will fire both if both triggers match. That is two products recording one thank-you, which is what you want only when Campaign Manager and Google Ads are both supposed to count it. It is double intent when someone copied the Floodlight tag into the conversion trigger by mistake.
Quantity and cost on a Floodlight sales tag, when you send them, are Floodlight fields. They do not fill Google Ads value and currency. value on the gtag conversion is the Google Ads number. Send each if each system is supposed to optimize. Do not assume Campaign Manager cost lands in the AW- action.
Image pixels are GETs. A fetch POST to those hosts is the wrong transport. Floodlight and the Google Ads image fallback stay images. The gtag conversion call is the tag, and it still results in a hit you can copy from Network. Paste that URL. Status 200 with a GIF is the start of the story.
Staging cats and staging actions
A production Floodlight cat on a QA site writes QA purchases into the live activity. Counting method then dedupes or accumulates them beside real orders. A production AW- label does the same in Google Ads. Use a staging cat and a staging conversion action. GTM environments exist to swap those ids. Do not reuse production secrets, and do not reuse production activity tags.
Enhanced conversions and Floodlight consent can both be wrong on the same page without either tag looking broken. Consent Mode denied means the linker may not store gclid. The Floodlight tag can still fire with gdpr_consent=1, which is not a TC string, and Campaign Manager records a non-consent. Fix the macro and the consent update separately. One green tag is not the other signal.
Validate each URL with its pack. The Floodlight pack checks src, type, cat, and ord. The Google Ads pack checks the conversion id in the path and label on the query. Core privacy rules read the Floodlight path for gdpr_consent. Run both. A single playground paste of the wrong host answers the wrong contract.
What does not transfer
- Floodlight src, type, and cat do not select an AW- conversion action. label does.
- ord and num are the Floodlight fire. transaction_id is the Google Ads sale id.
- Do not hash the Floodlight path. Do not put email in ord.
- gdpr_consent=1 is not a TC string. Consent Mode does not write that string for you.
- gclid belongs on the Google Ads join. It is not a Floodlight parameter.
- Offline Google Ads time is conversionDateTime with an offset, not Unix seconds and not ord.
- Filter Network on doubleclick.net for Floodlight and on googleadservices.com for the conversion image. A filter on pixel misses both.
Sources
Contract pages
The dated argument is above. These pages are the field lists.