Privacy Policy

Operator: Lawri's Apps, LLC
Privacy contact: privacy@bumpshq.com
Support contact: support@bumpshq.com

This Privacy Policy describes how Bumps ("we", "us", "the App") handles information when you install and use our Wix App Market application (Checkout Bump & Post-Purchase Upsell). By installing or using the App you agree to this policy.

1. Data we collect

The App collects only data necessary to render and measure the offers you configure. We do not sell, rent, or share data with third parties for advertising.

From the merchant (you)

• Wix instance ID (a UUID Wix assigns to your installation)
• Wix site ID and account ID (when supplied by Wix). The account ID is used only to group multiple sites you own under one management view.
• We do not store your Wix OAuth tokens. The App mints a short-lived Wix API credential on demand for each call it makes on your behalf (product lookups, discount-rule sync) and discards it. There is no access or refresh token at rest to leak, log, or expose.
• Branding settings you enter in the dashboard (logo URL, primary color, default storefront locale).
• Billing state from Wix (your current plan ID, trial end, expiration, cancellation timestamp). Wix sends this via webhooks; we do not touch payment instruments.
• Dashboard usage analytics. How you use the Bumps dashboard itself: pages you open, the offer types you create, and the style mode you choose. These carry only closed-vocabulary values (an offer type, not its name; a route, not a URL) tied to your installation ID, never free text, names, or emails. Used to improve the product; excluded from cross-install aggregates when fleetAggregateOptOut is set (see below).
• An optional fleet-analytics exclusion preference (fleetAggregateOptOut) if you ask us to keep this installation out of anonymized cross-install product-improvement aggregates.
• Support chat messages you send from the dashboard Help → Contact support page (plain text). Authorized Bumps operators can read these to answer your request. Avoid pasting shopper PII unless needed to resolve an issue.
• Operator dashboard notices: occasional messages operators may send into your in-app notification bell about your install (e.g. a resolved outage). You can dismiss them like other notifications.

From your shoppers

• Anonymous session ID (a UUID generated client-side and persisted in sessionStorage; does not include name, email, IP, or device fingerprint). Persisted only after the shopper grants analytics consent on your site; without consent it is held in memory and regenerates each page load.
• Anonymous shopper ID (a UUID generated client-side and stored in localStorage) used only to enforce the per-shopper frequency cap (how often the same browser sees a bump across sessions). Like the session ID it is written only after analytics consent is granted. Without consent it stays in memory and resets each page load, and it is cleared whenever the shopper's browser privacy tools (Brave Shield, Firefox ETP, Safari ITP) clear site data. It contains no name, email, IP, or device fingerprint.
• The fact that an offer was shown, clicked, accepted, declined, or converted, plus the order ID and amount the order-approved webhook delivers from Wix.
• The buyer's Wix contact ID (an opaque identifier from your store's contact list, not a name or email): on each sale credited to an offer and, on a store that runs a thank-you offer, on each order, so that offer is credited only for a later order by the same buyer. It is reported and erased with the shopper's other data on request (§5).
• For collection-based triggers, the Wix product IDs in the cart at request time. These are public catalog identifiers, not shopper PII.

We never collect or store: names, emails, phone numbers, payment instruments, IP addresses (rate-limit middleware sees them transiently but does not persist them), browser fingerprints, or cross-site tracking identifiers.

2. How we use it

• Render offers. The App uses your offer config and cart contents to decide which (if any) bump to show.
• Measure performance. Aggregated counters (shown / clicked / accepted / converted) drive the dashboard analytics views.
• Improve templates and defaults. We compute anonymized, aggregate-only benchmarks across installations, including authored-offer configuration patterns (for example trigger families, launch style, and bounded mechanic buckets) so we can improve starter templates, defaults, and in-app suggestions without mining your free text or product IDs.
• Improve the dashboard. We record how merchants use the Bumps dashboard (pages opened, offer types created, style mode chosen) to see which features help and which go unused, and improve them. This is our legitimate interest in improving a product you pay for. Closed-vocabulary values only, no free text or PII, and honoured by the same fleet-aggregate exclusion.
• Deliver app features. The App calls the Wix Stores + Orders APIs on your behalf (product lookups, trigger evaluation, discount-rule sync) using a short-lived credential minted per request, never a stored token.
• Operate reliably. Server logs (kept up to 30 days) and Sentry error reports help us debug failures. Both have authorization headers, cookies, and request bodies stripped before egress.
• Provide support. In-app chat is visible to authorized Bumps operators only and is used solely to resolve your support request.

We never: build advertising profiles, use shopper data for purposes outside delivering and measuring your configured offers, or train ML models on identifiable shopper or merchant data.

3. Where it lives

• Production runs in one region: Railway's US East region (Virginia, USA).
• During our move to Railway: storefronts still running app version 52.x keep calling our previous host, Fly.io (its Chicago, USA and Frankfurt, Germany regions, as described in the previous version of this policy), until the site owner updates the app. That host answers from a copy of the database as it stood on 2026-10-12, which accepts no new writes, and it is retired once no site uses it.
• Database: PostgreSQL on Railway, a single database in that region. Our servers reach it only over Railway's private network, which encrypts traffic between services. (No Wix OAuth tokens are stored; see §1.)
• Database backups: the database's point-in-time-recovery archive is kept in a Railway Storage Bucket in the same region; Railway encrypts storage buckets at rest.
• Application servers: Railway, same region.
• Cache and realtime fanout: Redis on Railway, same region, reachable only over the private network. Holds short-lived cache entries, rate-limit counters, and in-flight support-chat fanout, with no durable record of your data.
• Error reports: Sentry, US region.

4. How long we keep it

• Offer configuration & settings: for the lifetime of the installation (until you uninstall).
• Shopper analytics: impression and decline events (shown, viewed, clicked, declined) are pruned after 90 days. All other analytics events, namely purchase attribution (accepted, converted, refunded) and offer-interaction steps (progress-threshold, reveal and fee-toggle events), are kept for the install lifetime so your lifetime revenue and funnel stats stay correct; they carry only the pseudonymous identifiers described in §1, never names or emails.
• Order records: each order's checkout ID and sales channel and, on a store that runs a thank-you offer, its buyer's contact ID, kept for the install lifetime like purchase attribution.
• Onboarding / funnel telemetry: 365 days.
• Dashboard usage analytics: kept for the lifetime of your installation and removed with your other installation data after uninstall (the same 90-day window).
• Anonymized product-improvement aggregates: retained as aggregate rollups only; merchants can exclude their installation from future aggregate recomputes via the setting above.
• After uninstall: uninstalling starts a retention window. We keep your offers, triggers, variants, analytics events, and settings for up to 90 days so a reinstall within that window restores your configuration instead of starting you from zero. (If Wix never delivers the App Removed webhook, a scheduled reconciler detects the removal and starts the same window.) Once the window lapses, the installation record and every row tied to it, including all analytics, are permanently hard-deleted.
• Data export / erasure on request: you don't have to wait out the window. Shopper-level GDPR/CCPA requests are served immediately via the erasure endpoint (§5), and you can request immediate deletion of your installation data by emailing us at the privacy address above or from your dashboard's authenticated session.
• Webhook receipts: event-type + received-at timestamps retained for 30 days; payload bodies are not retained.
• Performance samples: 30 days.
• Sentry events: 90 days.
• Server logs: kept by Railway for up to 30 days (and, for the transition calls in §3, by Fly.io for up to 7 days).
• Support chat: retained up to 24 months after the last message, then archived or deleted. Included in GDPR export on request.
• Operator dashboard notices: until dismissed or expired, and no longer than the support-chat retention window.

5. Your rights (GDPR / CCPA)

You have the right to:

• Access what we hold about your site (use the export endpoint in your dashboard Settings → Data & privacy, or email us).
• Rectify any incorrect data via the dashboard's edit flows.
• Erase all data by uninstalling the app (permanent after the 90-day retention window; see "After uninstall" above) or immediately on request.
• Port your data: the export endpoint returns a stable JSON shape.
• Object to processing: see "Erase" above; uninstall is the kill switch.
• Lodge a complaint with your local data-protection authority.

For shopper-level requests, the App processes data on the merchant's behalf. Direct shoppers to the merchant first. The merchant should then contact us if a programmatic removal is required.

6. Sub-processors

We rely on the following sub-processors (all bound by their own GDPR-compliant DPAs):

• Wix.com Ltd.: App Market platform, OAuth issuer, webhook source.
• Railway Corporation: application, database, backup and cache hosting (US East, Virginia, USA). Its storage buckets run on Tigris's servers.
• Fly.io: our previous application and database host, answering read-only for storefronts still on app version 52.x until they update (see §3).
• Sentry: error reporting.
• Clerk: identity for our own support operators. It authenticates our staff; it does not receive merchant or shopper data.

We do not pass data to additional processors without amending this policy.

7. Cookies and similar

The dashboard plugin runs inside a Wix-served iframe and does not set cookies of its own. The storefront widgets use sessionStorage (not cookies) to maintain the anonymous session ID and the cross-remount "shown" dedupe set; both are scoped to the merchant's domain and cleared on browser session end. They additionally use localStorage for the anonymous shopper ID that backs the per-shopper frequency cap (see §1). All three are written only after analytics consent is granted.

Our website, bumpshq.com, sets no cookies. We count its visits with Cloudflare Web Analytics, which does not use cookies or local storage to track visitors and does not fingerprint them. We see only totals: which pages were viewed, which sites sent visitors, and breakdowns by country, browser, operating system and device type.

8. Changes to this policy

We will post material changes to this URL and bump the "Last updated" date. For changes that materially expand the data we collect, we will notify installed merchants via the dashboard's notification surface before the change takes effect.

9. Contact

Lawri's Apps, LLC · privacy@bumpshq.com