How OmdaBazar works
OmdaBazar is an assisted wholesale marketplace for Afghan-made products. The design follows the 2026 feasibility study: narrow catalog, verified records, comparable quotes and repeat-order tooling — not a listing free-for-all.
The RFQ → order flow
Buyer specifies product, quantity, grade, delivery province. OmdaBazar completes missing details.
Matched suppliers answer with unit price, MOQ, lead time, sample terms — comparable by design.
Where quality cannot be fully specified digitally, a paid sample (credited later) locks the standard.
Unit, grade, batch, quantity tolerance, packing, delivery, freight bearer, inspection window, remedies.
Supplier ships; buyer confirms receipt against the spec. Proof of delivery is recorded.
Platform service fee is invoiced on fulfilled orders. Merchandise funds settle buyer→seller directly.
Reason-coded complaints (stockout, late, quality) with a 7-day documented resolution target.
Fulfilled orders become one-click reorder templates — the core repeat-purchase value.
Verification tiers — what the badges mean
Verified supplier
Verified supplierBusiness identity documents reviewed and an on-site visit completed: production site, capacity and records confirmed on the visit date. Re-checked annually. Visible on every listing and profile.
Verified is not a per-shipment quality guarantee — order samples or pre-shipment inspection for critical specs.
📋 Assessed supplier
Documents reviewed, site visit scheduled. Can list and quote, but ranks below verified suppliers and carries the assessed badge until the visit is passed.
A supplier can always contest their record; ratings are correctable, not absolute.
📍 Origin records — the anti-“market for lemons” device
Each listing carries one of four claims with evidence on file: Grown, Manufactured, Processed in Afghanistan, or Afghan reseller (imported stock). Supplier nationality is never conflated with product origin. Batch/lot traceability is flagged per product. Unsupported claims are removed.
Payments, delivery and what OmdaBazar does not do
Model
| Merchandise funds | Settle buyer ↔ supplier directly |
| Platform fee | ~4% service fee on fulfilled orders (illustrative) |
| Freight | Quoted per province lane; borne by counterparties |
| Supplier credit / escrow | Not offered at pilot stage |
Service levels
| Quote turnaround | 48h target |
| Complaint acknowledgement | 1 business day |
| Resolution target | 7 days, documented |
| Low-bandwidth support | Phone-assisted ordering available |
Privacy-preserving analytics — production spec
The platform needs usage insight to run the study's validation gates — but it will never buy that insight with user tracking. This is the spec the production build will implement. Status: specification, not yet implemented — this build has no analytics at all.
🚫 Cookieless, no third parties
No analytics cookies, no fingerprinting, no advertising pixels, no cross-site identifiers. One self-hosted, open-source counter (Plausible or GoatCounter class) — or a zero-script server-log pipeline. Nothing loads from third-party domains.
📊 Counts, not people
No accounts of behaviour, no sessions, no user IDs in analytics. IP addresses are truncated (or hashed with a daily-rotating salt) to derive coarse geography, then the raw value is discarded — never stored whole. Approximate country/province is the finest resolution kept.
🪶 Built for Afghan bandwidth
Under 1 KB, loaded async after first paint — a hard performance budget, since buyers on mobile data are the norm, not the edge case. Phone-assisted orders (the low-bandwidth channel) are logged as aggregate counts by the operator, not by tracking callers.
What we measure (aggregate only)
| Page & search | Views, top searches, zero-result searches |
| Acquisition | Referring domain, country/province (coarse), device class |
| RFQ funnel | Started → submitted → quoted → approved → reordered |
| Marketplace health | Quote coverage %, quote turnaround, repeat-order rate |
| Errors | JS error counts, failed-request counts by endpoint |
What we never measure
| Identity | Names, accounts, precise location, exact IP |
| Cross-site | Anything linking a visitor to activity off omdabazar.com |
| Per-user journeys | Individual click paths, heatmaps, session recordings |
| Commercial content | Buyer prices/volumes as analytics dimensions — those stay in order records, access-controlled |
| Resale data | Analytics never leave the platform or feed ad networks |
The one funnel that matters
The study's month 4–6 validation gate needs exactly five numbers. The analytics spec exists to produce them honestly — everything else is optional.
| Stage | Counted event | Gate it answers |
|---|---|---|
| 1 · RFQ started | Form opened / first field filled (counter increments, nothing stored per person) | Are buyers arriving with real intent? |
| 2 · RFQ submitted | Requirement submitted for matching | Does the flow survive real-world completion? |
| 3 · ≥2 quotes | RFQs that reached two or more usable quotes in 48h | Supplier liquidity — the core supply-side test |
| 4 · Order approved | Written spec approved by both sides | Do buyers actually transact here? |
| 5 · Reordered | Fulfilled order reused as a repeat order | Retention — the study's repeat-purchase thesis |
Because every event is a counter keyed by stage and week — never a person — the pipeline needs no consent banner under GDPR-style regimes, and it matches the commitments in the privacy policy (§4–§5). Raw request logs are kept 30 days maximum, then only daily rollups survive.
Implementation checklist
☐ Self-host the counter (own domain or subdomain) · ☐ Daily-rotating IP salt or truncation, raw IP never persisted · ☐ Aggregate rollups only after 30 days · ☐ Analytics endpoint blocked from receiving order/RFQ payloads · ☐ Disclosure paragraph in the privacy policy before launch · ☐ Dari & Pashto disclosure alongside English · ☐ Quarterly audit that no event schema has crept toward user-level data
Ready to try the workflow?
Post an RFQ — it takes two minutes and there is no obligation until you approve an order.