Search the Omeda Knowledge Base

Data Loader – Loading Data

Initial Layout and Uploading

Figure-1

Initial Layout

When the User arrives to the Data Loader section, if no file has been uploaded previously for the Selected Profile (Figure-1.C), they will be met with a screen similar to Figure-1. Otherwise, the only difference will be a list of previously uploaded files instead of the splash screen suggesting to drag a file onto the window.

Uploading

Data Loader currently only accepts Delimited Files. They can be either comma, pipe, semicolon, or tab delimited.

To upload a file, the User can either use the Upload File Button(s) (Figure-1.A) or drag-and-drop the file into the Dropzone (Figure-1.B). The Upload File Button will open up a standard file-browser, allowing the user to search their system for the desired file. The Dropzone is signified by the dotted outline around the content of the page. Either will bring up the intermediary dialog for supplying additional information prior to submitting the file(s) for upload.

 

Figure-2

Upload supports multiple files, shown by Figure-2.A. The User may use the file-named tabs to switch between options they want to setup individually for each file. Each file should be reviewed using these tabs. A Delimiter must be specified for each file (Figure-2.C). Data Loader will try to predict which delimiter it is by the file’s extension, otherwise it will default to comma and may be changed to a more appropriate one if needed. The user may also specify a Template (Figure-2.B) to be used as a baseline of the file, but it is not required. Templates are explained in more depth in their own article.

When the User is satisfied with the selected options for each file, they may click the Upload Button (Figure-2.D). This will send the files to Omeda which will prepare the system for the next steps.

Upload Process

 

Figure-3

After the dialog closes, Data Loader should change to show the files that have been uploaded (Figure-3). The main information displayed for each file is as follows:

  • File Name
  • Upload Date
  • User Note indicator
    • This explained in the next section.
    • If a User has added a Note to the file, a little sticky-note image will appear on this row.
  • Who uploaded the file
  • Status of the File

Upon uploading, the file’s initial state is Pending. Once the system picks up the file will change to Loading File. Currently, the status (Figure-3.B) doesn’t automatically update, so the user can use the “Check Status” button (Figure-3.C) to check all of the states of the files.

Depending on the size of the file, this could take some time. While the file is being loaded into the system, it will make note of various aspects of the file to attempt to make the rest of the process proceed smoothly. It will grab the header row and attempt to predict which incoming field will map to one of Omeda’s fields. This works best with the customer and contact related fields as they are to be the most universal. Doing this will potentially speed up the Field Mapping step later, so it is recommended for file headers for such fields to have common naming. An example of this is using similar variations of “First Name”, “first_name”, or “fname” to represent “first name”.

The other main thing this process does is to note each row and column. Some minor validation exist at this step, but is mostly related to the structure of the file’s rows and not the actual content of the file. An example of this is if a row is found to have a number of cells less or more than the number of cells. In such a case, the row will be marked and skipped.

 

Details and Actions

 

 

Figure-4

File Details

Once the file has been uploaded, it will likely end up in the Ready to Map state. At this point the User can interact with the file in various ways. The most basic of which is to click on the file’s row. This will open a panel from the right (Figure-4.A) which is used to give a bunch of basic information pertaining to the file:

  • Last Update – This marks the last time something about the file was changed. Most interactions with the file that causes information about it to change will affect this time.
  • Last Updated By – This is the user who touched something about the file recently. This user is tied to the “Last Update” timestamp.
  • File Type – This is just stating what type the file was identified as.
  • Rows – This is typically the number of rows in the file excluding the header row. This represents the possible rows that could be processed. If a row was found in error as part of the upload process, they will still be counted here.
    • The “Record” and “Record Errors” counts should total this count.
  • Columns – This is the number of headers found in the file.
  • Records – This is the number of rows that were successfully processed to the database.
  • Record Errors – This is the number of rows that either partially or completely failed to process. This includes any rows that may have been skipped as part of the upload.
  • Batch Tracking Code – This area will be filled after the file has processed at least once. This will be used to identify records created or changed by this file. This can be used in Audience Builder to look up which customers were involved with this file. This will include existing customers, if they were found in the file.
    • This will be touched upon again later.

The Sample Record Preview Card (Figure-4.B) offers one record at a glance. Initially, only the first six headers and their values are shown, but clicking the Show All will reveal any others.

An additional feature of this pane is being able to add a Note to the file (Figure-4.C). This is a purely optional space used to communicate something important or clerical about the file and doesn’t need to be used for every file. Only one note can be stored at time. This means the User can edit an existing one or completely rewrite it. Saving a new note will cause the previous note to no longer exist. The user can tell which file has a Note by looking for a sticky-note image among the file list.

File Actions

The button at the end of the file’s row will display a menu of further actions the User may take with that particular file (Figure-4.D).

Edit Mapping

Choosing this will open the Field Mapping dialog where the User can dictate how the system interprets the file. The process of this is explained in the next section.

Process

This option is how to take a successfully mapped file – it will be in the state of Ready to Process – and attempt to put the data in the database. This will go over in more detail in a later section.

Upon selecting it, a warning will appear to inform the User that processing the file is something that can potentially ruin their database and cannot simply be undone.

View Row Errors

If there are any rows that have errors, this section will list them and the errors associated with those errors. Currently, those rows will need to be fixed and re-submitted via a new Upload. A future goal is to allow the user to change data related to certain errors and re-process instead of uploading a new file.

Delete

This option is for removing the file from the system. This could be because it was uploaded accidentally or the file didn’t upload correctly. This option only works after the file has been uploaded and before it has been processed.

If the Field Mapping tied to the File has been set to be used a Template, the Template will still exist even if the File is removed. This way, if the file needs to be re-uploaded, the changes to the Field Mapping can be saved and used instead of having to re-map the files.

 

Field Mapping

General Aspects of the Dialog

 

Figure-5

There are many elements of the dialog that appear in every step, keeping certain information and actions present whenever the User decides it to be useful. Each step has a small description (Figure-5.A) to explain the goal either the step is presenting or the user is to accomplish.

Various Template related features are also shown each step. Changing the name of the Field Mapping/Template is readily available when/if the User decides to change it (Figure-5.B). Clicking the little edit icon will allow the user to change this. By default, it is the name of the file (minus the extension). It will only appear in other places if the User chooses to make the Field Mapping a Template. This is done by clicking the checkbox (Figure-5.D), which will allow it to be used as Template in other areas of Data Loader. The Apply a Template Button (Figure-5.C) will open a modal allowing the user to pick an existing template to apply to the file. Making a Field Mapping a Template is only required if they want to use the mapping in other places, otherwise it can be ignored. More on Templates can be viewed in the Template documentation.

In the top right corner, the number of Records in the file is displayed (Figure-5.E). This is basically the number of non-header rows in the file.

Along the bottom the User will find information about the Field Mapping and the navigational buttons.

Field Mapping Validation/Feedback

Warnings, errors, and general information is tracked along the bottom (Figure-5.G). Clicking either the Warnings or Errors will bring up a dialog that will display brief explanation about things that the User might need to take action upon.

Warnings do not prevent the file from processing and is more to communicate that something about the Field Mapping doesn’t seem correct. An example is mapping both “Postal Address Id” and “Customer Id”. These serve the same purpose – looking up an existing customer – so mapping them at the same time is redundant. Another example is mapping a full name, such as “First Name Last Name”, while mapping separately “First Name” and/or “Last Name” in the same file will warn that the name could potentially not appear as desired.

Errors prevent the file from processing and need to be acted upon before the file can be processed. The most common one of these is the requirement of a known Data Source. Some other option besides the “Unidentified” should be chosen instead.

Unmapped Fields (introduced with the Template feature) will have it’s own little alert in this area. Having Unmapped Fields is not an issue and there is no requirement to have all fields mapped. This just keeps track of how many fields are currently unmapped, just in case the User would like to know this information. In the General Mapping step, these unmapped fields are highlighted as such so that they can be found at a glance.

Navigational Buttons

To go from step-to-step, the User will use the “Back” and “Next” Buttons. The “Finish” Button that appears, marks the last step. However, it is possible that changes to the Field Mapping could add or remove steps, causing the last step to change. More about this is discussed in the General Mapping step, as this case is typically triggered from there.

Overview Step

This is the initial step when viewing any uploaded file. In the content section of the dialog (Figure-5.F), a snippet of the file (first of up to 100 rows) is displayed. The rows and columns are order as they appear in the file. This step is used to get a feel of how the file uploaded and how the system will process the information. The best way to use this step is to see at a glance if the data is being placed in the proper columns. With delimited files, if the file is malformed or the wrong delimiter is chosen, data could end up being mapped to the wrong fields. If data doesn’t look proper, the User should make sure the file has columns formatted properly.

For example, if the File is delimited by comma and one of the fields is supposed to be “Last Name, First Name” in the same column, then each cell should be wrapped in quotes to prevent something like “Doe, Jane” from being viewed as 2 columns instead of 1. Something like this could cause the row to be skipped during upload or data being misplaced in other columns.

General Mapping Step

 

Figure-6

The overall goal of this step is to map incoming headers to their equivalent Omeda fields. Near the top of the page (Figure-6.A), information reminding what file is being mapped to which brand is displayed. Below that is a place to declare the source of the data in the file (Figure-6.B). “Undefined” is not an allowed Data Source, so the user is forced to change it. The remainder is mapping each field (Figure-6.C)

During the upload process, some of fields may have been identified and already mapped. These are to be viewed as suggestions and can be changed by the User as they see fit. Any field that was not suggested will be set to –Not Mapped–.

By default, most contact fields are considered of the Contact Type “Business” (Figure-6.D). This can be changed by the User by choosing another available option. It is important that the user makes sure all relevant fields have a matching Contact Type. If it is setup that all of the fields are tied to the Contact Type “Business” except, for example, City is set to “Home”, then it will result in two different incomplete addresses. If the file contains a way to identify an existing customer, then mapping contact information will cause a new step to appear.

A glossary of fields can be found here.

Navigating

For any step that can change aspects about the mapping, if the User tries to leave the step – such as clicking Finish (Figure-6.E) – they will be prompted with a confirmation screen (shown below).

 

Figure-7

Cancel will close the dialog, useful if it was accidentally opened. Continue without Saving will perform the action that was used to trigger this dialog, but no changes will be saved. Save and Continue will save the changes and proceed with whatever action caused the dialog to appear.

If the changes were saved, there is a chance that the number of steps may have changed. If this happened, then a dialog will open noting the changes (Figure-8). If “Finish” was clicked prior to saving, if more steps were added, the next step will be displayed. If “Next” was clicked and steps were removed, then the dialog will close stating that no more steps existed.

 

Figure-8

Contact Type Step

 

Figure-9

This step only appears if the User has mapped Postal and/or Email related fields and has mapped a way to detect an existing customer (such as mapping Customer Id). The main goal of this step is to figure out how incoming contact information should be applied to the existing subscriptions of an existing customer. This step will not create new subscriptions. All this will do is swap out the relevant contact information; for example, it will change the Shipping Address to use the incoming address.

Each Contact Type combination can have it’s own rules (Figure-7.A). The default is “None” (Figure-7.D), but can be changed by selecting an option in the dropdown (similar to Figure-7.B). Selection of Products is special in that it provides a granular way of dictating which products get updated. These are divided by product type. The products displayed are based on those available to the Selected Profile. Checking the box to the left of the product type – such as Magazines – will select all of the products of that (Figure-7.C). For example, the User could want a single magazine and all of the newsletters to change, so they would select one of the available Magazines and then the checkbox next to “Newsletters”.

Contact Type Validations

Because “None” is the default value and is an acceptable value, it makes this step completely optional. The user isn’t required to map incoming contact information to products. However, if they do make some selections, Data Loader will attempt to find potential issues with certain combinations (or lack there of). It is considered an error to use “Selection of Products” and not select any products. This will make the file unable to be processed.

The most likely warning would be the overlapping of products for a particular contact object across multiple types. For example, if the User maps two Email fields, one for Business and one for Home, they will have the opportunity to select which products should receive those. If during the selection of the products and overlap is found (for example, they both map in explicitly or implicitly to Product-A), then a warning will appear stating that the user should probably change the data or face potentially incorrect data. A subscription can only have one email address or shipping address assigned to it, so having multiple incoming emails apply to the same subscription will cause one of the emails to win over the other.

Finishing Field Mapping

After going through all of the steps or closing the dialog, if the Field Mapping was saved, there is a chance that the file will be evaluated to either of two statuses.

 

Figure-10

Mapping Incomplete appears if the Field Mapping has Errors in it. These are things that must be addressed before Data Loader can move forward with that file. The common error is not re-mapping Data Source during General Mapping.

 

Figure-11

Ready to Process (Figure-11.A) means that the Field Mapping is in a state that it can be processed. Warnings may still exist in the Field Mapping, but as stated before, warnings do not prevent processing. At this point, the file may be processed by using the button and clicking the Process option (Figure-11.B).

 

Processing

 

Figure-12

Upon clicking the Process option, the User is presented with a dialog warning about the potential danger of uploading a file (Figure-12). This will be presented each time the user attempts to process the file, reiterating that the process has a chance of making changes that are not easily reversed. Therefore, they should make sure that what they are uploading is in a sound state. Accepting these terms (Figure-12.A) will enable them to press the Commit to Database Button (Figure-12.B). Pressing this button starts the processing cycle, which cannot be interrupted.

Processing Steps Overview

Data Loader’s processing component is made up of three stages. With the Beta, a lot of these areas are currently under utilized, but it is possible to glimpse some of these stages from the User Interface. When a file is being processed, it will go through each stage with each stage having it’s own queue. It starts with the Pre-Processor; this stage responsible for validating the data, looking for anything that may need to be held up. After that completes it gets passed to the Processor; this stage is responsible for creating new data and modifying existing based on the Field Mapping. The third stage, Post-Processor, currently isn’t being used but is designed to perform any data manipulation or validation after the data has been processed to the database.

The User may see the status Waiting to Pre-Process or Waiting to Process. This means that file is scheduled for that stage and is waiting for a server to pick it up.

When everything is a done, the user will receive an email stating everything is complete. It will contain some basic info and a small report of the overall results.

A glossary of fields can be found here.

Pre-Processor

At the time of this documentation, no features have been implemented for this stage.

Processor

During this stage the program is taking all of the rows that are cleared for processing and pushes the data into the database. Each row is processed fully before moving on to the next. Processing the data in the row is done in sequential steps, ensuring data gets added in a proper order if certain things are required by other steps.

  1. Customer – Processing a row starts by identifying the customer and whether or not they are to be treated as a new one or not. If Postal Address Id or Customer Id has been mapped, then it will attempt to look for an existing customer with that value. If they don’t exist, then a new customer will be created. Otherwise any customer related field will be applied to the customer.
    1. If the customer is an existing customer, mapped fields will overwrite existing values. For example, if First Name is mapped, then the customer’s name will change to new value. The old value is preserved in a Memo placed on the customer. It can be viewed in Audience Search for that customer. A Memo is also made for Title changes.
  2. External Customer Ids – This is the second step and is dedicated to figuring out how to interpret the incoming External Customer Id. Mostly it’s deciding if it’s a new one, in which case it will add it to the customer. Data Loader does not update existing External Customer Ids. If it sees that the external namespace exists for that customer, the External Customer Id will be skipped.
  3. Postal Addresses – This step starts off by creating a temporary version of the address. It fills in all the fields and once it has everything that it has been supplied, it will compare this address to any existing. This comparison is close enough to be considered an exact match comparison. If it is found to match an existing address, then the verification date and batch will be updated on the existing address. Otherwise a new address will be added to the customer.
  4. Email Addresses – This step is similar to the Postal Addresses step where the program creates a temporary email address with the given mapped fields. If the email address exists, then no new address will be created and the verification date and batch tracking is updated on the existing address. Otherwise a new email is created.
  5. Phones – Anything in the phone category (Phone, Mobile, Pager, Fax) ends up being processed here. Incoming phone numbers are checked against any existing phones. If they are the same, verification date and batch are updated on the existing. Otherwise a new phone is created for the customer.
  6. Apply New Contact Data to Existing Subscriptions – If the row is tied to an existing customer and the user set rules for how new contact information is applied, this step will fry to find any relevant subscriptions and swap out the old contact data with the new one. This applies for the Shipping Address and/or Email Address of the subscription. If no rules have been setup during the Contact Type Mapping, then no changes to the existing subscription will occur. This step does not create new subscriptions.
  7. Housekeeping – This is a type of finalizing step, wrapping up any loose ends that may have been created or attaching additional meta-data to the customer. One thing that occurs is that the customer is marked as changed and given a timestamp for it. This is relevant for other applications and reports. If the customer created for this row was a new customer, if any contact information exists, one of each type of contact is set as Primary. Many things care about Primary status, so Data Loader makes sure that the new customers have one. A nightly process will reassign the Primary status based on the rules setup for the brand as part of a nightly data cleanup.

That’s the bulk of how the processor works. At the moment, Audience Builder is not rebuilt as part of this. Before the customers can be used in Audience Builder, it will need be rebuilt.

Post-Processor

At the time of this documentation, no features have been implemented for this stage.

After a File has Processed

 

Figure-13

When everything is done processing, the User may see the file in one of many different states (Figure-13.A), depending on how well the Processing stages went.

  • Completed – All of the rows in the file have processed successfully.
  • Processed with Errors – The file has been partially processed. It is likely that some rows were completely processed, while others were not. The errors can be viewed in View Row Errors option from the file’s menu.
  • Pre-Processor, Processor, Post-Processor Failure – These three all mean mostly the same thing but occurred during the respective stage. Essentially, some internal server error that wasn’t accounted for occurred and the file was not processed completely.
    • In either of these cases, a support ticket should be opened so that the problem can be fixed for similar scenarios. The information in that ticket should include:
      • Name of the File that was Processing
      • Name of the Client
      • Name of the Profile (if possible)
      • Around when the Failure occurred.

The counts of rows which processed versus those that received an error can be viewed in the Details pane from clicking on the file’s row (Figure-13.B). As a reminder, Records represents the number of successfully processed rows, while Record Errors is the number found with an error.

Each file has it’s own Batch Tracking Code (Figure-13.C) which can be used to track customers and their data related to file. Clicking on it brings up a menu (Figure-14 below).

 

Figure-14

Currently, only one option exists and that is to copy it to your computer’s clipboard so that it can be pasted in other places. There is a way to query the customers used in a file via the Data Loader Tracking Code ‘skittle’. Future options will use the batch of customers for other Omeda tools.

Rows with Errors

At the moment, the only solution to rows with errors is to correct them, create a new file, and upload the new file.

Last Updated On June 19, 2019
Knowledge Base Feedback