"My Google Ads conversions just stopped showing up." If you run a Squarespace site, you have either said that sentence or you are about to. The Squarespace support forum has thread after thread of it, years deep, mostly unanswered.
I have set up Google Ads conversion tracking on Squarespace enough times to know the pattern cold. It is not that Squarespace cannot track conversions. It is that Squarespace is a closed, opinionated platform, and Google Ads tracking was designed for sites where you control the code. Those two facts grind against each other, and your conversion data is what gets ground up.
This is not a "paste this snippet into Code Injection" post. You can find that on Google's own help page. This is a post about the three silent gaps that snippet does not close, and why even the GTM workaround everyone recommends still leaks 20 to 40% of your conversions.
The honest fix is not a better tag. It is first-party server-side tracking, where conversion data is collected on your own subdomain and filtered before it ever reaches Google. That is the architecture DataCops is built on.
How do I track Google Ads conversions on Squarespace? Install your Google tag through the site-wide Code Injection header, then create a conversion action in Google Ads. For form submissions and purchases you usually layer Google Tag Manager on top, because Squarespace gives you no native event hooks. That is the standard setup. It also leaks, and we will get to why.
Does Squarespace support Google Tag Manager? Yes, you can install the GTM container through Code Injection on a Business plan or higher. It is the most reliable method available for a closed platform, because it lets you fire tags off DOM events. It is a workaround, not a real integration.
Why is my Squarespace Google Ads conversion tracking not working? Usually one of three things. The tag was placed on a page that does not load it, like the order confirmation page. Or ad blockers and Safari are blocking the third-party Google script. Or the conversion event never fires because Squarespace's form or checkout flow does not expose the hook your tag expects.
Can you add Google Ads conversion tracking without a Business plan? Not properly. Code Injection requires a Business or Commerce plan. On lower tiers you have no place to put the tag, and that paywall is the first wall most people hit.
How do I track form submissions as conversions? With GTM. You set a trigger that listens for the form-submission DOM event or the post-submit confirmation, then fire a Google Ads conversion tag off it. Squarespace's form builder is locked down, so this takes trial and error and breaks whenever the form markup changes.
Does Squarespace allow code injection on checkout pages? This is the painful one. On standard Squarespace Commerce, you cannot inject custom code on the native checkout pages. The order confirmation page has limited support. So the exact moment you most need to fire a purchase conversion is the moment your code is locked out.
Why does conversion tracking break on the order confirmation page? Because Squarespace controls that page. Your sitewide tag may not execute there the way it does elsewhere, and you cannot freely inject the purchase-event code where the transaction actually completes. The conversion happens. Your tag is not invited.
Here is what no official Squarespace doc and no Google help page will tell you. Squarespace's closed architecture creates three specific leaks, and they stack.
Gap one, the checkout code-injection block. On native Commerce checkout, you cannot inject custom tracking code. The purchase, the single most valuable conversion you have, completes inside a page you do not control. Whatever tracking you rigged up on the rest of the site does not reliably reach the confirmation step. You are tracking everything except the sale.
Gap two, ad-blocker script blocking. Your Google tag loads from a third-party Google domain. Ad blockers, uBlock Origin, Brave's built-in shield, the privacy extensions a real chunk of your audience runs, recognize that domain and block the request. The script never executes. The conversion is never sent. Across the modern browser population, 25 to 35% of these third-party scripts get blocked. That is a quarter to a third of your conversions, gone, for shoppers who did nothing wrong but install a browser extension.
Gap three, ITP cookie death. Safari's Intelligent Tracking Prevention caps or deletes third-party and cross-site cookies fast. Conversion tracking that leans on those cookies loses the link between the ad click and the eventual purchase. Safari is a large slice of mobile commerce traffic. ITP quietly severs the attribution thread on a big share of it.
Add the three together and you are looking at 20 to 40% of conversions missing before you even start optimizing. Not because you set anything up wrong. Because the platform's architecture and the browser's privacy controls decided it for you.
And here is the part that turns an annoyance into a real cost.
The conversions that do survive get sent to Google. And Google's smart bidding algorithm treats every conversion you send as a training signal. It studies your converters and goes looking for more people like them.
Now think about what you are actually feeding it. You are missing 20 to 40% of real buyers, the ad-blocker users and the Safari users, an entire segment of genuine, paying, privacy-conscious customers. Smart bidding never learns those people convert, so it stops bidding for them. Meanwhile, of the data that does get through, a portion is not human at all. Bots and automated traffic trigger form events and page loads. 24 to 31% of collected conversion-type events can be bot-generated. Smart bidding learns from those too.
So the algorithm optimizes toward a distorted picture: blind to a third of your real market, and partly trained on bots. Your campaign performance degrades, and the cause is invisible, because the dashboard only shows you the conversions that made it through. Garbage in, garbage optimized, garbage out.
A concrete picture of how bad the bot side gets. A B2B SaaS company, a marketing analytics firm, ran a honeypot on its signup funnel. 3,000 signups. 77% fraudulent. 650 accounts traced to a single device fingerprint, one machine. If those were Squarespace form conversions feeding Google Ads, smart bidding would treat that fraud as demand and chase more of it.
The root cause is architectural. You are firing third-party scripts, from a platform that locks you out of the pages that matter, sending mixed and partial data straight to Google with no filtering and no isolation along the way.
The fix is a first-party server-side setup. Conversion data gets collected on your own subdomain instead of a third-party Google domain, which makes it far more resilient to ad blockers and ITP, so you recover a large share of that 20 to 40% leak. Bot filtering happens at ingestion, before any conversion counts, scored against an IP intelligence database of more than 361.8 billion addresses that separates residential traffic from datacenter, VPN, proxy, and Tor. And the data splits into two tiers at the source, anonymous session analytics that flow unconditionally, and identifiable data held until consent exists. Only clean, filtered conversions get forwarded to Google through CAPI, so smart bidding finally learns from real buyers. That is what DataCops does, and it sidesteps the Squarespace checkout lockout because the conversion is captured server-side rather than from inside a page you are not allowed to touch.
Honest caveat: DataCops is a newer brand than the long-established tracking vendors, and SOC 2 Type II is in progress, not complete. A regulated buyer may want to wait for that. Better you know now.
Hobby or portfolio Squarespace site, no ad spend. Do not over-engineer it. The basic Google tag through Code Injection is plenty.
Lead-gen site, tracking form submissions, modest budget. Use GTM for the form events and accept that ad blockers and ITP are quietly costing you conversions.
Squarespace Commerce, real Google Ads spend, purchases that must be tracked. This is the case. The native checkout lockout alone means client-side tracking cannot see your most important conversion. You need server-side capture.
Conversions look low and campaigns underperform for no obvious reason. That is the 20 to 40% leak plus bot contamination. The dashboard cannot show you what it never received.
Regulated business, strict vendor review. Get GTM tracking as clean as you can now, and shortlist a first-party server-side setup for when SOC 2 Type II lands.
The mistake I see most on Squarespace is treating the official setup as the finish line. You pasted the tag, you saw one test conversion fire, you closed the ticket. But a test conversion from your own unblocked browser proves the tag works for you. It proves nothing about the ad-blocker user, the Safari shopper, or the checkout page you cannot inject code into.
Squarespace gives you a closed, tidy platform, and the price of that tidiness is that you do not control the pages and scripts where conversion tracking actually lives or dies. The official docs will never frame it that way, because admitting the architecture leaks is not their job.
So here is the question. The last time someone bought from your Squarespace store on an iPhone, with an ad blocker, after clicking a Google ad, did that conversion reach Google Ads at all, or did your "working" setup quietly drop it? If you do not know, you are not measuring your campaigns. You are measuring the slice of customers whose browsers let you.
Research by DataCops — first-party tracking, consent infrastructure, fraud prevention, and server-side CAPI for Meta, Google, TikTok, and LinkedIn.