Note: The matching criteria in this section only apply to special event registrations. All other web form transactions now use match settings from the Constituent matching page in Administration. Special event registrants will continue to use the current criteria until the new algorithm is implemented in a future release. The one exception for special event registrations is the host (the order patron). The shopping cart determines the host, and since it uses the new matching algorithm, hosts on special event registrations are matched based on the match settings on the Constituent matching page. For information about the match settings, see the Administration section of the help file.
When website users submit payments for special events on your web forms, the program associates the transactions with constituent records. To determine whether website users match existing constituents in your database, the program uses matching criteria to compare data on web forms to the corresponding data on constituent records. If the program finds a match, it associates the record with the transaction and updates it with any new data on the payment form. Otherwise, it creates a record and associates the transaction with that new record.
Note: When the program creates a constituent, address, phone, or email address record based on a web form, it selects “Web Forms” in the Information source field and does not allow you to edit the selection. In queries, you can use the Origin and Origin information fields to include the information source in query results or to filter queries based on whether records were created manually by program users or automatically based on web forms.
To determine whether a matching record exists, the program compares the following fields on the payment form with the corresponding fields on constituent records.
Title
First Name
Last Name
Address
City
Country
State
Zip
Email Address
Phone
For a website user to be considered a match for an existing constituent, these fields must all match exactly according to the following matching criteria.
The program only compares website users to individual constituent records. It does not consider organizations or groups. It also does not compare website users to constituents who are inactive or deceased.
Matching criteria is not case-sensitive, so the program treats “Smith” and “SMITH” as an exact match.
Because the Title, First Name, and Phone fields are not always required fields, the program treats them as matching fields when data exists in one location but not the other. If the fields contain data on both the payment form and the constituent record, then an exact match is required.
The program compares first names on payment forms to the First Name, Nickname, and Alias fields on constituent records. If an exact match exists to any of these fields, the program treats it as a match.
The program does not consider types such as Home or Business when it compares addresses, phone numbers, and email addresses. If an address, phone number, or email address on a payment form matches any address, phone number, or email address of any type on a record, the program treats it as a match.
For Zip codes, the program only compares the first five digits.
For addresses, the program treats the primary street names and standard abbreviations in the U.S. Postal Service’s list of street suffix abbreviations as exact matches. So if a user enters a Postal Service abbreviation but an address record includes the full name, the program treats this an exact match. For example, if a website user enters “123 Main St” but an address record uses “123 Main Street,” the program treats these fields as a match. For the list of Postal Service abbreviations, go to http://pe.usps.gov/text/pub28/pub28apc_002.htm.
If the fields on a payment form and constituent record match exactly according to these matching criteria, the program associates the online transaction with the constituent record and updates the record with any new data from the payment form.
If the fields are not exact matches, the program creates a constituent record for the website user and associates the transaction with that new record.
Note: The program can only match a website user to a single record. If your database includes duplicate records and the website user matches multiple constituents, the program disregards the matches and creates a new record for the website user.