Eloqua Architecture / Visitor GUID Capture
Eloqua Visitor Identity Layer
A practical identity stitching layer for Eloqua form submissions. Capture the Eloqua visitor GUID where it exists, submit it with the form, and store it in a CDO called SYSTEM - Eloqua ID for downstream processing.
The pattern
Capture identity without blocking conversion.
The page JavaScript reads the Eloqua visitor GUID from the Eloqua tracking cookie or client-side tracking context where available, injects it into a hidden form field, and submits it with the normal form payload.
Missing GUID must not block the form submission. If a form fails because the visitor GUID is unavailable, that is a production defect. The identity layer should enrich submissions, not become another failure point on a campaign landing page.
Read GUID where available -> inject hidden field -> submit with form -> store in SYSTEM - Eloqua ID CDO.
Implementation summary
A small front-end layer with useful downstream consequences.
01
Read visitor identity
Use the Eloqua client-side context or tracking cookie where available. Treat absence as normal.
02
Inject hidden field
Add the GUID to a hidden Eloqua form field without changing the visible conversion path.
03
Store in CDO
Write the submitted identity value into a CDO named SYSTEM - Eloqua ID.
04
Stitch downstream
Use it for CDO processing, CRM matching, campaign reporting, and visitor/contact stitching.
Operating rule
Identity is enrichment. Form submission is the priority.
The useful architecture is tolerant. Known visitors carry a stitching key into Eloqua. Unknown visitors still convert. The downstream process can decide how to match, update, report, or defer records without breaking the campaign form.
View related Eloqua form protection