GOCK PUMP FREQUENCY TRACKER — VERSION 7.0

For those new to this thread: I have been maintaining a comprehensive spreadsheet of every credible gock pump report posted on this forum since 2008. Version 1 was a Google Sheet with 140 rows. Version 7 has 2,400 rows across 47 columns of data, 14 pivot tables, 8 correlation matrices, and a custom scoring algorithm I call the Gock Probability Index (GPI).

The spreadsheet is too large for Google Sheets now. I migrated to a PostgreSQL database in 2024. I still call it a spreadsheet because that is what the thread is called and I am not starting a new thread.

Here are the headline findings from v7:

GOCK OCCURRENCE BY DAY OF WEEK:

DAY	REPORTS	% OF TOTAL	GPI SCORE
Monday	298	12.4%	0.71
Tuesday	471	19.6%	1.42
Wednesday	384	16.0%	1.08
Thursday	449	18.7%	1.34
Friday	312	13.0%	0.82
Saturday	289	12.1%	0.68
Sunday	197	8.2%	0.44

Tuesday and Thursday are statistically dominant. Sunday is a gock desert. I have theories about why but they belong in a separate post.

GOCK OCCURRENCE BY TIME OF DAY:

TIME WINDOW	REPORTS	% OF TOTAL	GPI SCORE
5:00 AM - 8:00 AM	188	7.8%	0.52
8:00 AM - 11:00 AM	312	13.0%	0.88
11:00 AM - 2:00 PM	267	11.1%	0.74
2:00 PM - 5:00 PM	384	16.0%	1.09
5:00 PM - 8:00 PM	741	30.9%	2.14
8:00 PM - 11:00 PM	442	18.4%	1.48
11:00 PM - 5:00 AM	66	2.8%	0.19

The 5-8 PM window is the gock golden hour. Nearly a third of all documented gock events occur during this window. Evening pumpers, you have the statistical advantage.

GOCK OCCURRENCE BY EXERCISE TYPE:

EXERCISE	REPORTS	% OF TOTAL	GPI SCORE
Neck curls (cable)	612	25.5%	2.88
Trap shrugs	498	20.8%	2.31
Neck extensions	334	13.9%	1.44
Face pulls	287	12.0%	1.19
Lateral neck flexion	201	8.4%	0.91
Jaw resistance work	156	6.5%	0.68
Reverse neck curls	144	6.0%	0.62
Compound (deadlift/row)	102	4.3%	0.38
Leg exercises	14	0.6%	0.04
Other / unspecified	52	2.2%	0.18

Cable neck curls remain the single most gock-correlated exercise by a significant margin. The leg exercise number is so low (14 out of 2,400) that it is statistically negligible. The gock is a neck and trap phenomenon. The data is unambiguous on this point.

Full dataset download link: [REMOVED BY MODERATOR — file exceeded 200MB attachment limit. Contact SpreadsheetPumper directly for access.]

I just spent four hours going through the v7 dataset and I have some observations.

First: the Tuesday/Thursday dominance is real and it is not an artifact of gym attendance patterns. I cross-referenced with the general forum post volume by day (which serves as a proxy for when people are actually at the gym) and Tuesday/Thursday gock rates are elevated even after controlling for session frequency. The effect size is small but statistically significant (p = 0.003).

Second: I ran a multivariate regression on the top 10 predictor variables and the three strongest predictors of gock occurrence are:

1. Exercise type (neck/trap work vs. other) — beta = 0.44
2. Session minute at onset (40-50 range) — beta = 0.31
3. Time of day (5-8 PM) — beta = 0.22

Together these three variables explain approximately 38% of the variance in gock occurrence. That means 62% is still unexplained. Which is honestly kind of poetic. We can quantify a third of the gock but two-thirds remains mystery.

Third, and this is the finding that kept me up: the GPI score for leg exercises is 0.04. That is not low. That is essentially zero. Out of 2,400 documented gock events, only 14 occurred during leg work. And of those 14, SpreadsheetPumper flagged 9 as "low confidence" in the credibility column. So we might be looking at 5 credible leg-day gock events in the entire dataset. Five. Out of 2,400.

SpreadsheetPumper, I have a request: can you expose this as a read-only API? I want to build a dashboard. I have a React frontend ready to go. Please. I am begging you.

Moderator note: I am pinning this thread (again). SpreadsheetPumper's work is an invaluable resource for the gock community and I want to make sure every new member sees it.

SpreadsheetPumper, on behalf of the moderation team: thank you. Seven versions over seven years. 2,400 rows of meticulously verified data. You have done more to advance our quantitative understanding of the gock than anyone else on this forum. The GPI scoring system alone was cited in three academic papers last year (yes, there are academic papers about gock now, we live in remarkable times).

Regarding the API request from DataGock_Analyst: I have spoken with SpreadsheetPumper privately and we have concerns about making the raw data publicly accessible via API. The dataset contains anonymized but potentially de-anonymizable information about gock events. We need to protect the privacy of gock experiencers. Some of them shared their reports in confidence.

We are considering a compromise: a public API that serves only aggregate statistics (daily/weekly/monthly totals, exercise type breakdowns, time-of-day distributions) without individual row-level data. SpreadsheetPumper is evaluating the technical feasibility. Do not hold your breath but do not lose hope either.

Also: the 200MB attachment limit is a PumpBB limitation I cannot override. I have been asking the PumpBB developers for larger attachments since 2014. They do not respond to my emails. I do not think PumpBB has active developers anymore. I do not think PumpBB has had active developers since 2011. We are running on abandoned software. This is fine.

I am a software engineer. I have been lurking this thread for six months. I want to help.

SpreadsheetPumper, GockAdmin_Primus: I can build the aggregate API for free. I have experience with PostgreSQL, REST APIs, and data anonymization. I can have a read-only endpoint serving aggregate stats within a week. I will open-source the code. I will host it on my own infrastructure. Zero cost to the forum.

Proposed endpoints:

GET /api/v1/gock/daily — daily gock counts
GET /api/v1/gock/by-exercise — breakdown by exercise type
GET /api/v1/gock/by-time — breakdown by time of day
GET /api/v1/gock/by-day — breakdown by day of week
GET /api/v1/gock/gpi?exercise=X&time=Y&day=Z — GPI calculator
GET /api/v1/gock/stats — summary statistics

All aggregate. No individual records. Full k-anonymity with k=5 minimum. Rate limited to prevent scraping. I have done this kind of work before for public health datasets. The gock data deserves the same rigor.

Also: I know a PumpBB developer. He is retired but he owes me a favor. I might be able to get the attachment limit raised. No promises. But I will try.

DM me. Let me help. The gock data is too important to be locked in a PostgreSQL instance that only one person can query.

DataGock_Analyst: your regression analysis is excellent. The 38% explained variance number is consistent with my own modeling. I have been hovering around 35-40% for three versions now and I am starting to think that might be a ceiling. The remaining 62% may be genuinely unexplainable with the variables we are currently tracking. There might be factors we are not measuring. There might be factors we cannot measure.

This is going in the spreadsheet README. This is the most accurate one-sentence summary of seven years of gock data analysis I have ever read.

GockAdmin_Primus: thank you for the pin. And for the kind words. This spreadsheet is my life's work. I say that without irony. I have spent more time on gock data than I have on my actual job. My manager does not know this. My therapist does.

API_Gock_Dev: I am DMing you. Your proposal is exactly what I have been looking for. The k-anonymity approach is correct. The endpoints look clean. If you can actually get the PumpBB attachment limit raised you will be a hero to this entire community. I have 200MB of gock data and nowhere to put it. That sentence sounds wrong but it is the reality of my life.

For everyone else: v7.1 is already in progress. I have 47 new reports from January and February 2026 that need to be verified and added. The dataset grows. The columns multiply. The queries get slower. But the gock does not wait for database optimization. Row 2,401 is coming.

The spreadsheet continues. The data is the data. The gock is quantifiable but not fully. And that might be enough.