Koddi supports integrations with third-party identity resolution partners (IRPs) to enable audience-based targeting and measurement. This allows publishers to activate enriched audience data for onsite, offsite and in-store/on-prem ad types.

Common Use Cases

Typical use cases include:

Enabling targeting and measurement using an external identity spine
Enriching lighter-weight internal identifiers with third-party audience attributes
Supporting large-scale audience activation across onsite and offsite media

This pattern applies whether the partner is a retailer with a CDP, a publisher with limited identifiers, or a platform using an IRP as its primary onboarder.

High-Level Integration to Koddi Flow

At a high level, the integration follows this flow:

The partner sends source data to an identity resolution provider for onboarding and audience creation.
The IRP prepares a delivery of audience attributes and or segment membership for Koddi.
1. The data is keyed by a stable identifier (for example, an IRP-issued ID like a RampID).
Koddi ingests this data and stores it in a low-latency customer-level cache. Audience data should be refreshed on a recurring cadence.
1. Option 1: Can be sent to Koddi using a Secure Data Collaboration tool, SFTP, or direct API integrations with your CDP or DMP.
2. Option 2: Koddi maintains direct integrations with some IRP solutions; your Koddi team can help you with access requirements for Koddi to get data directly from the IRP partner.
The ID is used in ad delivery

Ad Served by Koddi

At ad request time, the you should include the identifier in the request payload. This is most common with onsite.

Koddi matches the runtime identifier to the cached audience data for targeting and measurement.
IRP IDs should be delivered in the id field in the user object in the winning ads call.

Ad Not Served by Koddi

The IRP should also send the data to the third-party platform serving the ad. This is most common with offsite. Koddi references that audience when trafficking and optimizing campaigns.

📘
Using GUID and ID
GUID should be UUID that tracks back to something maintained in your internal systems, not third-party identity resolution partners. This should always be included.
ID can be safely used for third-party identity resolution partners IDs. If you're using LiveRamp, use ID field for the LiveRamp RampID. This may not always be included - you match not have a match from your identity resolution partner.

Targeting and Decisioning

During ad decisioning:

Koddi will look up the identifier in the audience cache
Koddi will match attributes and segments to the targeting logic
Non-matching requests continue without audience enrichment

Audience targeting can be used for:

Campaign eligibility
Bidding or ranking signals
Reporting and measurement

Refresh Cadence

Audience data should be refreshed on a cadence appropriate to how frequently segments change.

Typical cadences include:

Hourly or daily for fast-changing or high-value segments
Daily or weekly for slower-changing attributes

Refresh cadence is agreed during onboarding and can evolve over time.

Scale and Performance Considerations

Koddi supports large-scale audience datasets, but asks that you follow best practices:

Starting with a limited number of high-impact segments
Monitoring match rates and cache hit rates
Gradually expanding attribute and segment coverage

In Summary

Integrating with a third-party identity resolution provider allows you to activate rich audience targeting in Koddi while maintaining privacy and flexibility.

The core requirements are simple:

A stable identifier shared offline and at runtime
A consistent audience data feed
A defined refresh cadence and operational plan

Once in place, this pattern supports scalable, privacy-safe audience activation across Koddi-powered media.