This is for New Jersey district data coordinators and test coordinators who keep results from more than one year.
A district trying to compare NJSLA performance levels across two or more years can run into an obstacle before any actual comparison begins: nothing NJDOE publishes guarantees that exported data files use the same column header for the same field from one year to the next. Two files that both report performance level, subject, and school can still fail to line up automatically, because the field that held "performance level" in one year's export might be labeled differently in another year's.
This is a data-alignment problem first. Treating it as a statistical one is how comparisons go wrong before they start.
Why the columns don't match
Column naming in a state assessment export isn't a fixed contract across years. It can shift when the state revises a reporting template, when an administration adds or renames a field, or when the underlying testing platform changes. New Jersey does publish field-level specifications for its student-data collections: the NJSLEDS Student Management Data Handbook defines each field and its format. Those specifications govern what a district submits, not the column headers on an assessment results export. The state's testing vendor also changed for the 2025–26 school year, and the NJSLA-Adaptive (NJSLA-A) replaced the fixed-form NJSLA. NJDOE's vendor update confirmed that the State Assessment Registration files districts submit did not change: "No changes have been made to the file layout, required data elements, or validation rules." It says nothing about the results files districts receive. A change of that size can alter file formats even where the thing being reported, a student's performance level in a subject, is the same kind of value.
The data is still usable across years. The alignment between years just has to be set up deliberately, once, rather than assumed.
What the alignment step actually looks like
Hypothetical example for illustration only: imagine a district's 2024 export lists a student's performance level under a column named "Performance Level," while its 2025 export uses a column named "Level." Both columns hold the same kind of value, on the same five-level scale, for the same thing being measured. A valid multi-year comparison requires mapping "Performance Level" and "Level" to a single output field before any year-over-year analysis happens, not assuming that a similar name will be inferred correctly on its own.
The mapping decision belongs to a person who can check that both columns hold the same measure. A header-matching rule cannot make that check. A near-identical column name is a hint, not proof. A differently named column can still be the correct match once its contents are checked against a few known rows.
What alignment can't fix
Aligning two columns under a shared output field solves the naming problem. It doesn't guarantee the two years are comparable in every sense a reader might assume. If the test itself changes its scale, cut scores, or questions, the same header holding the same five levels may not represent the same measurement from one year to the next. This happened in 2026. NJDOE's standard-setting presentation states that prior fixed-form cut scores no longer apply to the adaptive test. Treat any comparison across that change with more scrutiny than a routine year-over-year check. When a Test Changes covers what evidence would be needed.
Alignment gets two files speaking the same language. It doesn't certify that what they say means the same thing.
Where a tool fits, and where it doesn't
DataVot handles the mechanical part of this alignment. "Compare across years" combines a school's data sets for the same test, and columns with identical names line up automatically. Differently named columns stay separate until someone maps them to a shared output field in the "Combine data sets" form, so a district isn't re-keying or reformatting files before comparing them. That automatic match by name is itself a decision, and it is the one to check: DataVot does not verify that an identically named column still holds the same measure, does not decide that two differently named columns do, and does not check whether a testing-platform change altered what a header measures. Those remain judgments for the person building the comparison.
A district evaluating any tool for this purpose, DataVot included, should ask the same question either way: does it require an explicit alignment decision, or does it make that decision invisibly on the district's behalf? The second approach is faster to set up and harder to defend later.
If you're sitting on two or more years of NJSLA exports, you'll gain more from mapping one pair of years by hand and checking that the mapped columns agree in a handful of sample rows than from trusting any tool's default behavior. That check, not the mapping itself, is what makes the resulting comparison something you can stand behind in a board presentation.
Related reading: What Is the NJSLA? A 2026 Guide for NJ Educators · How to Read NJSLA-A Reporting Categories