When we pull fullmeasure_student.csv files from multiple different sources, we need a way to sort out the duplicates. Let's say you want to pull students from your CRM and your SIS: we need a source file to establish which student we'll keep in the interface so as not to have duplicates when those students matriculate from the CRM to the SIS. You and your team can create this file and store it in the FTP to pass over to us.
Columns: (a sample file is attached at the bottom of the article)
In this file example, let's imagine that contact_id_1 and source_1 are from your CRM. You would add the same contact_id you use in the fullmeasure_student.csv file in the contact_id_1 column. The name in source_1 can be anything that you feel is descriptive for your students from this source, except "student" or "primary". We'll get into those below.
For the second set of student information, let's say it is from your SIS. The second column, contact_id_2 would be the same contact_id from the fullmeasure_student.csv file from your SIS. Source_2 is where we would distinguish this contact_id as "student" or "primary". This label is to highlight which student you would like to remain in our system as searchable or able to paste into audiences. In this scenario, if "12345" and "ABCDE" are both Emily Schreiber, when you search for Emily Schreiber, you will only see her ABDCE record, you won't also see a duplicate of her 12345 record. All of the information associated to that student will combined into this one record: our main goal is avoid seeing duplicates in the system.
Will my audience files change?
No, you'll still be able to use the appropriate IDs in the FTPs from each source. We save the original IDs on the back end to store for those students, we only don't show them in the interface. You won't be able to use each kind of ID for uploads: you'll have to use whatever you label as the "primary" or "student" as your pasted IDs for messaging.