We track our own traffic as monthly snapshots, and the recording method matters more than the dashboard. Our traffic overview tool stores one row per month with seven columns, refuses to show a trend when it has no valid baseline, and replaces a month on resubmission instead of keeping both. Each of those decisions prevents a specific bad habit in manual analytics. This article lays out the snapshot method, the rules the tool enforces, and the failure modes you accept when your history lives in a browser.
Why one row per month beats a dashboard you never open
A monthly snapshot forces a decision about what counts. You pick seven numbers, you write them down, and you close the tab. The alternative, an analytics account with unlimited history, tends to produce no recorded conclusions at all, because the data is always available and therefore never summarized.
The snapshot also fixes the unit of comparison. Months differ in length and in seasonality, and the tool compares each month to the month before it in the sorted table. That comparison is crude. It is also honest about being crude, since it shows one percentage and asks for nothing more.
The seven columns and where each number comes from
Each row holds month, sessions, users, pageviews, bounce rate, average session duration in seconds, and primary source.
Month is a year and month pair you select from two dropdowns. The year picker offers 6 options, running from three years before the current year to two years after. Sessions, users, and pageviews are whole numbers you copy from your analytics property. Bounce rate accepts a percentage capped at 100. Duration accepts seconds, and the tool renders stored values as minutes and seconds in the table.
The primary source column is one text field. It holds the channel that led the month, and it cannot hold a split. That is the deliberate constraint. If your traffic splits between two channels, you write the larger one and you note the split somewhere else, or you record the month twice in your own notes with two sources and add them yourself later.
Resubmission replaces, and that is the correction path
The tool de duplicates by month. When you add a snapshot for a month that already exists, the new entry replaces the old row entirely. There is no version history and no undo.
Use this rule as your correction path. When analytics recalculates a month after spam filtering, re enter the corrected numbers and the row is replaced. Never keep two rows for one month by shifting a date, because the month over month comparison reads the sorted table and a duplicate month breaks the pairing.
The replacement rule has a cost worth stating. If you enter a month by mistake and save over a correct row, the original numbers are gone. Export the CSV before any bulk correction session.
When the tool refuses to show a trend
The month over month change appears only when the previous month value is above 0. For the newest row in an empty history, and for any month following a zero month, the tool shows a dash instead of a percentage.
This is the honest rule in the title. A percentage change from a zero baseline is undefined, and many tools silently substitute a large number or a zero. Showing a dash keeps a small site honest, including ours during a month with negligible traffic. A history that starts with a zero month shows no trend for its second month, and the correct response is to wait for a third month, not to massage the zero.
The change value itself is the session difference divided by the previous sessions, shown with one decimal. Only sessions drive the headline change. Users and pageviews carry no trend marker in the table, so read them as levels, and export the CSV to compute their changes yourself.
Export and archive discipline
The export button writes a CSV with the same 7 columns, ordered newest month first, in a file named with the export date. Make the export a monthly ritual with a fixed slot in your checklist, because of where the data lives.
All snapshots are stored in the browser that created them, under one storage key. There is no account and no sync. Clearing site data, switching browsers, or using a private window each start a separate history, and the clear all button deletes every snapshot after one confirmation with no recovery.
The CSV is your only durable copy. Store it next to your other project records, and open it once to confirm the file is not empty.
Steps to run the method each month
1. Open your analytics property and set the range to the finished calendar month.
2. Record sessions, users, and pageviews exactly as reported, without rounding.
3. Record bounce rate and average session duration in the units the tool requests.
4. Name the primary source, largest channel first.
5. Add the row, confirm it sorted to the top, and read the trend cell.
6. Export the CSV and save it with the month in the filename.
7. Once per quarter, open the oldest CSV and compare the level columns.
Checklist for a trustworthy history
1. Every month has exactly one row.
2. Corrected months were re entered, so no stale values remain.
3. A dash in the trend cell means the baseline was 0, and you left it alone.
4. The latest CSV lives outside the browser.
5. Primary source names stay consistent, so month over month reading works.
Start your own record on the [traffic overview tool](https://webrecast.com/en/traffic-overview) and keep the monthly export habit. If your snapshot history caught a change a live dashboard missed, or the one source column cost you a real insight, send us the case. We adjust the method from recorded months, not from projections.
