InEvent + Oracle Eloqua Event Integration: Sync CDOs & Campaign Canvas

2.0 Data Model & Schema (The CDO Strategy)

2.1 The Problem: Data Flatness in the Contact Table

Most event integrations map fields like “Last Event Attended,” “Event Status,” or “Last Webinar Date” directly onto Eloqua Contact fields. This is bad practice in high-volume, multi-event environments for several reasons:

• Overwriting destroys history
  
  

• Each new event overwrites previous values, making it impossible to reconstruct a whole new timeline of engagement.
  
  

• Contact schema inflation
  
  

• Adding multiple event-related fields for every program quickly bloats the Contact schema.
  
  

• Low signal fidelity
  
  

• A single “Last Event Attended” field cannot distinguish between a buyer who attended fifteen targeted workshops and another who joined one generic webinar.
  
  

• Poor alignment with Lead Scoring Models
  
  

• Scoring models that rely on flat fields cannot differentiate event frequency, recency, or intensity of engagement.
  
  
  

2.2 The Solution: One-to-Many Relationship with CDOs

To resolve data flatness, the integration uses a one-to-many model:

• One Contact
  
  

• Many Event Engagement CDO records
  
  

Each event activity generates a new CDO record rather than overwriting previous values. This provides:

• A permanent audit trail of every event, session, and action.
  
  

• Easy filtering and segment building based on event type, engagement score, or attendance status.
  
  

• Fine-grained inputs for Lead Scoring Models and Program Canvas rules.
  
  

The CDO is linked to the Contact by Eloqua Contact ID or primary key field mapping (for example, Email Address) as configured in the AppCloud connector.

2.3 Core CDOs

A recommended pattern is to use a single primary CDO called, for example, “InEvent Event Engagement” that stores any activity at the granularity you require. Common choices:

• One CDO record per event registration.
  
  

• One CDO record per session attendance.
  
  

• Optional separate CDO for aggregated metrics per event, if needed.
  
  

The specification below assumes per-session records as the highest fidelity.

2.4 CDO Schema Table

Below is a representative schema for the “InEvent Event Engagement” CDO. Example values are provided for illustration.

Minimal fields to satisfy your requirement directly:

• Event Name: “Annual Summit 2025”
  
  

• Activity Type: “Session View”
  
  

• Duration: “45 Minutes” (stored as integer or text field DurationMinutes = 45)
  
  
  
  

2.5 Field Mapping Strategy

Typical mapping strategy:

• Contact
  
  

• Email → Contact.EmailAddress
  
  

• First Name → Contact.FirstName
  
  

• Last Name → Contact.LastName
  
  

• Company → Contact.Company
  
  

• Eloqua Contact ID used as the primary key for linking to the CDO.
  
  

• CDO (InEvent Event Engagement)
  
  

• InEvent Event Name → CDO.EventName
  
  

• InEvent Session Name → CDO.SessionName
  
  

• Activity Type (Registration, Check-in, Attendance, View) → CDO.ActivityType
  
  

• Local Duration value → CDO.DurationMinutes
  
  

• Time of activity → CDO.ActivityTimestamp
  
  

• Derived EngagementScore based on activity classification → CDO.EngagementScore
  
  

This mapping ensures the Contact table remains clean, while detailed historical activity resides in the CDO.

2.6 Data Retention, Dedupe, and History

• No CDO updates are performed for historical rewriting except when correcting known technical errors.
  
  

• Each new behavior generates a new CDO row.
  
  

• Optional deduplication can be applied in Program Canvas if the business requires merging repeated identical events.
  
  

• Retention policies can be implemented at the CDO level to archive or delete records older than a defined period, while preserving aggregate metrics on the Contact or account level.

4.0 Blind Form Submits & Identity Resolution

4.1 Concept

The integration uses Eloqua Blind Form Submits and “magic links” to avoid re-registration friction and to ensure accurate identity resolution across devices and sessions.

When a known Eloqua contact clicks a tracked InEvent link embedded in an Eloqua email, a Blind Form Submit can be used to:

• Pass the Eloqua Contact ID, email, and key context to InEvent.
  
  

• Associate subsequent event activity back to the correct Eloqua Contact without requiring login or form completion.
  
  
  

4.2 Magic Link Pattern

A typical pattern:

1. Eloqua email contains a URL to InEvent registration or session pages with tracking parameters.
   
   

2. When clicked, one of the following occurs:
   
   

• Eloqua logs the email click and forwards to InEvent.
  
  

• A Blind Form Submit is triggered server side by the connector using the contact’s Eloqua ID and email.
  
  

3. InEvent reads the parameters or payload and resolves the contact:
   
   

• If an InEvent attendee profile exists for the email or external ID, it is linked.
  
  

• If not, a new attendee is created and connected to the Eloqua Contact ID.
  
  
  

4.3 Blind Form Submit Implementation

Key elements:

• Eloqua Form Definition
  
  

• A hidden “integration” form in Eloqua includes fields such as:
  
  

• Eloqua Contact ID
  
  

• Email Address
  
  

• Event ID
  
  

• Session ID
  
  

• Campaign Source
  
  

• All fields can be hidden from the user.
  
  

• Blind Form Submit Mechanism
  
  

• When the magic link is clicked, the integration posts the data to the form endpoint without exposing a visible form.
  
  

• Eloqua processes the form submission, updating internal tracking logs and optionally setting routing logic.
  
  

• Identity Binding
  
  

• The form submission and the click event are both associated with the same visitor profile and Contact record.
  
  

• InEvent stores the Eloqua Contact ID as the external key, allowing all subsequent activity to be written back against that Contact’s CDOs.
  
  
  

4.4 Identity and Security Considerations

• Eloqua Contact IDs or hashed identifiers should be used instead of raw personally identifiable information whenever feasible.
  
  

• Tracking links should be signed or tokenized to avoid tampering.
  
  

• Optional expiry timestamps can be added to magic links to limit validity.
  
  

• If SSO or corporate identity providers are used, InEvent can combine Eloqua Contact ID with SSO attributes to further harden identity resolution.
  
  

Result: known Eloqua Contacts can transition from an email click to a live or on-demand InEvent experience without filling out another form, while Eloqua retains a full, linked event history via CDO records.

5.0 Lead Scoring Models

5.1 Integration with Eloqua Profiler

InEvent-derived event activities surface in Eloqua as:

• CDO records in the “InEvent Event Engagement” object.
  
  

• Optional External Activities (for example InEventSessionAttended) mapped per activity type.
  
  

These records can be displayed within Eloqua Profiler to give sales a chronological view of event engagement, including event names, session titles, and engagement scores.

5.2 Scoring Concept

Lead Scoring Models can use event engagement as a high-intent behavioral signal. Instead of a static “Attended Webinar” flag, the scoring engine can consume every event, session, and duration.

Base rule as requested:

• Rule: If a CDO “Event Activity” is created, add +10 to Score.
  
  

You can extend this with differentiated rules:

• Check-in to a physical event: +15 points.
  
  

• Attendance to a product-specific demo: +20 points.
  
  

• On-demand content view: +5 points.
  
  

• Multiple session views in a single event: additional cumulative points.
  
  
  

5.3 Technical Implementation in Eloqua Lead Scoring

Steps:

1. Expose CDO Fields to the Scoring Model
   
   

• Ensure that the Event Engagement CDO is configured with a Contact link field.
  
  

• Expose relevant fields such as ActivityType, EventName, and ActivityTimestamp in the model’s criteria.
  
  

2. Define Scoring Rules
   
   

• Example basic rule:
  
  

• Condition: Exists CDO record where ActivityTimestamp in last 30 days
  
  

• Action: Add +10 points for “Recent Event Engagement”.
  
  

• Example advanced rule:
  
  

• Condition: Exists CDO where ActivityType = "Session View" and DurationMinutes ≥ 30
  
  

• Action: Add +15 points for “High-value Session Attendance”.
  
  

3. Use External Activities if preferred
   
   

• Map InEvent activities to Eloqua External Activities.
  
  

• Configure scoring rules that read External Activity types such as InEventSessionAttended, InEventEventRegistered, etc.
  
  

4. Align with Demographic Scoring
   
   

• Combine event-based behavioral scores with demographic or firmographic criteria for a composite score.
  
  
  

5.4 Example Scoring Logic

Sample scoring tiers:

• Base Rule (required by you):
  
  

• Rule: When any new Event Engagement CDO record is created, add +10 points.
  
  

• Additional optional rules:
  
  

• If ActivityType = "Check-in" for a high-value event, add +20.
  
  

• If contact has attended more than 3 sessions within last 60 days, add +25.
  
  

• If EventName contains “Executive Roundtable” or “VIP” and AttendanceStatus = “Attended”, add +30.
  
  

This pattern allows sales teams to see a step-change in scores for event-intensive prospects, with clear justification in Profiler based on the CDO event history.

To avoid score inflation, apply caps and decay. Cap points per event (e.g., max 50), decay engagement after 30–60 days, and exclude internal/test contacts. This keeps scores comparable across campaigns and prevents one marathon attendee from dominating prioritization sales queues.

5.5 Profiler Experience

In Profiler, reps can see:

• Chronological list of InEvent activities, sourced from CDO and External Activities.
  
  

• Event and session titles, timestamps, and durations.
  
  

• How each event activity contributed to the Lead Scoring Model.
  
  

This provides context to prioritize follow-up immediately after key events, using the same audit trail that powers Campaign and Program automation.

6.0 Implementation & Governance

6.1 Prerequisites

• Oracle Eloqua instance with permissions to:

• Manage AppCloud apps.

• Create and configure Custom Data Objects.

• Edit Campaign Canvas and Program Canvas.

• Configure External Activities.
  
  

• InEvent administrator access to configure integrations and API credentials.

• Network-level approvals if outbound IP whitelisting or firewall rules exist.

Step 1: Install AppCloud Connector

1. Navigate to Settings → Apps → AppCloud Catalog in Eloqua.
   
   

2. Locate the InEvent Connector and install it to your instance.
   
   

3. Grant requested scopes, which typically include:
   
   

• Read and write Contacts.
  
  

• Read and write CDOs.
  
  

• Access to Campaign Canvas and Program Canvas.
  
  

4. Configure authentication to InEvent:
   
   

• Provide API key or OAuth credentials.
  
  

• Optionally specify tenant or environment (production, staging).
  
  

Once installed, the connector appears as a Feeder and Action service on Campaign Canvas.

Step 2: Define CDO Mapping

1. Create the InEvent Event Engagement CDO object in Eloqua:
   
   

• Define link field to Contact (ContactId or EmailAddress).
  
  

• Add fields listed in section 2.4 or a subset that matches your use case.
  
  

2. Open the InEvent Connector configuration:
   
   

• Map source fields from InEvent (event name, session id, activity type, etc.) to CDO fields.
  
  

• Specify which InEvent events or event groups should be synchronized into this CDO.
  
  

3. Configure key mapping:
   
   

• Decide whether Eloqua Contact ID or email will be the primary identifier for linking CDO records to Contacts.
  
  

• Ensure identity resolution is consistent with Blind Form Submit setup.
  
  

4. Save and test:
   
   

• Run a small test event with a limited audience.
  
  

• Confirm that new CDO records are created and linked correctly for the test Contacts.
  
  

Step 3: Configure External Activity Types

External Activities allow event actions to appear in Eloqua’s activity log and be used in Campaigns and Scoring.

1. In Eloqua, define External Activity types such as:
   
   

• InEventEventRegistered
  
  

• InEventSessionAttended
  
  

• InEventOnDemandView
  
  

2. In the InEvent Connector:
   
   

• Map InEvent activity types to these External Activity types.
  
  

• Optionally specify which activities should be written both to CDOs and External Activities for redundancy.
  
  

3. Validate:
   
   

• Trigger a registration and attendance.
  
  

• Confirm that the appropriate External Activity entries appear in the Contact’s activity log.
  
  
  

Step 4: Whitelist IP Addresses (If Required by IT)

In environments with strict firewall rules, your IT team may need to whitelist known IP ranges used by the InEvent connector to:

• Allow inbound traffic to Eloqua endpoints from InEvent’s integration infrastructure.
  
  

• Allow outbound traffic from Eloqua, if required, to callback URLs or APIs in InEvent.
  
  

Document the IP ranges and ports for change management and ensure monitoring is established at the network level.

6.2: Error Handling and Monitoring

Recommended monitoring practices:

• Connector Logs
  
  

• The InEvent connector should expose logs for:
  
  

• Failed API calls to Eloqua.
  
  

• Mapping errors due to unexpected field types.
  
  

• Rate limit responses from Bulk API 2.0.
  
  

• Eloqua Error Reports
  
  

• Monitor Bulk API import error files.
  
  

• Configure alerts when error rates exceed defined thresholds.
  
  

• Retry Strategy
  
  

• Implement backoff and retry for transient network or limit errors.
  
  

• Use idempotent insert patterns where possible to avoid duplicate CDO records.
  
  
  

6.3 Change Control and Governance

Because this integration touches core engagement data, treat configuration changes as governed assets. Recommended practices:

• Maintain a version-controlled specification of:
  
  

• CDO schema.
  
  

• Field mappings.
  
  

• External Activity mappings.
  
  

• Campaign and Program Canvas flows related to InEvent.
  
  

• Use non-production Eloqua and InEvent environments for testing before push to production.
  
  

• Document all changes via your standard change request process, including:
  
  

• Rationale.
  
  

• Impact assessment.
  
  

• Rollback plan.

7.0 Technical FAQ

1. How do you handle 10M+ contact databases?

For very large databases, the integration leverages Eloqua Bulk API 2.0 for high-volume ingestion. Key characteristics:

• Batch-oriented data loads

• Contacts and CDO records are sent in batches that align with Eloqua’s Bulk API job size recommendations.
  
  

• Incremental updates

• Only changed or new records are included in each batch, based on event timestamps and internal checkpoints in InEvent.
  
  

• Parallel processing

• Multiple Bulk API jobs can be queued in parallel within Eloqua’s concurrency limits, allowing high throughput while respecting API policies.
  
  

• Backpressure awareness

• The connector monitors Eloqua API responses to back off automatically when close to rate limits.
  
  

For environments with more than 10 million Contacts, this approach provides consistent performance and predictable synchronization windows.

2. Can I trigger emails from the Canvas in real time based on InEvent data?

Yes. Because InEvent acts as a Feeder on Campaign Canvas, contacts can enter Campaigns in near real time at the point of registration or attendance. A typical pattern:

1. InEvent pushes a contact into Campaign Canvas as soon as they register or attend.

2. The contact enters a Campaign step that sends a confirmation, reminder, or “Thank You” email.

3. Decision steps can branch based on CDO-derived criteria, such as attendance status, session topic, or engagement score.
   
   

Latency is bounded by the synchronization window configured in the InEvent connector. For most deployments this is short enough to treat as real time at marketing program scale.

3. Do you support Shared Lists for audience management?

Yes. The integration can work with Eloqua Shared Lists in two ways:

1. As a source
   
   

• Use Shared Lists as entry criteria in Campaign Canvas, then attach the InEvent Feeder as part of the Campaign to create targeted event audiences.
  
  

2. As a target
   
   

• Program Canvas or Campaign Canvas can add contacts with defined event engagement patterns (for example, high session attendance, specific event topics) into Shared Lists.
  
  

• These Shared Lists can be used for sales outreach, remarketing, or as seeds for lookalike audiences in other systems.
  
  

If desired, selected Shared Lists can also be synchronized back to InEvent as registration lists, ensuring alignment between Eloqua segmentation and event registration audiences.

4. Can I use Program Canvas for always-on event engagement processing?

Yes. Program Canvas is recommended for operational logic such as:

• Periodic evaluation of CDO records to identify thresholds for sales hand-off.
  
  

• Cleansing and normalizing fields in the Event Engagement CDO.
  
  

• Moving qualified contacts into Shared Lists or CRM sync queues based on cumulative event behavior.
  
  

Campaign Canvas is used for specific event or series journeys. Program Canvas is used for continuous background processing of the ongoing CDO event stream from InEvent.

5. How do you prevent duplicate CDO records?

Several controls are available:

• A natural key can be established on ContactId + EventId + SessionId + ActivityType + ActivityTimestamp window.
  
  

• The connector can perform deduplication before writing, ensuring only unique combinations are sent.
  
  

• Program Canvas can run dedup logic periodically, merging or deleting duplicates if they appear.
  
  

This balances the need for a detailed audit trail with practical data hygiene.