Practical guide
When an Event-File Summary Is a Poor Fit
A fictional marketing report looks polished at 8:03 on Wednesday morning. Every pageview and custom event in Tuesday’s file has a place. The totals add up. Wednesday’s first visitor never enters the report.
The report did its assigned job. The missing visitor exposes a different one.
An event-file summary can organize supplied rows. It cannot collect the next row, receive remote traffic, host an interactive view, reconstruct exact sessions, or govern team access. If any of those duties drive the decision, the file is too small for the job.
A summary begins where collection ends
An event-file summary begins after collection has ended. Someone or something has already gathered pageviews and custom events, formed a JSON or NDJSON file, and placed it where the transform can read it.
The bounded file job validates that input before writing. It rejects duplicate event IDs inside the batch, sorts the events, groups them by site and day, and counts pageviews, custom events, pages, referrers, devices, and custom-event names. It can write a stable JSON rollup and a monthly CSV with dates and two totals.
Those files answer aggregate questions about the supplied set. They do not explain how the next event arrives.
Simple Analytics describes a wider service process. Its methodology says a browser script sends a page-level event for each pageview. Its event documentation covers custom browser events. Its server-side guide describes JSON submissions to an event endpoint. Collection happens before an aggregate can exist.
Five verbs the event file does not own
This poor-fit matrix follows the work around the summary. Each proof card starts with a verb the file does not perform.
Collect in the browser
Question: Must the analytics setup record a new pageview, download, form submission, or button click inside the website?
Simple Analytics documents a browser script for pageviews and separate event functions for custom actions. The file transform contains no browser script. It waits for events that have already been supplied.
Decision: Keep a browser collection method when observing new visits is part of the requirement. A flawless summary of yesterday’s file still misses today’s unsupplied traffic.
Receive through an API
Question: Must a website, mobile app, or server send event data to a remote destination as activity occurs?
Simple Analytics documents server-side JSON submissions to its event endpoint. The file transform reads one file from its working folder and makes no network request.
Decision: Keep an ingestion service when remote intake is the recurring job. Moving an exported file by hand does not replace an endpoint that receives new data.
Filter in a live dashboard
Question: Must a marketer change filters, inspect events, compare views, or revisit a shared screen after more data arrives?
Simple Analytics describes dashboards, filters, events, goals, exports, and APIs for working with collected data. A JSON rollup or CSV is a static result. Changing the question means reading the file another way or producing another output.
Decision: Keep an interactive analytics surface when changing the view matters more than one predetermined summary. A file fits a known report. It strains when every answer creates the next question.
Connect events into sessions
Question: Must the analysis reconstruct one person’s path across pages or visits?
The file transform emits no session, visitor, identity, bounce, or journey field. It counts supplied pageviews and custom events without linking them to a person.
Simple Analytics draws its own boundary here. Its methodology says events remain independent and are not linked across visits. It describes visitor and session metrics as estimates, and it says user-level tracking across sessions is outside its primary fit.
Decision: Use a different evidence source when exact session reconstruction or user-level journeys are required. Neither a daily event rollup nor an unlinked page-event model proves that sequence.
Share governed access
Question: Must owners, analysts, developers, finance staff, and viewers see different websites or perform different actions?
Simple Analytics documents account roles with different permissions for settings, dashboards, goals, events, exports, and website access. The output files contain no login, role, permission, or shared account control.
Decision: Keep a governed team surface when access rules belong inside the analytics job. Sending copies of a CSV may distribute data, but it does not control what each recipient can view or change later.
The smaller file job still has a clean use
The file job fits a report with a settled input and a settled question.
A content strategist can compare page counts from one supplied day. An agency reporter can reconcile the JSON rollup with a monthly CSV. A site owner can correct one event and check which aggregate changes. A marketing analyst can inspect page, referrer, device, and custom-event totals without asking the file to collect anything new.
That boundary keeps the result honest. The summary says what appears in the input. It makes no claim about traffic that never reached the file, people behind the events, or questions the output was not designed to answer.
The decision in one sentence
Use an event-file summary for bounded aggregation of supplied data. Reject it when the job includes observing, receiving, filtering, connecting, or sharing analytics activity as an ongoing service.
Run the blank-hour test
Choose one ordinary hour when nobody will prepare or move an event file. Write down every analytics question that still must be answered during that hour. Mark each question with one verb: collect, receive, filter, connect, or share. Any marked question identifies a service responsibility that the event-file summary cannot own.