Implementation Overview

Integrating with Koddi involves four types of data exchange, organized by when they happen:

Timing	Integration Type	What it does
Before Launch: Before ads can be served	Data to Koddi	Gives data key data points to run the ads platform: Inventory Feeds (required) AND Targets + Audiences (optional)
At Serve Time: When a shopper loads a page with ad placements	Ad Serving	Request ads from Koddi to display on your site: Winning Ads API OR Using a Tag Manager
At Serve Time: When shoppers see, click, or purchase a product	Event Collection	Tells Koddi what happened with those ads: Impressions AND Clicks AND Conversions
After Ads Are Served: Ongoing, for BI/billing	Data Back to You	Allows you to ingest reporting data into your systems (for DW/BI or billing use cases, as examples): Reporting APIs

Before Launch: Data to Koddi

Before Koddi can run auctions and serve ads, certain data needs to flow from your systems into Koddi. This data enables eligibility, relevance, pacing, and reporting. Some of it is required, some is optional depending on your use cases.

Required: Inventory Feeds

Inventory feeds tell Koddi what can be advertised.

What this typically includes:

Products, listings, or offers eligible for ads
IDs, titles, images, categories
Merchant or brand associations
Etc.

How it’s used:

Determines which items can enter auctions
Powers relevance, filtering, and eligibility logic

Optional: Targets and Audiences

Targets and audiences allow more precise campaign control.

What this typically includes:

Page or placement targeting (search terms, categories, destinations)
First-party audience segments from your CDP
Loyalty tiers or behavioral cohorts
Etc.

How it’s used:

Campaign targeting and exclusion logic
Bid and budget optimization
Personalization when applicable

Audience data is optional, but it significantly increases advertiser value and performance. Server-side ad serving makes this much easier since your server already has direct access to CDP data.

At Runtime: Ad Serving

When a shopper visits a page on your site (e.g., search results, product page, homepage), you need to request ads from Koddi. There are two ways to do this:

Option A: Server-to-Server API (Recommended)

How it works: Your server makes an API call to Koddi's "Winning Ads" endpoint. Koddi runs an auction and returns the winning ads. Your server then includes those ads in the page it sends to the shopper.

Shopper's Browser → Your Server → Koddi API → Your Server → Shopper's Browser

Pros:

Full control over what data you send
Privacy-friendly (no third-party browser calls, no cookie risk)
Direct access to CDP/audience data
Not vulnerable to ad blockers

Cons:

Requires server-side development work

Option B: Client-Side Pixel/Tag

How it works: A JavaScript tag in your page makes a call to Koddi when the page loads. Koddi returns ads that get inserted into the page.

Shopper's Browser → Your Server → Shopper's Browser → Koddi → Shopper's Browser

Pros:

Simpler initial implementation
No server-side changes needed

Cons:

Privacy/cookie trajectory risk: Third-party calls from the browser are subject to ongoing browser privacy changes (cookie deprecation, tracking prevention). Server-side integration avoids this entirely.'
CDP integration is more complex: To include external audience data, you need that data available in the browser (e.g., via data layer), then coordinate a call to your CDP before the ad request. Server-side has direct access to CDP data.
Ad blocker exposure: Consumer ad blockers can block third-party pixels, which means lost ad inventory. Server-side calls can't be blocked.

📘
Bottom line: Most Koddi publishers use the API approach. Server-side avoids third-party privacy headwinds and simplifies CDP integration.

At Runtime: Event Collection

Once ads are displayed, you need to tell Koddi when shoppers interact with them. There are three events to track:

Event	What it is	When to send
Impression	Ad was viewed	When the ad becomes visible to the shopper
Click	Ad was clicked	When the shopper clicks/taps on an ad
Conversion	Purchase occurred	When any checkout completes (Koddi handles attribution)

For Impressions & Clicks

Option A: Server-to-Server API (Recommended)

Your front-end detects the event (ad viewed, ad clicked), sends a signal to your server, and your server calls Koddi's tracking API:
- More reliable (retries if failed)
- Follows IAB measurement guidelines
- Better fraud protection
- Consistent with ad serving integration

Option B: Client-Side Pixel

Your front-end directly calls a Koddi tracking URL when events occur.
- Simpler to implement initially
- But: less reliable, harder to retry failed calls

For Conversions

Option A: Server-to-Server API (Recommended)

Send all conversion events from your checkout system to Koddi. You can batch these (e.g., hourly) if needed.
Koddi handles attribution - you don't need to figure out which conversions came from ads.

Option B: Checkout Page Pixel

A Koddi pixel on your checkout confirmation page fires when purchases complete.
Common fallback option
Works when server-side conversion tracking isn't feasible

After Ads are Served: Data Back to You

After ads run, Koddi makes performance data available so you can ingest it into your own systems for reporting, billing, and analysis.

Koddi provides APIs to retrieve aggregated reporting data.

What you can access:

Impressions, clicks, conversions
Spend, revenue, CPC, ROAS
Campaign, advertiser, placement, and time-based breakdowns

Common use cases:

Internal dashboards and BI tools
Invoicing and Billing
Billing reconciliation

Koddi is the system of record for ad delivery and performance. These APIs are designed for downstream consumption rather than real-time decisioning.