One of the benefits of the standardization is realized in the construction of the query which is submitted.  Some of the nation's addresses can be rather cryptic and we go to great lengths to resolve these addresses into the fields necessary for query construction and for later use in our matching process.  This guarantees that each query utilizes the correctly spelled street, city and state components of the address.
	We then utilize the zip code component of the then standardized address to determine the appropriate area code to query.  This guarantees that each request is sent to the appropriate data resource using the correct area code information.
	Another of the benefits of standardization is realized on the return of the "listings" from the Telco.  As each "listing" is returned the street information is standardized to provide correctly spelled address components for use in our matching process.

Another benefit of RealMatchTechnology™ which some users may prove useful is our ability to very accurately identify "business" inquiries.  Our processes require that a query be identified as a business or residential inquiry.  Transmitting a business name query which should be submitted as a residential inquiry will result in a "no listing" response.   By incorporating into our query construction process the ability to access our proprietary 5000 word business names database, we can usually identify the proper query.  Our ability to identify each inquiry as each is processed allows you to mix residential and business requests as needed.  As a user you also always have the ability to override our logic and require that our process treat the inquiry as a residential or business lookup.

 

	A very important function of our query construction module is the utilization of our proprietary CommonName/Locality database to better enhance the query string before it is sent to the Telco.  Using the above example again, for the Juan Garcia example, because it will probably have been identified as a common last name in Los Angeles, we would have populated the query with all the information we had available, including first name, last name, street name, city and state.
	For the previous DeCicco example, we would have structured the inquiry with minimal information such as last name, street initial, city and state.   The reason for not including the first name or initial is to not eliminate a hit because the phone happened to be in the spouse's name.  In addition, we have included only the street initial because we do want to eliminate a potential match because of a misspelling of the street name.  With the street initial we would retrieve the listings as long as the first letter of the street matched and then our standardization and matching algorithms would provide a successful match.
	We also use a similar method for business names.

Matching & Scoring

The successful construction and submission of each inquiry, using the absolutely best information,  and receiving back the raw data results is just one side of the equation.   The result our data sources return are raw "listings".  These listings are returned in batches of up to 10 listings in a screen.  You are only charged for ONE request even when the request results in up to 10 result responses.  By efficiently utilizing our matching and scoring processes we are able to match and score "on the fly".  As each of these listings are presented to our matching and scoring modules, we standardize the information, match each component with your original request data and then score each component separately and also in the aggregate.

	It's totally up to you.  If you only want the "best single match" returned.  The top 5 "best matches" returned...  Or, we can even return back to you all of the listings which we received from the Telcos as a result of your query, whether there was a successful match or not.
	We do have a standard return format which contains all the information available, which could then be filtered at will by you based upon your own needs.  The standard data returned includes your original request record in original order, followed in the same record by the standardized address and then also followed in the same record with the returned listings.  Each returned listings results in a separate record.  Each record also includes the score for each component in addition to the total score.  Each file is in its original input sequential order and then sub-sorted descending by ScoreTotal.
	We can also put the returned data in the same output format of any current data provider which you may be using.  This capability we have of providing any reasonable output record, in addition to our flexibility with the input record, provides the ability for the RealEDA Electronic Directory Assistance service to seamlessly replace any slower or less accurate services which you may be currently using.