# Worked diagnosis: a failed form fires the demo event

This is a fictional training record for an invented B2B software company. Every observation, release label, and evidence reference below is illustrative. No live account was inspected. The .invalid URLs cannot be used as a real test destination. IDs remain Unknown; never copy this record into a real installation as its starting evidence.

## 1. Account and Partner ID
Account identity: Fictional software company's advertising account; actual identity Unknown.
Expected Partner ID from this account: Unknown.
Private account/ID evidence reference: Unknown. The imagined test did not capture the identifier comparison.

## 2. Tested destination
Exact tested URL: https://example.invalid/request-demo
Final URL and domain after redirects: Same URL; example.invalid.
External booking or thank-you destinations: Unknown. A successful submission has not been tested.

## 3. Installation inventory
Implementation route (GTM/manual/other): GTM.
Code or tag location: Global container on the imagined request-demo page.
Existing base installations and their owners: One base tag listed in the fictional container inventory; independent hardcoded/plugin installations Unknown. Owner: fictional web developer.

## 4. Release scope
Published site release or GTM container/version: Fictional release demo-form-A / published container demo-A.
Preview container/version, recorded separately: Fictional draft demo-B; no results from it used here.
Publish evidence: Fictional reference EX-PUBLISH, showing demo-A as published. This is an example reference, not an attached receipt.

## 5. Observation context
Date/time and timezone: Fictional test, 26 October 2026, 10:00–10:10 UTC.
Browser/version and extensions: Chromium-family desktop browser; exact version and extension inventory Unknown.
Environment (production/preview/staging): Fictional production environment, published demo-A.
Test operator: Fictional QA operator.

## 6. Approved consent behavior
Approved requirements and policy owner/reference: Fictional policy EX-POLICY requires no LinkedIn requests before advertising consent; policy owner: fictional privacy lead.
Eligible pages and excluded pages: request-demo approved as eligible in this scenario; other-page inventory Unknown.
Expected default/denied, granted, revisit, and withdrawal behavior: No LinkedIn requests while denied; eligible requests after grant; revisit/withdrawal details Unknown.
CMP category mapping, template checks, and grant trigger: Unknown. Observing one request does not establish the full configuration.

## 7. Actual consent observations
Default/denied action, result, scope, time, and evidence: No LinkedIn request observed during the fictional 10:00–10:02 UTC denied-state recording on request-demo/demo-A; EX-DENIED. This bounded result does not prove every denied visit works.
Granted action, result, scope, time, and evidence: QA granted advertising consent at 10:03 UTC; a base-tag request appeared in the fictional browser recording on request-demo/demo-A; EX-GRANT.
Revisit action, result, scope, time, and evidence: Unknown.
Withdrawal and subsequent visit result, scope, time, and evidence: Unknown.
Excluded-page result, scope, time, and evidence: Unknown.

## 8. Base-tag browser evidence
Request destination: Unknown; omitted from the fictional recording summary.
Observed Partner ID and comparison with expected ID: Unknown.
Response or blocking error: Unknown; a request was listed, but its result was not recorded.
Consent state, tested URL/version, time, and evidence reference: Granted; request-demo/demo-A; 10:03 UTC; EX-GRANT.
GTM firing observation, if applicable: Base tag reported Fired in the fictional live debug session. Delivery remains Unknown.

## 9. LinkedIn source evidence
Source status: Unknown.
Account, associated domain, and last signal context: Unknown.
Observation time and evidence reference: Unknown.

## 10. Intended conversion and observed action
Business meaning and actual success condition: Completed demo request. Success requires confirmed successful submission; an invalid form is not a demo request.
Rule/method and expected conversion ID: Fictional event-specific conversion tied to the submit button click; expected conversion ID Unknown.
Failed/cancelled action and event result: At 10:05 UTC, QA clicked submit with a required field empty. The page displayed a validation error and stayed on the form. The event tag reported Fired on that click. Fictional references EX-INVALID-FORM and EX-EVENT-TRIGGER show the same action and timestamp.
Confirmed successful action and event result: Unknown; not performed.
Observed identifier, URL/version, consent state, time, and evidence: Identifier Unknown; request-demo/demo-A; granted; 10:05 UTC; EX-EVENT-TRIGGER. Actual request result and platform receipt Unknown.

## 11. Conversion receipt and association
Conversion status, observation time, and evidence: Unknown.
Selected ad-set association and account/conversion evidence: Unknown.

## 12. Attribution
Attributed advertising result, if observed: Unknown.
Account, conversion, reporting period, attribution windows/model, and evidence: Unknown.

## 13. Handoff
Responsible owner: Fictional web developer for the success signal and trigger; fictional paid-media owner for account and conversion matching.
Next narrow test (proposed): In an approved test environment, inspect the form's documented success callback or completion response. Repeat an invalid submission and a valid test submission, recording the actual application success signal and event-trigger decision for each. Keep consent requirements unchanged. Do not assume the form exposes a particular callback.
Expected result and evidence to save (proposed): Invalid submission has no completed-demo event; a confirmed successful submission has the intended event. Save application result, timestamp, URL, consent state, release/container version, trigger decision, and actual request/identifier/result. Verify the Partner ID and conversion ID privately before interpreting delivery.
Rollback or previous-version reference: Fictional published demo-A; the rollback procedure and previously verified version are Unknown. Any proposed change needs its own reviewed release and rollback record.
Unresolved questions: Which documented signal proves this form succeeded? Are account and conversion IDs correct? Are there duplicate installations? Does the event reach LinkedIn? Is the conversion attached to the intended ad sets? What happens on revisit, withdrawal, and excluded pages? Attribution remains Unknown.

## Diagnosis

The fictional record establishes a trigger mismatch. The event tag fires when the visitor clicks submit even though validation prevents a completed demo request. EX-INVALID-FORM and EX-EVENT-TRIGGER support that conclusion within demo-A's recorded test. They do not establish that LinkedIn counted a conversion.

The next test is to identify and observe the actual success signal, then compare invalid and successful submissions against that signal. The developer can propose a trigger repair after that test identifies the missing condition. A button-click trigger should not stand for completed submission in this scenario.

Base-tag delivery is also incomplete: the request destination, ID match, response, and source receipt are missing. The paid-media owner and developer need those observations before declaring the base installation verified. The consent matrix, conversion receipt, association, and attribution remain open. One denied-state recording cannot certify consent behavior across the site.

Keep this failed result after a repair. A changed container version needs a new record with its own tests; demo-A's observations become historical evidence for demo-A.
