Case Study Methodology and Data Integrity

Case Study Methodology and Data Integrity

Every case study we publish on Site Studio is built on a simple rule: the numbers have to be real and the methods repeatable. We don’t dress up anecdotal wins as proof. If we claim a redesign lifted conversion by 40%, we show the pre/post data and explain what else changed during that period.

Data Sources

We pull performance data from first-party analytics accounts (Google Analytics 4, Search Console, server logs) and from the platforms we work with directly – ad networks, CMS backends, hosting dashboards. For arbitration cases we also record bid-level data from the traffic sources and trackers like Binom or Keitaro. Client-owned data is exported raw and stored before any optimization work begins. That baseline is the only honest starting point.

  • Web development case studies: Lighthouse scores, Core Web Vitals, page weight, build times.
  • SEO case studies: organic traffic, keyword rankings, backlink profiles, crawl stats.
  • Arbitrage case studies: ROI per source, landing page conversion rates, click fraud filters.

Verification and Sourcing Standards

We do not cherry-pick time frames. A case study covers a clearly defined start and end date. If we exclude a month because of a seasonal anomaly, we say so. We also document any changes outside the tested variable – server migrations, Google algorithm updates, competitor ad spend shifts – and note how they might affect the results.

Internal data is cross-checked by a second team member. For revenue figures, we compare analytics revenue against payment processor reports. If the two do not match within 2%, we flag the discrepancy and explain it.

What We Don’t Publish

We skip cases where the data is incomplete, where a client revoked permission after the fact, or where the testing environment was so controlled that it would mislead a real-world reader. Sample size matters too. A two-day spike from 10 visitors does not make a case study. We set a minimum of 500 unique visitors per variant for A/B tests and a full business cycle for seasonal SEO work.

Updates and Corrections

If we later discover an error in a published case study – a tool gave us a wrong metric, or a client changed their site after the study period – we update the page with a note at the top explaining what changed and when. No silent fixes. You can see every correction in the page’s revision history.

All our published articles, case studies, and guides follow this same framework. It’s the only way I’d trust the work if I were on the other side of the desk.