DataGYM Technology

Structure of the DataGYM DR

The DataGYM DR is both physical and logical in its structure. There are industry specific blocks of information and common blocks of information (blocks). The industry specific blocks can change from industry to industry but, typically, common blocks of information do not change, such as individual or company name and address data. Whatever change is imposed on this structure due to market and language differences are handled within the Software Architecture of DataGYM Modules.

DataGYM Modules and the DataGYM DR

The DataGYM Modules have a very close relationship with the DataGYM DR as not only does the DataGYM DR maintain customer data in an organized fashion, it also maintains specific tables for each of the DataGYM Modules to enable proper execution of their functionality. Processing options or settings are saved in tables within the DR for ease of repeated execution while market specific tables provide local content and intelligence to the DataGYM Modules to make them effective in any market around the world.

The DataGYM Modules have been described below but in addition to these other third-party tools can access the DataGYM DR to facilitate statistical analysis or other activities.

• Customer or Prospect data could either come from Legacy environments or from existing Data Repositories and/or operational data stores. If the source of data is a Legacy environment, it is brought into the the DataGYM environment through the DataGYM Import module.
  
  
• The DataGYM Consolidation module cleans, parses, validates and standardizes data before it is finally committed to the Data Repository as blocks and components. If the source of data is from existing Data Repositories and/or operational data stores, DataGYM Consolidation links to the source without 'importing' the entire bulk of data into the DataGYM environment.
  
  
• Customer or Prospect data within the DataGYM DR are identified by their source and can arrive from various locations. Using this information, one source of data can be matched against another source of data based on specific phonetic and probabilistic matching algorithms and matched data are removed from the DR for operational efficiency. This functionality is delivered by DataGYM Suppression module.
  
  
• Alternatively, one source of data can be matched against another source of data based on specific phonetic and probabilistic matching algorithms and relationships can be established in multiple dimensions called "Relationship to the Nth Degree" within the DataGYM DR. As new data sources are inserted into the DataGYM DR, they get related to existing relationships or existing relationships might get reassigned based on new information. This functionality is delivered by DataGYM Householding module.
  
  
• Once data is within the DataGYM DR, whether they have just been cleaned or whether the data from various sources within the DataGYM DR are related to each other, it can be used to select specific populations or segments for marketing communication or other operational considerations. This functionality is delivered by DataGYM Extraction module.
  
  
• From time to time data from within the DataGYM DR is sent to other processes and the resulting information needs to be updated within the DR based on DataGYM DR assigned unique identification number (UIN). This functionality is delivered by DataGYM Update module.
  
  
• From time to time it will become necessary for data obtained from different sources to be combined into one physical record or instance. Using the existing relationships within the DataGYM DR this is accomplished by the DataGYM Rationalize module.
  
  
• To create effective Test Cells for marketing require analysis of demographic attributes stored within the DataGYM DR and using that to ensure each Test Cell represents the demographic slice accurately. This is accomplished by DataGYM Sample-It module.
  
  
• When a transaction record data not only needs to be matched against all the data within an existing DataGYM DR but the resulting matched records are used to decide a course of action that is reflected in the response returned to the transaction, the DataGYM Instant Decisioning (ID) module is used. More often than not this is preceded by the DataGYM Consolidation and DataGYM Householding Modules.

All DataGYM Modules can work in two modes:

1. Sequential batch process - used for bulk processing of data, and
2. Per transaction basis

How Market Specific Influences are dealt with in DataGYM

We have stated already, all changes imposed on the structure due to market and language differences are handled within the Software Architecture of DataGYM modules. This is accomplished by not only maintaining specific tables for each of the DataGYM modules to enable proper execution of their functionality, but also with the use of market specific tables, which provide local content and intelligence to the DataGYM modules to make them effective in any market around the world.

This diagram illustrates this aspect of DataGYM architecture.

For more information, please contact CIANT at info@ciant.com.