Reports – Data Tracker Reporting
- Bettina Lippisch
Overview
The Data Tracker Report is a report you may refer to when you want to view the activity of data batches as it is processed through Datapool and onto the Omeda Database. From beginning to end, you will be able to see when your entries get processed, how many are successful, how many have to be reconciled and how any new entries affect your current customer records previously processed.
Running the Data Tracker Report
You need to be given access to this report by your Client Services Manager. To run the report,
Go to the Reports tab.
In the Data Reports section, click on Data Tracker Report. Select your report parameters:
Required field: Client, Brand, Product, Sources, Date Range (Input is required for internal Omeda users only)
Prep Date: The date the mailed customer records were initially scanned & sent for keying.
Processed Date: The date the first customer record in the batch was processed from Datapool into the Omeda Database.
Optional fields: Promo Codes, Batch, Error Codes
Click Generate Report in the upper right corner.
Data Tracker Report Fields
The Data Tracker Report is an excellent resource when wanting to view the status & success of one or multiple batches from start to finish. In it, you will find three buckets – “Batch Description,” “Processor Status” and “Successfully Processed Records.”
Under “Batch Description,” you will see the exact number of customer records sent in each batch, input method, source, number of returned customer records, Datapool entry date and processed date. Under “Processor Status,” you will see in more detail the number of customer records that are ready to process in each batch, if any additional mapping is necessary, how many customer records failed and how many were successfully processed. Lastly, within “Successfully Processed Records,” you will be able to view the number of qualified and non-qualified customer records for new additions and updates as well as customer records that are already classified as 1 year.
Batch Description
Input: This field lists the input value being reviewed.
Source: The source field reflects where the data came from (e.g., Request from Company – Written, Direct Request – Telecom, etc.).
Batch Tracking Code: This field specifies which customer records batch the data is for. Each batch ID is unique.
Note: All Web Batch Tracking Codes for a given day will be rolled up into one line.
Vendor File Name: The vendor’s file name now appears in the Data Tracker report for files from external sources. This will allow you to easily balance the files that you receive from external sources.
Sent: This field reflects the total number of processed and unprocessed customer records sent for keying.
Returned: This field reflects the total number of customer records keyed and ready for processing.
Balance: The number of customer records not sent back to Omeda from the key house.
Prep Date: The date the mailed customer records were initially scanned & sent for keying. Neither Internet nor phoned customer records will have a prep date.
Datapool Date: The date the first customer records were placed into Datapool.
Processed Date: The date the first customer record in the batch was processed from Datapool into the Omeda Database.
Processor Status
Data within Processor Status (except for the Loaded into Datapool column) is equivalent to the Sent column under Batch Description
Loaded into Datapool: The number of customer records loaded into Datapool on the date specified under Datapool Date that are awaiting processing.
Failed Validation Rules: The number of customer records that contained an error or did not include required information (e.g. ZIP code and state didn’t match, missing name, missing PID, suspected vulgarity, etc.).
Open Ended Coding: The number of customer records that require additional mapping before the record(s) may be processed (e.g. a customer who selects an “other” field and needs to be mapped to another valid category).
Failed Source Priority: If the record has already been inputted into the Omeda Database on a prior date with a more reliable source, the new source may or may not be rejected based on pre-defined source priority rules. Note: this field is commonly only attributed to non-paid/controlled records.
Ready to Process: The number of customer records ready to be processed into the Omeda Database.
Discarded: The number of entries Omeda is not able to input. These entries are not able to be processed and will remain in Datapool.
Partially Processed: If a record has all required information but only missing optional fields or has a failed prioritization source, these entries will still be processed partially and be reflected in this field.
Successfully Processed
New: The number of new records successfully processed to the database resulting in a new customer record being created.
Existing: The number of existing customer records successfully updated and processed within the database.
Successfully Processed Records
Note: All fields (except “Other”) within Successful Processed Reports are split by “Qualified” or “Non-Qualified.” Qualified customer records are those in which are qualified subscribers (class 1 or 3). Non-Qualified customer records are those which are not qualified subscribers (expired, suspended, killed, payment pending, etc.).
Adds and Updates/renewals is equivalent to the sum of New and Existing under Successfully Processed in the Processor Status section
Adds: The number of new qualified and non-qualified customer records that passed all Datapool checks and have been successfully processed.
Updates/Renewals: The number of updated or renewed qualified and non-qualified customer records that passed all Datapool checks and have been successfully processed.
Updated Already 1 Year: The number of customer records that have already been updated within the past audit cycle year. The record will be added but counted as already 1 year.
Example: Product A: 1 year start date is 1 Dec 2012, which means audit cycle period is 1 Dec 2012 – 30 Nov 2013.
Scenario #1: I have a subscription to that product with a verifdate of 1 June 2012. I am a “2yr” record because my verfidate (1 June 2012) is before the start date (1 Dec 2012). I submit a new order with a verifdate of 1 Jan 2013. I become a 1 year record. I am counted as a renewal. I am not counted as an already 1 year renewal.
Scenario #2: I have a subscription to that product with a verifdate of 2 Dec 2012. I am a “1yr” record because my verifdate (2 Dec 2012) is > start date ( 1 Dec 2012). I submit a new order with a verifdate of 1 Jan 2013. I am counted as an “already 1yr renewal.”
Other: This field reflects the number of non-magazine products that have been successfully processed in Datapool. This field does not have “Qualified” or “Non-Qualified” sub-fields.
Updates/Renewals Minus Updates Already 1 Year: The number of customer records in the batch that resulted in either new records being created, or existing records being upgraded to a better source/recency.
Formula: adds + (update/renewal – updates a already 1 year) = updates/renewal minus updates already 1 year
Table of Contents