After the export: combining ForceDecks, NordBord and ForceFrame data into one athlete sheet

Every VALD platform exports cleanly on its own. The difficulty starts when you want one athlete's ForceDecks, NordBord, ForceFrame and DynaMo results in a single row for a single week — which is the only view that shows cross-test patterns. This guide is the data-modelling side of that problem, written for someone doing it in Excel or Power BI. It is device-agnostic on purpose: the exports change format from time to time, the shape below does not.

The shape that works: one long table

Do not try to build a wide sheet with a column per metric per device. It breaks the first time a new test is added. Instead, put every result from every device into one long table with the same seven columns:

With every device in this shape, an athlete's week is a filter, an asymmetry is a pivot, and adding PhotonSport is appending rows, not adding columns.

Getting each export into that shape

• ForceDecks exports are wide (one row per trial, a column per metric). Unpivot them: in Power Query, select the ID columns and use Unpivot Other Columns. Keep the trial number so you can pick best-of or mean consistently.
• NordBord exports are already close to long, with left and right as separate columns; unpivot those two into the limb column.
• ForceFrame exports have a position (hip adduction, hip abduction, etc.) — that is your test column — and left/right that become limb.
• DynaMo has the widest range of tests; normalise the test names hard, because the same movement can be recorded under two labels.
• Best-of versus mean: decide once per device and metric, apply it in the transform, and write it down. Mixing them silently is the most common reason two people get different numbers from the same export.

The five joins that go wrong

• Athlete names. 'J. Smith', 'Jack Smith' and 'Smith, Jack' are three athletes to a computer. Build an athlete lookup table once, map every export's name field to your athlete_id, and never join on the name.
• Dates and time zones. Exports can carry a UTC timestamp. A 23:30 test in the US lands on the next day if you strip the time carelessly. Convert to local date before you truncate.
• Duplicate trials. Re-exporting a date range re-imports the same trials. Deduplicate on athlete_id + test_date + device + test + trial before you aggregate.
• Units. ForceDecks reports some forces in N and some relative to body mass; NordBord in N and N/kg. Keep raw values in the long table and derive relative values from one body-mass table so they agree.
• Body mass itself. It changes. Keep a dated body-mass table and join on the nearest date on or before the test, not the current value.

From the long table to a report

Once the long table exists, the athlete report is a matrix: rows are athletes, columns are metric × device for the chosen week, and each cell is coloured against that athlete's rolling baseline. In Power BI that is a matrix visual with a measure for the z-score; in Excel it is a pivot with conditional formatting. The interpretation — the sentence a coach reads — is still yours to write, and it is the step that takes the hour per athlete.

When to stop doing it by hand

This approach works well for one practitioner and one squad, and it is worth building at least once because it teaches you your own data. It stops working when the exports are weekly across five platforms, when two people need the same numbers, or when the interpretation step is what is eating the week. That is the point where the transform, the baselines and the written flags should run automatically.

How Kinexis handles this

Kinexis is that automation: it reads every VALD platform and PhotonSport into exactly this long-table model using your organisation's own credentials, resolves athletes, dates, units and duplicates, and writes the per-athlete interpretation against rolling baselines — so the hour per athlete becomes minutes for the squad, with no export step at all.