Skip to content

Consider limiting Prebid EID KV ingestion to navigation requests #993

Description

@ChristianPavilonis

Summary

Prebid EID cookie ingestion currently runs during response finalization for every eligible request carrying an EC/EID cookie. On a page load, concurrent subresource, XHR, integration, and auction requests can all attempt to update the same EC KV entry, producing CAS-conflict warnings such as:

EID cookies: failed to sync 13 partner IDs ... CAS conflict after 5 retries

Optimization to consider

Evaluate gating EID ingestion to top-level document navigations, using the existing is_navigation_request() detection (Sec-Fetch-Dest: document, with an HTML Accept fallback), or another narrowly scoped request policy.

Possible alternatives or additions include:

  • An explicit post-auction sync request.
  • Throttling or deduplicating ingestion for the same EID-cookie value.
  • Supporting a first eligible request per cookie value while preserving SPA behavior.

Trade-offs

The EID cookie is written client-side after a Prebid auction. Navigation-only ingestion could delay syncing until the next navigation, or miss syncing for single-page apps that never navigate again. The team should decide the desired freshness/coverage versus KV contention trade-off without weakening CAS protection.

Context

EC generation is already limited to document navigations, but EID ingestion is currently performed for returning-user requests during ec_finalize_response more broadly. Reducing the number of competing read-modify-write operations could lower CAS conflicts during page loads.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions