Appearance
Data storage & geo-residency
This page describes what VWAM stores today and where VWAM stores it. It also describes the difference between our US and EU deployments.
What VWAM stores
VWAM persists three broad categories of data for a merchant.
- Conversations — the messages between a shopper and the assistant. This category also holds conversation state, such as ratings and feedback. It also holds the session context of a conversation, such as the shopper's IP address and device or browser information. A dedicated conversations database holds this data.
- Leads — the fields that a shopper submits in a lead-capture form, for example name, email address, phone number, and consent. The platform database holds these fields. The merchant reads them in the app and through export.
- Analytics — event-level metrics about the use of a chat, such as loads, views, engagements, product clicks, and themes. A separate insights database holds analytics events, keyed to internal identifiers. Lead analytics record only which fields a shopper submits, never the values, so lead personally identifiable information (PII) does not reach the analytics store.
A private object-storage bucket holds uploaded files. Those files are the attachments that a shopper sends in a conversation. The bucket is not public.
VWAM encrypts all of this data at rest. Databases use encryption keys that AWS KMS manages. Object storage uses server-side encryption. VWAM partitions the data per organization. See Access control & tenant isolation.
PII scrubbing at egress
Free-text fields can carry personal data on the way out of the conversation store. VWAM scrubs that text before it leaves. On the analytics path, a redaction step rewrites shopper-submitted feedback text before VWAM emits the event. The step replaces email addresses, phone numbers, credit-card numbers, US social-security numbers, street addresses, and URLs with placeholder tokens. Raw PII therefore does not reach the analytics pipeline.
VWAM applies the same redaction to message bodies and conversation previews in the merchant-facing conversation-records views. VWAM hashes the analytics identifiers for user and IP address with a one-way salted SHA-256 function, and does not store them in the clear. VWAM also reduces the user-agent to a browser and OS family.
This redaction is pattern-based and best-effort. It targets common, well-structured PII formats. It does not change the content that VWAM sends to the AI providers during a live conversation. See AI providers. The purpose of the redaction is to keep raw PII out of the analytics store and out of the surfaced-transcript paths.
Data retention
Stored data does not persist indefinitely. Scheduled purge jobs enforce retention limits on the conversation, lead, analytics, and file-storage paths.
| Data | Retention | What happens at the limit |
|---|---|---|
| Conversations, leads, and their attachments | 365 days by default; each organization can configure a shorter window | VWAM hard-deletes the raw records, the stored files, and the prior object-storage versions of those files. |
| Raw analytics events | 7 days | VWAM purges the raw events. The de-identified aggregate metrics behind the dashboards persist. |
| Conversations in a privacy-preserving consent-pending mode | Less than 1 day | VWAM purges the conversation if the shopper does not give consent. |
| Superseded file versions and incomplete uploads | An object-storage lifecycle rule | Object storage expires the superseded versions, so deleted content does not remain in version history. |
Retention differs from erasure on request. See Privacy & compliance. Retention is the automatic, time-based deletion that applies to everyone. Erasure is the on-demand removal of one shopper's data.
Where VWAM hosts the platform
VWAM runs entirely on AWS.
- Primary, US. The production platform runs in AWS us-east-1, in N. Virginia. This platform holds the API, the background processing, the analytics, and the primary databases.
- EU, Frankfurt. A dedicated EU chat environment runs in AWS eu-central-1. It holds a chat service and EU-regional data stores: a conversations database, a Redis cache, and a read replica of the product catalog. The environment runs today, but no shopper traffic reaches it. See the next section.
EU geo-residency — where we are
EU geo-residency is not in effect today. The EU chat environment runs in Frankfurt, but no shopper traffic reaches it. The widget calls a single chat host. That host resolves to us-east-1 for every visitor, both EU and non-EU. VWAM has no region-based DNS routing and no per-organization region setting. VWAM therefore handles and stores EU shopper conversations in us-east-1 today, as a cross-border transfer under Standard Contractual Clauses (SCCs).
Several processing paths have no EU-regional equivalent at all. Resources in us-east-1 handle lead submissions, analytics events, and file uploads. The assistant also calls the platform API in us-east-1. These flows would still leave the EU after EU traffic reaches the EU environment.
We are closing this gap as part of our GDPR remediation program. See Privacy & compliance. The work routes EU shopper traffic to the EU environment. It moves the remaining lead, analytics, and upload paths onto EU-regional infrastructure. It adds EU consent controls. We target completion in the near term. Contact us for the current status and for a geo-residency commitment for your contract.