When Ascent360 pulls customer records into our system from our clients source systems, we need to decide which records are complete and should be stored as a "customer record", which ones should be matched to individuals already in the database and then which ones are so incomplete that they should not be loaded into the database. This article will help you understand which records Ascent360 will incorporate into the database and which ones we will drop. Please see our other articles on the matching and hygiene process to better understand how individuals match to individuals already on file.
Every individual in the Ascent360 database will have a unique individual ID, which is called the Ascent360ID. A unique individual is defined by some combination of the following fields:
However most records that come into the database will be missing many of the fields listed above. As an example, many records may have a first name, last name and email address but will not have a physical address or a phone number. This is OK. We will still create the individual with just the First Name / Last Name/ Email Address combination. Here are some of the rules that Ascent360 uses to determine who is an individual:
- The individual record must be “Contactable” – This means that an address, phone number, cell phone number or email address are required.
- A record with only First Name or Last Name and no other data will be thrown out. If as an example, we have an incoming purchase transaction and the contact information with the record is "John Smith", with no address, phone or email address. We will throw out this record. Why? We will not be able to match this to another record at some point in the future. Even if another record comes in that has John Smith with a full address, we can not safely match the first record to the following record. (the first John Smith could be a totally different John Smith that lives in another state.
- A record can be "email only". So if the incoming record is firstname.lastname@example.org, we will load this to the database. If at a later time, anohter record comes in with the nameTed Johnson and the email email@example.com, we will match this to the original record and will now have a record with first, last and email address.
- We will not store "Postal Only" records. If a postal address does not include a first or last name, than we will throw it out.
- Similar to an email only record, we can load "phone only" records but this is not done by default. This is an option we create during setup.
- Every Unique Individual in the database will be assigned a unique ID number called the Ascent360 ID. This ID is randomly assigned but will persist, meaning that the individual will have the same ID over time in the database. (Ascent360 ID's may change over time if individuals get merged with other individuals)
- There are about 150 combinations of contact information that can make an individual.
- Two individuals can have the same email address, the same phone number or the same physical address.
Below are Examples:
Here is an example of two individuals that share the same address, email and phone number. It is somewhat common for older couples to share an email address. It is also common for parents to use their own email address when signing children up for activities (such as a ski lesson). The child may be in the database but will share the same email address as the mother. (child records with a known age under 16 will be automatically unsubscribed)
|12345672||Susan Johnson||123 Main Street, Golden Coloradofirstname.lastname@example.org||303-555-1212|
|54321543||Ted Johnson||123 Main Street, Golden Coloradoemail@example.com||303-555-1212|
Below is an example of a few individuals with different amounts of information:
|Name + Phone||54321543||Bob Simpson||303-555-1212|
|Name + Address||543958382||Tom Johnson||456 Elm Street, Denver CO 84834|
|Email + Zip||91362||ttoms@ascent3|
Why does Ascent360 not load records with just First and Last Name? Clients often ask us why we do not load records with just a first and last name. The answer is that we do not have the ability to do anything with them. Suppose a record comes in with just the name John Smith. If we load this data, we will not be able to communicate with John in any way. If later, another record comes with the the name John Smith and an email address - we will not be able to match this record with the original record. The first may not be the same John Smith.
The above examples are just a few examples. There are over 150 combinations of this data that we typically see in databases. For additional questions, please contact support at firstname.lastname@example.org