CAT Mock Analysis Excel Template: What It Can and Cannot Do

A spreadsheet logs a CAT mock's score, section-wise breakdown and percentile in under a minute, and that part never breaks. Three specific jobs around that log do break, and they are the reason "cat mock analysis excel sheet" searches keep turning up generic productivity templates with nothing CAT-specific in them: chaining a revision due-date off whenever the previous pass actually finished rather than the mock date, flagging a section whose rolling average has quietly stopped moving, and keeping a study session reliably linked to the one mock instance it was actually about. None of the three is a spreadsheet limitation in principle - Excel can compute all of it. All three are limitations of maintaining formulas by hand for a year, which is the actual failure mode.

This is a narrower, mock-specific sequel to the general study-tracker-versus-Excel argument already on this site - that post covers daily session logging, streaks and heatmaps. This one is about the mock-analysis layer specifically: the part of a CAT prep tracker that has to remember which test something belongs to, and what happened to it since.

What a spreadsheet gets right here, without qualification

• Logging one mock's numbers is trivially fast. Date, provider, overall score, overall percentile, then score/attempted/correct/percentile per section. A row, thirty seconds, done.
• It is free and it is yours. No account, no product roadmap deciding your data model for you.
• For under about ten mocks, none of what follows matters yet. The three failure modes below are all about accumulation - they do not show up on mock three, they show up on mock fifteen.

So the honest scope of this post is narrow: a spreadsheet is a fine mock-score ledger. It is a poor mock-analysis system once "analysis" means cross-referencing a mock against its own revision history and against every other mock's section trend.

1. Revision due-dates are a chain, and a sheet cannot chain itself

Karma Yogi's spaced-revision schedule for a mock runs R1 three days after the mock date, then R2 seven days after R1 was actually completed, R3 fourteen days after R2, then 21, 30, 45 and 60 days after each preceding round. The load-bearing word is after R2 was actually completed - not after the mock date. A round finished five days late pushes every later round back by the same five days.

In a spreadsheet, that is a lookup chained onto a lookup: R2's due date needs R1's actual completion date, which itself needs to be typed in when it happens, not assumed from a schedule. Model it wrong - due dates as mock-date-plus-3/10/24/45/75/120/180, which is what a fixed-offset formula naturally produces - and the sheet systematically overstates how overdue you are the moment a single round slips, which is exactly the failure this site's own excel-vs-app post documents from personal use. The correct version needs one column recording when each round actually finished and a formula referencing the previous row's actual date, not the mock's. Multiply that by twenty mocks and seven possible rounds and you are maintaining 140 potential due-date cells, each dependent on a completion date somebody has to remember to type in.

2. A plateau does not announce itself in a raw score column

This is the specific failure that a raw per-mock score column hides, and it is not hypothetical - it is this site's own logged data. Across 20 real CAT mocks, DILR moved from an 18.4 average across the first five attempts to 20.6 across the last five - two marks in three months - while VARC and Quant gained 8.2 and 8.8 over the same span. A straight line through all 20 DILR scores against the date has a slope of +0.16 marks per 30 days, r-squared 0.000. The overall mock score, meanwhile, climbed the whole time, because VARC and Quant were carrying it.

Catching that DILR flatline requires a rolling section average (a five-mock moving window, recomputed every time a new mock is added) compared against a threshold, or at minimum a chart per section you actually look at rather than one combined score. A spreadsheet can absolutely compute a rolling average - =AVERAGE(OFFSET(...)) or a plain shifted range - but the range has to be extended by hand every week, and a range that silently stops at row 18 while you are on row 22 does not throw an error. It just quietly shows a trend that stopped updating a month ago, which is the actual reason this went unnoticed for roughly two months in this site's own log.

3. Linking a session to one specific mock instance has no natural key in a flat sheet

Analysing a mock is rarely one sitting. A real revision pattern is: log the mock, analyse it the same evening, revise it again three days later, again a week after that. Each of those is a separate study session, and each has to point back at the same mock - not "a DILR mock," a specific one, dated, with its own scores.

Karma Yogi's data model makes this an explicit link: every session that carries a revisionRound also carries a linkedTestId and linkedTestType pointing at exactly one FullMock or SectionalTest record, so R0 (the test itself), R1, R2 and so on for the same mock can all be found by that one ID regardless of how many weeks apart they happened. A spreadsheet has no built-in equivalent - you invent an ID scheme yourself (a "Mock #" column, typed by hand into both the Tests sheet and every related Sessions row) and it has no referential integrity: a typo, a copy-paste that shifts one row, or a mock you renamed after the fact breaks the join silently. The formula does not error. It just quietly matches nothing, or worse, matches the wrong mock.

If you are building a CAT mock-analysis sheet anyway, build it like this

Two sheets, not one wide one, so the joins above are at least possible:

Rules that matter more than the column list itself: never reuse or renumber a Mock ID once assigned; record the date a round finished, not the date you meant to do it; and keep raw score and percentile in separate columns per section - never average across providers, since an identical section score has landed anywhere from the 65th to the 90th percentile on different papers in this site's own log, a 25-point spread on the same number of marks.

Where this is weak

The DILR-plateau numbers are one aspirant's log, not a general finding. 20 mocks over three months shows what a raw-score view hid in one case. It does not establish how often this happens to other CAT candidates, or with what frequency a plateau would actually be missed rather than noticed on a quick scan.

I have not run a live comparison of what actually ranks for "cat mock analysis excel sheet." A search attempted for this post returned results dominated by the unrelated "cat" (the animal) rather than the exam, which made a clean SERP read impossible today. The reasoning above - that CAT-specific mock-analysis content is thin and mostly generic-template or coaching-forum advice - is inference from the adjacent "study tracker excel template" gap already documented on this site, not a verified live result for this exact phrase.

None of the three failure modes are impossible in a spreadsheet, only effortful to maintain without them silently going stale. A disciplined spreadsheet user with fewer mocks, or more patience for formula maintenance, may never hit any of this.

Karma Yogi keeps the Mock ID link, the revision due-dates and the per-section rolling trend as product features rather than formulas you maintain - see why mock scores plateau and what the evidence supports about the revision schedule itself for the rest of this argument.