The Senzing subscription pricing is based on Data Source Records (DSRs). A simple definition for DSR is a record processed by Senzing for resolution. Updates to the same record are not counted as additional DSRs.
From an audit perspective, each DSR creates a record in Senzing’s DSRC_RECORD table (Data Source Record). The number of DSRs in your repository are the number of records in the DSRC_RECORD table.
Generally, entities get sourced from one of three types of data sources:
- Master files
- Reference data
- Transaction and/or events
Master files include data sources like customer master, employee master, vendor master, etc. Each unique entity (identified by a unique key or the combination of it's unique attributes) in the master file is a DSR. If the customer master contains additional entities beyond a primary customer e.g., a spouse, co-signer, beneficiary, guarantor - each of these are additional DSRs. Same goes with employees: if you send the employee's emergency contact and job application reference entities to G2, these are DSRs.
Updates to any of these entity records, i.e., same unique key, do not increase your DSR count. Relationship records associating entities are not DSRs. In most use cases, deleting an entity decreases your DSR count. See the last section entitled "Non-persistent Use Cases" for the exception.
Reference data is often purchased. One example is the US Social Security Administrations death master file with about 90M records containing name, date of birth, data of death, last four SSN and more. Another example is the US Department of Treasury's OFAC Specially Designated Nationals (SDN) watch list with 10's of thousands of parties of interest contains names, addresses, dates of birth, passport, and more. In each case, each identity is a DSR.
Updates to any of these entity records, i.e., same key, does not increase your DSR count. Relationship records associating entities are not DSRs. In most use cases, deleting an entity decreases your DSR count. See the last section entitled "Non-persistent Use Cases" for the exception.
Transaction and/or events
Often transactions will just have a unique key (e.g., a customer number) referencing the related master file entity. These are not DSRs as there is no entity resolution needs to be performed. Even if a new entity feature is learned e.g., a new phone number is found on the transaction, adding this new information to Senzing by submitting an update (using the unique key) is also not a DSR.
Sometimes transactions will include new entities that are not master file entities. One example is a banking transaction: Often a wire transaction will contain a bank customer and a counterparty whom is not a customer. We call these types of entities "keyless" as they do not have a "account number." In this scenario, the best approach involves generating a unique key (e.g., based on a hash of all the counterparties entity features like name, address, routing code and bank account number). By doing this, if the same keyless counterparty shows up in another transaction, the key will be the same if the identity information is the same. Each unique key is treated as a DSR. For example, if there are 1,000 transactions with a keyless counterparty; yet, there are only three unique identity variations across all these transactions (e.g., three different addresses), then the DSR count is three not 1,000.
Relationship records associating entities are not DSRs. In most use cases, deleting an entity, decreases your DSR count. See the last section entitled "Non-persistent Use Cases" for the exception.
Counting Your Actual DSRs
We provide a DSR audit script that simply counts the records in Senzing's DSRC_RECORD table (Data Source Records). Run this on your system as often as you like to see how many DSR's are in your system.
Non-Persistent Use Cases
There is one use case whereby entity resolution is needed on small data sets (e.g., 2 - 100's records), repeatedly - dynamic, on the fly, and without any persistence. In this mode, Senzing is resolving DSRs and then immediately deleting these same DSRs, all in one transaction. Therefore, Senzing does not accumulate DSRs in the DSRC_RECORD table. In this scenario, the DSR count is the total cumulative number of DSRC_RECORDs (excluding delete records) passed to Senzing annually.