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
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
Fallback Strategy
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
Case 2: Family Using Same Email
Situation: Husband and wife registered with same email address
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