Over the past few months, my engineering team and I have performed dozens of Slate audits of existing databases. These audits are designed to give our partners a roadmap of improvements to their existing Slate instance so they can better recruit students and gain efficiencies in business processes.
We’ve uncovered a similar, significant error in almost every one: spreading out key student datapoints across multiple fields.
Key Datapoints
When we think about key datapoints on inquiry and prospect records, what are some items that come to mind? For me, those datapoints are simply:
- Student Type
- Entry Term
- Major of Interest.
These are the datapoints we need to know to communicate effectively with students and offer an appropriate call to action. This is also the data we need to know when assessing how many students in various categories are contained within our instance.
When we implement databases from scratch, we will usually introduce these three fields only, with very limited prompt options, as a foundational piece for the rest of the instance. Student Type options might be First-Year or Transfer, or in a shared instance, perhaps we’ll also include an option for Graduate as well. For Entry Term, this will simply be a list of spring, fall, and perhaps summer entry term options for the next four to five academic years.
When we introduce anything more than this, we are adding unneeded complexity that will hamper our communication and reporting efforts, and confuse our internal users.
Unclear Prompts
One version of overcomplicating this foundation we have seen recently is blending the Slate-native field for Citizenship Status with the traditional Student Type field, with prompt options for “First-Year,” “International First-Year,” “Transfer,” and “International Transfer,” among others. Because another important datapoint, the citizenship of the student, was now relayed in multiple fields (the default Citizenship Status field, and now the custom field created for Student Type), we uncovered some records with very murky data on file.
In this instance, there were Person records with a Student Type of International First-Year, with a Citizenship Status of US Citizen. We also unearthed students with a Citizenship Status of Foreign National (I.E. they possessed a Citizenship 1 outside of the United States), but their Student Type was First-Year, rather than International First-Year. Beyond the messy data in multiple fields, there’s the inherent overlap: an International First-Year student is, by definition, also a First-Year Student.
When it comes to populations leveraged in communication, staff assignment rules, or simply reporting out on domestic versus international inquiries, this kind of data structure makes it extremely difficult to segment students accurately.
Duplicate Fields
The second version of this error is creating duplicate field values for the same type of datapoint. A recent example of this pertained to the Major of Interest. In this instance, the data was spread out among a number of similarly titled fields: “Major of Interest,” “Campus Visit Major of Interest,” and “Vendor Major of Interest,” to name a few.
As you can guess, we also saw some conflicting datapoints on student records in this instance. There were many students where one field indicated interest in a certain program, say “History,” while another field indicated interest in something entirely different, say “Education.”
When Major of Interest is stored in multiple fields, conflicting data can result in students receiving irrelevant communications or invitations—weakening engagement. Not to mention, time is wasted reconciling data manually, and reporting fails to provide a clear picture of student interests.
Final Thoughts
This type of critical, foundational error shows up in nearly every Slate audit we perform. What else might be hiding within plain sight in your Slate instance? Let us help you identify and troubleshoot, so we can help you recruit students more effectively and simplify your business process.