Do Faces in YouTube Thumbnails Drive Views?, Replication Package

A Hitfactor Labs study on whether thumbnails with a human face (and more faces) correlate with higher views-per-day, measured within the same channel so the result is not just "big channels use faces."

This repository is the public replication package for the study. It exists so anyone can audit the design, check that it was pre-registered before we looked at outcomes, and re-derive the published charts from the released aggregate tables.

What's here

File / dir	What it is	When published
design-spec.md	The study design: question, unit of analysis, clustering, confounders (DAG), the locked holdout, and the detector-validation gate.	At pre-registration, before any outcome data was analyzed.
preregistration.md	The pre-registered analysis plan: hypotheses, exact statistical methods, outlier rule, practical-significance thresholds. Committed and tagged before the first query touching views.	At pre-registration.
aggregates/	The binned / decile tables behind every chart in the published report.	At publication.
dataset/	A de-identified, row-level dataset (see "The dataset" below) so you can re-run our statistics yourself.	At publication.
report.md	The written study (prose + key takeaways), mirroring the interactive page on hitfactorapp.com.	At publication.
methodology.md	Full methodology and disclosures.	At publication.

The pre-registration timestamp

The v0-preregistration git tag marks the commit of design-spec.md + preregistration.md that was published before any view/views-per-day data was queried. That tag is the audit trail: it is what lets a skeptic verify the analysis plan was fixed in advance, not reverse-engineered to fit a result we'd already seen. (See the "prior exposure" disclosure in design-spec.md for the one honest caveat: a small internal exploration on three channels predates this study; those channels are excluded from the held-out test set.)

The dataset (de-identified, methods-reproduction)

When the study publishes, dataset/ contains row-level data so you can re-run our statistics, not just re-plot our charts. Each row is one video:

video_hash, channel_hash, has_face, n_faces, vpd, publish_quarter, niche

The YouTube IDs are removed. video_hash and channel_hash are keyed HMAC-SHA256 hashes computed with a secret salt we do not publish. This is deliberate and it does two things:

• It preserves what you need to check our method. Rows that share a channel_hash belong to the same channel, so you can reproduce the load-bearing part of our analysis: the within-channel contrast, the channel-clustered confidence intervals, and the bootstrap that resamples channels. You can recompute every number, re-run the clustering, and catch a coding error or a questionable specification.
• It removes what would make this a YouTube ToS violation. A keyed hash is one-way in practice (YouTube IDs are short and enumerable, so a plain hash would be reversible by anyone; an HMAC with an unpublished salt is not). With no recoverable resource IDs, a row is a point in a distribution, not republished YouTube API data.

Honest about the limit: this dataset reproduces our method, not our measurement. Because the IDs are hashed, you cannot pull the thumbnail or re-fetch the view count, so you cannot independently verify that a given has_face label or vpd value is correct. You can verify "given these numbers, is the statistics sound?" but not "are these numbers true?" Our defense of the measurement is the detector-validation gate described in methodology.md (we hand-label a VPD-stratified sample and show the detector's error does not correlate with views), not the dataset.

Re-identification is not a realistic risk. vpd is a point-in-time snapshot, the exact views at the moment we captured them. That instant is unrepeatable, so no one can reconstruct which real video a row is by matching view counts against their own copy of YouTube.

Why we don't release the raw data or real video IDs

This is not a preference, it is the YouTube API Services Terms / Developer Policies. Publishing a dataset that keys real YouTube video/channel IDs to derived columns runs into:

• III.E.4.h, you may not use API Data "to create new or derived data or metrics" (a public ID-keyed dataset of our derived face features is exactly that pattern), and
• III.E.2, you may not aggregate API Data across channels you don't own, or to gain insights into YouTube's business.

The resource ID is the hook those rules hang on. Strip the IDs (via the keyed hash above) and the data leaves that category while staying useful for statistical replication. We verified this against the current policies before release; the ToS can change, and we re-check per study.

How to replicate

• Re-plot the charts: each chart in report.md cites a table in aggregates/ (plain CSV); re-plotting reproduces the figures exactly.
• Re-run the statistics: the dataset/ rows + the pre-registered analysis plan (preregistration.md) + methodology.md specify every filter, transform, and test. Group by channel_hash, apply the within-channel same-period contrast, bootstrap over channels, and you should recover our headline number and its interval.

Citation

Hitfactor (2026). Do Faces in YouTube Thumbnails Drive Views? hitfactorapp.com/labs/thumbnail-faces