Boloop-made explanatory illustration: site events, GA4 sessions and search clicks observe different activity and time boundaries.
After adding analytics to Boloop, I had several sets of numbers that seemed related but did not line up: the site recorded downloads, GA4 showed only a few sessions, and Search Console showed even fewer search clicks. Getting the reports to return data had made interpretation harder, not easier.
Treat those numbers as different actions by the same people and you can quickly calculate an impressive conversion rate. But we had no evidence that they covered the same visitors. Even their days started at different times. I went back to a basic question for every number: what exactly does it count?
One website, three observation points
Our database records events that occur on the site and satisfy the endpoint’s rules: hosted file downloads, views of original articles, and clicks through to a recommended item’s source. These events sit close to individual features and help answer whether an entry point was used. One download does not automatically mean one distinct reader, or that the file was subsequently installed.
GA4 provides users, sessions, page views, acquisition sources and engagement metrics. On Boloop, browser-side GA4 starts only after a visitor accepts optional analytics. Its observed audience therefore differs by design from that of some site feature events. Expecting an exact match would ignore our own collection choices.
Search Console observes impressions and clicks from the Google Search side. Someone typing the address, opening a link on X, or using a bookmark need not generate a Google search click. A search click cannot directly stand in for a completed reading session either.
The three sources can help explain each other, but they cannot simply be combined into one funnel.
The same date may describe different days
Boloop aggregates site events by UTC day. The GA4 property uses Asia/Shanghai. Search Console reports use their Pacific date boundaries, represented as America/Los_Angeles in our operating records.
For example, a visit just after midnight in Shanghai may already belong to the next GA4 day while remaining in the previous UTC day. Joining the reports on 2026-10-21 alone would compare two sets with different boundaries.
I now retain both the date selected in the interface and the time zone actually used by the source. If the daily email covers complete UTC days while a temporary dashboard query includes today, I keep those ranges separate too. Both saying “last 30 days” is not enough to justify subtraction.
In practice, I start with comparisons within one source: the same metric, time zone and length of complete window. Only when the question requires multiple sources do I examine whether their boundaries can be aligned.
Complete-looking rows may still be provisional
Freshness creates another trap. An API returning dates and values tells us that those rows were available at that moment. It does not establish that the values will never change.
Boloop’s operating process marks the most recent two GA4 days as provisional. For trend comparisons, it conservatively uses property days that ended at least 48 hours earlier. Older values can still be backfilled. Search Console retains its own delay window; a missing date remains unknown instead of becoming a zero that completes a tidy chart.
This adds some waiting to the daily report, but avoids many unsupported claims that traffic suddenly dropped yesterday. A new site already has small samples. Comparing a still-processing yesterday with a more mature earlier day can magnify a small difference further.
Display counts, observed events and organic growth are separate
Boloop has administrator-set initial counts as well as events produced by actual requests. They are stored separately as initial_* and real_*. Initial values do not belong in growth reporting and cannot prove that an article has acquired real readers.
Removing initial values still does not directly produce organic growth. Release checks, browser acceptance tests and ordinary operational work can contribute actual requests. Those requests happened, but they are not evidence of search acquisition.
Nor can daily active users be added together and called unique users for the period: one person may appear on several days. Dividing site download events by GA4 sessions does not establish a download conversion rate either. Without a consistent population, time range and event relationship, the numerator and denominator are merely next to each other.
Four questions I ask before reading a report
For each report, I first check:
- What is the metric: events, sessions, users, search impressions or search clicks?
- What is the scope: source time zone, cutoff date and actual start of coverage?
- What is its state: data available, no records, not integrated, or a failed read?
- How far does this change support an explanation: does it include acceptance traffic or lack a comparable baseline?
A failed read is unavailable; a source not connected is not-integrated; a successful query with no records is no-data. These states do not share a single zero. Otherwise, an external API failure can manufacture a “traffic dropped to zero” event on the chart.
At our October 22, 2026 review, search evidence was still sparse, mainly the brand term and English home page. It was not enough to judge whether a particular page change had produced growth. That did not stop us fixing pages and writing articles; the effect judgment needed to wait.
If you are adding analytics to your own AI project, start with a small metric dictionary listing source, unit, time zone, coverage and limitations. It will reveal which questions you can already answer, and which you cannot, sooner than arranging every number into a beautiful dashboard.