The model for providing ongoing enrollment analytics data/insights should be:

• flexible: can integrate new requirements rapidly without requiring wholesale changes

• robust: can withstand uncertainty, constant changes, variety of dataset size, and missing data without compromising overall integrity or validity

• comprehensive: all schools, programs, centers and units with programs or courses that ultimately generate a transcript are included

• inclusive: ensuring our core data reflects as accurately as possible the multiple disparate identities that every single prospect, applicant, and student brings with them

Challenges

• Accommodating all kinds of schools and programs, especially “non-traditional cycle” graduate & professional programs

  • multiple annual entry terms

  • spring or summer start dates

  • “unaligned” start dates (e.g. late July starts in Medical and Dental)

  • alternate application stages, including interviewing and traffic rules

  • small application populations

  • programs with external admissions vendors

• Accommodating a variety of dataset sizes; not all programs will have statistically significant numbers or numbers that make sense

• Aligning our consumption of external admissions vendors (e.g. CAS/Liaison) data with our standards

Points of ambiguity

• Which programs are included?

  • anything that ‘admits’?

  • anything that generates a transcript?

  • anything that generates an enrollment record?

    • corner cases include programs where students enroll in their coursework through University College, but are admitted into a program (GSBS: PREP)

• What counts as a “cycle”?

  • Application changes within cycle (MPH change concentration or start term from spring to fall)

• Clearly define when admissions stops being the “system of record” (e.g., if a student withdraws during add/drop, does admissions update their decision stack?)

  • SIS quick admit

  • SIS history of admit decline? Program Action codes?

  • What counts as a complete application?

  • Deferrals

  • Withdrawals

  • Deny vs. Do Not Interview

  • our policies vs. external reporting organization requirements/policies (i.e., what APTA considers complete vs. what TUSMGP PT consider complete.

  • different prompts in different systems, need for consistent classifications

    • race

    • gender (e.g. is X an option?)

    • gender identity (East Asian vs. West Asian, Hispanic country of origin, etc.)

    • veteran status

Initial Data points

Biodemo

Programmatic

Application cycle dates for each person

Sources

Paid marketing

{needs to accommodate different ways of attributing sources?]

Recruitment Activities

• Campus Visit: anything where they physically come to us (admitted students day, in-person interviews)

• External Event: anything where we physically go to them (tabling at a conference, school visit or fair, etc)

• Online event (online recruitment fair, information session, or interview)

• Mailing campaign

Scholarship(s)

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?)