Privacy Policy

Last updated: November 2, 2026

Woven Reach (“the App”) is a Shopify application operated by Solidstone, Inc. (“we”, “us”) that helps merchants recover abandoned carts with on-brand email. This policy describes what we collect from merchants who install the App and from their customers, why we collect it, and the choices available.

Information we collect from merchants

• Store details from Shopify: your store domain at install, and then your store name, locale, currency, and plan name when Shopify notifies us of them.
• Your Shopify session, including the access token that lets the App call Shopify on your behalf, and the name, email address, and locale of the staff account that installed or authorized it.
• Onboarding and settings you provide: business name, contact email, email sender name, reply-to address, timezone, quiet hours, and any brand style guidance you write.
• Storefront content for brand extraction: we crawl your public storefront pages and capture their text, metadata, and full-page screenshots, and we read your shop profile, policies, and shop-level metafields through the Shopify Admin API. From this we derive your brand’s colors, typography, voice, and catalog style. Screenshots are stored in S3-compatible object storage; storefront text is also converted into numeric embeddings and stored alongside your other data so the App can retrieve relevant brand context when drafting copy.
• Billing state: your selected plan and subscription status via the Shopify Billing API. We never see or store payment card details — Shopify processes all charges.
• If you try the App on our demo page (app.wovenreach.com/try) without installing it: the storefront address and work email you enter, a salted hash of your IP address, and the demo we build from your public storefront — crawled page text and screenshots, the brand profile we derive from them, and the sample email we write.

Information we process about your customers

To recover abandoned carts on your behalf we process, as your service provider:

• Cart and checkout contents — items, quantities, totals, and currency — from Shopify webhooks. We store the webhook payload Shopify sends us as it arrives, rather than extracting only those fields. Depending on how far a shopper got, a Shopify cart, checkout, or order payload can also contain a billing or shipping address, a phone number, the shopper’s IP address, and browser details. We do not read or use those fields, but they are present in the stored payload, so we list them here rather than describe the payload as narrower than it is.
• Customer email addresses associated with carts and checkouts. When a checkout payload does not include one — a guest checkout, typically — we ask the Shopify Admin API for the email address on that abandoned checkout.
• Email marketing consent state from Shopify. Shoppers who unsubscribe through a Woven Reach email are not emailed again by that store, except as described for the suppression list below; each send also checks the shopper’s marketing status in Shopify first. Before every send we look up the shopper’s Shopify marketing-consent state, and the send is blocked when that state is UNSUBSCRIBED. Any other state — including a shopper who was never asked, one who started a double opt-in and did not finish, a guest checkout with no customer record, or a lookup we could not complete — does not block the send. In other words the App emails by default and stops on an explicit opt-out; it does not require an opt-in. The resolved decision and the time it was made are recorded against the cart.
• Email delivery and engagement events for the emails the App sends: delivered, bounced, complained, opened, and clicked. Opens are measured with a small tracking image embedded in the email, and clicks by routing links through a redirect that records the click before forwarding the shopper on.
• Unsubscribe requests and other reasons an address must not be emailed, kept on a per-store suppression list. Addresses land on it when a shopper uses the unsubscribe link, when mail to them hard-bounces, when they report it as spam, or when the merchant adds them. While an address is on that list, the App will not send to it for that store — the check runs before the email is drafted or sent. Two things that list does not guarantee: the merchant can remove an entry from their own settings page (they are warned first, and the removal is logged), and if the merchant deletes their store data the whole list is deleted with it.

We do not collect or store customer payment card details or government identifiers, and we do not build location profiles or track shoppers across sites. As noted above, the raw Shopify payloads we store may contain an address or IP address that Shopify included.

If you try the demo

The demo at app.wovenreach.com/try writes one sample abandoned-cart email for a Shopify store before anyone installs the App. It does not touch a Shopify account. When you use it we store:

• The storefront address you enter, the email address you give us, and the store name, currency, and .myshopify.com address your storefront publishes.
• What we read from your public storefront, as any visitor could: page text and full-page screenshots, your public product listings, and the logo, colors, and writing voice we derive from them. Screenshots are kept in object storage, the page text is also stored as numeric embeddings, and this storefront content is sent to Google Gemini to extract the brand and write the email.
• The email we wrote, and a one-way hash of your IP address, used only to limit how often demos can be requested.

We use your email address to send you one copy of the email you asked for, and we may write to you once more to ask whether you would like to install. We do not add it to a mailing list. Our analytics record that a demo was requested, finished or failed, was emailed, and whether its Install button was clicked, identified by the store’s domain and never including your email address. The demo pages themselves are measured anonymously, with anything typed into a form field masked before it leaves your browser.

30 days after you request a demo, we delete it: the request and your email address, the screenshots, the storefront text and embeddings, the brand data derived from them, and the generated email. Our internal workflow-engine history of the run, which holds the generated email but not your address, is pruned after 30 days as well. Resend, which delivers the copy, keeps its own record of the message. To have a demo deleted sooner, write to [email protected].

How we use this information

• Detect abandoned carts and send the recovery emails you configure.
• Generate on-brand email copy using AI (Google Gemini). The prompt we send to the model contains your brand profile, the cart’s line items, where the email sits in the sequence, any style guidance you wrote, and — as the prompt template stands today — the shopper’s email address. The model is not asked to use the address and it does not appear in the finished email, but it is sent, so we disclose it. A second and third model call review and revise the draft, so the drafted email body is sent to the model as well. The prompt inputs, the generated copy, and generation metadata (tokens, latency, cost, model) are stored for quality and audit.
• Show you dashboards: recovery rates, recovered revenue, send health, and suppression counts.
• Email the reply-to address you give us about your own account. Today that is one email at most: if you saved your details but cart recovery is still off 24 hours later, we send a single reminder saying how many abandoned carts have not been followed up, and we never send a second one.
• Choose between alternative subject-line angles and send-time offsets automatically, learning from which ones lead to clicks. This is an automated choice about which version of an email a given shopper receives. It has no legal or similarly significant effect, and it never decides eligibility, pricing, or access.
• Operate, secure, and improve the App, using PostHog for product analytics. These events are identified by your store domain rather than being anonymous, and some of them — cart abandoned, recovery email sent — have included the shopper’s email address as an event property. We are removing it: once that change is live, the analytics events our servers send to PostHog carry no shopper email address, and events already recorded stay in PostHog until they are purged. Inside the App’s own pages we also record how the App is used: page views, clicks, browser errors, and session recordings of the App’s screens, again identified by your store domain. Anything typed into a form field is masked in your browser before the recording is sent. Text the App displays is recorded as it appears, so a recording can show a shopper’s email address: in full if you choose Reveal under Settings → Privacy requests or Settings → Unsubscribes, or add or remove an unsubscribed address there, and shortened (for example a***[email protected]) where the App lists carts. Nothing runs in your storefront or in the emails your customers receive. The same analytics run on our demo page and on wovenreach.com, where visitors are not identified.

We do not sell personal information, and we do not use your customers’ data to market to them on anyone else’s behalf.

Subprocessors

• Shopify — platform, webhooks, billing.
• Hetzner — application hosting, and the server that runs our Postgres database. Since September 2026 the production database runs on our own server rather than a managed provider.
• Cloudflare — network and tunnel in front of the application.
• Neon — the managed Postgres provider we used until September 2026. It still holds a copy of the data from before that date, retained as a fallback while the new database is proven, and will be deleted when it is.
• S3-compatible object storage — screenshots captured during brand extraction.
• Resend — email delivery. Svix signs the delivery and engagement webhooks Resend sends back to us.
• Google (Gemini API) — AI copy generation, brand and voice analysis, and text embeddings. The App also supports NVIDIA’s hosted model API as an alternative provider for these steps; we will update this list before routing any production traffic to it.
• PostHog — product analytics, session recording, error tracking, and experimentation.

Data retention & deletion

• How long we keep data: we keep shopper data — email addresses, carts, the emails we sent and how they were opened and clicked — for as long as the App is installed on your store. We do not delete it automatically after a set number of days or months. Except as listed below, it is deleted when Shopify tells us to: when a shopper asks for their data to be erased, and after you uninstall. Uninstalling stops all sending straight away but does not by itself delete this data; the deletion follows when Shopify sends its store-deletion request. The one exception with a timer is the internal workflow-engine run history, which we normally delete once a run has been finished for 30 days; this can be paused for maintenance. Shopper email addresses already included in analytics events sent to PostHog, and any shown in session recordings of the App, stay there, according to PostHog’s retention settings, until they are purged; neither deletion request removes them. Deleted data can remain in our nightly database backups until those backups are rotated out, and in the copy held by Neon described above, which is not rotated and will be deleted as a whole.
• Customer data deletion (GDPR Art. 17): when Shopify sends a customer redaction request, we delete that customer’s carts, outbound emails, engagement events, and stored data-request snapshots for your store. Their suppression entry is deliberately kept, so that deleting their data does not have the effect of opting them back in. Some records are not reached by this deletion today, and we would rather list them than claim a clean sweep: the raw webhook payloads we received for that shopper, the stored AI generation records for emails drafted for them, the internal workflow-engine run history, which holds the same cart and email content, and the shopper’s email address in analytics events and session recordings held by PostHog. Removing these safely is open work, tracked internally, and they are not used to contact anyone.
• Customer data access (GDPR Art. 15): data-request webhooks produce a snapshot you can review and deliver to your customer from Settings → Privacy requests in the App. That snapshot includes the raw webhook payloads described above.
• Store deletion: 48 hours after you uninstall, Shopify sends a shop-redaction request and we delete your store’s data — sessions, carts, campaigns, emails and engagement events, suppression list (including opt-outs made by replying to our unsubscribe address), brand profiles, crawls, AI generation records, billing records, onboarding, settings, and the store record itself. A small number of operational records outlive it: send rate-limit history, custom sending-domain configuration, failed-job records, our own operator audit log, the workflow-engine run history, storefront text embeddings, the storefront screenshots held in object storage, analytics events and session recordings already sent to PostHog, some of which include shopper email addresses, and a small number of opt-outs made by replying to our unsubscribe address for stores that were deleted before we fixed how those opt-outs were stored, which remain pending a decision on deleting them. Completing that cleanup is open work.
• Demo requests: a demo requested on our demo page, and everything built for it, is deleted automatically 30 days after the request: the storefront address, email address and IP hash, the sample email, and the demo’s crawled pages, brand profile, AI generation records, text embeddings, and screenshots. Like the run-history deletion, this can be paused for maintenance. If a screenshot cannot be removed from object storage at that point, it stays there. The workflow-engine run history for a demo follows the rule above.

Security

Data is encrypted in transit (TLS). Access to production data is restricted to an allowlist of authorized operators who sign in with Google single sign-on; operator sessions are short-lived and administrative changes are written to an audit log, though read-only access to production records is not yet audited to the same standard, which is work we have open. Every webhook Shopify sends us is verified against its HMAC signature before we process it, and the delivery webhooks Resend sends are verified against their Svix signature.

Your choices & contact

Merchants can uninstall the App at any time, which triggers the deletion flow above. Every recovery email we send carries an unsubscribe link and a one-click unsubscribe header; using either adds the address to that store’s suppression list immediately. Shoppers can also contact the merchant to exercise data rights — we honor all requests relayed through Shopify’s privacy webhooks.

Questions or requests: [email protected].