Privacy Policy

Data we store

When you install LabelCraft, we store:

Store information. Your shop’s .myshopify.com domain, subscription plan, monthly label usage count, and app settings (default quantities, GS1 prefix, your declared printer brand and model, and any printer calibration offsets). Since 4 September 2026 we also keep the store owner’s email address, which Shopify uses to contact the owner, read from Shopify when we refresh your store name (about once a month). We write to it, as the owner’s address: one welcome message the day you install; the Tuesday news, once that welcome has announced it, at the address the welcome went to; and, if you have left no address in the app, every other email described under Where data lives: the help email, the one question we ask when you cancel your paid plan, the messages about setting up and about labels that stop coming out, the one question about what you think of the app, and the weekly note on barcode problems in your catalogue. The weekly note goes there too when the box you ticked beside your address does not cover it. Every message carries a one-click unsubscribe, and the address goes with everything else when you uninstall, unless you asked us to stop writing to it: that address then stays on our opt-out list so we can honour it, as the retention section says. Removing the address you left in the app is narrower than unsubscribing: it leaves the owner’s address untouched, and every one of those emails then goes there, and the Tuesday news to the address your welcome went to, if that welcome announced it. The unsubscribe page each of these emails links to can stop all of them, at the address it reached as well as at your store’s other addresses.

Printer connection and station settings. If you connect a printer through PrintNode, we store the PrintNode API key you paste, the printer you pick, and its name, so the app can send jobs to it. That key is used server-side only to talk to PrintNode and is never sent back to your browser. If you set up per-location print stations, we also store, for each Shopify location, the label template and the copies rule that station last used. Both live in the same app settings record as your store information above.

Product data snapshots. Label templates you create and your print job history, which includes the product details printed on labels (titles, variants, SKUs, prices, barcodes). Product data is read from Shopify’s API only to render your labels.

Staff account details. The app reaches your store with an access key Shopify issues to the store, not to a person. Shopify’s sign-in gives us no staff member’s name and no email address (the address listed under “Store information” is read separately, through Shopify’s API). Each screen of the app does carry the Shopify user ID of the staff member using it. That ID is a number with no name or email address, and we use it only for the admin language described in the next paragraph.

Your chosen admin language. Shopify tells us which language your admin is set to only on the first screen you open, so to keep the app in that language as you move around it we store the language together with the Shopify user ID of the staff member it belongs to. That ID, which Shopify puts in the login session, is a number with no name or email address. We keep only one at a time per store, never a list of who works there.

Feedback you write to us. The notes you type into the app’s feedback box are kept with your store, read by us, published nowhere, and deleted with everything else when you uninstall. Under that box you can add an address for us to reply to and tick a box beside it. If you do, two things happen: we keep that address on that one note, and we also send that note and that address to ourselves by email, through Resend, so we can answer you. That email then sits in our support mailbox like any message we receive, and uninstalling deletes your note from the app but does not erase an email we have already been sent. The address receives nothing but our answer, it joins no mailing list, and it is never used to contact you about anything else. When we write back inside the app, our reply is kept with your note and deleted with it, and the first time you open your feedback page after that we record that the reply was shown to you, so we know it arrived and can stop flagging it.

Data we do NOT collect

LabelCraft never asks for your customers’ identity and keeps none of it: no customer name, email, phone number, address, or payment information. If a customer data request carries any, we drop it (see GDPR). From orders and returns, the app reads only the product lines, the number, the date, the ID Shopify gives them and, for a return, its status, and only if you give it access. Of those, it keeps, in your print-job history and on your store’s behalf, only the printed product lines, the order or return number, and the ID Shopify gives the order (see Order and return access).

Order and return access

Two features - printing labels straight from an order, and relabeling a return - need Shopify’s read_orders and read_returns permissions. These are optional: the base install asks only for your products and inventory. You grant order or return access in-context, only when you open those pages, and you can revoke each permission from the page that uses it: order access on “Order labels”, return access on “Returns to label”. Relabeling a return needs BOTH, because in Shopify a return belongs to an order, so “Returns to label” asks for both and “Order labels” is where the order permission is turned off again.

When granted, we read only the label fields. From each order or return line we read the product and variant details needed to print a label - title, variant, SKU, barcode, price, compare-at price, vendor, and weight - plus the quantity (and, for a return, the restocked quantity and the return's status) and the order or return number and date.

We never read customer identity. No customer name, email, phone number, or shipping or billing address is ever requested, read, or stored. Shopify’s install screen names a broad order data category, but LabelCraft selects only the product lines inside an order - never the shopper. See Data we do NOT collect above.

Read live, not stockpiled. Order and return data is read at the moment you print; for a print job made before we kept the order’s ID, Shopify is asked, by the order number already saved there, for that order’s ID and creation date, and only the ID is kept. Nothing from it is kept except the product details and the order or return number saved in your print-job history, so you can reprint the same label (see Data we store). Beside that number, the ID Shopify gives the order is kept too, for the reason given under GDPR.

Hosted in the EU, erased on uninstall. These reads run on our EU servers (see Where data lives) and, like all of your data, are purged when you uninstall (see Data retention and deletion).

How we use data

To provide the service: rendering label PDFs, remembering your templates and settings, enforcing plan quotas, and responding to support requests. Beyond that, and only as the sections below describe, to find where setup and printing break, to understand why a store leaves, to see how stores use the app and what it earns, to decide whom to write to, and to put the app back after a failure. We do not sell data, share it with third parties for marketing, or use it for advertising.

Usage measurement inside the app

Some stores install LabelCraft and never print a label. From outside the app we cannot tell whether they could not find a button, could not connect a printer, or opened it once and closed the tab. So the app records which of its own screens you open, inside the Shopify admin only. That is the whole of it.

What is sent. What we put in them: the name of the screen you opened, your plan, and a pseudonym for your store. Nothing else. No product titles, no SKUs, no prices, no barcodes, no label content, no order or customer data, and no staff name or email address. PostHog’s own script adds a technical description of your browser to both, described below.

Your domain does not leave. The pseudonym is the same stable one-way hash of your .myshopify.com domain that the churn record described below uses. It is a pseudonym rather than anonymisation, and this says so instead of pretending otherwise.

How that stays true. The tool we use, PostHog, can be configured to capture every click and every string on a page by itself, and to record the session as video. Both are switched off. Two events leave: the screen view we named by hand, and the one PostHog sends when the app tells it which pseudonym that screen view belongs to, which carries that pseudonym and your plan. On both, PostHog’s script stamps its own technical properties, which we do not remove: the browser and its version, the operating system, the device type, the size of your screen and of the window, your time zone, and the version of PostHog’s own library. The address of the page is cut out of them before they leave, but the connection itself still shows PostHog’s servers the internet address your browser comes from, and we do not switch off the country lookup PostHog derives from it. Text that happens to be on your screen is never read, and your screen is never filmed.

PostHog processes these events on servers in the European Union, the same region as ours. We use them to find where setup breaks. They are not used for advertising and are not shared with anyone, apart from the last screen seen per store, which our code repository keeps (see Where data lives).

The legal basis is our legitimate interest in making the app usable by the people who install it. Because these events are stored under the pseudonym and not under your domain, the automatic purge described below does not reach them. Email support@labelcraft.tech and we will delete them, or keep your store out of this measurement entirely.

This is not Google Analytics. Google Analytics still never runs inside the Shopify admin or during login, exactly as described under The labelcraft.tech website. One measures the public site, the other measures the app, and neither loads where the other runs.

Where data lives

Our servers and database are hosted on Fly.io in Paris, France (European Union). All traffic between your browser, Shopify, and LabelCraft is encrypted with TLS.

Ten outbound exceptions, one of them only if you set it up. If you connect a printer through PrintNode, the finished label is sent to PrintNode’s service so it can reach your printer. That means the label’s own content - whatever your template prints, such as titles, SKUs, prices, and barcodes - leaves our EU servers for PrintNode, outside the EU, for as long as it takes them to deliver the job. Nothing is sent there unless you have saved a PrintNode key and chosen a printer, and disconnecting PrintNode in Settings stops it.

Email goes out through Resend. Six kinds of email go through Resend, our email provider (its servers, not ours): the welcome message the app sends on install day; the help email we may send, for one of four reasons (warnings on your prints, a trial about to end, printing on one day only, or no print for a while), to the address you leave in the app or, if there is none, to the store owner’s address; the one question we ask when you cancel your paid plan, to the same address as the help email; the other messages to the address you leave in the app, each of them named by the box you tick beside it (setting up, labels that stop coming out, a weekly note on barcode problems found in your catalogue when there are any, the Tuesday news, and one question about what you think of the app), or, if you have left none, all of them except the Tuesday news to the store owner’s address, the weekly note also when the box you ticked does not cover it; the few messages we send to a contact address a store publishes, when we have neither address; and, when you tick the reply box under the feedback form, the copy of your note that we send to ourselves so we can answer you. Resend receives the address and the message, keeps its delivery log, and holds the addresses that unsubscribe, bounce or complain so that we never write to them again; that list is checked, together with our own, before every message to you. The feedback copy is the one that goes the other way, to our own support mailbox, so no opt-out list applies to it. When Resend is unavailable, all of these messages except the welcome and the feedback copy may go out instead through the mail server of our own mailbox, Namecheap Private Email; those are then checked against our own list only.

The Tuesday news, and how to stop it. A short email on Tuesdays tells you what changed in LabelCraft, and only in weeks when something did. It goes to the address you leave in the app when you tick the box that names it, or to the store owner's address Shopify gives us once your welcome email has announced it, with a link that stops it before the first one. It goes out the same way as the messages above and is checked against the same lists. Its own link stops that email alone; everything else we send you stays as it is. A store whose welcome did not announce it, and that has not ticked that box, never receives it.

Error reports go to Sentry. When a screen of the app breaks, the app sends the error to Sentry, our error-tracking provider (its servers, not ours), so that we learn about the fault instead of waiting for you to report it. Sentry receives the error message, the technical trace of where the code stopped, and the address of the screen with everything after the question mark cut off. What else is attached as a label depends on where the fault happened. In your browser: your .myshopify.com domain, your plan, and the two headers a browser attaches by itself, which are the browser and system you run and the address of the page you came from, that one cut at the question mark as well. That report goes from your browser straight to Sentry’s servers, so the connection itself shows them the internet address your browser comes from. On our servers: the address of the screen, and on some of them a reference number that ties the report to our own server log. Since 15 September 2026 no report carries the Shopify user ID of the staff member who hit the fault, the cookies, any other request header, or the content of whatever was being sent when it broke: all of that is cut before the report leaves. No product title, SKU, price, barcode or label content is attached. Sentry keeps these reports in its European region, on servers in Frankfurt, Germany, and we accepted its data processing terms on 15 September 2026.

The live chat goes through Crisp. When the app shows a chat button, the chat window inside the Shopify admin is run by Crisp, our chat provider (its servers, not ours). The chat bubble on the pages of labelcraft.tech is Crisp’s too, and what it sees there is described under The labelcraft.tech website. In the admin, Crisp’s script loads on the app’s screens, so the connection shows Crisp the internet address your browser comes from, and the script can read, like any script on a page, the browser and system you run and the address of the screen you are on. Before it loads, the app cuts from that address the sign-in details Shopify puts in it, the Shopify user ID of the staff member included. The rest of that address stays as it is, so it can hold what you asked to see on that screen, such as the words you typed in one of the app’s search boxes (a product title or a SKU, for example) or a barcode. As soon as the app loads, it hands Crisp your store’s name and your .myshopify.com domain, so the person on duty can see which store is visiting. When you open the chat, the app adds, when it knows them, the code of the last warning one of your prints raised and the name of the template you last printed on. It may also add, next to your store’s domain, a short key signed by our server, so that we can tell a conversation opened from your store’s admin from one that someone else has labelled with your domain. If you answer the two questions the chat asks first, your printer brand and your label size go too. When the app shows you a message from our team in the chat, it notes in Crisp which message it was and its language and, for a message offering help, its reason (warnings on your prints, a trial about to end, printing on one day only, or no print for a while). Crisp then receives what you write, and the address you type if you leave one. To find that conversation again from one screen to the next, its script keeps an identifier for it in your browser. That address serves to answer that conversation and nothing else: it never signs you up for our emails, which only the separate box in the app does, and that box is never ticked in advance. Beyond that address, the app itself sends Crisp no product title, SKU, price, barcode or label content. When one of us marks your support problem as solved, our server reads your conversation in Crisp, its messages included, and your store’s other conversations there, their messages included. To find them, it goes through the list of our conversations in Crisp, with the details each one carries, and keeps nothing from those of other stores or of visitors to the website. Of all that, it uses only your conversation’s channel, whether an email address is attached to it, the signed key, who wrote each message and when, and whether one of our own messages already holds the link to our App Store reviews. It may then write one message into your conversation asking for a review on the Shopify App Store. We keep only the date and the outcome, never what the conversation says. When the app has a message from our team for you (a welcome, a follow-up, a note after your first print, an offer of help or, once on a paid plan, a question about why you chose it), your browser sends our server the identifier of your Crisp conversation; our server checks that the conversation names your store and, when it carries the signed key, that the key is valid, then writes the message into it, so it stays in your history and we can see it. To check, it reads your conversation’s details in Crisp and, before the note after your first print, its latest messages, yours included. Of all that, it uses only the store your conversation names, the signed key, the conversation’s channel, whether an email address is attached to it, and whether one of our own messages already holds the link to our App Store reviews. It never writes the message when an email address is attached to the conversation, or when the check fails or Crisp refuses the message; the app then shows the message only on your screen, as before. We keep only which message it was, the date and the outcome. When a member of our team opens your conversation in Crisp, our server shows the state of your store (installation, plan, prints, warnings, messages from our team already shown, our team’s contacts) directly in their browser, without sending it to Crisp. For that, when the chat loads in the app, your browser sends our server the identifier of your Crisp conversation, which our server links to your store; that identifier is kept with your store’s data and deleted with it. Each time a message leaves our side of your conversation in Crisp (a reply from one of us, an automatic message or a note between us), Crisp sends it to our server, its text included; to find your store, our server uses that identifier or, failing it, reads your conversation’s details in Crisp. Of all that, it keeps only, for a reply from one of us and as one of our team’s contacts with your store, the date, which of us replied and the channel, never what a message says. Each time you write in your conversation in Crisp, Crisp also sends your message to our server, its text included, so that we are alerted when nobody has answered you within 15 minutes during the chat’s hours. Of that, our server keeps only the identifier of your conversation, the time of your message and, once known, your store, until one of us replies, or a week after the alert at most, and deletes them with your store’s data; to find your store, it uses that identifier or reads your conversation’s details in Crisp. The alert we receive on Telegram never carries what you wrote, nor your store’s name or domain.

Store events reach our phone through Telegram. Moments in the life of your store send us a one-line message the day they happen: an install, a plan change, an uninstall, a thumbs-down on the satisfaction question, a data request, and a note left in the feedback box. That list names the common ones rather than all of them: anything that needs our attention the same day can send a line. Those lines go out through Telegram (its servers, not ours). They carry neither your store’s name nor its domain, only an eight-character code computed from its domain and, depending on the event, its plan, how many labels it has printed, or how many orders a data request covers. What never travels is the text you typed: a note sends the fact that one arrived and that code, while the note itself stays in the app and reaches us by email. No product, customer or label content is ever in one.

A backup copy of the database goes to GitHub every night. Once a night our whole database is copied onto a machine GitHub runs, checked there, encrypted there, and stored with GitHub, where it stays 90 days and is then deleted. That copy holds everything: the templates, print history and settings of every store, yours included. So the database passes through GitHub’s hardware unencrypted for as long as the check and the encryption take, and the key that opens the encrypted file is kept as a secret inside the same GitHub account that stores the file, which means GitHub holds the file and the key both. Two other copies reach GitHub outside that backup. One is a page of our internal customer dashboard, with a row per store, which we build by hand when we need it and which GitHub deletes after 30 days. The other is a job that runs every morning and commits its results to a branch of our code as a batch of files. Those files are a census of every store we have, flagged or not: a row per store with its domain, how many print jobs and labels it ran, how many of them hit a warning, when it installed, how far it got in setup, and when it last printed, plus a row for each store that left, with the reason it chose and the day. Two of those files identify a store by a shortened hash of its domain rather than the domain itself, and the note written inside them calls that hash correlatable rather than anonymous. The same branch also keeps the subscription payments Shopify reports to us for the app, each with the store’s domain, an identifier, the date, the net amount, its currency, and whether it was billed monthly or yearly; a log of every email we send a store, giving the store’s domain, which of our messages it was, the day, whether it went out, and the address cut down to its first letter and its domain, plus, when we found that address on the store’s own website, the page we found it on; the same details for each store that an email we have not yet switched on would have gone to, with, for a help email, its subject; a copy of the unresolved error reports Sentry holds, each with its title, the text of the error cut to 300 characters, and the domains of the stores it touched; and the addresses Resend could not deliver to or will no longer write to, cut down the same way. For each new store still installed when our morning pass reads it, it also keeps a short note read from the app and from the store’s own public website: its domain and name, its country, what its website says it sells, its plan, how many labels it printed, whether its welcome went out, whether it cancelled a Pro trial, and whether we found an Instagram account for it. When we look into a print problem a store ran into, the branch also keeps our working files on it: the store’s domain or name, the titles, variants and their Shopify IDs, vendors, SKUs, barcodes, prices and weights of the products concerned, how many of each were printed, and the template it printed with, including the font file it had uploaded. Some of those titles and templates were also copied into the tests of our code; we have since replaced them there with invented titles and with templates of our own, which leaves them only in our code’s history and in its pull requests on GitHub. Beyond the files named above, that branch and our code repository itself, meaning its code, the data files it carries, its tests and comments, and the working notes we keep beside them (our backlog, plans, reports, audits, notes and our work journal), name some stores by their domain or by a shortened hash of it, sometimes with their name, website, country and what they sell, next to what we knew or had measured about them at the time: how they found us, one of our ads included; when they installed, started or ended a trial, changed plan, closed or reopened their store, or left, and the reason they picked; their plan, billing events and payments; their Shopify plan, the age of their store, the size of their catalogue, how many locations it has and how often it receives stock in Shopify; how many print jobs and labels they ran and which warnings came up; how far they got in the app, down to the last screen they were seen on; their printer and label stock, whether they connected a printer, and which of the app’s offers they were shown and which they took; their answer to our satisfaction question; the health of their barcodes and their GS1 company prefix; what our own checks flagged; the browser and language of an error they ran into; the first name, sometimes the full name, of a person who wrote to us, and what they wrote or reported, at times word for word; which of our emails and review requests reached them, at which address, when, and what came of each or why one was held back; when one of us last contacted them; the review they left on the App Store; and what we decided about contacting them. Those mentions are in the current version of the repository, not only in its history: they stay there until we edit them out, and the history keeps them for as long as the repository exists. A branch keeps what is written to it until we take it out, and the repository’s history keeps every earlier version for as long as the repository exists. The repository belongs to our organisation on GitHub’s Team plan, and we have signed GitHub’s Customer Agreement. A backup is what puts the app back on its feet after a failure, so a copy taken before you uninstall keeps your data until its 90 days run out, and the deletion described below does not reach it. Why we keep all of this, on the basis of our legitimate interest (GDPR, Article 6(1)(f)): the backup, to put the app back after a failure; the census, the dashboard page, the payments, the email logs, the error copies and the notes on new stores, to see how stores use the app, where printing goes wrong, what the app earns, which emails went out and whom to write to; the working files on a print problem and the mentions in our repository, to fix what a store ran into and keep that fix tested. You can object to it (GDPR, Article 21), as described under GDPR below.

What a store typed as it left, and who reads our code. Until 6 October 2026 the branch described above also kept the words a store may have typed as it left: Shopify shows a store that uninstalls a short survey and passes its answer on to us, the reason picked from its list and, when there is one, the text typed beside it. A few of those words were also quoted in our working notes, in comments in our code and in the description of one of our pull requests. We stopped copying them that day; those already written stay in the history of our repository and in its pull requests on GitHub, sometimes next to the store’s domain, for as long as the repository exists. Our team reads that repository, GitHub hosts it, a server we rent from Hetzner in the European Union keeps a copy of it and of the branch, and the coding assistants we have working in it read it too: Claude, from Anthropic, and Codex, from OpenAI. We collected those words on the basis of our legitimate interest in understanding why a store leaves, so that we could fix the app (GDPR, Article 6(1)(f)). We stopped using them for that on 6 October 2026. On 7 October 2026 we read them once more, only to count them for this notice and to replace their quotes in our current code and notes with our own words; those rewordings stay there, and the words themselves stay only because we do not rewrite that history. You can object to that (GDPR, Article 21), or ask us to take your store’s words out of everything we still use: write to support@labelcraft.tech. That takes them out of what we use, not out of the history of our repository, which we do not rewrite: it is narrower than having them erased (GDPR, Article 17).

Where GitHub, Anthropic and OpenAI keep what they read, and on what terms. GitHub, Inc., in the United States, keeps the repository, the branch, the nightly backup and the other copies described above as our processor, under GitHub’s Data Protection Agreement, which the Customer Agreement we signed brings in: GitHub handles that data on our instructions, apart from the few purposes of its own the agreement lists (such as billing, its legal obligations, abuse and security checks, and aggregated statistics), and may not use it for anything else, model training included. Its transfer to the United States rests on the European Commission’s standard contractual clauses, which that agreement incorporates, and on GitHub’s self-certification under the EU-U.S. Data Privacy Framework (GDPR, Articles 45 and 46). Claude and Codex, on the other hand, read our repository and the branch through our founders’ individual accounts, not under a business contract. Anthropic and OpenAI therefore each handle what their assistant reads, as a controller in its own right, under their own privacy policy rather than on our instructions. Because our founders live in the European Union, the companies they deal with are Anthropic Ireland, Limited and OpenAI Ireland Limited, which send it on to servers in the United States and other countries outside the European Union, relying on the European Commission’s standard contractual clauses (and, for some countries, on an adequacy decision; Anthropic, in some situations, also on the derogations the GDPR allows). For data about people who live outside the European Economic Area, the United Kingdom and Switzerland, Anthropic names its US company, Anthropic, PBC, as controller: that transfer rests on no adequacy decision Anthropic claims and on no agreement of ours. Each may also use what it reads to improve its models, unless the account’s training settings refuse it, and even then when one of us gives feedback on an answer and, at Anthropic, when it flags content for a safety review.

Data retention and deletion

When you uninstall LabelCraft, Shopify sends us a deletion request and we purge all of your store’s data - templates, print history, settings (including any PrintNode key you saved), and login sessions. We run that purge once Shopify confirms the uninstall to us, which Shopify’s data protection terms put at 48 hours; the confirmation is Shopify’s to send, so it can occasionally reach us later than that.

Four narrow records outlive that purge. So does what has already left for the providers named above: the nightly backup for its 90 days, the dashboard page for its 30, the branch until we take it out and its history for as long as our code repository exists (it keeps, among the rest, the log of the emails we sent a store, with the date we sent it our one question about what it thinks of the app, so that a store that reinstalls does not receive that email a second time; it also keeps the payments described above and, for a store that left before 6 October 2026, the words it may have typed as it left), our code repository itself and its history, which mention some stores together with what we knew about them, as described above (in our code, the product titles and templates we had copied there have been replaced with invented titles and templates of our own and remain in its history and in its pull requests, while our working files on the branch still hold them), the error reports, the one-line store events and the chat conversations for as long as those providers keep them, what the coding assistants named above have read, for as long as the companies that run them keep it under their own policies, the delivery log of a message at our email provider, an email you have already sent us, and the usage events under your pseudonym until you ask us to delete them. Nothing else of your store’s outlives that purge. Two are markers, each one line: if your store started a Pro free trial we keep your .myshopify.com domain with the date the trial was used, and if your store uninstalled while we still had it recorded as installed we keep the domain with the date the install was first announced. They exist to stop one store taking an endless run of free trials by reinstalling, and to stop a returning store being announced as brand new. The third is a churn record, written once when a store uninstalls: how long the install lasted, which setup steps it reached, how many templates, saved lists, print jobs and labels there were, and which warning codes came up - and, for each of those codes, how many print jobs hit it on each day, so we can tell whether a fix we shipped actually stopped the problem for the stores it had been failing. It also records which plan the store was on when it left, whether that plan was paid, billed monthly or yearly, and whether the store was still inside its free trial - we keep it to tell a trial that ended from a subscription that was cancelled. And it carries, when you gave them, the two short answers you chose from our own lists: why you were leaving, if you told us while cancelling, and why you had not printed yet, if you answered that question in the app. Only the option you picked travels, never anything you typed in the box beside it - that text stays on your store's record and is deleted with it. It is stored under a shortened one-way hash of your domain rather than the domain itself - a pseudonym, not full anonymisation - and it holds no product, order, customer or staff data and no label content. We keep it to understand why stores leave. The fourth is an opt-out list: if anyone asks us to stop emailing an address, we keep that address so we can honour it. It outlives your store on purpose, because a request to be left alone that we forget is a request we did not honour.

Three counters on our side are not about your store at all, so none of the above reaches them. One is a daily tally of how many people clicked from the public labelcraft.tech pages towards our App Store listing: a date, which button, which campaign, and a number. Another is a daily copy of what our own advertising on the App Store cost us and how many installs it brought, which is Shopify's figure about our spending, not about you. The third measures how fast the app itself loads: for each day we count, in speed ranges, the standard web performance readings (largest paint, input delay and the like) that Shopify's own admin toolkit reports - a date, a metric name, a screen name, a speed range, and a count. None of the three holds a store, a person or a device, so a deletion request finds nothing in any of them to erase. The first is described in full under The labelcraft.tech website.

You can also request deletion or a copy of your data at any time by emailing support@labelcraft.tech.

The labelcraft.tech website

This section is about the public site you are reading, not about the app. Browsing labelcraft.tech installs nothing and creates no account, and the site itself never ties your visit to a Shopify store. The one way a conversation may come to be tied to one is the chat, described at the end of this section.

We run Google Analytics 4 on the public pages to count visits and see which pages lead to an install. It never loads inside the Shopify admin or during login. What it stores on your device depends on where you are, and there are three cases.

In the United States, Canada outside Quebec, Australia and New Zealand it sets one first-party cookie, _ga, holding a random number so that several page views count as one visit. No advertising cookie is set in those four countries, ever, and you are not asked anything.

In Quebec, it stores nothing and nothing is asked: the tag runs without a cookie and Google publishes none of it.

Everywhere else, the European Economic Area, the United Kingdom and Switzerland included, a bar asks before Google writes anything. Refuse it, or ignore it, and Google sets no cookie. Accept and two things start together: the _ga cookie above, and Google’s advertising storage, which lets us see which ads bring installs and can be used to show you our ads on other sites.

Google receives your IP address to work out an approximate country, and does not store it. We never send your name, your email, or anything else that identifies you. To opt out, block or delete the _ga cookie in your browser settings, or install Google’s opt-out add-on. Your answer to the bar is kept in your own browser under lc-consent-v1. To change your answer, use the Cookies button at the bottom of any page: the bar comes back and your new choice replaces the old one. Clearing this site’s data works too. Every page keeps working whatever you choose.

Separately from Google, we count the clicks that leave for our App Store listing. When you click an Install button, your browser sends our own server three things: today’s date, which button you clicked, and which campaign the link carried. Nothing is written to your device and nothing is read from it, no identifier is created, and the message is byte for byte the same whether you accepted the bar, refused it, or never saw it, because nothing in it could tell you apart from the next visitor. All we ever keep is a running total per day and per button. We added it because Google Analytics reports to us in the four countries above and nowhere else, so before it we had no way to know whether our own ads brought anyone at all.

The chat bubble is Crisp’s, and it loads for every visitor. A chat bubble sits in the corner of every page of this site except the unsubscribe and sign-in pages, so that you can write to us from here. It is run by Crisp, the chat provider described under Where data lives. Its script loads as soon as a page opens, for every visitor, before you answer the cookie bar and whatever you answer, because it is how you reach us. The connection shows Crisp the internet address your browser comes from, and the script can read, like any script on a page, the browser and system you run and the address of the page you are on. It sets Crisp’s own cookies on this site, whose names begin with crisp-client, and they keep an identifier of your conversation for about six months, so that a conversation you start finds you again on your next visit. If you write, Crisp receives what you write, and the address you type if you leave one; that address serves to answer you and never signs you up for our emails. The site itself sends Crisp nothing about you: no name, no email address, no store. Each time you write, Crisp also sends your message to our server, its text included, so that we are alerted when nobody has answered you within 15 minutes during the chat’s hours. Of that, our server keeps only the identifier of your conversation, the time of your message and, once known, your store, until one of us replies, or a week after the alert at most; to know whether a store is tied to it, it reads your conversation’s details in Crisp. The alert we receive on Telegram never carries what you wrote. A conversation started here is tied to no store, but if you then open LabelCraft in your Shopify admin in the same browser, the app may find that same conversation and add your store’s name and domain to it, as described under Where data lives. The reverse holds too: a conversation you started in the app may be picked up here, with your store’s name and domain. To remove these cookies, clear this site’s data in your browser.

GDPR

LabelCraft implements Shopify’s mandatory privacy webhooks. We store no customer identity (no name, email, phone number or address): the app never asks Shopify for them, and when a customer data request carries them, we drop them without keeping them. If, on the other hand, you use Order labels or Returns to label, the order or return number stays in your print-job history (see Order and return access).

A customer data request is answered from that history. When a shopper asks a store you run for the data we hold about them, Shopify tells us which orders the request covers. We record the request, look those orders up in your print-job history, and undertake to provide you, the store owner, with what we hold about them - the order or return number, the date, and how many labels were printed - or to tell you there are none, within the 30 days Shopify allows. We keep one record of each request we receive, holding the order numbers it named and the dates it arrived and was answered, so that it can be shown to have been answered. No shopper name, email address or phone number is stored: the request carries them, and we drop them. The record is erased with the rest of your store’s data (see Data retention and deletion).

A customer erasure request removes those numbers. The order numbers named in the request are erased from your print-job history, and from our record of any earlier request about the same orders. A print job made from an order or a return also keeps, next to the order number, the ID Shopify gives that order (for a return, the order it belongs to), because an erasure request names orders by their ID, not their number: the ID is kept so that the request can find them, and it is erased along with the number. Shop data erasure is honored automatically as described above. If you are in the EU/EEA you may also contact us to exercise your rights of access, rectification, erasure, restriction of processing and portability, and your right to object to what we keep on the basis of our legitimate interest. You can also lodge a complaint with a data protection supervisory authority, in particular in the EU/EEA country where you live or work or where you think your rights were infringed (GDPR, Article 77).

Changes

If this policy changes materially we will update this page and note the new date at the top. Continued use of the app after a change constitutes acceptance.

Contact

Privacy questions: support@labelcraft.tech