this is a living document
| Tip |
|---|
We recommend that the university identify and standardize a core set of enrollment data that accommodates the varied nature of an institution as complex as Tufts University while also providing real-time, actionable data that clarifies fiscal realities and supports institutional goals. |
flexible
robust
comprehensive
inclusive
Initial Data points
Biodemo
gender identity
legal sex
race/ethnicity
veteran status
state of residence
citizenship
year of birth
Programmatic
program
start term/year
concentration
degree
school
decisions
application deadline(s)
Application cycle dates
Started
Submitted
Complete
Invited to Interview
Decided
Committed
Cancelled
Deferred
Enrolled
Source?
Paid marketing
{needs to accommodate different ways of attributing sources?]
Recruitment
Campus Visit
Recruitment Fair
Scholarships
Decline Data?!
What school attending
Why?
Yield Activities---what of this is our responsibility?
[dataset of programs; then dataset scoped entity for cycle open date. CONSIDER USING EXPORT DATA ON DATASET FOR FEED THROUGH KAFKA]
Application open and close
Program start/open semester/term
Program history (i.e., DPT started Jan 2021)
Open House/key recruitment dates (interview timing?)
Key dates for cycle based on program type (i.e., MD has plan to enroll, commit to enroll “traffic rules”)
At what point do we do a data freeze? What sort of auditing reports/processes would we need for each program to comply? What does a clean data set look like, anyway?
everyone has a decision (bonus points if it is the correct one)
Phase I
review data needs with stakeholders
EADs
Admissions directors
OIR?
Marketing?
Consultants?
explore Denodo and Tableau
Identify sources of data (Slate, Hubspot, etc.)
Milestone: report of key pain points/problems to be solved with this project? Roadblocks?
Phase II
Identify core data needed for reporting:
Develop data dictionary/common definitions/crosswalk
Identify which data need to be restructured(?) and which cannot be; accommodate these differences across instances/schools/programs
Plan for how to implement any updates/new fields in each Slate instance
timed to application cycles?
auditing and correcting old data?
Develop model for operational querying and reporting out of local Slate instances, differentiate that from analytics and dashboards based in Denodo/Tableau, provide appropriate access, and support this distinction with robust retention policies in individual Slate instances.
current versus year over year
single school versus multiple
admission operations versus marketing and communications
Develop initial model/templates for enrollment analytics reports/dashboards
identify which data is required for each and how it needs to be structured
Who gets access to which dashboards?
Build out connections between systems (Denodo, Slate, DW, etc.)
Phase III
Launch initial dashboards
Process for data auditing and maintenance
Process for requesting/accommodating new data (in Slate or for Tableau reporting)
Advanced/custom reporting and dashboards (by school/program?)