Decentralised News · AI · Decision research
By Heath Muchena · Source review 2026-11-14 · Instrument version 1.0.0
What Matters
A request, impression, citation, session and sale are different events. Before adding counts, calculating an outcome rate or comparing periods, reconcile the unit, definition, population, window and linkage. Preserve unavailable values. The original DN instrument performs only the arithmetic supported by the entered relationships; it never converts traffic into agent headcount or causally attributed revenue.
The most misleading number on an AI-traffic dashboard may be one that was calculated correctly from incompatible inputs. A crawler total can be added to a referral total, or purchase events divided by sessions, without the resulting figure answering the question its label promises.
This article supplies a source-to-metric reconciliation method. It does not propose another dashboard score or claim that DN has run a traffic experiment. Its original local instrument checks whether a particular sum, outcome rate or period comparison follows from the stated measurement contract.
DN Evidence Block
Sources reviewed: 2026-11-14 · Evidence type: Current official Google Search Console, Google Analytics and Cloudflare definitions, plus an original reconciliation method. Sources checked 13 November 2026 UTC, corresponding to the 14 November editorial review in South Africa.
Scope: Count-based reconciliation for requests, impressions, sessions, attempts, orders, answers and users. No live property access, causal attribution, revenue calculation, agent identification or platform ranking.
- Current source definitions and aggregation can differ across analytics systems.
- Outcome-rate arithmetic requires a linked subset of the same eligible entities.
- An unavailable source value must remain unavailable even when an export stores it as zero.
Not established by this work: No DN analytics account, live traffic export, crawler identity, citation experiment, order or affiliate commission was inspected. All worked records are synthetic and demonstrate local arithmetic and evidence gates only.
Original DN instrument · version 1.0.0
DN Measurement Reconciliation Record
Check two measurement records before adding disjoint counts, calculating a linked session/attempt outcome rate, or comparing equal-length windows. Preserve incompatible or unavailable results as unknown.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
Counts only, with no currency totals, weighted scores, rate averaging or automatic exposure normalization. A subset rate is limited to linked sessions or attempts. Whole-entity counts and user-entered compatibility declarations do not establish data collection quality, causal effect, agent identity, complete coverage or revenue attribution. Calendar-day and timezone-label checks cannot resolve daylight-saving effects or incomplete collection. No external system or personal session data is accessed.
1. Name the event and the unit before naming the channel
Write what happened before writing AI traffic. A server received a request; a search feature displayed a link; a sampled answer cited a page; a session began; an authorized attempt completed; or a transaction was recorded. Those are separate observations.
A request count is not an agent headcount. A citation count is not a visit count. A purchase-event count is not necessarily a count of sessions containing a purchase. A useful dashboard keeps the original unit visible even when the values sit beside one another.
Reconcile: metric name, event definition, unit, source, population, observation window and missing-value status. The DN instrument deliberately accepts whole counts rather than money or percentages. This prevents a shared numeric format from making unlike measurements appear interchangeable. A result with an unresolved unit remains unknown.
2. Separate the verified operator from the user and the behavior
Cloudflare’s current Verified bots documentation says signed agents are included in Verified, with Direct and Intermediary access describing who can operate them. An intermediary’s operator and end user are different parties. A bot may have more than one behavior category.
Reconcile: the classification version, request identity and behavior labels used by the source. Do not add overlapping behavior totals as though each request belongs to exactly one category. Do not treat verification of an operator as evidence of an individual purchaser or a completed sale.
A change in taxonomy can look like growth if yesterday’s signed-agent count and today’s Verified count have different boundaries. Retain the old and new definitions before interpreting the movement. The instrument cannot establish identity from a user-agent string; it only records whether the supplied populations and definitions are compatible.
3. Distinguish search impressions from a sampled citation rate
The current Google Search Console generative AI performance report covers impressions in AI Overviews and AI Mode. An impression is not a click or sale. This is more specific than the older claim that only combined Search totals are available.
A research team may separately ask a fixed prompt set and record whether answers cite its articles. That produces a result for the sampled prompts, models, dates and answer versions. It does not become a population-wide citation share merely because the tool calls it visibility.
Reconcile: whether the numerator counts displayed links, cited answers, citation instances or successful retrievals. One answer can contain several citations. A rate of answers citing a page therefore needs distinct eligible answers as its denominator. Keep that custom research measure separate from a platform’s impression definition and from measured website sessions.
4. Match the aggregation level before checking the total
In the Google report, a property-level chart and page-grouped table can use different aggregation. Their totals may differ for that reason. A discrepancy does not automatically indicate missing tracking.
Reconcile: the grouping key and the duplicate-counting rule. Does a property appear once per eligible display while two of its pages appear in separate table rows? Are two source rows different events, or two views of the same event? Record the answer before summing them.
The tool requires a documented disjoint population for addition. It also rejects a disjointness declaration that uses the identical population label for both slices. Distinct labels do not prove disjointness; the source evidence must still establish it. This is a guard against an obvious inconsistency, not a replacement for deduplication.
5. Align timezones, observation windows and comparison exposure
The Google report’s date dimension uses Pacific Time. A same-date label in another system can cover different hours. Align the underlying windows before comparing or joining them.
Reconcile: start, end, timezone, collection coverage and whether the period is still preliminary. For a sum or subset rate, the instrument requires the same recorded window. For a change, it requires a later non-overlapping window with the same number of calendar days and a user-declared comparability assessment.
Equal calendar length is only an entry gate. Daylight-saving changes, weekdays, promotions, seasonality and interrupted collection can still matter. A seven-day interval with two missing collection days is not equivalent to a complete week. The tool performs no exposure normalization, fills no gap and does not infer that a chronological change was caused by an editorial or technical intervention.
6. Keep user, session and event scopes distinct
Google Analytics documents user, session and event scopes separately. A first-user acquisition dimension, a session source and an event-related attribution field can answer different questions even when each displays the same channel name.
The sessions documentation also describes how events associate with session identifiers and notes that some collection routes do not attach those identifiers automatically. The presence of an event in an export should not be assumed to establish the session relationship a proposed ratio requires.
Reconcile: the exact dimension and metric names, filters, identity assumptions and collection method. Keep a source-specific metric in its original scope until a documented transformation produces the new one. The local checker cannot inspect tags or Analytics settings; a compatible label is a claim that needs retained evidence.
7. Build a conversion rate from linked entities, not unlike counts
GA4’s session key event rate divides sessions containing a key event by total sessions. It does not divide the number of event firings by sessions. For a purchase-specific analysis, define the purchase outcome and count each eligible session at most once in the numerator.
Synthetic example: 12 distinct sessions with at least one purchase among 200 eligible sessions produce a 6% session outcome rate. Twelve order events among 200 sessions do not establish that rate: several orders could occur in one session, and some events may not be linked to the eligible population.
An attempt-completion rate follows the same discipline: completed eligible attempts divided by eligible attempts, with explicit linkage and one outcome per attempt. The instrument accepts these two bounded rate types, requires the numerator to be a subset, rejects a numerator above its denominator and withholds a percentage when the denominator is zero.
8. Preserve unavailable values when exports encode them as zero
Google’s report export documentation warns that unavailable values shown as ~ or - become zeros in downloaded data. Preserve that status when importing the file. A zero in a spreadsheet may not mean zero observed activity.
Reconcile: the original cell status, export format, retrieval time and any transformation. In the instrument, a reported zero is a valid count. An unavailable or unknown value stays unusable even if its numeric field contains zero. The export retains the entered status alongside the number.
For comparable-period change from a genuine zero baseline, an absolute difference can be calculated, but relative percentage change is undefined. That is different from a missing baseline, where neither change is supported. Replacing both with a convenient zero conceals the distinction and can manufacture an apparent increase.
9. Prove disjointness for a sum and comparability for a change
Two labelled synthetic request slices of 120 and 80 can be added to 200 only when they use the same definition and window and are disjoint. If both include the same request, addition double counts it. If one counts requests and the other counts sessions, the sum has no useful common unit.
A different operation compares an earlier count of 100 with a later count of 120. Under a supported, unchanged population definition and comparable windows, the absolute change is 20 and the relative change is 20%. That arithmetic does not reveal the mechanism behind the movement.
Reconcile: the intended operation before choosing inputs. The same two numbers may support one calculation and fail another. DN’s checker has no generic combined score and no option that silently mixes units. It exports the requested operation, source records, declared relationships and withheld-result reasons so a reviewer can reproduce the decision.
10. Keep commercial outcomes separate until the relationship is evidenced
A page can be crawled, cited and visited without producing a sale. A purchase can occur after research that leaves no useful referral signal. Placing those series on one chart does not create an observed path between them.
Reconcile: the event that supports the commercial claim. A recorded order, a refunded order, an attributed sale and a validated affiliate commission are different states. Retain the relevant source and status rather than calling every early-stage event revenue. The count instrument does not add money, settle attribution or validate commissions.
Use a linked cohort when the research question requires a conversion path, and state the coverage gap when linkage is incomplete. Separate observed association from an incremental effect that needs a suitable causal design. A useful dashboard can end with unknown: it identifies the next evidence to collect instead of presenting a precise commercial story built from unrelated totals.
Methodology, limitations and corrections
DN’s original measurement contract uses two records with explicit count unit, reported/unavailable status, dates, timezone, population and source. The input value is either a whole nonnegative count or null. An unavailable zero is preserved as entered but excluded from arithmetic. The tool accepts no currency amount or percentage as a count.
| Operation | Required relationship | Calculation |
|---|---|---|
| Sum | Same unit, definition and exact window; documented disjoint population slices | A + B |
| Subset outcome rate | Linked sessions or attempts; A is an outcome subset of B; same cohort window; B greater than zero | 100 × A / B |
| Period change | Same unit and population definition; later non-overlapping, equal-length calendar window; explicit comparability evidence | B − A; relative change is 100 × (B − A) / A when A is greater than zero |
The checker requires the same timezone label and does not convert times. Period change is intentionally narrower than every possible statistical comparison: unequal observation exposure must be normalized and justified outside this count instrument. Matching dates do not prove matching collection coverage. The source, filter, attribution and population decisions remain the user’s assertions.
Examples are synthetic: the linked session case is 12 / 200 = 6%; the disjoint request case is 120 + 80 = 200; the comparable-week case is (120 − 100) / 100 = 20%. An order-event numerator against a session denominator is withheld, as is an unavailable zero baseline. No dashboard, property or merchant was tested.
The local JSON export preserves the original records, declared relationships, evidence reference, calculated values or unknowns, explanatory findings and creation timestamp. It contains no personal session or user identifiers. Version 1.0.0, 14 November 2026: original count reconciliation method, tested with synthetic fixtures. Source checks were completed on 13 November UTC.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version 1.0.0, 2026-11-14. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Can I add crawler requests to AI referral sessions?
No. They are different units and events. Show them separately unless a documented transformation answers a clearly defined question; the instrument does not invent that transformation.
Does a Verified agent count tell me how many shoppers used it?
No. Operator classification and request counts do not establish a count of distinct end users or purchasers.
Why does the tool reject orders divided by sessions as a conversion rate?
An order-event count may include several events in one session or events outside the eligible session population. Count distinct eligible sessions with the defined purchase outcome and retain their linkage instead.
What is the difference between zero and unavailable?
A reported zero says the measured count is zero under the source method. Unavailable means the count is not supplied. The instrument preserves that distinction even if an export represents an unavailable cell numerically as zero.
Can two equal-length weeks still be incomparable?
Yes. Collection gaps, changed definitions, consent coverage, daylight-saving effects, promotions and seasonality can matter. The date check is only one gate; a separate comparability judgment is required.
Does a calculated rate prove AI caused the sale?
No. It describes the entered linked population. Incremental causation, commercial attribution and validated revenue require additional evidence and an appropriate research design.
Primary sources
- Google Search Console: Generative AI performance report (Search). Current impression scope, PT dates, property/page aggregation, preliminary data and unavailable export values represented as zero. Reviewed 2026-11-13.
- Cloudflare: Verified bots. Current inclusion of signed agents, Direct/Intermediary access and potentially multiple behavior categories; operator is not end-user headcount. Reviewed 2026-11-13.
- Google Analytics: About Analytics sessions. Session definition and event/session identifier association, including collection-route limitations. Reviewed 2026-11-13.
- Google Analytics: Scopes of traffic-source dimensions. User, session and event scope distinctions; acquisition dimensions are not interchangeable. Reviewed 2026-11-13.
- Google Analytics: Traffic acquisition report. Session key event rate counts sessions containing the event divided by sessions, rather than event firings divided by sessions. Reviewed 2026-11-13.
- Google Analytics: Analytics dimensions and metrics. Metric compatibility and distinct event, session and user count/rate definitions. Reviewed 2026-11-13.
Turn the finding into a decision
A publisher or merchant can bring a disputed dashboard claim and its source definitions to the DN Research Desk for a bounded reconciliation brief. Agree the data access, permitted use, deliverable and quote before work begins. Buying an integration tool does not resolve incompatible populations or missing linkage, so no automation affiliate is inserted into this measurement decision.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
