Nesvo Privacy Policy

Last updated: July 26, 2026

This policy explains how Nesvo ("Nesvo", "we", "us") handles personal data. Questions about anything in it go to support@nesvo.co.

It is written to describe what our software actually does. Where something is limited, or not yet built, we say so rather than describing an intention.

1. What Nesvo is, and the two kinds of people in this policy

Nesvo is an app that a Shopify store owner installs into their store. It does two things:

• Analytics — it reads the store's own Shopify data (orders, customers, products) and shows the owner profit, margin, lifetime value and similar figures.
• Email marketing — on paid plans, it decides which of the store's customers should receive which marketing email, and sends those emails on the store's behalf through Amazon SES.

That means two different groups of people appear in this policy, and we handle their data differently:

Merchants. The Shopify store owners and their staff who use Nesvo. They are our customers. For their data — account details, business address, billing history, support messages — we are the data controller.

Shoppers. The people who buy from, or browse, a merchant's store. We never have a direct relationship with them. We process their data on the merchant's instructions, as the merchant's processor. The merchant is the data controller for their own customer relationships and for anything collected on their storefront. If you are a shopper and you want your data corrected or deleted, the store you shopped with is the right place to start — Shopify passes that request through to us and we act on it (see section 9).

2. Merchant data — where we are the controller

When a merchant installs Nesvo, we collect and store:

• Store identity: myshopify domain, store name, install date, plan tier.
• Account contact: the store owner's email address, and the email addresses of any staff the merchant gives app access to.
• Sender configuration: the display name and reply-to inbox used on marketing emails, and the merchant's own sending domain if they choose to add one.
• Physical postal address. Required by anti-spam law to appear in the footer of every marketing email. It is prefilled from Shopify, confirmed by the merchant, and checked against Google Address Validation. PO boxes and commercial mail-receiving addresses are accepted.
• Brand assets: logo, colours, fonts and social links, pulled from the storefront so email templates match the store. A merchant can switch this to manual, and we stop pulling until they switch back.
• Cost data: product costs, universal shipping cost or default margin, and ad spend the merchant enters. Used to calculate profit and to check whether a discount would eat a merchant's margin.
• Billing history: a local copy of Shopify's billing events for the merchant's subscription — plan changes, charges, credits, top-ups. We do not receive or store payment card details; Shopify handles all payment.
• Shopify OAuth access token. Stored in our database, readable only by the application itself. This token is how we read the store's data; the merchant never types a credential into Nesvo.
• Support correspondence and any feature requests submitted in-app.
• Export records. Every time a merchant exports data out of Nesvo, we log who did it, from which screen, which columns, how many rows, when, and what role they held at the time. This is an accountability record. Note the asymmetry: we log merchant exports; we do not log a merchant merely viewing their own customers, because the merchant is the controller of that relationship. Our own staff access is logged differently and more strictly — see section 11.

3. Shopper data — where we are the merchant's processor

3.1 From Shopify

We sync the merchant's own store records: customer name, email address, and address (broken into country, province, city and postal code), marketing-consent status, order history and line items, refunds, discount-code redemptions, products and inventory, and any tags the merchant has applied.

We do not collect or store shopper phone numbers. We do not receive or store payment details.

From this data we derive and store: order counts, total spend, average order value, first and last order dates, average days between purchases, per-customer profit, RFM scores, per-product repurchase cycles, and a subscriber lifecycle state. See section 7 on profiling.

3.2 From the Web Pixel — browse tracking

This is one of two separate storefront mechanisms, and it is the one that runs everywhere.

The Web Pixel is a small script Shopify loads on the merchant's storefront inside a sandbox. It cannot read the page, cannot see form fields, and displays nothing. It records:

• page views
• product views and collection views
• adding to and removing from cart
• viewing the cart
• starting checkout
• completing checkout
• the referrer and campaign (UTM) parameters of the visit

It installs on every Nesvo store, on every plan, including the free plan. A free plan means no marketing email — it does not mean no data collection.

Consent. The pixel is registered with Shopify declaring that it uses data for analytics and for marketing, that it does not use it for preferences, and that it does not involve any sale of data. Shopify's own consent manager only loads the pixel when a visitor has permitted every purpose we declared. In regions where consent is required before tracking, such as the EEA and the UK, the pixel does not run at all until the visitor consents — a session without consent produces no records of any kind on our side. In regions where consent is granted by default, it runs from the start of the session.

We declare a marketing purpose deliberately and honestly: browse and cart behaviour is what triggers abandoned-cart, browse-abandonment and back-in-stock emails. That is marketing, so we say so.

Identifying the visitor. The pixel never reads a name, email address or postal address, and no part of our system reads those fields out of a pixel event. Identity is resolved by ID only, against the customer records the merchant already holds. A visitor is linked to a customer record when they are logged in, or when they complete a purchase, at which point we set a first-party cookie holding an opaque identifier so later visits from that browser resolve to the same record.

Sessions we cannot identify are still recorded, without a customer link, and count only toward aggregate traffic figures. An unidentified session never produces an email. If the cookie is cleared or expires, the visitor simply becomes unidentified again and is not emailed.

We do not currently offer merchants an on/off switch for the pixel. Storefront tracking cannot be switched off on request today. We can halt collection platform-wide, but there is no per-merchant control, and we would rather say that plainly than imply one exists.

3.3 From the Theme Extension — signup forms

This is the second, separate storefront mechanism. It is a different piece of software with different consent behaviour, and it only exists on paid plans. Free-plan stores have the pixel and no forms at all.

Where a merchant has our signup forms enabled, we record three things:

• form viewed and form interacted — these are gated on the visitor's analytics-consent status. In consent-required regions, they are not recorded unless the visitor has consented; if a visitor consents part-way through a session, recording starts from that moment and not before. If we cannot read the consent status, we record nothing.
• form submitted — this is not consent-gated. A person who typed their email address and pressed submit, underneath a disclosure line telling them what they were signing up for, has given us their address deliberately. That act is the consent, and we record it.

3.4 What we do not do

• We do not track email opens. No tracking pixel is placed in our emails, no open is recorded, and no metric anywhere in Nesvo is based on opens.
• We do track link clicks. Links in marketing emails route through a redirect that records the click and forwards to the store. Clicks are used as a diagnostic signal and to build segments; they do not gate anything.
• We do not sell or share personal information, in the sense those words carry under US state privacy laws. We do not run advertising, we do not operate an ad network, and we do not disclose personal information for cross-context behavioural advertising.
• We do not accept uploaded mailing lists. A merchant cannot upload a list of addresses for us to email. The only list a merchant can upload is a suppression list — addresses we must never email.

4. Cookies and similar technologies

On merchant storefronts, Nesvo sets first-party cookies:

The two pixel cookies are set only when the pixel itself runs, so in consent-required regions they are not set until the visitor consents.

In the Nesvo app, session cookies keep a merchant logged in. Authentication itself is handled by Shopify.

5. Consent to marketing email

We do not email a shopper simply because they exist in a merchant's Shopify data. A person becomes emailable in two steps:

1. They opt in. Through a Nesvo signup form on the storefront, through Shopify's checkout or account consent checkbox, or through the merchant's own account signup. Our storefront forms use an implied-consent model: there is no separate tick-box, and a disclosure line sits directly beneath the submit button reading "By submitting, you agree to receive marketing emails — unsubscribe anytime."

2. They confirm. A person who opts in lands in a pending state and is not part of any marketing audience. The only email a pending person receives is a single confirmation message. They become active — and start receiving marketing — only when they either click the confirmation link or complete a purchase. A purchase is treated as proof the address is real and the person is engaged.

Some consequences of this that are worth stating plainly:

• A person marked "subscribed" in Shopify may still not be emailable by Nesvo, because they have not confirmed with us. These are two separate records and they disagree routinely and correctly.
• A person who has never opted in, and a person who has explicitly unsubscribed, are tracked as different states. Neither is emailed. Neither is converted into a subscriber by making a purchase — buying something is not consent to marketing, and our system will not treat it as such.
• Back-in-stock alerts are a separate and narrower consent. A guest who joins a waitlist for an out-of-stock product has consented to be told about that product, and receives one restock alert for it. They are not added to any marketing audience and receive no marketing email.

Every marketing email we send carries a one-click unsubscribe link, a List-Unsubscribe header for the recipient's mail client, and the merchant's physical postal address. This footer is added by our rendering pipeline outside the editable area — a merchant can style the email around it but cannot delete or alter it. Unsubscribes take effect immediately and are permanent unless the person opts in again themselves.

6. How we use the data

Merchant data — to run the service, authenticate the merchant, bill through Shopify, calculate their analytics, send them reports and operational alerts, answer support requests, and meet our legal obligations.

Shopper data — on the merchant's instructions, to:

• calculate the analytics the merchant sees;
• decide which shoppers qualify for which of the merchant's marketing campaigns, and when;
• assemble and send those emails;
• measure whether a campaign led to a purchase;
• protect the deliverability of our shared sending infrastructure, by detecting bounces and complaints and suppressing addresses that generate them.

Our lawful bases, where the GDPR or UK GDPR applies, are the merchant's own basis for their marketing (normally consent) for sending, and our and the merchant's legitimate interests in operating, securing and improving the service for analytics, deliverability protection, fraud and abuse prevention.

7. Profiling and automated decision-making

We should be direct about this: Nesvo profiles shoppers, and the decision to send a given person a given marketing email is normally made automatically.

Specifically, we:

• score each customer on recency, frequency and monetary value (RFM) against the merchant's other customers, and classify them into cells such as "champion", "at risk" or "can't lose";
• compute a repurchase cycle per customer per product, and estimate when they are due to buy again;
• track browse-level behaviour — products viewed, pages viewed, cart activity — and use it both to trigger emails and as filters a merchant can build audiences from;
• track discount-code usage and refund history and use them as targeting dimensions;
• use all of the above to decide who receives an abandoned-cart, browse-abandonment, win-back, VIP, replenishment, anniversary, first-purchase or welcome email, at what time, and whether a discount is included and how large it is.

By default a merchant approves these rules once, at setup, and the engine then sends without a further human decision on each send. A merchant may switch any campaign to review-before-send instead.

These decisions determine what marketing a person receives. They do not determine access to goods or services, pricing beyond promotional discounts, credit, or anything with a legal or similarly significant effect on the person. A shopper who wants to stop being profiled for marketing can unsubscribe, which removes them from every audience; a broader objection or erasure request should be made to the merchant, and we act on it (section 9).

8. Who else touches the data

We use the following service providers. Each is bound to process data only for the purpose below.

ZeroBounce, stated plainly

End-customer email addresses are transmitted to a third party for verification. This is the one place where shopper personal data leaves our systems for a purpose other than delivering an email to that person, and we are not going to bury it.

It exists to solve one specific problem: a merchant arriving from another email tool with a large list of Shopify subscribers that has never actually been mailed. Nobody knows how many of those addresses are still alive, and sending to a dead list damages delivery for every merchant on our shared infrastructure.

So every merchant's list is split into addresses we have good evidence are deliverable — recent purchasers, confirmed opt-ins — and addresses we do not. Only the second group is ever eligible for verification. Trusted addresses are never sent anywhere.

Verification runs in two situations:

• Automatically, once. If a merchant's first large broadcast trips our bounce threshold, we verify the next batch of unverified addresses at our own cost, not the merchant's. This happens once per merchant, ever. Dead addresses found this way are permanently suppressed.
• By the merchant's choice. If the list is still bad after that one clean, we stop sending and present the merchant with options. One of them is paying to verify the rest, charged at exactly what it costs us with no margin added, through a one-time charge they explicitly approve on Shopify. Nothing is ever charged automatically.

Which of us pays makes no difference to the person whose address it is, so the disclosure is the same either way: the address is sent to ZeroBounce and checked. Verification tells us whether an address exists. It does not tell us anything about the person, and no other data about them is sent.

9. Retention, deletion and requests

Retention

What deletion actually does

When a shopper asks a merchant to delete their data, Shopify sends us a redaction request and we act on it. We permanently null the person's email address, name, street address, city, province and postal code, and we sever the link to their Shopify customer record.

That last part matters. Because the join key is destroyed, a later sync from Shopify cannot find the redacted record to re-fill it — a subsequent sync creates a fresh, separate record instead of resurrecting the old one. Our sync paths additionally refuse to write to a redacted record. Redacted personal data does not come back.

We keep de-identified analytics — order values, dates, country — so the merchant's dashboards do not develop holes, and we keep the one-way hash on the suppression list.

We also null the identifiers on that person's browse and abandonment records, keeping only the de-identified event data.

One thing that is not deletion, so that nobody is misled: dismissing a notification in the app moves it to a dismissed state. It does not delete anything, and it never affects any underlying record or send.

Requests

• Access. A shopper's request for their data arrives from Shopify and is fulfilled automatically. The export contains their identity and consent fields, their orders, their campaign history, their coupons, and their browse and abandonment history — the products and pages they viewed, their cart and checkout activity. That behavioural history is their personal data, and we include it. The export is compiled and emailed to the requester.
• Deletion / erasure. As described above, via Shopify's redaction request.
• Correction. Corrections made in Shopify flow through to us on the next sync, which runs hourly.
• Objection to marketing. Unsubscribing removes a person from every audience, immediately and permanently.
• US state privacy rights (California and others) — the rights to know, delete, correct, and opt out of sale or sharing. We do not sell or share personal information. We do not discriminate against anyone for exercising a right.

If you are a shopper, contact the store you shopped with. If you contact us directly at support@nesvo.co we will route your request to the merchant, since we cannot verify your identity or act on your data without their instruction.

Merchants can export their own data at any time from Settings → Data & privacy.

10. Where your data is stored

All Nesvo data is stored and processed in the United States. Our database is hosted by Supabase in US East (Ohio), our application by Render in US East (Virginia), and our email delivery runs through Amazon SES in US East (Northern Virginia). Our own systems do not move personal data outside the United States. The service providers listed in section 8 are United States companies; where any of them processes data elsewhere in the course of providing their service, the safeguards below apply.

If you are in the EEA, the UK or Switzerland, this means personal data reaching us is transferred to the United States. Where we act as a processor for a merchant in those regions, we rely on appropriate safeguards, including the European Commission's Standard Contractual Clauses and the UK International Data Transfer Addendum. Merchants who need these in writing should contact us for our Data Processing Agreement.

11. Our own staff's access to your data

Our staff can access data held in Nesvo, for support, security, billing and legal-compliance purposes. We think you should know exactly what that looks like.

• We run an internal console, separate from the app, behind its own login with mandatory two-factor authentication. It is not reachable from anything a merchant can see.
• In that console, shopper names, email addresses and addresses are masked by default, everywhere. Masking is enforced in the database itself, not merely hidden in the interface.
• Viewing an individual shopper's real details requires a deliberate, separately-permissioned action on a single record, with a reason recorded, and it writes an entry to an audit log. It exists for escalated disputes a merchant has raised with us — not as a browsing feature.
• Every action our staff takes that changes something — configuration, suspensions, offboarding, deletions — writes to that same audit log.
• Merchant business information such as store name, owner email and plan is not masked, because it is not shopper data.

We may also disclose data where we are legally required to, or to protect our rights, safety, or the integrity of our sending infrastructure.

12. Support messages and merchant-disclosed information

Everything in section 11 governs data inside Nesvo. It cannot govern what a merchant chooses to type into an email to us.

If a merchant sends us a support message containing their customers' personal information — pasted addresses, exported rows, screenshots — that information sits outside our masking model entirely. It arrives in an inbox, it is visible to whoever reads the ticket, and it is stored by our support platform. We cannot prevent this and we cannot mask it after the fact.

The merchant who discloses that information is responsible for having done so. We ask merchants to identify customers by order number or by their Shopify customer ID, and to send us personal information only when there is genuinely no other way to resolve the issue.

13. Security

• Data at rest is encrypted using the platform-level AES-256 encryption provided by our database host. Backups are encrypted.
• Data in transit is transmitted over encrypted connections.
• Access is enforced at the database layer through separate, tightly-scoped roles, with a second independent access-control layer on top. Anonymous and public database access is explicitly revoked, including for objects created in future.
• Development and test data is kept separate from production data.
• We store only what the product uses, and we delete on the schedule in section 9.
• Merchants authenticate through Shopify; we never see or store a merchant's Shopify password. We do not store payment card details at any point.

No system is perfectly secure, and we will not claim otherwise.

14. Shopify protected customer data

Shopify classifies customer names, email addresses and addresses as protected customer data and reviews an app's access to them. Our access selections have been made but not yet submitted — Shopify conducts that review when an app is submitted to its App Store, which we have not yet done. We have not received Shopify's approval, and we are not claiming it. We also do not hold Shopify's higher "Level 2" access.

We have built the corresponding handling obligations — encryption, minimisation, retention limits, restricted internal access and audit logging — regardless of approval status, because they are the right way to handle the data.

15. The free plan

Nesvo has a permanent free analytics plan. On it, the merchant gets the dashboard and no email engine: no marketing email is ever sent, no signup forms run on the storefront, and no sending infrastructure is provisioned for them.

Their shoppers' data is still collected and processed. Store data still syncs from Shopify, and the Web Pixel still records browse behaviour on the storefront. "Free plan" does not mean "no data collection", and this policy applies in full to free-plan stores except where it describes email.

16. Children

Nesvo is a business tool sold to merchants and is not directed to children. We do not knowingly collect personal information from children. If you believe a child's information has reached us through a merchant's store, contact support@nesvo.co and we will work with that merchant to remove it.

17. Changes to this policy

We will update this policy when what we do changes. Material changes will be notified to merchants in-app or by email before they take effect. The date at the top always reflects the current version.

18. Contact

Nesvo — support@nesvo.co

Merchants who need a Data Processing Agreement, or the Standard Contractual Clauses for transfers out of the EEA or the UK, should contact us at that address.