The Golden Record summarizes records of an entity that refer to the same object in the real world, e.g., the same person or the same company.
We basically distinguish four general cases of how a Golden Record can be designed. The cases can of course all be used in combination. For the clarity and simplicity, the 4 cases are each listed in their basic form.
Simple Golden Record
If you integrate master data, it is recommended to create a golden record. This gives you a persistent ID (PID). The PID will be written back to the source systems. This way you avoid data redundancies caused by duplicates by not simply synchronizing the data into another system where it may already exist. With the PID, you can uniquely identify an object such as a contact across both systems (including the integration of any number of systems with master data of the same entity – e.g. contacts). Fewer duplicates have been proven to reduce costs – through more complete data, for example, and thus more informed decisions.
Technical implementation
For the implementation, the DataEngine is required as an ETL layer. The entities are synchronized into source modules in the DataEngine via the HubEngine. The Golden Record is modeled in a separate module. The source records are now assigned to a golden record (via relations). Which information is copied to the Golden Record can be freely defined in workflows.
The assignment or creation of the golden record, i.e., the record linkage, is done either by a third party provider, such as Omikron Data Solutions, or by simple if-then rules via workflows. A simple rule could be, for example, that source records with the same e-mail address are assigned to the same golden record.
The Golden Record can then be transferred to source and target systems. Alternatively, the ID of the Golden Record can be used as the PID and only this is synchronized back into the source systems. This way, a data record can be unmistakably identified across multiple systems via the PID.
Master Data and Transaction Data
From golden record to customer 360. If you not only combine master data in the golden record, but also link transaction data to it, you get a 360-degree view of your customers. All relevant information is available and visible in one centralized location. This eliminates the cost of information gathering and gives you a more complete view, allowing you to make more informed marketing and sales decisions.
Technical implementation
The basic technical implementation remains the same as for the Simple Golden Record. We only add transaction data to the golden record. This requires one additional HubEngine plan and one additional source module in the DataEngine for each system from which transaction data should be transferred. In addition, there is another module that bundles the transaction data (of the same entity) and assigns it to the golden record (via relations).
Golden Record Enrichment
Of course, you can still have the golden record validated and enriched by an external data service such as Dun and Bradstreet. In addition to the golden record, it is also possible to validate and enrich the data of the source modules. You can also enrich the source modules and the golden record with different data each. The golden record with the important data, which should be available centralized. The source modules with the data that you want to transfer back to the source systems. For example, financial or risk data is available to you for enrichment. The quality of your data already increases through the creation of the golden record, but with data validation and enrichment it increases even more. This gives you an even better and more complete view of your customers – for more informed marketing and sales decisions.
Technical implementation
The basic technical implementation remains the same as for the Simple Golden Record. We now enrich the Golden Record with additional data from a third-party data provider, such as Dun & Bradstreet, Omikron Data Solutions or Deutsche Post. The connection to the data provider is natively done via the DataEngine. This increases the data quality even further. The enriched golden record is then synchronized into the source and target systems. If the data is updated at the third-party provider, the changes are pushed directly into the DataEngine and resynchronized from there in real time.
Multi Golden Record
The Multi Golden Record refers to the fact that not only one entity, such as contacts, form a Golden Record, but also a second entity – such as companies. The special feature is that both Golden Records are set in relation to each other. Both Golden Records receive their unique PIDs. The Golden Account has a 1:n relation to Golden Contacts. A Golden Account can be associated with one or more Golden Contacts. The most common combination of Multi Golden Records is that of Golden Accounts and Golden Contacts. However, other combinations are theoretically possible, depending on the use case. This does not change the underlying logic though.
Technical implementation
Technically, as with the Simple Golden Record, we first create Golden Records of different entities (e.g. Contacts and Accounts) independently of each other. Then we create relations between both Golden Record entities. This is done based on the relations between the entities of the source records. Thus, we derive the relations of the two golden record entities from the relations of the source entities i.e. respectively merge them in the golden record.
Summary
Of course, all four cases can also be combined with each other as required depending on the use case and business processes. Multi Golden Records can thus also be assigned transaction data. The technical basis for the creation is the Marini Integration Platform. Master data can be consolidated and transformed there.
More resources on the Golden Record can be found here: