Practical guide
Build a Daily Site Summary From Supplied Event Files
A polished daily total can hide a broken source file.
One repeated event can raise a count. One malformed row can disappear during cleanup. One output saved over an earlier report can erase the comparison you needed. The table still looks tidy, but you cannot explain where its numbers came from.
If you already have event files, define the reporting job before choosing a larger analytics system. The smaller question is whether those files can become a daily pageview and custom-event summary you can inspect.
Start after the events already exist
This job begins with supplied JSON or NDJSON. It does not gather activity from a website.
Each record must identify its site, event, recorded time, and event kind. Pageview records can carry a page path, referrer, and device label. Custom-event records can carry an event name. The complete input is checked before any summary is written.
A repeated event identifier stops the transformation. So does an invalid record. That behavior matters because partial processing would leave you wondering which rows reached the total.
The file location also has a clear boundary. Inputs and outputs stay inside one private working folder. Parent-folder escapes, absolute destinations, linked paths that point elsewhere, and existing output names are refused. A new report cannot silently replace the previous one.
Turn records into daily counts
Valid events are sorted by their recorded time and identifier. They are then grouped by site and by the date in the supplied timestamp.
For each date, the summary counts two things:
- pageviews;
- custom events.
The JSON output also organizes page paths, referrers, device labels, and custom-event names into bounded daily counts. A separate monthly CSV contains three columns in date order: date, pageviews, and custom_events.
Those outputs answer a narrow reporting question. You can compare the source inventory with the JSON totals, then use the CSV as the daily table for one site and month.
The same input and reporting time produce the same JSON and CSV bytes. That makes a corrected source file easy to compare with its earlier version without claiming that the process remembers prior runs.
Read the raw-data rule before using the summary
Every valid event in the supplied file contributes to the daily counts. The JSON output keeps raw event bodies only for its most recent 30-day window. Older records can remain represented in the daily totals even when their raw bodies are absent from that output.
That distinction changes the fit. Use the daily table for aggregate review. Keep the original source file when you may need to inspect an older individual record.
The date also comes from the canonical timestamp already present in the event. This mechanism does not establish a separate timezone conversion. Resolve that field before comparing its days with another report.
Keep Simple Analytics and the file summary separate
Simple Analytics describes its service as recording page-level events and aggregating them. Its events documentation covers counts for named events. Its export guide explains raw-data exports through its interface or APIs, including CSV output.
The file summary starts later. It does not enter a Simple Analytics account, request an export, or prove that a vendor export matches the required input fields. Map the exported fields to the expected event shape before using them together.
This approach fits when the source files already exist, one person owns the reporting question, and daily pageviews plus custom-event counts are enough.
Choose a broader analytics service when the real job includes gathering website activity, continuous reports, a live dashboard, visitor journeys, attribution, shared access, or automatic bot handling.
Takeaway
A dependable daily summary needs a defined source boundary, whole-file validation, traceable counts, and output files that preserve earlier comparisons. Supplied event files can cover that job when the report ends with reviewable JSON and a three-column CSV.
Define the table before processing the file
Write the three output columns first: date, pageviews, and custom_events. Then map each supplied event field to one date and one event kind. If any row cannot make that mapping without guesswork, resolve the source definition before calculating the report.