Why we shipped a MENA-specific cookie database

The trigger

In the first live scans we ran for ourselves, roughly one in five cookies came back classified as unknown. We traced the pattern: the classifiers in our scanner (adapted from open-source lists) are largely built for EU and US web stacks. They know Meta, Google, Adobe, Optimizely, Segment. They do not know Tabby. They do not know Tamara. They do not know salla_* or _zid_* or stcpay_*.

This matters more than it sounds. An unknown cookie in the declaration reads, to a merchant, as "the tool doesn't know the site I'm running." Trust in the scanner collapses. The declaration is less useful to the visitor. The merchant ends up manually classifying 10-20 cookies on day 1 — the kind of paper-cut that drags install time from 5 minutes to an afternoon.

What we did

We added 32 MENA-specific cookie patterns to our classifier, covering:

• Ecommerce platforms (Salla, Zid, Bonat)
• BNPL (Tabby, Tamara, Postpay)
• GCC payment gateways (PayTabs, HyperPay, Telr, Geidea, Moyasar, URWAY, EdfaPay, Foloosi)
• Mada + STC Pay (Saudi payment network + wallet)
• MENA shipping carriers (Aramex, SMSA, Naqel, Bosta, Mylerz, iMile)
• Regional ad networks (ArabClicks, Lana Ads, Tap Network)
• Qitaf (STC's loyalty program)

Each entry carries a category (necessary / analytics / marketing / preferences), a plain-English description, an Arabic description, and a regex pattern tuned against the cookie-name conventions we see in the wild. Payment gateways are categorized as necessary (they're the redirect-back session state of a transaction flow), shipping carriers as necessary (tracking widget state), BNPL as marketing (attribution trackers).

Where we got it wrong the first time

The initial patterns were all prefix-based: ^tap_, ^mada_, ^_ac_, ^amwal_. This felt clean but was catastrophic in isolation. ^tap_ matches any cookie starting with "tap_" — which includes gesture libraries, audio libraries, anything unrelated. ^mada_ and ^amwal_ are worse: "mada" and "amwal" are common Arabic words ("when" and "monies"), so any Arabic-themed app using them as cookie prefixes gets misclassified as a payment session.

We tightened all six of those to require the vendor prefix plus a known cookie-suffix word — e.g. ^mada_(session|token|gw|pay|tx|3ds)/i. Pinned the change with 19 new unit tests: half positive assertions (the legitimate cookies still match), half anti-match assertions (previously-shadowed unrelated cookies no longer match). So if anyone ever widens these back, CI breaks before it ships.

What makes this a moat

The database now has 124 patterns, 37 of them built for this region (it was 81 before this work, and 113 when this note was first published). Cookiebot, OneTrust, Termly, Iubenda could add this tomorrow. They won't. The MENA SaaS ecosystem is too small for them to prioritize — and once they do, the patterns need ongoing curation as regional vendors change their cookie naming. That curation is now a permanent process for us, not a one-shot project. Every merchant scan surfaces unknown cookies that we can query, review, and add patterns for. The gap shrinks continuously.

The result that matters to a merchant: the cookie declaration that ships on install actually knows the stack. No regional cookie we have a pattern for reading as "Unknown." No guesswork. Bilingual descriptions. Correct categories. Day one.

What's next

The original 32 MENA patterns were the high-confidence seed; the regional set is 37 today. As real merchant scan volume grows, we pull a weekly view of the cookies that came back as unknown, grouped by frequency, and curate the top unrecognized names into specific patterns. If you run the scanner on a store with a cookie we don't classify — that's how it shows up in our backlog.