PortfolioAbout This Article
To match customers between two systems, you need to find unique information that exists in both. This article explains which information to use as a matching key, comparing candidates and rationale for selection.
Matching Key Candidates
Candidate Information
| Candidate | Uniqueness | Ease of Acquisition | Change Frequency | Format Variations |
|---|---|---|---|---|
| Email address | High | Easy | Low | None |
| Phone number | Moderate | Easy | Moderate | Yes |
| Name | Low | Easy | Low | Yes |
| Address | Moderate | Easy | High | Many |
| Birth date | Low | Moderate | None | None |
Detailed Analysis of Each Candidate
Email Address
Adoption level: Most reliable -> Adopted as primary key
Phone Number
Adoption level: Moderate -> Consider as fallback when email doesn't match
Name
Adoption level: Low -> Use only as supplementary information
Address
Adoption level: Low -> Not used for matching, only normalized and stored
This Project's Selection Result
Primary Key: Email Address
| Selection Reason | Details |
|---|---|
| High uniqueness | Rare for same email to be used by multiple people |
| No format variations | yamada@example.com is always the same (only lowercase normalization) |
| Can be required in both systems | Shopify: required field, POS: set as required |
| Suitable for automatic matching | Can determine by exact match |
Fallback Strategy
| Case | Response |
|---|---|
| Customer changed email | Register as new customer. Manual merge if customer requests later |
| Using multiple emails | Treat as separate customers. Consolidate if customer reports |
| No email address | Treat as store-only member. Guide to email registration when using online |
Matching Logic Design
Matching Flow
Retrieve email address from registration form
Convert to lowercase, trim leading/trailing spaces
Search POS customers with normalized email
If found -> existing customer, if not found -> new customer
Normalization During Matching
" Yamada@Example.COM "
"Yamada@Example.COM"
"yamada@example.com"
Search with this value
Note: Simple normalization only. Gmail "+" notation is not considered (yamada+shop@gmail.com treated as different address)
Edge Cases to Consider
Case 1: Multiple POS Customers with Same Email
Cause: Past operational errors caused duplicate registrations with same email
| Response | Details |
|---|---|
| Immediate response | Link to first found customer |
| Recording | Log warning, notify admin |
| Follow-up | Manual merge later |
| Long-term | Strengthen email duplicate checking in POS |
Case 2: Family Using Same Email
Situation: Husband and wife registered with same email address
| Response | Details |
|---|---|
| Default behavior | Treated as same customer (by design) |
| Guidance | Show 'Already registered' at registration |
| Recommendation | Encourage registration with different email |
| Exception handling | Consult at store if they insist on same email |
Policy: 1 email address = 1 customer
Benefits of This Design
Reliability
- Match using reliable email address key
- No concerns about format variations
- Easy to automate
Simplicity
- No complex matching logic required
- Clear operational rules
- Easy to identify causes when issues occur
Flexibility
- Manual handling when automatic matching fails
- Can add matching logic in the future
- Minimal impact on existing operations