Personal Data Test Data
Use customer master dummy data inspired by the Personal Information Protection Act and the opt-in rules of the Specified E-mail Act to test CRM/e-commerce registration, marketing, and withdrawal flows all at once.
Compliance disclaimer
This content is a technical sample and is not intended as real personal data or a substitute for anonymized/pseudonymized information. Have legal and security teams review it before production use.
Customer master data requires careful handling under the Personal Information Protection Act, which makes preparing test data time-consuming on its own. A standard schema lets you reproduce the key use cases safely.
The customer master schema covers name, address, and contact details, plus membership status and consent flags. Below are representative fields and references. Field names stay in Japanese even in the en-US locale, since they match the CSV headers used by Japanese business systems.
| Field | Description | Reference |
|---|---|---|
| 顧客ID | Unique member identifier | Digit count and prefix can be adjusted to your internal member-numbering scheme (this sample uses a sequence) |
| 氏名 | Member's full name | A fictional name unrelated to any real person |
| 氏名カナ | Full name in katakana | The reading of the name in full-width katakana |
| 性別 | Male/female binary value | Adjust the ratio with the genderRatio parameter |
| 生年月日 | Date of birth (YYYY-MM-DD) | Randomly generated within the ageMin–ageMax range |
| 郵便番号 | 7-digit postal code | Modeled on the real postal-code format but the value is fictional. JIS X 0401 (prefecture codes) is only a reference and the code itself is not output |
| 町域番地 | District/block and street number | Uses fictional district names and does not match any real address |
| 携帯電話番号 | Mobile number starting with 090/080/070 | A fictional number; do not use it to call or message a real recipient |
| メールアドレス | Member's e-mail address | Uses IANA-reserved domains such as example.com (RFC 2606), so it never collides with a real domain |
| メール配信同意 | Marketing e-mail opt-in flag | Models the opt-in (prior consent) required by the Specified E-mail Act; adjust the ratio with optInRatio |
| 第三者提供同意 | Third-party data-sharing consent flag | Reflects the safeguards and third-party-sharing consent concepts required under the Personal Information Protection Act |
| 退会フラグ | Withdrawn-member flag | Reproduces withdrawn members for testing deletion/anonymization flows; adjust the ratio with withdrawnRatio |
In production, build in the safeguard measures the Personal Information Protection Act requires (access control, restrictions on removal, etc.), and keep operational rules that prevent test data from mixing with production data. District and building names are fictional and do not correspond to real addresses. E-mail addresses use IANA-reserved domains such as example.com (RFC 2606), so there is no risk of misdirected mail.
Apply the marketing opt-in and third-party-sharing consent flags to production-equivalent logic to surface implementation mistakes in consent management.
Note on screens and materials that the generated data is not intended to match real people or addresses, and share this with stakeholders.
Use the withdrawal flag to check logical/physical deletion flows and retention-period rules.
Separate the test database/environment from production, and set naming conventions and access permissions to prevent accidental mixing.
A. Names and addresses (district, block, building name) are generated as fictional combinations and are not intended to match any real person or address. Because generation is fully random, an accidental match cannot be completely ruled out, so please do not treat the output as real data.
A. No. This schema generates data that is fictional from the start, and it does not meet the processing standards for anonymized or pseudonymized information under the Personal Information Protection Act. If you need to process production data, follow a formal procedure with your legal and security teams.
A. The digit counts and formats (7-digit postal codes, mobile numbers starting with 090/080/070, etc.) follow real conventions, but the values themselves are fictional. A coincidental match with a real number is not impossible, so be careful with tests that involve outbound communication.
A. You can generate as many as the API rate limit and your browser's memory allow. For very large volumes, consider paging through the API (see the API documentation for details).
Get member data inspired by the Personal Information Protection Act and Specified E-mail Act as CSV, JSON, or via the REST API. Combine it with corporate master data to build end-to-end B2B2C test scenarios.
Download a ready-made sample for each schema to check the format before touching the generator.
100-row sample with dummy watermark