Skip to main content

How an Analysis Project Unfolds, Start to Finish

"I sent my data — now what?" rarely gets a clear answer. Here we walk through every step using a fictional example: a physiotherapy study testing inter-rater reliability of knee range-of-motion measurements. What we do when data arrives, how we build the analysis plan, how the report gets written.

The institution, participants and numbers in the example are fictional; the point isn't a specific case but the steps GetBayes follows on every project.

Who this example helps

  • Anyone wondering how the process will actually unfold before sending their data

  • Researchers who need to report inter-rater/intra-rater reliability (ICC, kappa)

  • Anyone asking "does the process end once I hand over the data?"

  • Researchers who've had a frustratingly opaque analysis experience before

1. We clarified what was actually being measured

The researcher wanted to report how consistently two physiotherapists measured knee flexion angle with a goniometer in 96 post-arthroplasty rehab patients; the target journal also wanted intra-rater repeatability. The goal was publication in a physiotherapy journal, so the report had to meet publication standards.

What we pinned down in the first conversation: which measurement was the primary endpoint (inter-rater ICC), which subset would be set aside for intra-rater reliability (a random 20%, re-measured by the same rater a week later), and which guideline the report would follow (GRRAS-style reporting for reliability studies).

2. We audited the data

Once the data lands, it goes through an audit first — we don't say "your data is broken, go fix it"; we pinpoint the issue and fix what we can ourselves.

  • 4 records had the angle entered in radians instead of degrees by mistake — corrected by cross-checking the source form

  • 3 patients were missing age — recovered from the hospital record system via the chart number

  • The same complication type was recorded three different ways ("infection", "inf.", "wound site infection") — standardized into one category

  • The raw file was kept untouched; every correction was applied to a separate "cleaned data" copy with a log of which row changed and why

3. From analysis plan to delivery

  1. 01

    We wrote the analysis plan down

    Which ICC model (two-way random effects, absolute agreement) would be used, which confidence-interval method would be reported, and how to handle the fact that some patients had both knees measured (a non-independence issue) — via a mixed-effects model — were all written down and approved by the researcher before analysis started.

  2. 02

    We ran the analysis

    Assumption checks (normality, homogeneity of measurement error across groups) came first. Inter-rater ICC came out at 0.84 (95% CI: 0.76–0.89); intra-rater ICC in the subset was 0.91 (95% CI: 0.82–0.96) — both reported with their confidence interval and model type.

  3. 03

    We wrote the report

    Results followed GRRAS recommendations: sample description, measurement conditions, ICC model and type, confidence intervals, and a Bland-Altman agreement plot. The reasoning behind every method choice was written into the text.

  4. 04

    We ran quality control

    Before delivery, every table, number and figure was checked one by one against the source analysis output; formatting and language were checked line by line.

4. We delivered, and stayed through what came next

After delivery, the researcher submitted to the journal; the reviewer asked for the Bland-Altman plot's limits to be interpreted and for one table to state its measurement unit more clearly. Revisions driven by advisor or reviewer feedback like this are always free — we didn't send a new quote, we updated it and sent it back the same day. As long as the scope genuinely hasn't changed, we work through additional requests together throughout the process too; the goal is staying with you until you're ready for the defense or the journal.

Project data, as with every real delivery, was used solely for this study, was never shared with a third party, and was deleted within 90 days of delivery.

Frequently asked questions

Is this a real case?

No, the institution and every number are fictional. Its purpose isn't a specific study but the steps GetBayes follows on every project — real projects follow the same steps with your own data.

Does this process play out the same way on every project?

The order of the steps is fixed: clarify scope, audit the data, write the analysis plan, analyze, report, quality-check, deliver and support revisions. How long each step takes depends on the study's size and the data's condition — a small, clean dataset moves through these steps in hours.

What happens if you find a problem during the data audit?

We fix what we can ourselves (coding errors, unit mix-ups, filling in missing fields from the source) and log what changed and why. If something can't be fixed by us or needs your call (an exclusion criterion, say), we ask — we never fill a gap with a guess.

Can the analysis plan change after it's approved?

Yes, but every change — a new test, a dropped model, an alternate correction — is logged with its reason and stated transparently in the report. Nothing gets swapped silently.

When does the revision process end?

For revisions driven by advisor or reviewer feedback, we don't put a hard cap on it — we stay with you through the defense or the journal decision. If a genuinely new request changes the scope (a new dataset, a different research question), we discuss that separately.

Let's run the same process for your data

Tell us about your study and data — we'll do the first clarifying step within 24 hours as a free assessment.

Last updated: July 10, 2026