Field Notes / Measurement
A form click is not an accepted inquiry
A page view, a contact click, a form start, and a saved inquiry are different facts. The report should keep them that way.
First-party measurement implemented · no business outcome claimed
Someone clicks the contact button. Excellent: something happened. What happened, exactly? That small question is where a useful website report begins—and where a surprisingly large amount of wishful thinking can sneak in.
The receipt test
A click is not a receipt.
The first three events are browser observations. The fourth belongs to the receiving system and is written only with the retained inquiry record.
Browser observations
- Page viewed
page_viewedA supported public page-load event was stored.
Not a unique person, prospect, or human. - CTA clicked
cta_clickedA labeled internal decision link was activated.
Not a completed form or delivered inquiry. - Inquiry started
inquiry_startedThe form received its first focus or input on that page load.
Not validation, submission, or server acceptance.
Nice click. Still no inquiry.
Server acceptance
Retained together
Submission acceptedinquiry_submittedThe inquiry, its event, and the saved reference were retained together.
Not qualification, signed work, revenue, or causation.The process, in four moves
- PageStore a supported page-load observation, not a visitor identity.
- ActionRecord a labeled decision-link click without claiming form completion.
- StartRecord the first form interaction without claiming acceptance.
- ReceiptWrite the retained inquiry and submission event together, then read back its reference.
Use the live names, not the planning names
The current first-party contract uses four exact names: page_viewed, cta_clicked, inquiry_started, and inquiry_submitted. The first three describe browser-side observations. They can tell us that a supported page loaded, a labeled decision link was used, or the inquiry form received its first interaction. None of them establishes that the form passed validation or reached storage.
An earlier operating design used contact_form_submitted and inquiry_accepted as conceptual terms. They helped separate interface success from durable acceptance, but they are not the released event names and should not be totaled beside the live events as though they came from one dataset. The public journal now follows the implemented contract instead of preserving a tidier old diagram.
A receipt belongs at the receiving end
The inquiry handler validates the required fields, writes the inquiry and its inquiry_submitted event together, and reads back the retained reference before returning acceptance. Repeating the same submission key returns the original receipt instead of creating another pair of records. The generic browser-event endpoint now rejects inquiry_submitted, so a browser observation cannot award itself the server’s evidence label.
Abuse handling is another reason to avoid counting every successful-looking response. A filled decoy field receives a harmless response without creating either record. A failed save returns an error. The useful rule is simple: confirmation follows retained acceptance, not animation, HTTP activity, or optimism.
Internal review is still traffic
Launch checks, screenshots, health checks, and our own browsing can create events. The collector suppresses an explicitly tagged internal session and browsers that report WebDriver automation. That reduces future contamination; it does not identify every automated browser, reconstruct older rows, or prove that every remaining event came from an external person.
The event rows also intentionally have no analytics visitor identifier. Counts can describe stored events over a stated period, but they are not unique people and cannot support a person-level conversion rate. Any future report needs the exact source, date range, exclusions, event definition, and missing evidence beside the number.
The business continues after the form
A stored inquiry is not automatically a qualified opportunity. A qualified conversation is not a proposal. A proposal is not signed work, and signed work does not prove that one page change caused the outcome. Those later states belong in separate commercial records with their own dates and definitions.
Privacy stays part of the design. The event payload has no dedicated fields for a person’s name, email, message, query string, referrer URL, analytics user ID, IP address, or device fingerprint. Campaign tokens are normalized and bounded, but that syntax check is not a magic personal-data detector. Reporting still needs review, restraint, and aggregation.
No traffic lift, conversion rate, qualified inquiry, signed project, revenue, or causal result is claimed in this note. It documents what the released measurement contract can establish—and stops where the evidence stops.
| Event | It can establish | It cannot establish |
|---|---|---|
| page_viewed | A supported page-load event was stored | A unique person, prospect, or human |
| cta_clicked | A labeled internal decision link was activated | A completed inquiry |
| inquiry_started | The form received its first interaction | Validation or server acceptance |
| inquiry_submitted | A retained inquiry and receipt exist | Qualification, signed work, revenue, or causation |
Keep this part
Use the smallest truthful name for an event. You can always ask a bigger question once the evidence supports it.
Recorded checks, with the limits attached
- Contract v1.1.1 limits the generic browser-event endpoint to page_viewed, cta_clicked, and inquiry_started.
- The inquiry handler writes inquiry_submitted with the retained inquiry record and reads back its reference before returning accepted: true.
- Repeated submission keys keep one inquiry and one submission event; honeypot decoys write neither record.
- Internal-session and WebDriver suppression reduce review contamination but do not identify every automated or internal visit.
- This note reports no live audience, conversion, qualification, signed-work, revenue, or causal outcome.
What this note is based on
Based on tracking-plan v1.1.1, the public event and inquiry handlers, contract tests, privacy notice, results methodology, and the September 29, 2026 release record. This explains the implemented evidence boundary; it is not a traffic or conversion report.
Further reading: Privacy and first-party event boundaries · SEO web design and reporting limits
Our results page explains the same evidence standard. For the studio’s approach, return to the MORI MORI MORI home page.