PrestaSignal
Representative example

What recovering your tracking actually looks like.

A representative example based on typical results for a mid-sized PrestaShop store. Figures illustrate the kind of gap server-side tracking closes; your numbers depend on your traffic, devices and platforms.

Picture a PrestaShop store doing solid revenue on Google and Meta ads, with a competent client-side setup. On paper everything looked fine — until the conversions reported in GA4 and Ads Manager were lined up against the actual orders in the back office. They didn’t match. Here’s what the gap looked like, and what closing it changed.

Before: the numbers didn’t add up

The store’s analytics consistently showed fewer purchases than its order list. iPhone shoppers — a large share of traffic — were under-represented, and a chunk of ad-driven sales arrived with no attribution at all. Smart Bidding and Meta’s optimisation were learning from data that was missing roughly a third of the real conversions.

Metric
Before
After
Conversions seen by ad platforms
~63%
~97%
Purchases matched to a click
partial
restored
GA4 vs back-office orders
off by ~35%
reconciled
iOS conversions attributed
mostly lost
recovered
The change

What changed

Nothing about the store’s ads or products changed. The only difference was where the tracking lived.

01
Module installed

The PrestaSignal module went onto the PrestaShop store — no theme edits, no developer sprint.

02
Events moved server-side

GA4, Google Ads and Meta events began firing from the hosted server, beyond ad-blockers and ITP.

03
Signals restored

Click IDs, Enhanced Conversions and the Conversions API reconnected sales to the ads that earned them.

04
Numbers reconciled

Within weeks, the platforms’ conversion counts lined up with the store’s actual orders.

+47%

The result: roughly 47% more conversions recovered

Once events flowed server-side, the platforms started seeing conversions they had been blind to — about 47% more than the browser-only setup reported. That isn’t new sales the store didn’t make; it’s the real sales it was already making, finally measured. With complete data, Smart Bidding and Meta optimisation had an accurate picture to work from, and the client’s reporting stopped contradicting their bank statement.

What makes this repeatable is that the cause is universal: every PrestaShop store selling to iPhone users and shoppers with ad-blockers loses conversions the same way, for the same reasons. The size of the gap differs, but the mechanism — browser tags being blocked or shortened — is the same everywhere. That is why moving the same events server-side produces a similar shape of result across very different stores.

Good to know

About this example.

Is this a real, named customer?+

It’s a representative example built from the kind of results server-side tracking typically produces for a mid-sized PrestaShop store. We’ve kept it illustrative rather than attaching a brand, because the exact figures vary by store. A teardown gives you numbers specific to you.

Where does the “47%” come from?+

It reflects the order of magnitude of conversions commonly lost to iOS restrictions and ad-blockers — frequently 30–50% — which server-side tracking recovers. The recovered conversions are real sales that the browser-only setup failed to report, not additional revenue.

Will I see the same numbers?+

Not exactly — your result depends on how much of your traffic is on iOS, how many shoppers use blockers, and which platforms you run. The free teardown estimates your specific gap before you commit to anything.

Want to see your own gap?

A free teardown measures it on your real store — the same before-and-after, with your numbers.

Part of the PrestaChamps family →