The word hybrid suggests redundancy, two paths in case one of them fails.
That isn't what it is. The two paths carry different information, and the order is only complete when both arrive. Once you know which path holds what, you know exactly which number you're missing when you only have one.
The browser is where the visit happens and the server is where the sale becomes real. This is what each one holds:
| Browser | Server | |
|---|---|---|
| Click identifier in the URL | Yes | No |
| Pages viewed before the order, in sequence | Yes | No |
| Device and session | Yes | No |
| Confirmed total after discounts and shipping | No | Yes |
| Payment status after the purchase | No | Yes |
| Email, phone and customer ID | No | Yes |
Ask the browser for a confirmed total and you get the number printed on the page, which sometimes differs from the amount that settled. Ask the server for the click identifier and it has never heard of it.
The first practical reading of that table: with the browser path alone, your revenue figures include orders whose payment later failed. With the server path alone, you know a sale happened and not what brought it.
The extra 1,100 events come from orders that never passed through the visitor's browser at all. The order reaches Flowfy's server directly from Salla by webhook, so an ad blocker or an expired cookie has no effect on that path.
At a 250 SAR average order, 1,100 events a month is roughly 275,000 SAR moving out of the unknown-source bucket and into a campaign with a name on it. Same spend, same campaigns, same audience. What changed is that the data arrived.
The effect doesn't stop at the report. The platform learns from the events it receives, so more matched events means a clearer signal about the kind of buyer who actually buys from you. That shows up as better targeting after two or three weeks, not the same day.
Two paths sending the same order only helps if the destination understands they're the same order. Both messages carry the same event ID, and the platform keeps one and drops the other.
Get that wrong and the hybrid setup is worse than either path alone, because it inflates the count. That failure has its own article, counting every order once, and it's the most common way a hybrid installation goes wrong.
It isn't two tools. It isn't a fallback that only fires when the pixel is blocked. And it doesn't make the browser path redundant: remove the pixel and you lose the click identifier, the one field that lets you join your orders to ad spend on something more reliable than a UTM string.
Two questions come up before switching it on. Does the server path slow down checkout? No, because it runs after the order exists, outside the shopper's request path. And what if your store platform's webhook is delayed? Events are matched on the order rather than on arrival time, so a late webhook reconciles with the browser event instead of creating a second conversion.
Take a closed month and compare three numbers: your store's orders, the events your browser tracking recorded, and the conversions the platform reports.
If browser events sit clearly below your store's orders, you're losing events and you need the server path. If platform conversions sit above your store's orders, you're sending from two paths without a shared event ID, and that gets fixed before anything else because it's the fastest.
A server-only setup really is simpler, but it's blind to the session. You'd know the sale happened and have a much weaker claim about what caused it. That's fine if your store doesn't advertise, and expensive if it does.
In Flowfy, the hybrid path is live today: browser events plus a server webhook from Salla and Zid, reconciled on a shared event ID, with matching parameters hashed before they leave. Reading each destination's own match-quality score in one screen is partially available: per-event delivery and platform responses sit in the delivered log, and a consolidated score per destination over time is on the roadmap and hasn't shipped.
If you only have one path, don't ask which one is better. Ask which piece of information you're missing: the source of the order, or its confirmed value.
And before you switch on the second path, make sure both send the same event ID. Without it you'll watch conversions climb and ROAS improve, with no extra riyal arriving in your account.
The browser pixel and server-side tracking complete each other. Without a shared event ID between them, the same order is counted twice and ROAS reads better than reality. Here's what each path sees, and where deduplication breaks.
Tracking doesn't fail in unlimited ways. It fails in about six, and each one has a fingerprint. Here are the six, and the check to run if you only have time for one.
Alert me if events drop below 100 a day is a rule that works for one store, for about a month. A threshold that doesn't know your normal fires when you're fine and stays quiet when you're not.
