Nesvo Privacy Policy

Last updated: September 5, 2026

This policy explains how Nesvo handles personal data. Questions about anything in it go to support@nesvo.co.

Nesvo is operated by NESVO LLC, a New Jersey limited liability company at 83 Crease Road, Budd Lake, New Jersey 07828, United States. "Nesvo", "we" and "us" mean that company.

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 name and email address of each staff member who opens the app. Staff enter their own details themselves — nobody types a colleague's details for them, anywhere in Nesvo.
• 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 — installs, uninstalls, plan changes, charges, credits, cancellations, usage and 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. Section 12 covers what happens to an email a merchant sends us.
• Export records. When a merchant exports customer or account data — their contact list, a saved report, their suppression list, or the account export in Settings — we record who did it, from which screen, when, how many rows, and what role they held at the time. This is an accountability record. It does not cover a merchant downloading their own cost or ad-spend figures, which happens entirely in their browser and never reaches us.

Note the asymmetry: we log a merchant exporting customer data; we do not log a merchant merely viewing their own customers, because the merchant is the controller of that relationship. Our own staff's 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 or write 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 subscribes to those events and nothing else. Checkout contact details, address entry, payment information and site searches are all available to us and deliberately not collected, because no part of the product uses them.

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 two first-party cookies and uses browser storage for one further purpose:

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.
• Where we do not know a person's consent state at all, they are never emailed. An unknown state is an absence, not a permission.
• 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 — a high-value recent buyer becomes a "champion" and receives VIP recognition; a lapsing one is classified "at risk" or "can't lose" and enters a win-back sequence. Scores are recomputed monthly, and are not computed at all for a store with too few customers to rank meaningfully;
• 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;
• classify each store into an industry category from Shopify's own product taxonomy, so campaign performance can be compared against a median for that category. That comparison runs on aggregates across many stores, never on an individual shopper, and is switched off entirely for a category with too few stores in it;
• 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.

We do not use a third-party helpdesk. Email to our support address is received by Amazon SES, stored in our own S3 bucket, and read by our own internal console. No outside support vendor sees it.

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.
• 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.

What comes back, and what we do with it. ZeroBounce reports whether an address is deliverable, undeliverable, or something it cannot determine. An address it reports as not existing is suppressed permanently and platform-wide. An address it flags as a spam trap, an abuse address, or one on a do-not-mail list is suppressed for that merchant. An address it cannot resolve either way is left alone — never suppressed on a maybe, and never charged for twice.

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. No other data about that person is sent, and we keep no record of the exchange that contains their address — our diagnostic logs for these calls hold status codes, counts and timings only, by design, and are deleted after 14 days.

9. Retention, deletion and requests

Retention

How deletion is triggered, and how long it actually takes

Deletion requests reach us through Shopify, which controls when they are sent. We would rather be accurate about that than promise a schedule we do not control.

• When a merchant uninstalls, Shopify notifies us 48 hours later — a window that exists so an accidental uninstall can be undone. We then have 30 days to complete the purge, and we do not wait for the deadline.
• When a shopper asks a merchant to delete their data, Shopify holds the request for 10 days if that person has not ordered in the past six months, and withholds it until six months have passed if they have. That delay is Shopify's, not ours. Once the request reaches us we act on it, and we have 30 days to finish.
• If a store stops responding to us entirely — the access token stops working and never recovers — we treat it as uninstalled after four days of continuous failure, and the same purge runs. The clock starts from the last moment we know the store was live, not from the day we conclude it is gone, so the deletion happens sooner rather than later.

We cannot delete data before Shopify tells us to, because the request is how we learn of it. What we can say is that nothing waits once it arrives.

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 also null the identifiers on that person's browse and abandonment records, keeping only the de-identified event data.

We keep de-identified analytics — order values, dates, country — so the merchant's dashboards do not develop holes.

And we add that person to the suppression list as a one-way hash, at the moment we delete them. That is deliberate: without it, a deleted person could be collected again through a signup form and mailed again. The hash cannot be reversed into an address, and it exists so that "never email this person" outlives the record of who they were.

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 is returned to the merchant, who is the controller of that relationship and who provides it to the person who asked — that is how Shopify's process works. It 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.
• 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, and transfers out of Europe

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 and inbound support mail run through Amazon Web Services 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 the European Commission's Standard Contractual Clauses, and for the UK on the International Data Transfer Addendum. Both are annexed to our Data Processing Agreement, which is available to any merchant who asks for it at support@nesvo.co.

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, and it shares no session with the app.
• In that console, shopper names, email addresses and addresses are masked by default, everywhere. Masking is enforced in the database itself rather than hidden in the interface — the console holds no permission to read the underlying customer table at all, only a masked view of it.
• The console cannot change a single piece of merchant or customer data. Where an operator needs something done to an account, the console records an instruction and the app carries it out. That boundary is enforced by database permissions, not by convention.
• Looking a shopper up and looking at them are two separate steps, and both are recorded. When a merchant raises a dispute about a named customer, we can search that merchant's customers by name or email address to find the right record. That search is scoped to the one merchant, never across the platform, returns masked results only, and writes an entry to our audit log.
• Revealing that person's real details is a second, separately-permissioned action on a single record. It requires a reason to be recorded, and it writes its own audit entry. It exists for escalated disputes a merchant has raised with us — not as a browsing feature.
• The identity in that log is taken from the authenticated session, not from whatever the software asks for. An operator cannot write someone else's name into their own audit entry.
• Every action our staff takes that changes something — configuration, suspensions, offboarding, deletions — writes to that same log, which can be added to and never edited or erased.
• 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 as an email, it becomes a support ticket readable by whoever handles it, and the original message is stored for 90 days so that attachments remain available. 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.

One thing that helps us help you. We match the address an email comes from against the accounts on your store. If it matches, we know who you are and which store you are asking about, and we can talk about your account. If it does not, we will still answer — but only about how the product works, never about your account, your billing or your customers. Email us from an address on your Nesvo account so we can verify who you are.

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. Shopify conducts that review when an app is submitted to its App Store, which is the only point at which it can happen. Our access request and its data-protection details are prepared and will be reviewed at submission. We have not received Shopify's approval yet, and we are not claiming it.

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 LLC
83 Crease Road
Budd Lake, New Jersey 07828
United States

support@nesvo.co

EU representative (Article 27 GDPR). To be appointed before our first EU merchant. Name and contact details will be published here on appointment.

Merchants who need our Data Processing Agreement — which carries the Standard Contractual Clauses and the UK Addendum as annexes — should ask at that address.