Last updated: 26 August 2026
This policy says what SmartCart collects, what it sends to us, what it sends to the supermarkets, and what stays on your phone.
The short version. Your shopping list is kept on your phone and the price comparison runs there. We collect usage analytics about how the app is used, which includes the words you search for and the names of the products you add to a list. An account is optional and is only needed to sync your favourites. The app shows ads supplied by Google, which collect a device advertising identifier. Some features send requests from your phone straight to a supermarket: product photos, the store search, the check that asks which nearby stores have an item, and, once you pick a Coles store, a background check that reads that store's own prices and stock for the Coles items on your list. If your phone's own device backup is switched on, Android can include the app's data in that backup, which goes to your Google account. All of that is described below.
SmartCart compares the everyday prices anyone pays without a loyalty card at Woolworths, Coles and ALDI in Australia. You build a shopping list on your phone and the app shows what that list costs at each store.
Your shopping list, the items you add, the quantities you set, your favourites and your settings are stored on your phone, and the comparison between stores runs on the phone rather than on a server. The app does not read the phone's location. The one thing it asks about where you shop is a postcode or a suburb name for the store picker, which is optional and is described further down.
The list is not uploaded as a list. What does reach us is described in the next section: adding an item records one analytics event carrying that product's name, so we can see which products people put on their lists. That is one action at a time rather than a copy of your list, and unless you have signed in it is not attached to your name.
We collect analytics about how the app is used, so we can see which features people use and which products they look for. An event is recorded when you open the app, view a screen, run a search, add an item to a list or remove one, tick something off, set a favourite, open a product, change a setting, or use a feature.
Each event carries:
Events are queued on the phone and sent to our backend when the phone is online. Using the app with no connection does not lose them and does not send them either; they go when the phone next has a connection.
While you are signed in, the events reach us over a connection that identifies your account, so we can connect them to it as well as to the device identifier. While you are not, that identifier is the only thing joining one event to another.
The analytics do not carry your shopping list as a whole, your contacts, your photos, your calendar, your location, or anything you have not entered into the app.
An account is optional. Everything that compares prices works the same without one. What an account adds is that your favourites follow you to another phone.
Signing up is through Google. When you do that, Google tells us the email address and the name on your Google account, and we keep those. We never receive your Google password. If you already have an email and password account with us from earlier, that still works for signing in.
You can ask us to delete the account and what is attached to it. See "Data deletion".
The account details, the analytics events and the feedback described below are stored in a database we run on Supabase, in Supabase's Australian region, which is in Sydney. Supabase hosts it for us.
If you send feedback from inside the app, we receive what you wrote, which part of the app you said it was about, and the app version. You can add your email address if you want a reply, and you can attach screenshots. Both are optional. A screenshot shows whatever was on the screen when it was taken, which can include your shopping list, so it is worth a look before you send one.
Notifications about weekly specials, your favourites and the price alerts you set are worked out on the phone, from the price snapshot it has already downloaded, and shown by the phone. We do not send them and there is no push service. Turning one on or off records an analytics event saying which switch you moved, the same as any other setting.
SmartCart shows ads, supplied by Google AdMob, which is Google's advertising service. The ads pay for collecting and checking the prices the app compares. You can remove them: the "Stop ads" option in the app, and referring a friend, both turn ads off.
To choose, show and measure ads, AdMob receives your device's advertising ID, its IP address, and information about the ads you are shown and interact with. The advertising ID is an identifier Google issues for advertising, and it is a different thing from the random identifier our own analytics use; you can reset it, or ask your phone to limit ad tracking, in your device settings under Google, then Ads. AdMob is run by Google, and what it collects is Google's to handle under Google's privacy policy at https://policies.google.com/privacy and its advertising terms. SmartCart does not receive the advertising ID, and it never joins the ads you see to your shopping list, your searches, or your account.
To show prices, the app downloads a public price snapshot over https. The snapshot contains product names, prices, categories and store information, nothing about any person. It is one file served to every phone, so the download itself tells us nothing about you beyond what any web request carries.
Prices in the snapshot are refreshed regularly, and each price in the app shows its age. Woolworths and Coles prices each come from one specific store, named in the app by that retailer's own store number, and ALDI publishes one national price list. Price history accrues in the snapshot so the app can show whether a special is genuinely low. All of that data is about products.
The snapshot also carries a list of supermarkets, so that when you type a postcode the app can offer you the shops near it without asking anyone. That list is the same in every copy of the snapshot: it is the retailer's own published list of every store it has, with the suburb each store publishes, and where a store states its own postcode and location publicly, those too.
Alongside that, each store carries the postcodes its suburb covers, worked out on the computer that builds the snapshot by looking the suburb up in a public list of Australian localities. That is a fact about a suburb, not about a shop and not about you: it is worked out the same way for every store in the country, before anybody installs the app, and it would be identical if you never used it. Where the app shows one of these it says the postcode is the suburb's rather than the shop's, because a suburb can cover several postcodes and a shop sits in one of them.
It is a list of shops, not a list of your shops. Nothing in it records which store you picked, which stores you looked at, or that you use the app at all, and the snapshot is one file served to everybody rather than one built for you.
The app shows a photo on each product. The photos are not in the snapshot. They are loaded from image servers run by Woolworths, Coles and ALDI, one request per picture, straight from your phone. Each request identifies the product, and the server answering it can see the IP address it came from. Scrolling a list of products sends a series of those requests.
Photos are on when you install the app. The switch that turns them off is in the menu beside the refresh button. With photos off, no request of this kind is made, and nothing else changes: every price, every price age and every comparison works the same either way.
The store picker lets you search for the Woolworths and Coles shops you actually use, so prices and shelf answers can be about your shops rather than about a guess. A search happens only when you run one: you type a postcode or a suburb and press the search button. Nothing searches on its own or in the background.
One search makes four requests to woolworths.com.au from your phone, a few seconds apart. The first reads Woolworths' robots.txt, the file a website publishes to say what may be fetched from it, and the search stops there if that file says this is off limits. The second loads the home page, which is what starts the anonymous session the rest need. The third carries the postcode or suburb you typed, and Woolworths answers with the places that text matches and where they are on the map. The fourth asks for supermarkets around the first of those places, and the coordinates it carries are the ones Woolworths itself just answered with, not a location read from your phone. The app never reads the phone's location; the only places it knows are the ones you type and the ones Woolworths names back.
These four requests draw on the same daily allowance as the shelf check below: at most sixty Woolworths requests a day from one phone, with a pause of a few seconds between them, both enforced in the app. Searching does not open a second allowance.
The store you pick is saved on your phone: its name, suburb, postcode and map position, exactly as Woolworths listed them. The pick itself is not sent to Woolworths, and what reaches us about it is the ordinary analytics event that records that you changed a setting. The Coles side of the picker is matched against the store list already on your phone, so choosing a Coles store sends nothing to Coles for the choice itself, and nothing to ALDI. Picking a Coles store does start the background price and stock check described under "Your picked Coles store's prices and stock", which is the one thing that then makes requests to Coles.
The price snapshot cannot say what is on a shelf today, so the app can ask Woolworths. This happens only when you tap the check on an item, for that one item, and only once the app holds a postcode to ask about.
That postcode comes from the store picker. Searching a postcode there keeps it as the one the check uses, and picking a Woolworths store saves that store's own postcode if you have not searched one. So the saved postcode can be one you never typed: it is the store's own, from the retailer's public listing, not a statement about where you live.
A check makes three requests to woolworths.com.au from your phone, a few seconds apart, which is why it takes a moment. The first reads Woolworths' robots.txt, the file a website publishes to say what may be fetched from it, and the check stops there if that file says this is off limits. The second loads the home page, which is what starts the anonymous session the third one needs. The third carries the product's Woolworths product code and the saved postcode, and, if you have picked a Woolworths store, that store's map position exactly as Woolworths listed it, so the answer covers the store you actually shop at. Woolworths answers with up to five stores near that spot and what its own system says about each one.
The answer is held in memory while the app is running, for at most half a day, and it is never written to your phone or sent anywhere else. The postcode itself is stored on your phone until you clear it. The store picker shows the stored postcode whenever there is one and has a button that clears it.
Of the things stored on your phone, the postcode and the product's code are the only ones these requests carry. Your shopping list does not go with them. The requests also carry what an ordinary browser request carries: a browser user agent string, the address of the Woolworths product page the code belongs to, and the session cookies Woolworths sets on the home page. Those cookies are Woolworths' own and they tie the three requests of one check together. The app holds them in memory and drops them when the check finishes, so the next check starts a new session. The store search above carries the same ordinary headers and its own fresh session each time. The server answering any of these requests can see the IP address they came from. If the app holds no postcode, no request of this kind is made.
The price snapshot carries one set of Coles prices, from the store the price collector reads. Once you pick a Coles store, SmartCart can show that store's own price, and whether an item is on its shelf, instead. It does this for the Coles items already on your list, in the background, so your comparison becomes about the store you actually shop at.
Coles does not answer an ordinary app request, so this check is made through a hidden in-app browser: a web view, on your phone, that loads Coles pages the way your own browser would. It is not shown to you, and you do not have to do anything to start it. It runs only after you have picked a Coles store, and only for the Coles items on your list; an item you have not put on a list is never looked up. Woolworths and ALDI are not touched by this check, it is Coles only.
The check loads the Coles home page once, which starts an anonymous session and clears Coles' own check for automated traffic, and then loads one product page for each Coles item on your list. Each of those requests carries the product's Coles code, in the address of the page, and the store you picked, set as one of Coles' own preference cookies so the page prices for that store. It also carries what an ordinary browser request carries: a browser user agent, and the session and preference cookies Coles sets. Those cookies are Coles' own; the web view keeps them on the phone, in the app's private storage, so one cleared session can serve several lookups rather than starting Coles' check over each time. The server answering can see the IP address the requests came from, the same as any web request.
If Coles ever answers with a "confirm you are a person" check, the app shows that page to you to complete; it never tries to answer such a check for you. If you do not complete it, the prices simply stay at the snapshot's figures.
What comes back, the store's price and whether the item is on the shelf, is kept on your phone so a relaunch does not fetch it again, and it is retired after a couple of days. Your shopping list as a whole is not sent; only the individual items' product codes are looked up. Which store you picked, and which items were looked up, are not sent to us beyond the ordinary analytics that records that you changed a setting or added an item.
The outside parties the app talks to are these: the supermarkets, for the photo, store search, shelf check and Coles price requests above; the file host that serves the price snapshot; Supabase, which holds our database; and Google, both when you choose to sign in with a Google account and through Google AdMob, which supplies the ads. The analytics described above go to our own backend rather than to an analytics company, and the app carries no crash-reporting service. If that changes, this policy is updated first.
SmartCart allows Android's own device backup to include the app's data: your shopping list, your store picks, your postcode and your settings. This is so that when you reinstall the app, or move to a new phone, your setup comes back instead of starting from scratch. This backup is Android's, not the app's: the data goes to your own Google account under the backup you control, SmartCart never sees it there, and it is never sent to us or to any supermarket. It only happens if you have device backup switched on for your phone, and you can stop it at any time in Android's Settings, under System, then Backup, by turning backup off or by excluding SmartCart. Turning it off does not change anything on the phone itself.
Uninstalling the app removes your shopping list, your store picks, your postcode and your settings from the phone.
If you have an account, email cgdct97@gmail.com from the address the account uses and ask us to delete it. We delete the account, the email address and name we hold, the analytics events attached to it and any feedback you have sent, and we write back when it is done. You can ask for the data to be deleted without closing the account, and you can ask for a copy of what we hold about you.
Analytics events sent while you were not signed in carry the random device identifier and nothing else. We cannot connect that to a person, so we cannot pick yours out on request.
If you had device backup switched on, a copy of the app's data may remain in your own Google account backup until Android's own retention clears it or you delete that backup from your Google account; that copy is yours, held by Google under your account, and reachable only by you.
If this policy changes, the updated version will be published at the same address as this one, with a new "last updated" date.
Questions about this policy: cgdct97@gmail.com