Tracking and attribution
If the numbers are wrong,
every decision after
them is wrong.
Conversions API, enhanced conversions, offline conversion imports and a reporting setup that reconciles against your bank. This is the first thing we fix on every account, because nothing built on bad data is worth building.
Results
Sales the platforms
could not see.
An e-commerce account where counter sales are matched back to ad clicks. The offline columns on the right are revenue that used to be invisible.
How it fits together
Three sources of truth,
one clean signal.
Browser tracking alone loses a large share of Gulf traffic to iOS and Safari privacy settings. Server side recovers most of it. Offline recovers the rest.
What gets built
In this order,
every time.
- 1
Conversions API and enhanced conversions
Server side events for Meta and Google so purchases survive ad blockers and iOS. This alone usually recovers a double digit percentage of conversions.
- 2
Event deduplication
Once the server is reporting, the same purchase can arrive twice. Both reports must carry the same event ID. Miss this and your reported revenue inflates and a losing account looks profitable. It is the single most common fault we find.
- 3
Correct values and currency
Purchase value passing in AED or SAR, consistent about whether it includes VAT, and ideally margin adjusted so the algorithm optimises for profit rather than revenue.
- 4
Offline and in-store conversions
Counter sales, phone orders, confirmed cash on delivery deliveries and completed clinic bookings, sent back so the platform learns from real outcomes. The exact pipeline is documented here.
- 5
One number to run the business on
Blended return from your store platform against total ad spend. It cannot be double counted, and it is the only figure that answers whether the whole operation is profitable.
FAQ
What people ask
before they believe this matters.
Yes. Under 30 percent is normal for a Gulf store, especially with heavy iOS traffic. Above 50 percent means something is broken and you should stop optimising until it is fixed.
No, and anyone who says it does is overselling it. It recovers events that browser tracking loses. It does not remove the difference caused by attribution windows and backdating, because those are counting rules rather than tracking failures.
It quietly corrupts your reporting. The purchase event fires when the order is placed, but you are only paid if the customer accepts the parcel. Every refusal is a conversion the algorithm believes in and your bank does not. We wrote this up for the Saudi market.
Yes, though the depth is different from Shopify. The test that matters is the same on any platform: place one real order and confirm exactly one purchase event arrives, with the right value, in the right currency. Platform comparison here.
The build is a project. Keeping it correct is ongoing, because platforms change, themes get updated and apps get installed. We re-verify on a schedule rather than assuming it still works.
Partner programmes
Find out what your
real numbers are.
Send us your ad accounts and your store analytics. We will tell you the exact gap between what the platforms claim and what you actually sold, and which of the usual four causes it is.
Dubai, United Arab Emirates · We reply within one working day