Privacy Policy

This is the privacy policy for the NullGlitch Back in Stock app, built by NullGlitch - Bakhtiyar Duganov, a sole trader based in Hobsonville, Auckland, New Zealand. It covers the app only: what it reads from Shopify, what it stores, and how that data is deleted.

Two kinds of people's information are involved. Merchants (the store owners who install the app) give us and Shopify information about their store; for that, NullGlitch decides how it is used, to run the app. Shoppers (a store's visitors) type their email address into the form on the merchant's product page to ask for one alert; for shoppers' information, the merchant decides that the form exists and what it says, and we process it on the merchant's behalf, only to send the alert the shopper asked for.

Through Shopify's APIs (when a merchant installs the app). The app asks for these permissions: read products and read inventory (to know when a sold-out variant is back, its stock, and the product's name, address and picture for the alert); read and write customers (to add a shopper who asked for an alert to the store's Customers with the tag back-in-stock, and to read that customer's marketing status); and the app proxy permission Shopify requires to connect the storefront form to the app. We read the store's name, web address, time zone, country, owner and contact email addresses and business address, to prefill the sender details. We also request access to one protected customer data field: Email. We do not request Name, Address or Phone. When a shopper asks for an alert, the app creates or updates that customer in the store by email address only, adds the tag, and changes nothing else about the customer. Marketing consent is written to the customer only if the shopper ticked the optional box (which the merchant must switch on); an existing "unsubscribed" status is never overwritten.

Directly from the merchant. The sender name, reply-to email, postal address, notification email, batching settings and the wording of the alert email; the waiting-list files a merchant imports (an email address, which product, and optionally the date the person asked), together with the merchant's confirmation that these people asked to be told; and anything the merchant writes to our support email or chat. The app also keeps automatic logs of its own use: alerts sent, held or skipped, and the reason.

Directly from shoppers. On the storefront form: an email address, and a record of the request: the exact wording the shopper saw, the time, the language, the country the store's page reported (stored as reported, not checked), where the form was shown (product page or embed), the version of the form, and whether the optional marketing box was ticked. The form does not set cookies, does not use browser storage, does not track visitors, and sends nothing to any third party. We do not collect a shopper's IP address with the request, their name, phone number, street address or device details. One narrow exception: when a shopper opens the unsubscribe or confirmation link in an email, their IP address is used only to limit abuse: it is turned into a one-way code with a secret key, the address itself is not written to our database, and the counter that holds the code is deleted within two days. The address does appear in our hosting provider's request log.

To send each shopper the one alert they asked for, for the product they asked about; to show the merchant who is waiting and why an alert was or was not sent; to keep the proof that the shopper asked; to protect stores and shoppers from abuse; to bill and support the merchant. We use it for nothing else. We do not sell or rent it, share it with advertisers, add anyone to a mailing list, or use it for marketing or analytics. Each alert contains only the requested product, the store's name and postal address, why the shopper received it, and an unsubscribe link. There is no tracking pixel and no click tracking. We do not make automated decisions about people: the size of a batch follows the stock, and a store is paused when its emails bounce or are reported as spam.

• Shoppers: the waiting list (email, the request record above); a record of each alert (which product, when, what happened, and a scrambled fingerprint of the address instead of the address); a scrambled fingerprint of any address that unsubscribed, bounced or complained, so it is never emailed again.
• Merchants: the store's details and settings listed above, the plan, the alert wording, the shopper-list files (raw addresses only until processed), and Shopify's login session for the store.
• Hosting: the app runs on Vercel with its functions in Sydney. The database is MongoDB Atlas hosted on AWS in Sydney. Atlas encrypts data at rest and requires an encrypted connection. The app also backs up its database twice a day; each backup is encrypted before it leaves the server, can only be opened with a key that is never stored on our servers, is kept in private storage at Vercel, and is deleted after 28 days.
• Email: alerts are sent through Amazon SES in Sydney.

• Shopify - the platform the app runs inside. It sees the store's own data; it is the source of product and stock information and receives the customer we add.
• Vercel - runs the app and stores the encrypted backups. It sees requests to the app and the encrypted backup files, which it cannot read.
• MongoDB Atlas - stores the database. It sees everything the app stores.
• Amazon Web Services (SES and SNS) - sends the alerts and reports delivery, bounces and complaints. It sees the shopper's email address, the alert, the store's name, and what happened to each message. SES also keeps its own list of addresses that hard-bounced or complained; we can remove an address from it on request.
• Tawk.to - an optional support chat on the app's Help page, for merchants only. It sees the store's web address, the plan, and what the merchant types. It never receives shopper data. It may set its own cookies on that page.
• Our own alert channel - tells us when something is wrong. It sees a store's web address and error counts, never shopper data.

We do not use any third-party analytics, advertising or error-tracking tool inside the app.

• A shopper's waiting request (email and request record): up to 180 days; then the address is removed and the rest deleted 30 days later.
• A finished request (alert sent, failed, cancelled, unsubscribed) with its request record: 180 days after its last event, then deleted. The request record is kept exactly as long as the request, because it is the proof that the shopper asked.
• A request waiting for the shopper to confirm: 7 days.
• Records of alerts: 180 days after they finish.
• The scrambled fingerprint of an address that unsubscribed, bounced or complained: kept so the address is never emailed again, and for nothing else. A store-level unsubscribe is deleted with the store's data. A bounce or complaint is kept and reviewed once a year: bounce records older than 3 years are re-checked and normally deleted; a complaint is kept until you ask us to remove it. See below.
• Shopper-list files a merchant imports: each address is deleted as soon as the file is processed; rows that were skipped are kept up to 7 days so the merchant can download them.
• A merchant's store data: while the app is installed.
• Backups: 28 days.

• The app listens for Shopify's mandatory privacy requests and checks that each really comes from Shopify (a signature) before acting.
• If a merchant uninstalls the app, we stop all sending at once and delete the login session Shopify issued for that store.
• Shopify sends a shop/redact request 48 hours after an uninstall. If the store has not reinstalled the app since, we then delete everything about that store: settings, waiting lists, alert records, unsubscribe records for that store, counters and logs, keeping only one dated line recording that the deletion happened. If the store reinstalled first, we keep its data so a returning merchant keeps their lists, and record that the deletion was skipped.
• If a shopper asks a merchant to erase their data and Shopify forwards it (customers/redact), we delete that shopper's requests (found by the email address or by the store's customer number, whichever Shopify sends) and remove the address fingerprint from their alert records. We keep the fingerprint of an address that unsubscribed, bounced or complained so the opt-out is still honoured.
• About that fingerprint. It is the only thing we keep after a deletion request, and we keep it for one reason: so that someone who asked us to stop, or whose mailbox rejected us, is not emailed again the next time an address is typed into a form. It holds the scrambled fingerprint (not the address), whether it was an unsubscribe, a bounce or a complaint, the date, and for an unsubscribe the store it was for. Nothing else, and it is used only to check "may we email this address?"; it is never shown to another store and never used for marketing. New Zealand's Privacy Act (principle 9) says information must not be kept longer than the purpose needs, so we review these records once a year. We do not say that a law forces us to keep it; we keep it to protect your own opt-out. If you would rather it were removed, write to info@nullglitch.co.nz and we will remove it (you are then simply no longer blocked, and nothing is sent unless you ask for an alert again).
• If a shopper asks a merchant for their data (customers/data_request), the merchant can download it from the app's Settings page: the requests with their record, the alerts and the unsubscribe entries for that store only.
• Data deleted this way can remain in our encrypted backups until they are deleted automatically, so it is gone from every backup within 30 days.

NullGlitch is established in New Zealand, not in Europe or the United Kingdom. Data is stored and processed in Australia (Sydney), by the providers in section 5; the optional chat provider processes what a merchant types into it under its own terms.

If you are a merchant in the European Economic Area or the United Kingdom, or your shoppers are, and you need a data processing agreement or standard contractual clauses for that transfer, write to us before installing and we will provide one.

Every request to the app is encrypted (HTTPS), and so is every database connection. Requests are accepted only when they carry a valid signature from Shopify, from Amazon SNS, or from a link we signed; addresses are stored in the database only where needed to send the alert, and elsewhere as scrambled fingerprints; only one person has access to production systems, and every account used to run the app is protected by two-factor authentication. If we learn of a breach affecting your data we will tell affected merchants without undue delay, and the authorities where the law requires it.

The Shopify merchant who installed the app decides what their store collects and how their own shoppers are told about it. If you are a shopper, the first place to go is the store you asked for an alert from; you can also stop any alert with the unsubscribe link in it.

If you are a New Zealand resident, the Privacy Act 2020 gives you the right to ask what personal information is held about you and to ask for it to be corrected; complaints can be made to the Office of the Privacy Commissioner. If you are an Australian resident, the Privacy Act 1988 covers your rights; complaints can be made to the Office of the Australian Information Commissioner (OAIC). If you are in the EEA or the United Kingdom, you may have the right to access, correct, erase or restrict the use of your personal data and to complain to your data protection authority. To use a right with us, write to info@nullglitch.co.nz; we will act on the merchant's instruction where the merchant is responsible for the data.

Merchants: you can ask us at any time for a copy of your own settings and lists, or to close your account and delete everything.

We will update this page if what the app reads, stores or does with data changes, and update the date above.

NullGlitch - Bakhtiyar Duganov (sole trader), Hobsonville, Auckland, New Zealand. Email: info@nullglitch.co.nz. Merchants can also use support@nullglitch.co.nz (we reply within one business day, New Zealand time).