Almost every Salla store I've audited has the same setup: a Meta Pixel ID pasted into settings, a Snap Pixel from an app, and nobody who can say whether the Purchase numbers are real. The physics of fixing this match Shopify or WooCommerce. Only the access points differ.
What tracking access does Salla actually give you?
Three layers: native marketing integrations in the store admin, apps from the Salla App Store, and the developer platform with webhooks and a Merchant API. The admin has fields for common ad pixels, so a merchant can paste in a Meta or Snap Pixel ID without code (the exact list and placement move between admin updates). The developer platform at salla.dev is the layer most merchants never open, and it's the one that matters: webhooks fire on order lifecycle events (the current event names are in the salla.dev docs), carrying the order total, currency, line items, and the customer's email and phone.
What you don't get: checkout code access. Checkout is hosted, so browser-side purchase tracking depends entirely on what Salla and its integrations fire on the thank-you page. That constraint shapes everything below.
| Stacked pixel sources | One source per platform |
|---|---|
| Native integration fires Purchase | One browser pixel, checked in Test Events |
| An App Store app fires it again | Purchase server-side from the webhook |
| A GTM copy fires a third | Browser keeps ViewContent, AddToCart |
| No shared event_id anywhere | Server-only Purchase with strong matching |
| Three purchases per real order |
How do you set up Meta Pixel and CAPI on a Salla store?
Pixel through Salla's native integration, CAPI from outside via webhooks. The sequence I use:
- Add the Pixel through the native integration or the official app — not both, and not a third copy through GTM. One source per platform.
- Verify what actually fires. Open Test Events in Meta Events Manager, click through the store, and confirm which events Salla sends (PageView, ViewContent, AddToCart, Purchase). Don't assume the integration covers the full funnel.
- Build the CAPI leg from webhooks. Salla gives you nowhere to run server code, so CAPI lives outside the platform: a webhook posting to a server GTM container (Stape or self-hosted) or a small worker that maps the order payload to a Purchase event.
- Handle deduplication honestly. Meta dedupes browser and server events on a shared
event_id, and you don't control what Salla's native pixel sends, if anything — and its event_id behavior isn't documented, so assume there is none until you see deduplication working in Events Manager. If you can't match IDs, send Purchase server-side only and keep the browser pixel for ViewContent and AddToCart. A server-only Purchase with strong match data works fine. - Max out match quality. Hash email and phone (SHA-256), normalize the phone to E.164 first, add name and city where available. Meta scores this on its 0–10 Event Match Quality scale, and Saudi checkouts almost always collect a phone number. Use it.
Why does Snapchat matter so much for Saudi stores?
Because in Saudi Arabia, Snapchat reaches most of the young adult population — Snap's own advertising materials have long claimed roughly 90% reach of 13–34 year olds in KSA (their number, so treat it as marketing, but the direction is right). An untracked Snap campaign there is worse than none.
The setup mirrors Meta: Snap Pixel in the browser through Salla's integration or app, Snapchat Conversions API from the same webhook stream you built for Meta. Snap accepts hashed email and phone and has its own dedup identifier — same discipline, different field names. TikTok is the third leg: its Events API rides the identical webhook, deduped on event_id. One webhook, three ad platforms.
Google is the odd one out. Keep GA4 and the Google Ads conversion tag browser-side via GTM in Salla's custom code area, with Enhanced Conversions on using the hashed email from the thank-you page. Server-side GA4 from a webhook sounds appealing, but the payload has no GA4 client_id, so the hit won't stitch to a session. Browser-side Google also degrades less in KSA than in Europe, since Saudi Arabia's PDPL doesn't impose Consent Mode v2 the way the EEA does.
- Read values from data, not the DOM — Arabic-Indic numerals render as 450.75 in another script. Webhook values are locale-free
- Send SAR as a plain decimal — Never convert to USD yourself. The ad platform converts to your account currency
- Pick one VAT convention — Saudi VAT is 15%. Decide once whether the value includes VAT and shipping
- Normalize phones before hashing — 05XXXXXXXX becomes +9665XXXXXXXX, or Meta cannot match the hash at all
- Apply it identically everywhere — Meta, Snap, TikTok and GA4 on one rule, so a 15% gap stops looking like performance
How do you track SAR values correctly?
Send currency: "SAR" with the value as a plain decimal number, pulled from data, never from the rendered page. Arabic locale formatting can render totals in Arabic-Indic numerals (٤٥٠٫٧٥ instead of 450.75), so custom code that scrapes the DOM for an order total ships garbage to the pixel. Webhook and dataLayer values are locale-free. Use those.
Two more value decisions that quietly wreck ROAS:
- VAT. Saudi VAT is 15%. Decide whether your value includes VAT and shipping, then apply that rule identically across Meta, Snap, TikTok, and GA4. A 15% mismatch between platforms looks like a performance gap. It isn't.
- Cash on delivery. COD is still a large slice of MENA ecommerce, and a Purchase fired at "order placed" counts orders that never get paid. Status-change webhooks let you fire at confirmation instead. Slower signal, though — so on heavy-COD stores I send the browser Purchase at placement for optimization speed and a server-side confirmed event as the source of truth.
What Arabic and RTL gotchas break tracking on Salla?
RTL layout itself breaks nothing — the failures come from text handling. The ones I hit repeatedly:
- Encoding in the server leg. Arabic product names are fine as UTF-8 in
content_name, but a forwarder that double-encodes them shows up as mojibake in Events Manager. - Phone normalization. Saudi checkouts collect numbers as 05XXXXXXXX. Hash that raw and Meta can't match it. Convert to E.164 (+9665XXXXXXXX) before hashing. This one change moves EMQ more than anything else on phone-first Gulf traffic.
- Dual-language stores. An Arabic/English store can serve the same product at two URLs. Triggers and audience rules built on URL paths need to cover both, or you silently lose half the funnel.
- Arabic-Indic digits, again: anything parsed out of visible text — quantities, order numbers — is suspect. Parse data, not pixels on a screen.
| Layer | What sits there |
|---|---|
| Inputs | Salla order webhook, Status change, for COD, Signed payload from salla.dev, Email, phone, line items, SAR |
| Server GTM or a Worker | Verifies the signature, hashes PII, converts phones to E.164, sets the event IDs |
| Destinations | Meta Conversions API, Snapchat Conversions API, TikTok Events API |
Can you run server-side tracking on Salla with webhooks?
Yes, and it's the strongest tracking upgrade available on the platform. The pattern:
- Register an app or webhook subscription in the Salla Partners portal and point order events at your endpoint (the salla.dev docs walk the current flow and scopes).
- Make the endpoint a server GTM container with a custom client, or a small Cloudflare Worker for fewer moving parts.
- Verify the webhook signature before trusting the payload (salla.dev documents the signing mechanism) — an endpoint that accepts fake purchase events is a real attack surface.
- Map the payload to Meta CAPI, Snapchat CAPI, and TikTok Events API requests: hash the PII, set event IDs, convert phones to E.164, pass SAR values.
- Test each destination — Meta Test Events, Snap and TikTok's equivalents — before real spend depends on it.
What this buys you: purchase events that survive ad blockers and iOS privacy features, COD truth via status changes, and match data the browser pixel never sees. What it doesn't: browser context. The webhook carries no _fbp or _fbc cookie and no click ID, so attribution leans on customer matching. That's the honest limit of the platform — you won't get the perfectly stitched browser-plus-server event Shopify allows. Server-side with strong customer data still beats a lonely pixel.
Frequently asked questions
Does Salla support Facebook Pixel?
Yes. Merchants can add a Meta Pixel through Salla's built-in integrations or an App Store app, no code required. Verify the fired events in Meta's Test Events tool rather than trusting it blindly.
Can I install Google Tag Manager on a Salla store?
Yes, through Salla's custom code area, covering storefront pages. The hosted checkout limits what GTM sees, so purchase data is more reliable from thank-you page events or webhooks.
Does Salla work with Snapchat ads conversion tracking?
Yes. Add the Snap Pixel through Salla's integration or app for browser events, and use order webhooks to send purchases to the Snapchat Conversions API.
Why don't my Salla orders match my Facebook purchase numbers?
The usual causes: duplicate pixels without shared event IDs, attribution windows counting older clicks, and COD orders that later cancel. Fix dedup first — it's the most common inflation source.
Can I send Salla orders to ad platforms without an app?
Yes. Salla's developer webhooks can post order events to your own endpoint, which forwards them to Meta CAPI, Snapchat CAPI, or TikTok Events API. It takes a developer, not an off-the-shelf plugin.
What currency should a Saudi store send to Meta and Google?
SAR, as a plain decimal value. Ad platforms convert it to your ad account currency automatically — never convert it yourself or hardcode USD.
Do Salla stores need Consent Mode v2?
Not for Saudi and Gulf traffic — Consent Mode v2 enforcement applies to the EEA and UK. If a meaningful share of your buyers are in Europe, you'll need it like any other store.
