Data Source Records (DSRs) Explained

Overview

Senzing subscription pricing is based on Data Source Records (DSRs). A simple definition for a DSR is a single record processed for loading into Senzing. Updates to records and searches aren't counted. Deletes of records generally reduce the count.

To estimate your total DSR count, examine your source systems and count how many records there are in each that you plan to utilize with Senzing. The DSR count is the total across all these source systems. Moreover, don't forget to include the estimated future growth. Example source system (Data Source) may include: 

• Files (CSV or JSON): The number of lines
• Customer Database: The unique number of customer ids
• Claims Databases: The unique number of claim ids
• Account System: The unique number of account ids with one record for each account owner
• Employee HR Database: The unique number of employee ids
• ...you get the idea

From an audit perspective, we can provide a query informing you precisely how many DSRs you have in Senzing. If you never want to worry about it, Senzing has an unlimited license providing unlimited support which may cost the same as the support contract on your existing MDM or entity resolution software.

IMPORTANT: Some paid-for licenses may include time or DSR "buffers."  The buffers do not change your allowed license but are strictly there to help prevent an outage (e.g., you hit the limit before you expected and need to upgrade).  As soon as you exceed a license limit, you are out of compliance and need to upgrade/renew.

Uniquely Identifying Records in Senzing

Senzing identifies a record by the Data Source Code (A user-defined code to identify the source of the data - CRM, APPLICANT, VENDOR, HR, CLAIM, FRAUD, etc) paired to a unique record ID from that system. Think of the Data Source Code plus the record ID as the unique key for records in Senzing.

This unique key provides the provenance of each record in Senzing to the exact record in the source system it originated from. This makes it very easy to refer to the records in Senzing to query, update, or delete.

When a record with a unique key is sent to Senzing that matches a record already loaded, the new record replaces the current one in Senzing and doesn't contribute to the DSR count.

There is also a keyless mode to Senzing. When records do not have a unique record ID defined in the source system, Senzing will create a unique key to use based on a hash of the record data. Such records are harder to work with operationally, any change to the source record creates a new unique key upon ingestion to Senzing and it is harder to refer specifically to a past record. You have to find the unique key Senzing assigned previously and delete the record before ingesting to maintain the DSR count. We won't go into this mode in further detail but the same logic applies when estimating the number of records and the same audit query will work to count the DSRs created.

Important Nuances

The overview provides an estimate to calculate how many DSRs required for licensing. Typically this is the only concern but there are some caveats where the actual counts could be more or less.

1. Expanding Data Sources
   In some cases a single record in the Data Source may describe multiple entities and become multiple records. For instance, a claim may have a doctor, provider, and member. It may be desirable to load each separately if they contain names, addresses, phone numbers, etc and not merely account numbers.
   Moreover, a record might contain a mix of employee and company data which should become separate records in Senzing - one for the attributes identifying the person and one for attributes identifying the company.
   
   
2. Event Sources
   In some cases, data doesn't need to be loaded into Senzing and be entity resolved. For instance, a Data Source may represent a feed of current account balances containing the account number and the balance. Since the account number is associated with the account owner and loaded into Senzing, obtaining the history and current account balance is easily accomplished outside of Senzing for reporting.
   If you do want the current account balance in Senzing, you can identify the records associated with the account and update them without affecting the DSR count.
   
   
3. Exact ER Duplicates
   Senzing, by default, will automatically detect when records have the exact same entity resolution related data. It will preserve the records independently but will automatically "dedupe" them for processing. These "duplicate" records will not be counted against the total. For most users, this occurs so infrequently it can be ignored.
   
   
4. Deletes
   Deletes generally reduce the DSR count. An exception is when the delete is of one of the exact ER duplicate above. Since the duplicates weren't counted when added, they won't reduce the count when deleted. For most users, this occurs so infrequently it can be ignored.
   
   
5. Updates
   Updates will generally not change the DSR count. The exception is when the record involves an exact ER duplicate as above. If the update causes a duplicate to become unique, the count will increase. If the update causes a unique record to become a duplicate, the count will increase. For most users, this occurs so infrequently it can be ignored.
   

Senzing support can help you identify when your sources might be impacted by these conditions.