Captured payload anonymization
Personal data in captured example payloads is replaced with placeholders before a build leaves your site.
A captured example payload is the one part of a build nobody wrote — the plugin recorded whatever a real visitor actually submitted. A WooCommerce order carries the billing and shipping address, the customer's email, phone number, IP address and user agent. Every export and every published build now replaces those with placeholders by default.
Shape is preserved on purpose
The example payload exists so an importer can preview field mappings, and a preview needs the same keys, the same nesting and the same types. So every replacement is a plausible value of the same kind — [email protected], 1 Example Street, 203.0.113.10 — never a deleted key. Product names, totals, statuses, SKUs and IDs are left exactly as captured.
What it looks for
Names, emails, phone numbers, street addresses, cities, postcodes, companies, IP addresses, user agents, dates of birth, and identifiers that unlock something (order keys, session ids, tokens). Field-name matching handles prefixes, so _billing_email and customer_email are treated the same, and {key, value} pairs — WooCommerce meta_data, ACF, most form plugins — are judged by the field name they declare rather than by the literal key value. Free text is scanned for emails, IP addresses and international phone numbers, which is what catches values the AI conversation quotes back at you.
What is deliberately untouched
Field mappings, conditions, headers and URL params are configuration you wrote and reviewed, so they are left intact — blanking them would destroy what the build means.
The one opt-out
A download offers "Keep the real captured values" for a private backup of your own site. Publishing ignores it entirely.
/ Related