Privacy policy

Who we are

Qaema is a QR-menu platform operated by dzzz.ai for venues in the Kingdom of Saudi Arabia. This policy explains how we handle personal data when you use our website, menus and enabled business tools. Qaema handles account and subscription data for its own service; venues determine how they use their diner, staff and sales data and remain responsible for their own privacy notices.

What we collect from venue owners

Account details: your name, email address and password hash. Venue details: name, address, opening hours, phone number and social handles you enter. Activity: a change log of edits made by you, your team and connected AI agents, kept so that changes can be undone.

Connected agents act on your behalf through OAuth. We store the connection, its scopes and the time of each write. We never send your data to an AI model ourselves; extraction and translation happen inside the agent you connect.

What we collect from diners

Public menu pages do not require an account. When a diner leaves a rating, we store the rating, an optional comment and a daily session identifier derived from the request so that one device counts once per day. We do not store IP addresses with ratings.

The personal menu list is kept in the browser until the diner chooses an ordering or sharing action. Sending it through WhatsApp shares it with the venue and WhatsApp. Where Table Service is enabled, submitted orders, item choices, notes, table references and totals are processed by Qaema and the venue to handle the request. If the venue has analytics switched on we do record that items were added and removed, how many items were on the list when it was shown to staff, and — when a pickup order is sent — the number of items and which of four price bands the total fell in. Those records carry the same daily session key as the rest, so what a single device put on its list on a single day can be pieced together from them. The section below lists everything we record and how long we keep it.

Analytics on public menus

When a venue leaves analytics switched on, we count what happens on its public menu. This is the whole list: a printed QR code being scanned; the menu being opened, recorded with its template and whether it was opened as an installed app; a section being looked at, recorded with which section; an item, or an item marked sold out, being looked at, recorded with which item and which badges were showing on it; an item being added to or removed from the diner’s list; the list being shown to staff, with how many items were on it; a filter being used, recorded with which kind of filter — allergen, dietary, badge or calories — and which one: an allergen filter is recorded by name, so a diner filtering out gluten at their table has that stored as filtering out gluten, at that table; a search being made; the menu language being switched, recorded with the language switched to; the Wi-Fi password being copied; a tap on the call link; a tap on the reserve link, recorded with the reservation method; a tap on the delivery link, recorded with the delivery provider; a tap on the Google review link; a tap on a social follow link, recorded with the network and where on the page it was tapped; a pickup order being sent, with the number of items and a price band; the add-to-home-screen prompt being shown or accepted, recorded with the device platform — iOS, Android or other; a rating being submitted; and a visitor’s own AI assistant reading the menu, recorded with which of the two ways it read it — the assistant tool interface or the llms.txt file — and the assistant’s name. Nothing else is recorded: a record carrying anything we have not listed is rejected outright rather than trimmed. These basic venue statistics use no cookies or advertising. Optional Google analytics is separate and described below.

Every record is stamped with the venue, whether the visit is dine-in, pickup or delivery, the menu language, and — when the diner arrived by scanning a table code — the table number printed on that code. A table number is a location inside the venue: for as long as the record is kept, it says which table a visit came from.

To count a device once per day we derive a session key: the venue, the request address, the browser user agent and the local Riyadh date, hashed together with a secret we hold. Only the 16-character result is written to the record. The address and the user agent are never stored, and the key changes at midnight Riyadh time, so a visit cannot be linked to the same device on another day or at another venue. Records made in one day at one venue do share that key, so they can be read together as one visit.

The text a diner types into the menu search is never sent to us — only how many characters it was. We never store an address, a cookie, an advertising identifier or any other device identifier alongside these counts.

Analytics records are deleted 400 days after they are written. A venue can switch analytics off at any time from its dashboard, and its menu and its printed QR codes then count nothing at all. A rating sent through the feedback form is stored either way, as described above: a diner who fills that form in has chosen to send it, so only the analytics record of the submission stops.

Optional Google Analytics and Tag Manager

If enabled on this site, Google Tag Manager and Google Analytics load only after you choose Allow analytics. They help Qaema measure landing-page and pricing visits, signup clicks, completed signups, venue creation, menu publication, trial and checkout starts, POS activation, menu action types and POS workspace changes. Page labels are coarse; URL query strings, invitation and authentication tokens, names, phone numbers, form content, search text, item identifiers, dietary choices, order details and payment data are not included in our events.

Google receives browser and device information and processes your network address when the browser connects to Google. Google analytics cookies can recognise repeat visits on the same site for up to 90 days, renewed by later visits. This optional processing is separate from the venue statistics above and may take place outside Saudi Arabia. Advertising consent remains denied. We do not enable Google Signals, advertising personalisation or automatic form tracking.

You can decline and continue using the service, or change your choice using Analytics preferences at the end of the page. The choice is stored in this browser for 180 days and applies across qaema.ai and its subdomains, including the app and published menus. Withdrawing consent stops new events and removes accessible Google analytics cookies; it does not delete events already sent. Do Not Track and Global Privacy Control are honoured. If the venue disables menu analytics, optional Google tracking on that menu is also disabled.

Billing, staff and business records

For subscriptions, we process billing identity, business address, VAT registration details when supplied, payment references, status, amounts and receipts or invoices. Card entry is handled by the payment provider; Qaema does not store full card numbers or security codes.

Enabled POS and Host features process staff access records, device/session references, sales, refunds, table-service requests and guest queue details, such as names, contact numbers and party size when provided. Finance handoff processes uploaded purchase invoices, statements, attachments and the export/filing records owners choose to save. Do not upload personal information unrelated to your business purpose.

Where a venue offers a home-visit Booking service, a guest may share a location pin so the team can find them; we store it only if the guest gives consent, and declining it never blocks the booking — the venue simply learns the address another way. The venue’s team sees the pin’s exact coordinates only on the day of the visit; before and after, they see the matched zone rather than the address. We delete the pin and the vehicle plate once the venue’s own retention setting for Bookings has passed since the booking ended — 30 days by default, changeable at any time from the Bookings settings — while the booking record itself is kept.

Essential cookies and browser storage

Account sign-in and connected apps use necessary session and security cookies. Browser storage also keeps preferences, consent choices and local menu or register state. These functions are separate from optional Google analytics; declining optional analytics does not prevent sign-in or core service use. Clearing browser data may sign you out or remove locally saved information.

Why we process data

We use necessary information to provide and secure the service, authenticate users, publish menus, manage subscriptions, handle support, operate enabled venue features and keep required financial records. Processing is based on the applicable basis for that purpose, including performing agreements, legal obligations, consent where required, and legitimate interests where permitted. Optional analytics consent is separate from using the service.

Menu content you publish is public. Venue records are available to authorised members and integrations within their permissions. We share necessary information with service providers for hosting, payments and email, and may disclose information where required by law or to handle a lawful claim. Connected services have their own privacy policies.

Retention and security

Public-menu analytics and feedback follow the 400-day retention schedule described above. Other records are retained for their service purpose, security, required accounting obligations or lawful claims; closing an account does not instantly erase every invoice, backup or record held by another provider.

We use access controls and protected connections to limit unauthorised access. No system can promise absolute security. Keep credentials private, limit staff permissions and contact us if you suspect an account compromise.

Where data lives

Data is stored with Neon (database) and Cloudflare (edge cache, media) in data centres outside the Kingdom. Payment processing uses Moyasar, and configured transactional email uses Resend. These providers process the information needed for their service. Hosting and provider processing may take place outside Saudi Arabia; international transfers must meet applicable data-protection requirements. Contact us for details relevant to your account. We do not claim that all data stays in Saudi Arabia.

Your rights

Subject to applicable law, you may request information about processing, access to your personal data, a copy, correction, or destruction, and withdraw consent where processing relies on it. Contact us to make a request; we may need to verify your identity and relationship to the account. Withdrawal does not invalidate earlier lawful processing. A venue controls its own customer records, so diner requests may also need to be directed to that venue. You may complain to the competent Saudi data-protection authority (SDAIA).

Contact

For privacy requests, use the operator email in the policy enquiries section below. Include the account email and the request type, but do not send passwords, card details or unnecessary identity documents. For a restaurant order, contact the venue using its menu contact details.