Skip to content
MenuMap

Where are you eating?

So “open late” means near you, not somewhere across the country.

Or a whole state

Legal

Privacy

MenuMap is a search product, not an advertising product. It is built to collect as little as it can get away with, and this page describes exactly what that is.

Last updated August 2026

What we collect

  • Pages you open. Which page, when, how long it was open, and how far down it you scrolled. This is how we tell which pages are worth keeping: a menu opened and abandoned at the top looks exactly like one read to the bottom unless we know the difference.
  • Where you arrived from. The website, search engine, AI assistant or app that linked you here, and any campaign tag on the link. We keep the site and page you came from, never the rest of that address — other people’s links can carry their own private information in them.
  • Roughly where you are. A country, state and city estimated from your internet connection, which is often wrong by a whole state and is only used to know which cities to cover next. Your IP address is what makes that estimate possible; it is used and discarded, and never written down.
  • A code that lasts a day. So that four pages read in one afternoon count as one person rather than four, we work out a short scrambled code from your IP address and browser, using an ingredient we change daily. It is worked out on our server, never sent to your browser and never stored on your device, and it cannot be turned back into your IP address. Because the ingredient changes every day, the same person gets a different code tomorrow and these browsing records cannot be joined up across days. (The one thing on this site that does reach across days is the email-link code described below, and it belongs to venue operators we wrote to, not to people searching.)
  • What you are browsing on. Whether you are on a phone, a tablet or a computer, and which browser family — so pages can be built for the devices people actually use.
  • Searches. The text you type and how MenuMap interpreted it, so the matching can be improved. Searches are not linked to a personal identity.
  • Interactions. Which results you saw and tapped, so we can tell whether recommendations are any good and show venue operators how they are performing in aggregate.
  • Approximate location, only if you offer it. Tapping “Near me” on the website or in the iPhone app asks your device for a location, which is rounded to roughly 100 metres before it leaves the device and is used for ranking. It is not stored against you, and MenuMap never requests it in the background. In the iPhone app you can withdraw it at any time in Settings → MenuMap → Location; searching by naming a suburb keeps working exactly as it did.
  • Speech, only while you hold the microphone open. Tapping the microphone uses your browser’s own speech recognition to turn what you say into text in the search box. No audio reaches MenuMap and none is recorded by us — we receive only the words, exactly as though you had typed them. Be aware that “your browser” is not always “your device”: several browsers, Chrome included, send the audio to their own speech service to transcribe it. That is between you and your browser, but you should know it before you press the button. The microphone only ever opens when you tap it, and closes as soon as you stop speaking.
  • In the iPhone app, dictation never leaves your phone. The app asks iOS to transcribe on the device itself, and it only offers the microphone where your iPhone can actually do that — there is no fallback that quietly sends your voice to Apple instead. So the caveat above about browsers does not apply to the app: no recording is uploaded, kept, or sent anywhere, and MenuMap receives only the words, exactly as though you had typed them.
  • Claim submissions. If you claim a venue: your name, email, phone if given, role, and the file you attach to show you work there — usually an invoice, a bill, a registration, or a photo of you in the venue. Used to verify your connection to the venue and to contact you about the listing.
  • Opening a link in an email we sent you. If we write to a venue about its listing and somebody opens the link, we record that it was opened, which campaign it belonged to and which venue it was about, and we set a cookie holding a random code for up to 90 days. The code means nothing by itself and is not tied to your address, your name or anything else about you — it exists so that if you go on to claim the listing, we can tell the claim came from that email rather than from a search. Only venue operators we contact are ever given one.
  • Managing a venue you have claimed. When your claim is approved we email you a temporary password, and the first thing you do is replace it with one you choose. We store only a scrambled form of it — a one-way scrypt hash, from which the password cannot be worked back out — so nobody here can read your password, tell you what it is, or hand it to anyone who asks. We also record when it was last changed and how many failed sign-ins there have been since, which is what lets us lock an account that is being guessed at. Signing in sets a cookie that keeps you signed in for up to 30 days; you can also ask for a one-time link by email instead of using the password. While you are signed in we record which of your listing’s fields you changed and when, so a disputed edit can be traced to the account that made it.

What we don’t collect

  • No advertising cookies, no cross-site tracking, and no third-party analytics scripts. The two cookies we do set are described above and are ours alone: one keeps a venue operator signed in, the other tells us that a claim came from an email we sent. Neither follows you to any other website, because neither is readable by one.
  • No cross-site tracking, and no data sold or shared with data brokers.
  • No account is required to search, and searching builds no persistent profile of you. Claiming a venue does create an account — your name, your email, which venue you manage and when you last signed in — because holding a listing is a relationship and there is no way to have one anonymously.
  • Venues saved in the iPhone app stay on that iPhone. They are not uploaded to MenuMap or attached to an account.
  • No continuous location tracking.
  • No IP addresses or precise coordinates in the browsing records above. Claiming a venue and editing a listing are the exception: they store a one-way salted hash of the address, never the address itself, because rate-limiting abuse of a form that sends mail needs to tell two senders apart without knowing who either of them is.
  • No record of the full web address you came from — only the site and page.

Global Privacy Control

If your browser sends a Global Privacy Control or Do Not Track signal, we note that it was sent alongside the visit. We do not sell or share personal information, and nothing described on this page is tied to your identity, so there is nothing to opt you out of — recording the signal simply means it is not lost.

Session identifiers

To group one visit’s actions together, MenuMap generates a random value held in your browser’s session storage. It contains no personal information, your browser deletes it when you close the tab, and a new one is generated next time. It is sent to us with each measurement record and kept alongside them, which is what lets us see that four pages were one visit rather than four. It is not connected to you, to your device, or to anything you did on a previous visit. Venues you save are kept in your own browser’s local storage and are never sent to us.

Because that value dies with the tab, it cannot tell whether two visits in one afternoon were one person or two. The day-long code described above is what closes that gap. Of the identifiers that come with ordinary browsing it is the only one we hold that outlives a tab, it lives only in our own records, and it is deliberately built so that it cannot outlive the day. Two things are deliberately outside that, and both belong to venue operators rather than to people looking for somewhere to eat. If you sign in to manage a venue you claimed, that session cookie identifies you, because being signed in is the entire point of it; signing out removes it. And if you opened a link in an email we sent about your venue, the random code described above sits in your browser for 90 days — it identifies the email, not you, and clearing your cookies removes it.

Where data is processed

MenuMap is hosted on infrastructure that may process requests outside Australia. On the website, map tiles are served by a third-party basemap provider, which necessarily receives the requests needed to draw the map. The iPhone app draws its maps with Apple Maps instead, so those requests go to Apple rather than to us or to that provider.

The iPhone app

Everything above about searching applies to the app as well, with two differences worth stating plainly. The measurement described at the top of this page — pages opened, where you arrived from, the code that lasts a day — is a website record and is not collected from the app: the app talks to a separate interface that is deliberately outside the request log, and nothing it sends is written to those records. What the app sends is the sentence you typed and, only if you granted it, your rounded location; both are used to answer that one request. They appear in our hosting provider’s ordinary server logs, which it keeps for a day before deleting, and nowhere else.

Venues you save in the app are stored on that iPhone. Deleting the app removes them with it. Nothing is uploaded unless you sign in, which is optional and which nothing in the app requires: every feature works without it.

Dietary needs set in the app’s profile are the same: they are kept on that iPhone and are never stored against an account, because the one preference that is about a body rather than a taste has no business sitting on a server. They travel with a search as a preference — the same anonymous request as any other — and the results page tells you when they were used, with a way to drop them for that search.

There are two ways to sign in, and neither involves a password. Sign in with Apple, which is offered first; or an email address, which we send a six-digit code to. The code works once, expires after ten minutes, and is stored only as a hash — so there is no password to choose, no password to reset, and nothing to leak.

If you do sign in, we hold the identifier your sign-in method gives us for you (which identifies you on no other service), your email address, and the addresses of the venues you saved — so the list survives a new phone. Not what you searched for, not where you were, and not when you opened anything: search, venue, nearby and offers requests are all sent without your session, so they cannot be attached to you even while you are signed in. “Delete account” on the app’s Account screen removes all of it immediately, and leaves the venues saved on your iPhone exactly where they are.

The app also has a profile, and every field in it is optional: a first name for the greeting, tags for the kinds of food you like, and a mobile number. Signed out, the name and the tags stay on your iPhone and go nowhere. The mobile number exists for one thing — being told when an offer starts near you — and that has not launched yet, so we send no text messages at all today. The switch beside the number is off unless you turn it on, nothing reads the number while it is off, and clearing the number turns the switch off with it. The tags are suggestions on an empty search box; they never quietly filter an answer you asked for.

Retention

Search and interaction records are kept individually, in a database we control, for up to 24 months and then deleted. Individually rather than only as totals, because how one visit actually unfolded is what tells us whether the search worked; none of those records carries a name, an email address, an IP address or anything else that identifies you. Claim submissions are kept for as long as the claim relationship exists, and deleted on request once resolved. That includes the file you attach to prove the venue is yours: it is held in private storage that only a reviewer can open, it is never published or linked from any page, and nothing deletes it on a timer — if you want it gone, ask us and it goes.

The records of who opened a link in one of our emails are kept for as long as we are measuring the campaign it belonged to, and nothing deletes them on a timer either. They carry no name, no email address and no IP address — a venue slug, a campaign code, a random code and, once a claim exists, its reference. Ask and we will remove yours.

Your rights

Under the Australian Privacy Principles you can ask what personal information we hold about you, ask us to correct it, and ask us to delete it. Email hello@menumap.com.au and we’ll respond within 30 days.

Changes

If this policy changes materially, the updated date at the top of this page changes with it. See also our terms of use.