Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

This document is under construction and is actively being updated.

Main Ideas/Points

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.

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

    • flexible

    • robust

    • comprehensive

    • inclusive

  • Needs to accommodate all kinds of schools and programs, most especially “non-traditional cycle” graduate programs

    • multiple annual entry terms

    • spring or summer start dates

    • alternate application stages like interviewing/traffic rules

    • small application populations

  • Needs to accommodate variety of dataset sizes; not all programs will have statistically significant numbers or numbers that make sense

  • Points of ambiguity:

    • 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” (i.e., dropping during add/drop, etc.)

    • 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 we consider complete.

    • Race/Ethnicity – different prompts in different systems, how do classify consistently (East Asian vs. West Asian, Hispanic Spanish, etc.)

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

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.