How do we start working together?

Send a message through the form on this page or invite me on Upwork. I reply within a few hours during my working day (8:00 AM – 10:30 PM IST). For most jobs I suggest a small first milestone, such as a diagnosis or audit, so you can see how I work before committing to more.

Do you work through Upwork?

Yes. I'm a Top Rated freelancer on Upwork with 250+ completed jobs, and contracting there gives you milestone-based payments and Upwork's payment protection.

Will you touch my live site directly?

No. I take a full backup and make the changes on a staging copy first. Only tested changes go to live, at a time that suits your business.

Can you fix a hacked WordPress site?

Yes. I remove the malware and backdoors, patch the entry point, harden the site and request blacklist reviews if needed. Malware cleanups include a 3-month free re-clean warranty.

Which time zone do you work in?

I'm based in Sri Lanka (UTC+5:30) and work 8:00 AM – 10:30 PM IST, Monday to Saturday. That covers European business hours fully and the start and end of the US working day.

Do you outsource any of the work?

Never. Everything is done by me personally, so you always talk directly to the person writing your code.

Meta Conversions API on Squarespace with Server-Side GTM

A client came to me with a problem that many small online stores run into. He sells a single product through a Squarespace store and was about to launch a Facebook ad campaign. His Meta Pixel was installed and working correctly, but he needed the Meta Conversions API (CAPI) as well, so that Meta would get reliable server-side conversion data rather than relying on the browser alone.

He had already tried to connect CAPI using Zapier, and it hadn't worked. Here's why that approach falls short on a platform like Squarespace, and the server-side setup that fixed it.

The problem: Squarespace gives you no backend

Hosted website builders like Squarespace are excellent for running a store without a developer. The trade-off is that they're closed platforms. You don't get access to the backend code, which means:

you can't add your own server-side logic,
you can't send events directly from the store's server to Meta,
you're limited to client-side tracking: the Pixel, running in the visitor's browser.

In 2026, relying only on the Pixel is risky. A browser-only Pixel loses data because of:

iOS tracking limitations,
ad blockers,
browser privacy restrictions that block or shorten tracking cookies.

Every lost conversion means Meta's ad algorithm learns from less data, so your campaigns optimise worse and cost more. The store needed a true server-side solution.

Why a Zapier-only setup usually falls short

Connecting CAPI through Zapier sounds simple: when an order comes in, send a Purchase event to Meta. In practice, that kind of setup tends to give incomplete tracking for two reasons:

It only sees what the order contains. Meta matches server events to real people using browser details such as the click ID and browser ID cookies, the IP address and the user agent. An order notification doesn't carry most of these, so match quality stays low.
It doesn't line up with the Pixel. If the browser and the server both report the same purchase without a shared event ID, Meta can't tell they're the same event. It either double-counts it or can't combine the signals.

You need an architecture that captures events in the browser and forwards them through a server you control.

The solution: server-side Google Tag Manager + Stape

Here's the architecture I implemented:

Google Tag Manager, web container. Captures the front-end events on the Squarespace site: PageView, AddToCart, Purchase and so on.
Google Tag Manager, server container. Receives the event data from the web container.
Stape.io. Hosts the GTM server container, so there's no need to manage a cloud server yourself.
Meta Conversions API. Receives the events securely from the server container.

The flow looks like this:

Visitor action → GTM web container → GTM server container (hosted on Stape) → Meta Conversions API

Because the server container runs on infrastructure you control, it can forward events with the browser details Meta needs for matching. It also works alongside the Pixel instead of replacing it.

This setup gives:

more accurate tracking, with fewer conversions lost to blockers and browser restrictions,
better Event Match Quality, so Meta can link more events to real users,
less data loss overall,
a stronger signal for Facebook Ads optimisation.

Tips if you build this yourself

These are good practice for any Pixel + Conversions API setup:

Deduplicate events. Send the same event name and a shared event ID from both the Pixel and the server, so Meta counts each purchase once.
Test before you spend. Use GTM's Preview mode for both containers, and Meta's Test Events tool in Events Manager, to confirm each event arrives once with the right parameters.
Use a custom subdomain for the server container where your hosting supports it. This keeps tracking requests first-party.
Respect consent. Server-side tracking doesn't remove your privacy obligations. Make sure events only fire when the visitor's consent allows it.

The result

Once the server-side tracking was in place:

conversion events started matching correctly in Meta,
the event quality score improved,
the ad campaign had reliable tracking data to optimise against.

Most importantly, the client could scale his campaigns with confidence, knowing the numbers reflected real sales.

Key lesson

Connecting Meta CAPI through tools like Zapier, without a proper server-side architecture, often leads to incomplete tracking. For platforms like Squarespace, the reliable approach is server-side GTM with dependable hosting such as Stape.

If you run ads for a store on a no-code platform and your conversion numbers don't add up, server-side tracking may be the missing piece.

References

Need server-side tracking, Meta Conversions API or another API integration set up for your store? Tell me about your setup and I'll reply within a few hours.