| 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
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:
- Sequential batch process - used for bulk processing of data, and
- 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 firstname.lastname@example.org.