Use cases
Start from the problem, not the tool
13 cases across 6 sectors. Each names what actually goes wrong, what Raasid does about it step by step, and what appears on the screen afterwards. No promised results: the result belongs to your store and your campaigns.
Filter
Find the case that matches your situation
13 of 13 cases
Returns inflate ROAS
The platform counts a purchase the moment it completes and never subtracts from it. Every cancelled or returned order stays in the campaign report as revenue, so budget goes up on a campaign that only looks profitable.
Raasid builds the descent from the platform's number down: what the platform claimed, then what Raasid actually attributed, minus cancelled and returned, minus cash-on-delivery not yet delivered, down to revenue really collected. Each step shows orders and money, and the steps add up exactly.
You see it inThe revenue waterfall, and cost per confirmed order beside cost per placed order.
Events lost before they arrive
The pixel runs in the shopper's browser, and there it is stopped by privacy settings, ad blockers and a browser closed before it fires. No log tells you which events failed to arrive, or why.
The same event is sent from your store's server over each platform's own official API, carrying an ID that ties it to the pixel's copy so the sale counts once. The queue holds the event and retries if the platform is slow to answer.
You see it inTracking coverage: how many of your store's own orders Raasid actually saw, and a delivery record for every event.
One buyer, several clicks, several platforms
Each platform counts the sale for itself, so their three reports add up to more than your store sold. You cannot tell which click came first, or which came last.
Raasid puts the touchpoints before and after the purchase on one timeline in the order they actually happened, and names the channel correctly - a paid ad shows as a paid ad, not “Direct”.
You see it inThe buyer's full journey, and a side-by-side attribution comparison over the same orders.
The attribution window changes who gets the sale
Each platform uses a different attribution window, and you only see what changing it does after you have already moved the budget.
Raasid runs two settings side by side over the same orders: each channel's revenue under each, and a column showing exactly how much its share moved.
You see it inThe attribution comparison, and the matched-orders table with the real campaign name against each one.
The most expensive event is the one that got rejected
A platform rejects an event for a technical reason - a missing field, an expired token, a brief outage - and nobody tells you. You find the gap a week later, in a report that does not look like your sales.
Every event passes through a live feed with its status at each platform and the payload that was actually sent, and ten alerts watch the conditions that cost money: connection dropped, tracking stopped, events rejected, matching fell, spend up with no revenue behind it.
You see it inThe live feed with the full payload, and the alerts that reach you before you read the report.
Cash on delivery is not revenue yet
The platform counts a cash-on-delivery order at full value the moment it is placed. An order not yet delivered - or refused at the door - stays revenue in its report forever.
Raasid separates the states: order placed, order confirmed, cash-on-delivery order delivered. And it reports cost per order for each state separately rather than one number that mixes them.
You see it inReal cost per order in its three states, and the “COD awaiting delivery” step in the waterfall.
Your store's number and the platform's never meet
The platform says one number, your store says another, and you have no third number to appeal to. The discussion becomes a matter of opinion.
Raasid puts your own order counts from Zid or Salla beside what it received, day by day: how many arrived, how many were attributed to an ad, and how many stayed unattributed and why - order by order.
You see it inDay-by-day order reconciliation, and the coverage share against your real order total.
A repeat customer shows up as several people
The same buyer orders from the phone once and the browser once, so the platform sees two people and pays twice to reach them.
The customer's identifiers are normalized and hashed with SHA-256 before they are sent, and sessions are unified, so the platform receives one signal about one person rather than two weak ones.
You see it inThe match-quality score and the rate of each identifier on its own: email, phone, visitor ID.
The drop-off is in one step
You know ad visitors do not complete, but not where exactly they leave: the product page, the cart, or the checkout.
Raasid tracks the full journey - product view, add to cart, begin checkout, purchase - counting distinct shoppers at every step, then names your worst step outright.
You see it inThe drop-off funnel from landing to money collected, with the worst step named.
Strong matching without a raw identifier
Good matching needs identifiers, and raw identifiers must not leave the store. The common answer is to send less, which is exactly what weakens the matching.
Email and phone are normalized and then turned into a SHA-256 hash before they leave your store, and the hash cannot be reversed. The platform matches the hash against its own database without ever seeing the text.
You see it inThe match-quality score with a blunt verdict beside it, and the state of each identifier on its own.
The pixel failed at checkout
The purchase completed in your store and was written to its database, but the purchase event never reached the platform. The campaign looks like a loss when it is not.
Raasid recovers confirmed purchases straight from the store's database, so the event is built from what actually sold rather than from what the browser managed to send.
You see it inThe coverage share before and after recovery, and the orders that arrived with no source.
The platform optimises on the click, not the customer
No event from your store reaches the platform, so the algorithm learns from the click alone and brings traffic that does not convert.
Raasid sends the event from the server when it actually happens - not when a thank-you page loads - over each platform's official API, carrying hashed identifiers strong enough to match on.
You see it inThe live feed of outgoing events, and the state of every enabled ad channel.
The value arrives after the campaign is judged
You judge the campaign on the first subscription, and the difference between one channel and another only shows months later in renewals.
Raasid keeps a timeline for each customer covering what happened before the conversion and after it, with the correct channel on every point, so you compare channels on what accumulated rather than on the first event.
You see it inThe per-customer timeline, and the executive summary naming where each platform's numbers diverge from reality.
Found your case?
Start on your own, or message us and we'll work out which case to start from.