Month-to-date against last-month-to-date is the right default for a monthly report, because it answers the question a stakeholder actually has: are we ahead of where we were at this point last month?
It goes wrong in three predictable ways.
1. Comparing unequal windows
If today is 31 March, month-to-date covers 31 days. The obvious comparison — all of February — covers 28. February will look worse by roughly a tenth for no reason other than the calendar.
The fix is to cap the comparison window at the same number of elapsed days, and where the months genuinely differ in length, show clicks per day next to the totals. Per-day is the honest number when the windows are uneven.
2. Forgetting the data lag
Search Console runs two to three days behind. A report generated on the 1st of the month that includes "yesterday" is including a day that is not fully counted. The total will rise quietly over the next 48 hours and your report will no longer match the interface.
End the window three days back and say so on the report. A stated cut-off is a feature; a silent one produces arguments later.
3. Reading position as if it averages
Average position across a set of pages is not the mean of the positions. It has to be weighted by impressions, or a page with eleven impressions at position 2 will drag the whole property up.
Weighted properly, a fall in average position alongside a rise in impressions is usually good news — you started ranking for more terms, most of them lower down. Unweighted, the same movement looks like a problem.
What a useful MTD block contains
- Clicks, impressions, CTR and average position for both windows
- The absolute difference and the percentage change
- Days counted in each window, stated plainly
- Clicks per day when the windows differ
- The pages that gained and lost the most clicks
That last line is what turns a summary into something actionable. A total tells you the direction; the movers tell you where to look.