Google Ads server-side conversion tracking
Send your store's conversions to Google Ads Data Manager API from the server, not from the browser: deduplicated with your Google tag on a shared event ID, gated on marketing consent and processed in the EU. No Google Ads script to deploy on your own cloud, no GTM server container to configure: one connection key, and the same event also reaches GA4, TikTok, Pinterest, Google Ads and Microsoft Advertising.
Your Google Ads account is connected by OAuth: no key, no client secret, nothing to paste into your store.
What is Google Ads server-side conversion tracking?
Server-side conversion tracking for Google Ads sends the sale from your server to the Data Manager API, the interface Google now uses to receive conversions. Instead of asking the visitor's browser to report the sale, your server sends the conversion directly. The request leaves your infrastructure, so an ad-blocker or a browser cookie policy has nothing to intercept.
A Google Ads conversion needs a click id
This is the part most guides skip. Google attributes a sale to an ad through the click id it put in the landing URL: gclid, or gbraid and wbraid for app journeys. No click id, no attributed conversion, whatever the tracking method. Server-side does not change that rule; it changes how reliably the id survives from the landing page to the order.
The order id is what prevents double-counting
The browser tag and the server both send the same transaction id for the same sale. Google matches them and keeps one. Without that shared id, running the tag and the server side by side inflates your reported conversions.
Consent Mode still applies
Moving a tag to the server changes where the request comes from, not whether you need permission to send it. Marketing consent still applies, and we enforce it on both layers.
Looking for the wider picture rather than Google Ads specifically? Read what server-side tracking is and how it works.
Why Google Ads shows fewer conversions than you sold
The pixel runs in the customer's browser: the one place in the chain you don't control, and the place under the most pressure.
-
Ad-blockers
stop the tag from loading on the order confirmation page: the conversion is simply never reported to Google Ads.
-
Safari ITP and browser cookie limits
shorten or delete the
_gcl_awcookie that carries the click id from the ad to the order. -
A lost click id
costs you the whole conversion, not part of it: Google cannot attribute a sale it cannot tie to a click.
The result is not just a reporting gap. Smart Bidding learns from the conversions it receives: under-reported sales mean the algorithm is bidding on a partial picture of what actually converts, and it will spend accordingly.
A managed Google Ads connection, without the plumbing
Install the connector for your platform, or call our API directly. Validated orders are sent server-side to the Data Manager API, deduplicated with your Google tag on the order id and gated on consent.
Conversions that survive the browser
The server-side purchase is delivered from your infrastructure. When the browser tag is blocked, that event is the one Google Ads receives.
Deduplication handled for you
The connector sends the order id as the transaction id
(transactionId for purchases) on both sides. You don't
wire up the matching logic yourself.
Click ids handled properly
gclid, gbraid and wbraid are validated and normalised before they leave,
including the GCL.<timestamp>. cookie wrapper the Google tag
writes. A malformed or placeholder value is rejected rather than sent: one bad
id degrades every campaign consuming that conversion action.
Nothing lost in transit
A retry queue replays retryable delivery failures automatically, so a brief outage on either side doesn't cost you a conversion.
Consent enforced twice
The browser layer injects nothing without marketing consent, and the dispatcher applies a second check before anything reaches Google.
No credentials in your store
Google Ads is connected by OAuth from your DataFirefly account, and the refresh token is encrypted on our side. A compromised store front-end has nothing to leak.
Inspector to prove it works
Every event and its per-destination status is visible in the Inspector, including the ones skipped for want of a click id, so you know why rather than guess.
One event, six destinations
The same conversion also reaches GA4, TikTok, Pinterest, Google Ads and Microsoft Advertising, no second integration to build.
Connecting your store to Google Ads
Connect Google Ads once, by OAuth
In your DataFirefly account, click Connect Google Ads and pick the account. Then map each event to its conversion action . An event with no mapped action is skipped cleanly, never sent against the wrong one. generated in Events Manager. They're stored encrypted and never sent to your store.
Install the connector for your platform
PrestaShop,
WooCommerce or
Shopware: then paste
your single dfss_ connection key. On any other stack, post
events to our API.
Verify in Google Ads
Place a test order from a real ad click, then check the Inspector for a delivered
purchase and confirm the conversion appears in Google Ads under the action you mapped, counted once.
Your own script, server-side GTM or a managed connector?
Three routes reach the same Data Manager API. They differ in what you have to run, and in whether Google is the only destination.
Your own integration
Code you write against the Data Manager API: OAuth refresh, click-id validation, conversion-action mapping, retries. Full control, and every future API change is yours to follow.
Server-side GTM
A GTM server container you host and configure, with a Google Ads tag inside. Maximum control over tags and variables, and a real GTM skill set required to build and maintain it.
DataFirefly
A managed connector: no container, no cloud account, one key. Google Ads plus Meta CAPI, GA4, TikTok, Pinterest and Microsoft Advertising from the same event, EU-hosted.
When another route fits better. If you have a developer who will own the integration and Google is your only channel, writing it yourself against the Data Manager API is perfectly sound. If you have GTM expertise in-house and need tag-level control over transformations, server-side GTM is more flexible than we are. We're the better fit when you want conversions reaching several platforms reliably without becoming a tracking infrastructure team. See also our Stape alternative and Addingwell alternative pages.
Google Ads server-side tracking for every e-commerce platform
PrestaShop
A native module that sends validated orders server-side, with deduplication and consent handling built in.
WooCommerce
A WordPress plugin with a retry queue, an Activity panel and HPOS support, delivering purchases server-side to Google Ads.
Shopware 6
A Shopware plugin covering the same funnel, connected with the same single key.
Shopify
Shopify's order webhooks, subscribed in minutes with the same single key. Nothing to add to the theme.
A headless front-end or a custom stack? Post your events to our API and the dispatcher handles Google Ads and every other destination the same way. Tell us about your setup.
Google Ads included in every plan
One subscription covers your whole account and all its destinations: Google Ads is not a paid add-on. Move up a tier for more sites and more monthly events.
Free
Free while you stay under the monthly allowance: nothing breaks if you go over.
Starter
For a single store getting Google Ads conversions in place properly.
Billed €390 per year: 12 months commitment, no pro-rata refund.
Growth
For merchants and small agencies running up to five stores.
Billed €1 190 per year: 12 months commitment, no pro-rata refund.
Scale
For agencies and portfolios managing up to twenty stores at higher volume.
Billed €3 490 per year: 12 months commitment, no pro-rata refund.
Just want to try the connection first? The free plan lets you send events and see them land before you subscribe.
Sending data to Google, under European rules
Server-side tracking moves where the request comes from. It does not move you outside the GDPR: so we built the consent checks in rather than around.
Events are processed in the EU before they reach Google.
Nothing fires client-side without marketing consent, and the server re-checks.
Google Ads is connected by OAuth and the refresh token is encrypted at rest, never sent to the browser or the store.
A malformed or placeholder click id is rejected rather than sent to Google.
A data processing agreement covering this flow is on our DPA page.
Tracked in real time on our public status page, in line with our SLA.
Frequently asked questions: Google Ads server-side tracking
What is server-side conversion tracking for Google Ads?
It is sending the sale from your own server to the Google Ads Data Manager API, instead of relying on the Google tag running in the visitor's browser. Because the request leaves your infrastructure rather than the browser, it is not affected by ad-blockers or by browser restrictions on cookies. Google's own guidance is to keep the tag and add the server side, with both deduplicated on the order id.
How do you send conversions to Google Ads server-side?
Three usual routes: write your own integration against the Data Manager API, run a server-side GTM container with a Google Ads tag inside, or use a managed connector. With DataFirefly you install the connector for your platform (PrestaShop, WooCommerce, Shopware) or call our API, then paste a single connection key. Google Ads itself is connected by OAuth from your account: there is no key and no client secret to paste into your store.
Will server-side tracking count my Google Ads conversions twice?
Not when deduplication is set up. Each conversion carries the order id as its transaction id, on both the browser tag and the server-side event. Google matches the two on that id and counts the conversion once. If the tag is blocked, the server event still arrives and the conversion is recorded: that is the whole point of running both.
Why do some of my orders never reach Google Ads?
Almost always because the order carries no Google click id. Google attributes a conversion through the gclid (or gbraid and wbraid for app journeys) placed in the landing URL, and if that id is lost between the landing page and the order there is nothing to attribute the sale to. It is not an error and we never invent a value: the event is skipped cleanly and shown as such in the Inspector. Orders from organic search, direct traffic or another channel have no click id either, which is normal and expected. So the id survives the browser, our PrestaShop, WooCommerce and Shopware modules capture it on the landing page (gclid, gbraid and wbraid) in a first-party cookie kept for 90 days, and carry it to the order from the server.
Is server-side tracking to Google Ads GDPR-compliant?
Server-side tracking does not remove the need for consent. Our connectors gate both the browser layer and the server layer on marketing consent, and the dispatcher applies a second check before any event leaves for Google. Consent Mode signals from your banner still apply. Events are processed in the EU (Germany), a DPA is available, and the OAuth refresh token never leaves our server. Server-side is a reliability and data-quality mechanism, not a way around a consent banner.
Does this work with Smart Bidding and Consent Mode v2?
Yes, and that is the point. Smart Bidding optimises on the conversions Google actually receives, so recovering the ones a blocked tag lost changes what the algorithm bids on. Consent Mode v2 is unaffected: nothing is sent without marketing consent, on either layer, and our cookie-banner modules for WordPress and PrestaShop implement it natively. Expect the recovered volume to show up in Google Ads within a day, not instantly.
Google, Google Ads and Google Analytics are trademarks of Google LLC. DataFirefly is not affiliated with Google. Product names are used to describe interoperability.
Stop losing Google Ads conversions to the browser
Send your orders server-side to the Google Ads Data Manager API: consent-aware, EU-hosted, with Meta CAPI, GA4, TikTok, Pinterest and Microsoft Advertising from the same event.