ECAPI-talizing on Conversions

ECPI has arrived

Event signals, including how a consumer interacted with a brand after seeing an ad, are currency in the digital advertising ecosystem. They are the linchpins of data-driven marketing and at the heart of performance-promoting strategies such as measurement, attribution, optimization, and retargeting.

So it’s no surprise client-side signal loss has long been a hot topic for buyers and sellers alike in the industry. With a shift away from client-side tracking technology, the much-needed ability of advertisers to communicate marketing-related events and customer behavior to publishers and platforms is impacted.

Fortunately, these signals are not only sourced client-side— they exist server-side, too. If publishers and platforms have visibility into business-critical records that otherwise live siloed in client databases such as CRMs, then advertisers will have the opportunity to boost media performance and prove sell-side inventory value.

There just needs to be a way for the buyside to transmit this information.

That’s where ECAPI comes into the picture.

The ECAPI (Event and Conversion API) Specification provides a repeatable and scalable playbook for the server-side measurement solution called Conversion API, also known as CAPI. The Tech Lab Working Group didn’t think ‘CAPI’ was representative of the events advertisers find valuable and want to measure or optimize against, so we expanded the scope with the name.

This customizable, shared technical framework addresses the current fragmented nature of CAPI setup by acting as a bridge between both buyers and sellers in the advertising ecosystem. It provides guidance for key pain points such as deduplication during processing, data quality verification, and event type classification, including upper-funnel, mid-funnel, lower-funnel, and custom actions, not just conversions.

Here’s what that means if your team works with Conversion APIs today.

For advertisers and data intermediaries already sending server-side events, adoption is straightforward. In most cases, it starts as a mapping exercise: review your event taxonomy against ECAPI’s standard event types, map user fields into the user_data object, and align your event_id strategy with the spec’s deduplication approach. ECAPI supports both real-time and batch delivery to fit into the way teams already operate.

For platforms and publishers, supporting ECAPI-formatted payloads as a standard inbound format does not mean rebuilding existing integrations from scratch. The spec’s ext object is designed to accommodate platform-specific fields without breaking the shared structure. In practice, that means standardization where it creates efficiency, with flexibility where it still matters.

The biggest benefit is the compounding effect over time. Every integration built to a shared spec is one less integration that has to be scoped, negotiated, and engineered from scratch. Across partners and platforms, that efficiency adds up quickly and makes signal interoperability achievable.

What do buyers and sellers need to do next?

ECAPI enables outcome-driven advertising if both advertisers and publishers work together. Here’s how to get started:

Advertisers/Buyers:

Share outcome signals (like sales, visits, leads) via standardized, server-side methods, like ECAPI
Focus on key outcomes, mainly bottom-funnel metrics and map existing events to ECAPI; you don’t need new events, just alignment with the standard.
Use ECAPI to transmit these signals so publishers can optimize for real results, not just impressions.

This gives advertisers real-time insight into campaign performance while keeping control of their data.

Publishers & Platforms (Sellers):

Support ECAPI as a standard format for incoming signals.
Use shared outcomes for better optimization.
Switch from delayed offline reports to real-time insights and automated improvements.

Every ECAPI integration streamlines engineering, speeds up onboarding, and boosts inventory value through measurable business impact.

ECAPI is now available for implementation. See the full specification in GitHub.