These are frequently asked questions by clients and internal employees.

Can Ascent360 pull customer information off of a credit card at the point of sale?

No.  It is not currently possible to pull customer information from a credit card at point of sale.  Although there are some vendors and website that suggest that they are able to do this, none of the reputable Point of Sale vendors are selling this service.

What does a typical implementation look like?

A typical Ascent360 implementation will take either 8 weeks or 10 weeks.  A high level understanding of how these implementation will flow are described in the images below.  Critically, Ascent360 has completed implementations in as little as 4 weeks and other have taken 6 months.  The length of an implementation is very much dependent upon three things:

  1. Number of integrations:  Some clients will have only one data source.  Others may have as many as 15.  The more data sources, the more time it will take Ascent360 to execute on the implementation.
  2. Complexity of the integration:  Some integrations, such as Shopify or RetailPro are very simple.  We can get one of these done in just a few days. Others, such as WebSphere or Oracle ATG are quite complex and take more time.
  3. Client Involvement:  Ascent360 typically needs our clients to be engaged through the process.  This should not be a significant amount of time, but typically we like to have a 1 hour meeting each week through the implementation to answer questions and discuss ideas.
  4. Access to the Data:  Ascent360 typically needs very quick access to the source data.  This may be by our clients delivering an API key or some other mechanism but typically our client will need to give us access to the data.

8 Week Implementation:

Below is a flow chart for an 8 week implementation:

10 Week Implementation:

Below is a flow chart for a 10 week implementation:


Does Ascent360 store credit cards in our database?

No - Ascent360 will not store credit cards in our database.  However we can store an encrypted version of a credit card such as a token or a seeded and hashed credit card.  The encrypted version of the credit card can be very useful for matching.

What is the difference between an individual, customer and a prospect in Ascent360

The Ascent360 CDP has three different concepts.  These are:

  1. An Individual:  An individual is a unique person in our database after all the matching and duplication.  This is 
  2. A Customer: A customer is any individual (unique person) in the database that has made a financial purchase.  So, everyone in the database who has made a purchase is considered to be an Customer.  However, for all of our clients, purchases can occur without us knowing about them.  For example an John Smith can walk into a retail store, buy a product for $150 and walk out without ever telling 
  3. A Prospect:  A prospect is an individual (unique person) who has not made a purchase but is in the database.  Typically prospects will come from sources such as an Email Sign up form or a Facebook contest.  Prospects have not yet made a purchase, however once they do make a purchase, we will change the "Customer Status" of that individual.

Where do we store this information in the Ascent360 CDP?  Ascent360 has a field called "Customer Status" which will contain the values of "Customer" or "Prospect".  Everyone in the CDP is an individual and will have a unique Ascent360ID.

To get an in-depth understanding of how Ascent360 defines an "Individual" please see this article.

What is an "Individual" in Ascent360?

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:  

  • First Name
  • Last Name
  • Address
  • City
  • State
  • Postal Code
  • Email Address
  • Phone
  • Cell Phone
  • Company Name

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:

  1. The individual record must be “Contactable” – This means that an address, phone number, cell phone number or email address are required.  
  2. 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.
  3. A record can be "email only".  So if the incoming record is tjohnson@ascent360.com, we will load this to the database.  If at a later time, anohter record comes in with the nameTed Johnson and the email tjohnson@ascent360.com, we will match this to the original record and will now have a record with first, last and email address.
  4. 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.
  5. 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.
  6. 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)
  7. There are about 150 combinations of contact information that can make an individual.
  8. 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)

Ascent360 IDNameAddressEmailPhone
12345672Susan Johnson123 Main Street, Golden Colorado
54321543Ted Johnson123 Main Street, Golden Colorado

Below is an example of a few individuals with different amounts of information:

TypeAscent360 IDNameAddressEmailPhone
Email Only12345672

Name + Phone54321543Bob Simpson

Name + Address543958382Tom Johnson456 Elm Street, Denver CO 84834

Phone Only

Email + Zip


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 support@ascent360.com

Does Ascent360 share data across clients?

No.  Data is not shared across client databases without express written permission from our client.  The data that our clients send to us is strictly owned by our clients.

How does Ascent360 define email permission for contacts under CASL?

Email contacts that are known Canadians will be processed under CASL rules. Canadians are identified if they have a known address in Canadian territory or if they have a “.ca” email address.

Here's how their email permission is determined:

  • If they have explicitly subscribed or unsubscribed, we consider this a “hard” email permission and the subscriber will stay with that email permission status unless they change it. 
  • If they have never explicitly subscribed or unsubscribed, we consider this a “soft” email permission. If they have made a purchase within the last 23 months, we consider them contactable, or a “soft” yes because there is an implied business relationship because of the financial transaction. This allows them to be contacted by email for up to two years after that point.
  • If their last financial purchase was more than 23 months ago, they are no longer considered contactable and we treat them as a “soft” unsubscribe.
  • Similarly, if a soft opt-in or opt-out explicitly unsubscribes or subscribes, their subscription settings change to a hard no or hard yes.

Last Financial Purchase Date

Current Email Permission

Hard No

Hard Yes

Soft Yes

Soft No

23+ months ago

Not contactable


Becomes Soft No and not contactable

Not contactable

Less than 23 months ago

Not contactable



Becomes Soft Yes and contactable

Please note:

If any transaction data, specifically around a financial purchase date, was not being sent to Ascent360 correctly, that would impact the customer’s email permission for any contacts being processed under CASL rules. Because of this, a lack of transaction data would show more people as 'soft' unsubscribes than those that are.