Follow the enquiry evidence

Video transcript

1. 0:00–0:06

   Define acceptance • Name the system that confirms a received enquiry. • Valid enquiry sent • Receiving system · accepted + stored • Name the record owner • Acceptance ≠ qualification ≠ customer

   A valid enquiry attempt connects to a receiving system that accepts and stores the record, then to a named person who can verify it is available for the responsible team. A browser success message is useful only when it reflects that acceptance. Acceptance, qualification and becoming a customer are distinct decisions. This is an illustrative service-enquiry test, not a default GA4 setup or a measured result.

2. 0:06–0:12

   Trace every stage • Tag firing is only one checkpoint. • Tag fired • Property received • Business record • Report definition • Browser signal • Business evidence • Inspect independently

   The reviewed master keeps four probes independent: tag fired, intended property received, business record and report definition. Native panels highlight the browser signal and the separate business evidence in sequence. Inspect the payload, intended destination and receiving record. An automatically recorded interaction or a successful browser tag does not prove CRM receipt, qualification or the full journey. No personal enquiry content is shown or sent to analytics.

3. 0:12–0:18

   Test failure and repetition • Refresh and double-submit must not manufacture success. • Rejected field → not accepted • Accepted, then response lost • Check receiving record • Refresh / repeat → test duplicate handling

   A rejected field is highlighted as not meeting acceptance. A separate accepted request with a lost response connects to checking the receiving record: browser timeout does not prove the accepted record is absent. A repeat/refresh test then highlights duplicate handling rather than manufacturing another lead. Compare expected versus observed outcomes for missing fields, server rejection, double submit, response loss after acceptance, confirmation refresh, consent denied then granted, and a second legitimate enquiry.

4. 0:18–0:24

   Separate events and records • The example has two enquiries and three events. • E17 • E18 • Session counting: 1 • Event counting: 3 • One invented session · 2 accepted records · 3 event occurrences

   Two accepted enquiry records E17 and E18 remain visible. E17 emits two separate native event tokens with the same identifier, while E18 emits one. This yields three event occurrences from two accepted enquiries in one hypothetical session. The reviewed counting lenses show one with once-per-session counting and three with once-per-event counting. Neither lens corrects the duplicate trigger, and neither total automatically equals accepted business records. Fix and retest emission, choose the business question, and document the counting rule. Identifiers are invented and contain no personal information.

5. 0:24–0:30

   Document the correction • Record evidence, owner and the change date. • Evidence + owner + repeatable test • Earlier data · retain limits • Future data · dated correction • Respect configured consent · no personal data in analytics

   An evidence handover names expected and observed behavior, test environment and action, relevant payload and receiving record, report definition, severity, owner, proposed correction, reproducible retest and change date. A boundary separates earlier data with retained limits from future data under a dated correction: counting changes do not reconstruct missing observations. Keep confirmed faults separate from unanswered questions. Respect configured consent; advanced consent mode can send cookieless measurements while denied, so a network request alone is not a complete diagnosis. Do not override consent just to obtain a passing test.