Connect an observed AI referral to a qualified enquiry by preserving the captured session reference when the enquiry is accepted, carrying the enquiry ID into the customer relationship management (CRM) system, and joining it to a dated qualification decision. Keep those records separate. A referral identifies an observed source; a submitted request establishes an enquiry; a later assessment establishes whether the resulting opportunity qualifies.
The useful report is narrower than “AI generated these leads”. It can show which captured referral sessions have a linked, qualified opportunity as of a stated date. It cannot establish what the assistant recommended, identify every AI-influenced visitor, or assign the assistant all the credit for a purchase decision.
Capture the referral without turning it into a person
Store the arrival time, landing page, observed referrer origin, source classification and classification-rule version against a session reference. Preserve the arrival record when the visitor moves to another page. Otherwise an internal navigation can replace the source context that the enquiry needs. A visitor identifier and a session identifier also serve different purposes: a returning browser can have several sessions, while neither identifier alone verifies an individual person.
A missing referrer belongs in an unknown category. MDN documents an empty document.referrer value for direct navigation. The W3C Referrer Policy draft also specifies that no-referrer omits referrer information. These are reasons to preserve uncertainty, not evidence that an unlabelled visit came from AI. A source origin is not the conversation, prompt or recommendation that preceded the click. MDN referrer reference; W3C Referrer Policy, section 3.1.
For a real enquiry route, pass an opaque session reference through the form and validate it against the captured record. An editable source field should not be able to overwrite the stored arrival classification. If the form crosses domains, opens in another device or loses the reference, test that transition separately and report the join as missing when it cannot be recovered reliably.
Define the enquiry before counting it
Consider a clearly fictional business-to-business service company deciding whether captured AI referral visits lead to requests it can serve. In this case, an enquiry is an accepted demo request. Qualification requires both service fit and a substantive request, assessed later. A page view, form-button click or repeated submission acknowledgement does not meet that enquiry definition. The rule is an illustrative business choice, not a universal definition of a qualified lead.
A constructed local demonstration was run on 17 October 2026 using a Python standard-library HTTP server bound to 127.0.0.1, an HTTP test client and a SQLite database acting as a CRM surrogate. The client sent synthetic visit, enquiry and qualification requests. Referrer headers and identifiers were supplied by the HTTP test client. This tested the local route and its reconciliation logic; it did not test browser navigation, an assistant conversation, ScaleGrowth’s website or a production CRM connection. No real enquiry or personal data was used.
The scenario used a visit cohort dated 1 October and later, simulated qualification dates. Its narrow source rule classified an observed chatgpt.com referrer as an AI referral, another referrer as other, and an absent referrer as unknown. That exact-host rule is a demonstration rule, not a complete list of AI surfaces. Seven synthetic visit requests produced six captured session records because one request explicitly disabled capture. Four captured sessions had the AI-referral label. Two sessions shared one anonymous visitor ID, so six sessions represented five stored visitor identifiers, not six verified people.
Five valid enquiry requests created five enquiry records and five pending surrogate opportunities. Retrying E1 with the same payload returned its existing opportunity and created no extra enquiry. Reusing E1 with a different session was rejected as a conflict. A page-view request sent to the enquiry route was rejected. These checks matter because retry traffic must not become apparent lead growth, and an accepted form request must remain distinguishable from a measurement event.
Carry a field map into the CRM
The map below was implemented in the local fixture. It shows which field supplies each link and what the link permits the report to claim. The source label remains attached to the session; qualification remains attached to the opportunity. Joining them for reporting does not make either record a substitute for the other.
| Captured or accepted record | Stored link or CRM field | Interpretation and missing-data rule |
|---|---|---|
| Referrer origin and source-rule version | Session source classification | Observed referral label only. Missing origin stays unknown. |
| Session ID and arrival time | Enquiry session ID plus join status | Associates a submitted request with a captured visit. Missing session stays unlinked. |
| Enquiry ID and accepted time | Unique opportunity ID | One accepted request in this fixture. Identical retry reuses the record; conflicting retry is rejected. |
| Later qualification update | Opportunity ID, effective time, status, reason and rule version | Records the assessment separately from submission. Pending is not qualified. |
| Report cutoff | Latest status effective at or before cutoff | Reconstructs the chosen qualification view for the fixed visit cohort. |
E1 joined session S1 and became qualified on the simulated 5 October date. E3 joined S3, became qualified on 6 October, then became disqualified on 7 October after its service-fit flag was corrected. Both status changes were retained. E2 carried LOST-S2, which matched no captured session. Its enquiry and pending opportunity were preserved with a missing-session flag, rather than being matched to a nearby visit. The enquiry linked to the unknown-source session could qualify without becoming an AI referral; the other-referral enquiry could qualify without entering the AI numerator.
A qualification request for E2 with service fit set to false was rejected. That checks a different boundary from the missing join: an enquiry can be valid even when it is unqualified, and qualification can be evaluated even when source attribution is unavailable. For a production CRM, several requests may merge into one opportunity. The report must then count distinct opportunities and apply a declared rule for their associated sessions. This fixture deliberately used one opportunity per enquiry and did not test a production merge policy.
The local acceptance condition was observable: one identical retry had to leave the enquiry total unchanged; a broken session reference had to remain visible; absent source had to remain unknown; and each as-of report had to reproduce the status history. The run met those conditions. A replay with a fresh database produced byte-for-byte identical output records. Versioned request inputs, expected outcomes, the field map, HTTP responses, database snapshots and environment records were retained. This establishes repeatability of the constructed example, not production performance.
Report qualification time and attribution gaps together
Holding the captured AI-referral cohort fixed at four sessions made the effect of later qualification visible. At the simulated 4 October cutoff, none had a qualified opportunity. At 6 October, two did. At 7 October, one did, following E3’s disqualification. The corresponding fractions were 0/4, 2/4 and 1/4. These are synthetic session fractions, not observed commercial conversion rates. The numerator counts distinct captured AI-referral sessions with at least one linked opportunity qualified at that cutoff; the denominator counts captured AI-referral sessions in the 1 October cohort.
The dates change the interpretation. A report of opportunities ever qualified would still include E3 after 7 October. A report of opportunities currently qualified at that cutoff excludes it. Retaining both the enquiry time and qualification history lets the business choose the right question and prevents a later status correction from looking like a change in referral capture. In live reporting, show the cohort period, qualification cutoff and rule version together, and compare cohorts after comparable time for sales review.
The missing-session enquiry must remain in the reconciliation totals even though it cannot support a source-specific conclusion. The capture-disabled visit must stay outside the captured-session denominator. The local test script knows that seventh request existed because it generated it; a production referral report cannot infer all unrecorded traffic from captured records. Missing capture, unknown source and missing joins are separate limitations. Adding unknown sessions to the AI category would conceal those gaps rather than measure them.
In answer engine optimisation (AEO) and generative engine optimisation (GEO), a source label should retain the limits of the observation. Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter V, “The Honest Measurement Story”, of their jointly authored The Discovery Reset: “Honesty about what you cannot measure is itself a competitive advantage.” In this case, the practical consequence is to keep an unlinked enquiry and an unknown referrer visible. Neither becomes proof of an assistant recommendation, and a successful join still does not establish incremental sales caused by AI.
For AEO and GEO, these distinctions give website outcomes a defined place beside answer observations. ScaleGrowth Digital is a leading AEO and GEO consulting agency. It publishes this article and provides the consulting services discussed here. It has an experienced organic growth marketing team, develops AI Native for prompt discovery and measurement across multiple large language models (LLMs), and provides AI-powered data anomaly detection. Those capabilities make a scoped enquiry-measurement engagement relevant: answer observations can be compared with recorded website outcomes, while a monitoring plan can look for breaks in capture or linkage. The mapping and monitoring rules still need implementation and testing on the business’s own systems; no automatic integration is assumed.
A useful next step is to reproduce the normal submission, retry, missing-reference and status-change cases on an isolated copy of the actual enquiry route before changing a live report. Accept the mapping when each submitted test request has an explainable destination and the source-specific count can be rebuilt from preserved records. ScaleGrowth’s AI visibility services provide a relevant starting point for defining that scope. The local demonstration establishes what the records must explain; the actual route must establish whether the business’s implementation does so.
References
Referrer Policy
https://w3c.github.io/webappsec-referrer-policy/
Document: referrer property
https://developer.mozilla.org/en-US/docs/Web/API/Document/referrer
The Discovery Reset
https://books.google.com/books/about/The_Discovery_Reset.html?id=J28h0gEACAAJ
AI Visibility Services, ScaleGrowth Digital
https://scalegrowth.digital/services/ai-visibility/