Hi Jeff,
Thanks for confirming, that explains it. With retention at 180 days the nightly job at midnight removes detail rows older than the cutoff. 180 days back from today lands at the end of January, which matches what you are seeing.
1. Change the setting before you restore anything
WP Statistics → Settings → Advanced Options, “Purge Old Data Daily” section, set the retention dropdown to “Keep data forever” and save. If you put old rows back while it still says 180 days, tonight’s run deletes them again.
2. Check what you may still have
The cleanup does not touch the daily totals table. If you were on 14.16 or newer through that period, your per day visitors and views may still be there:
SELECT date, visitors, views FROM wp_statistics_summary_totals ORDER BY date;
(adjust wp_ to your prefix). No per page or per referrer breakdown, but it usually covers the trend line a leadership report needs, without restoring anything.
3. Merging the old data back
It works, with care:
– Load the 18 Jan 2026 backup into a separate database, not your live one.
– Find your live cutoff first: SELECT MIN(last_counter) FROM wp_statistics_visitor;
– Copy only rows older than that cutoff, so nothing overlaps. Tables and date columns: wp_statistics_visitor (last_counter), wp_statistics_pages (date), wp_statistics_visitor_relationships (date), wp_statistics_exclusions (date).
– Example: INSERT IGNORE INTO live.wp_statistics_visitor SELECT * FROM backup.wp_statistics_visitor WHERE last_counter < '2026-01-29'; If the backup came from an older plugin version the columns may differ, in that case list the column names explicitly.
– Keep the original row IDs. The relationships table points at visitor and page IDs, so renumbering breaks the links. Your surviving live rows were all created after 18 Jan, so their IDs are higher and should not collide.
– Test on a staging copy and take a fresh backup of live before writing anything.
On coverage: since the 180 day setting was already active, the January backup should reach back to roughly July 2025 and the May backup to roughly November 2025. So January is the one that matters for the older history, and May can fill the gap between them.
One correction to make afterwards: each cleanup run adds what it removed into wp_statistics_historical as a running total. If you re-import the detail rows, those get counted twice in all time figures. After the merge, review that table and reduce or clear the rows the cleanup added.
4. Your feedback
Fair points and I will pass both on. “Keep data forever” is already an option, but the default is 180 days and the control sits low in Advanced Options, which is exactly how you got caught. In recent versions the job aggregates rather than simply deletes, so all time visitors and views survive while the detailed rows go, and we should say that clearly where people can see it. It is not quite free to keep everything, on busy sites those tables grow into millions of rows and reports slow down, which is why a default exists at all. But the value should be visible up front rather than buried.
Best
