Product metricsمؤشرات المنتج

A metric is a number describing what the product does, like active customers or the share of successful transactions. What separates one that holds up from one that collapses is a written definition and a route back to the event it came from.

A trustworthy metric rests on a written definition and a visible route back to raw events.

Why does one number differ between two teams in the same company?

This happens almost everywhere. Marketing says active users are a million, finance says seven hundred thousand, and both present an official dashboard.

Neither is lying. The disagreement is not about the number. It is about the definition.

Is "active" someone who opened the app, or someone who transacted? Does opening it once a month count? Does someone with two accounts on one ID count as one user or two? Does an account closed on the 29th count?

Each team answered those questions its own way, built its dashboard on its answer, and then forgot it had answered.

The problem turns serious when the number leaves the company. Sending it to an investor or a regulator is not sending a number. It is making a commitment. And the first question in an audit is not whether the number is correct. It is how you defined it, when the definition changed, and who approved the change.

So a metric that survives an audit is not the most arithmetically precise one. It is the most clearly defined one. Whoever can state their definition in two lines, and show it did not quietly change after a bad quarter, has a real metric. Whoever cannot has a pretty number that means nothing.

Begin with the decision

Measurement is useful when it changes an action. A product manager may need to know whether account opening became easier. A risk owner may need to know whether additional approvals increased fraud loss. If nobody acts when the number changes, it is decoration.

Choose a few outcomes rather than activity counts. Meetings do not prove complaint handling improved. New rules do not prove fraud declined. Complaint resolution time and fraud loss per thousand riyals describe consequences.

Do not begin with what the system can display easily. Downloads are easy to count; accounts still using the product after 30 days are harder. The harder figure is closer to value. Let the decision determine the data.

Define numerator, denominator, and time

Every metric needs a definition card. Record its purpose, numerator, denominator, time zone, closing time, exclusions, and sources. State whether a transaction counts when requested, completed, or settled.

Two companies can report a 90 percent approval rate while measuring different things. One divides successes by every attempt. The other removes outages and retries. One uses local time and the other UTC. The disagreement is definitional, not mathematical.

Test the definition with a small example. A customer retries after a timeout and one attempt succeeds. Is that two requests or one payment? If it reverses tomorrow, does today's report still call it successful? The card should answer before an analyst writes a query.

Never change a definition silently to improve the trend. Version any new exclusion with a reason and effective date. Recalculate history where possible or mark the break clearly.

Rebuild the number from raw data

A second analyst should be able to reproduce the result. Preserve raw events, transformation logic, query version, and run time. Link to sources without copying customer identity into every dashboard.

A success event may arrive twice after a retry. Settlement may arrive the next day. A transaction may move from pending to successful and then reversed. The model needs a deduplication key and a rule for the authoritative state.

Separate event time from arrival time. A payment occurring at 23:59 may be reported after midnight. Network delay should not silently change the sales day. The distinction matters at month-end and in regulatory reports.

Reconcile totals with an external or core source. If the dashboard reports SAR 1 million while the ledger reports SAR 990,000, investigate the difference before publication.

Pair growth with protection

A guardrail metric (المؤشر الحارس) prevents improvement in one number from damaging another. Pair approvals with fraud and disputes, lending with default and affordability, and faster onboarding with complaints and fake accounts.

Give the guardrail an owner, threshold, and time window. A team might continue after a tiny one-day fraud movement but stop if seven-day losses breach an agreed limit.

Review value and count together. A stable fraud rate can conceal losses concentrated among five large customers. Complaint count can fall while disputed value rises. Each view describes a different exposure.

Follow cohorts through time

A cohort (الفوج) is a group that began in the same period or condition. Follow customers who opened in January after one and three months. Their activity, default, and complaints remain visible instead of being hidden by new acquisition.

Total active users may rise weekly while every cohort loses half its members after one month. A February campaign temporarily replaces January's losses. The leak appears only when acquisition stops.

Split cohorts only where a decision follows, such as channel, product version, or customer type. Do not create dozens of tiny segments that turn every movement into noise. Each split needs a hypothesis and possible action.

Protect measurement from gaming

A metric decays when it becomes an isolated target. Support may close complaints early to improve speed. Risk may reject more legitimate cases to reduce loss. Product may label one app open as activity.

Define success from the customer's perspective and add a counter-metric. Pair closure speed with reopened cases and satisfaction. Pair lower fraud with legitimate approvals. Pair activity with completion of a meaningful financial action.

Do not let one team write the event, calculate the number, and explain every exclusion without review. A data or risk owner should periodically inspect definitions and logic.

Prepare an audit package

Choose one management number and assume an auditor asks for it in six months. You should produce the approved definition, source, query, change permissions, reconciliation, and history of revisions. A screenshot without a path to origin proves little.

Automate the package where possible. Store code versions with runs, record test results, and alert when a source stops or volume changes sharply. Evidence dependent on an analyst remembering a file will eventually be absent.

Review metrics quarterly. Remove those that drive no decision, stabilise those used in reporting, and add guardrails where harm appeared. The result is a small set you can explain, rebuild, and defend to managers, customers, and auditors.