MF_Yield

Fact

Fact table for calculating matriculant-to-admit yield ratios longitudinally, per application.

The grain of this table is one row per student per application (or entry term). It is based on the Recruitment Plus DataStuAppAcad view. The business key here is the prospective student's Recruitment Plus PKID and the application's PKID (probably only the latter is strictly needed), but because applications are associated with one and only one entry term at any given time, we actually structure this table so that the database key is composed of foreign keys linking this table to the MD_Prospect and MD_CarlTerm dimensions.

THIS TABLE SHOULD NOT BE USED FOR COUNTING HOW MANY STUDENTS ARE ENTERING IN THE FALL! Reason: If a student applies, accepts, and defers entrance until the subsequent academic year, their personal entry term is the fall of the subsequent academic year. But their application entry term is still the fall of the current (or soon-to-be-current) academic year. For purposes of yield calculations, we use the application entry term. If we use the personal entry term for yield calculations, then our numbers will be skewed (we'll count some applications tendered one year towards the next year's numbers), or else matriculants/deposits will be doubly counted, or counted for the wrong year (e.g., their application will be counted for one year, but their matriculation for another, or worse yet the matriculation will be counted for both years). Yields therefore must be calculated using the application's entry term, which in the case of deferments will not provide an accurate body count of entering students for a given fall term. If you want a body count for the fall term, use MF_Rate!

If you are looking to track prospect-to-applicant ratios (to see who is applying and why), use MD_Rate in that case, too.

This is really a kind of accumulating snapshot table. We repeatedly visit the same rows, and update counts based on current application status information. It is not a periodic snapshot table, and therefore is little use if what we want to do is compare current data (e.g., number of matriculants) with past data (e.g., number of people who said they were coming to Carleton and paid their deposit). It cannot be used to look back in history, to compare what is happening now with what happened at parallel periods a year (or multiple years) ago. Nor is it a transaction table.

Rows in this table link to the most recent row in MD_Prospect.