Skip to content

Product

Your COD figures, each with the base that lets you challenge it

Nawras computes your indicators on timestamps written the moment the event happens, not on the status showing the day you look. "Confirmed" means a confirmation date exists: an order confirmed on the 3rd and cancelled on the 9th still counts in the month it was confirmed. Six tabs answer six questions, 25 reports feed them, and every rate shows the denominator that makes it verifiable.

Four layers of numbers, and an indicator belongs to exactly one

The present, the recent trend, the money, the history. Ask the same question of two layers and you get two different answers — and you end up believing the convenient one.

The present

How many orders are waiting for a confirmation, a parcel, a cash collection — right now. This counter goes up and down all day; it says nothing about the month, and we never ask it for a trend.

The recent trend

How many orders were created, confirmed, shipped, delivered each day. A flow, not a state: an order enters on the day the event happened and never leaves again, whatever happens to it afterwards.

The money

Delivered revenue, fees, margin. A single authority writes it, and analytics never recomputes an amount: it reads what the finance engine settled at delivery.

The breakdowns and the history

By city, by SKU, by carrier, by agent, over the window you choose. This is the reporting layer, and the only one queried on demand.

This boundary is why two Nawras screens never give two different answers to the same question. An indicator appearing in two layers would be a defect, not a convenience.

A figure is dated on a timestamp, never on today's status

An order's status is a present tense: it can still change. A timestamp is a fact: it is written inside the very transaction that produces the event, once, and never moves again.

  • The order arrives

    createdAt

    The denominator of everything judged on a cohort: a month's confirmation rate is computed on the orders born that month, including those confirmed the month after.

  • The customer said yes

    confirmedAt

    "Confirmed" does not mean "currently in CONFIRMED status". An order confirmed then cancelled still counts in the rate of the day it was confirmed — otherwise a bad month would quietly clean itself up.

  • The parcel is ready

    readyToShipAt

    End of picking. The field is back-dated when a parcel leaves without passing through the packing screen, so the tiers stay nested — packed ⊇ shipped ⊇ delivered — whatever the team's discipline was that day.

  • The parcel leaves

    shippedAt

    The actual departure, not the assignment to a driver. Assigning is an intention; departure is what updates the denominator of the carrier delivery rate.

  • The customer pays

    deliveredAt

    The axis of all money. Cash collected on 2 September belongs to September even if the order dates from 28 August — that is what makes a month readable again a year later.

One example of what this rule avoids: the delivery attempt counter is only incremented on failure. An order delivered first time therefore carries zero attempts, never one. The first-attempt success rate is computed on deliveries with no failure at all; the naive formula — "attempts = 1" — would have shown 0% on a perfect month, with no test turning red.

Two dates, two questions — and the report chooses, not you

A confirmation rate reads on orders created in the window. Revenue reads on orders delivered in the window. Mixing the two produces a report that looks right and never is.

The axis is declared, not picked

Every report declares, in one catalogue, whether it dates on creation or on delivery. A report added tomorrow without declaring its axis does not compile: it cannot silently land on the wrong one.

Midnight, Casablanca time

Bounds are local, never UTC. An order placed at 11:30 pm belongs to its own day and not the next one, and the last day you select is counted in full.

The previous period, in the same computation

Comparing means comparing against a window of the same width. It is computed in the same query, and the screen states which dates it compares to: "vs 36%" with no reference is not a figure, it is an impression.

The window lives in the address

The link you send your partner opens exactly what you were looking at. Nothing is lost on reload, and nobody argues over two different periods while believing they share one.

Beyond roughly six months the comparison stops showing: widening the read to two years in order to compare one year no longer compares anything useful.

What a report refuses to count — and the one that counts it on purpose

A test order, a duplicate, an attempted fraud: they exist, they stay in your history, and they have no business inside a performance rate.

  • The reason is written once, at cancellation

    The flag is set inside the transaction that cancels the order. Analytics itself knows no reason names: adding an exclusion reason tomorrow requires touching no query at all, so it can forget none.

  • Except one screen, whose whole job that is

    "Why I lose" deliberately counts what the others set aside: it is the only report in the product that lifts this filter. A fake order shows up there as a loss line with its reason, not as a hole in a total.

  • A partial delivery is worth what was handed over

    If the customer refuses one item out of three, the amount counted is that of the items actually handed over, not that of the order. Quantity per SKU follows the same rule: a refused item cannot appear as sold.

None of these rules is written twice. The amount actually delivered is settled by the delivery command and read as-is by analytics: copying a money rule into a second language manufactures exactly the divergence it existed to prevent.

Six tabs, six questions — and 25 reports to answer them

Past seven tabs, a bar becomes a carousel nobody scrolls to the end of. Each one therefore carries a whole question, and sections stack inside it rather than spawning one more tab.

  • Overview

    Where do I stand?

    The headline cards — orders, rates, money — each compared to the previous window of the same width.

  • Funnel

    Where is it stuck?

    The path order → confirmation → packing → shipping → delivery, the average time lost at each tier, and the spread by weekday and by hour.

  • Money

    What am I really earning?

    Delivered revenue, margin, per-order fees, monthly performance, cash cycle — and what evaporates, with its reason.

  • Delivery

    Who delivers well, and where?

    By city, by zone and by region, each with its delivery rate and its base — then each carrier's performance, parcels shipped against parcels delivered.

  • Products and customers

    What sells, and to whom?

    Best sellers, returned or cancelled products, acquisition channels and campaigns, customer base, risk distribution.

  • Team

    Who performs?

    Your packers and your drivers: how much each handled, and how long they took. Both group on an identifier, never on a hand-typed name — two spellings of one first name would make two people.

The catalogue holds thirty. Two are reserved for running the platform and refused to a merchant account; three more are written server-side but have no screen yet — so they are not counted here. Twenty-five is what you can actually open.

A customer exists before your window — that is what makes the word "new" true

The one defect that really matters here is silent: bounding a customer's history to the displayed window turns everyone into a new customer, breaking nothing and showing nothing odd.

History is not cut off

To decide whether a customer is new, Nawras reads all of their earlier orders, not just those in the window. Someone who has been buying from you for a year does not become new again because you are looking at August.

Two frames, stated on screen

The cards and the ranking cover the window. Loyalty and segments cover your whole base as of the end of that window: a lost customer ordered nothing inside it, and looking for them there would hide them at the exact moment you are looking.

Five segments, thresholds written once

Champions, loyal, new, to win back, lost. Recency is measured at the end of the displayed window rather than today — otherwise a screen dated March would declare every March customer lost.

The figure this section exists to produce is the delivery rate of your returning customers, placed next to that of your new ones. In COD, the gap between the two tells you what a win-back campaign is worth — and it is invisible in any total.

A report costs money — yours, and ours

A dashboard that re-reads the whole history on every click ends up costing more than it earns. Here is the mechanism, written down because it concerns you.

A closed period is not recomputed

A report on a finished period is kept for 24 hours: its data can no longer change. A window that includes today is kept for ten minutes only. A view served from that store touches neither the analytics warehouse nor your quota.

Adding a column expires the store

Every result shape carries a version number. Without it, adding a column would show it empty for 24 hours, to everyone, with no error anywhere — the kind of defect everyone calls temporary until it gets reported.

The cap is a fuse, not a tier

The number of computations is the same on all four plans. It is not a sales argument: it exists to stop a runaway loop, never to push you to upgrade — a cap that varied by plan would be a commercial tier nobody decided to sell.

A runaway query is stopped, not billed

Every computation carries a cap on the bytes it may read, and the volume actually scanned is logged. A query that would blow past that cap fails instead of costing — which is exactly what makes it possible to keep the fuse generous rather than tightening it on the merchant.

And a capped table says so. The "partial data" badge does not appear because a query carries a limit: it appears when a query actually hit one. A complete ranking of twenty rows is not partial, and must not invite suspicion.

The questions we get about these figures

Where do these figures come from? Is there nothing to install?

Nothing. Every order feeds analytics the moment it changes state, whatever its origin — online store, WhatsApp, phone call, spreadsheet, API. There is no tag to place on your site, no export to run, no spreadsheet to keep up to date at night.

My carrier reports a different delivery rate than yours.

You are probably both right. They divide parcels delivered by parcels they took charge of; you divide by the orders you had confirmed. Nawras shows both, side by side, with their base. The gap between them is your confirmed orders that never left — the only figure in that conversation that belongs to you.

My margin shows as "provisional". Why not display a round number?

Because a missing purchase cost is not a zero cost. Counting products whose cost you never entered as free would give a prettier, wrong margin. Nawras computes the margin of covered products and shows what share that represents; the day you fill a cost in, coverage rises.

Is it real time?

No, and that is a choice. The counter of orders waiting is immediate — that is a different layer. Analysis reports can lag up to ten minutes behind the current day: re-reading the whole history on every view would cost real money to move a second decimal.

Do I lose my figures if I change plan or leave?

No. Analytics is not a separate warehouse: it is a reading of your orders, and the orders are the source. Changing plan does not change what you can read — plans only vary volumes, and the computation cap is the same on all four. And because every figure is dated on a timestamp carried by the order itself, a past period stays readable as-is months later.

Ready to take back control?

Create your workspace in 2 minutes and see the impact in the first week.

Create my free account

Zero dirhams. Zero commitment. Cancel in one click.

Merchant stepping onto an indigo path toward an organized COD cockpit.