Event & Conversion APIs and Outcome Signals.
The outcome-signal layer: IAB Tech Lab’s ECAPI 1.0, the named event taxonomy, server-to-server transport, consent metadata, payload governance — and what trustworthy outcomes mean when agents do the optimizing.
This is a deep dive inside the six-layer standards system, not a seventh pillar. Conversion data has been the least standardized load-bearing layer in advertising: every platform built its own Conversion API, every advertiser rebuilt the same integration N times, and the numbers that steer budgets traveled in N different containers. ECAPI 1.0 is the cross-industry answer to the container problem. This page maps what the spec actually standardizes, what it deliberately leaves to implementers, and where outcome signals still have to earn their trust.
Outcome signals are the steering data of advertising. Until ECAPI, every platform defined its own container for them.
ECAPI standardizes how outcome events travel. It does not certify that the outcomes are true, deduplicated, or caused by the media.
Agents should not optimize against outcomes they cannot trust, interpret, or audit.
Status, precisely
ECAPI 1.0 was announced for public comment on January 20, 2026; the window closed February 20, 2026; and IAB Tech Lab’s April 28, 2026 post declares the specification finalized and available for implementation, with the canonical spec on GitHub.
Fast read
- What it is
- A deep-dive guide to outcome signals — the conversion and event data that advertising optimization steers on — anchored on IAB Tech Lab’s Event & Conversion API (ECAPI) 1.0, the cross-industry specification that standardizes how those signals travel server-to-server.
- What it covers
- ECAPI 1.0 status and scope, the named event taxonomy (purchase, generate_lead, install, subscribe, and more), payload and deduplication governance, the GPP consent fields gpp_string and gpp_sid plus the mmt_only measurement-only flag, the clean-room connection, and agentic optimization.
- What it is not
- Not an attribution methodology and not a replacement for incrementality — an event API reports that outcomes occurred; it does not establish that the marketing caused them. And not an adoption claim: contributor names in the spec are not platform commitments.
- Why it matters
- Optimization — human or agentic — is only as good as the outcome signals it steers on. ECAPI standardizes the container; trust, interpretation, and audit remain the implementer’s job.
- Best for
- AdTech, brand, agency, platform, retail media, measurement, and data-infrastructure leaders wiring outcome signals into buying systems and agentic workflows.
- Best next read
- Privacy & Consent Standards, Research & Measurement Science, and the Data Clean Rooms, PETs & PAIR deep dive.
Where ECAPI fits.
ECAPI sits where the measurement layer meets the privacy layer: a server-to-server specification for transmitting marketing events — from upper-funnel engagement through lower-funnel conversion activity — from advertiser systems to advertising platforms and partners, developed in IAB Tech Lab’s CAPI Working Group. Three facts orient everything else on this page: the spec is final and implementable; it is a shared layer over platform-specific Conversion APIs, not a replacement for them; and it standardizes transport and structure, not attribution or causality.
- Status — verified
Final and implementable
ECAPI was announced for public comment on January 20, 2026; the window closed February 20, 2026. IAB Tech Lab’s April 28, 2026 post states the 1.0 specification has been finalized and is now available for implementation, with the canonical spec maintained on GitHub (ecapi_1.0.md, CC BY 3.0). One Tech Lab download page still carries comment-period status language — cite the GitHub spec and the finalization post, not the stale page.
- The relationship
A layer over platform CAPIs
Per the launch press release, many platforms operate their own Conversion APIs that work individually but multiply custom integration work. ECAPI is the shared structure across them — it names no platforms as adopters, platforms may still require specific fields, and every object carries an ext extension object for platform-specific additions. Contribution to the spec is not adoption of it.
- The boundary
Not an attribution method
An event API standardizes how outcome events travel; it does not allocate credit and it does not establish cause. Attribution remains a modeling choice, and incrementality remains an experimental discipline — ECAPI feeds both and replaces neither.
Status discipline
Public-comment language survives on official pages after specs finalize. The April 28, 2026 finalization post and the GitHub spec are the status of record — validate current status before citing.
Why outcome signals are hard.
Conversion data looks like the most objective signal in advertising — a purchase happened or it did not. In practice, eight realities stand between an event in an advertiser’s system and a number an optimizer can be trusted with.
- 01
Every platform speaks its own CAPI
The IAB Tech Lab launch framing is blunt: many advertising platforms operate their own versions of Conversion APIs, and integrating with multiple partners often requires custom development work due to differences in structure and requirements. ECAPI exists to standardize that container.
- 02
The same outcome means different things
What counts as a purchase, a lead, or a trial varies by team, system, and platform. Named events only help when the internal mapping — your event dictionary — is written down, owned, and versioned.
- 03
Duplicates inflate everything
The same conversion can arrive via a client-side tag and a server event. ECAPI keys deduplication on the combination of data_set_id and event id; without enforced dedup, the optimizer double-counts and the readout flatters.
- 04
Matching is never total
user_data carries hashed identifiers — email, phone, customer IDs, ifa, click_id — and match rates vary by channel and consent state. An unmatched event is invisible to optimization, and that absence is itself a bias.
- 05
Consent state must travel with the event
ECAPI gives consent a seat in the schema: gpp_string and gpp_sid per event. Carrying them correctly for each jurisdiction is the implementer’s work — the spec explicitly leaves legal compliance to implementers.
- 06
Measuring and optimizing are different permissions
Some events may inform reporting but must not steer ads delivery. The mmt_only flag makes that boundary machine-readable — and meaningless unless both sender and receiver actually enforce it.
- 07
Timing skews the signal
Server events arrive late; refunds arrive later; offline confirmations later still. An optimizer reading a partial window learns the wrong lesson with full confidence.
- 08
Reported is not caused
Event feeds report outcomes after exposure or click. Causality needs experiments — optimizing on raw conversions can reward the channels best at harvesting demand that already existed.
The ECAPI event taxonomy.
The spec defines a named set of standard events spanning the funnel — the finalization post describes classification across upper-funnel, mid-funnel, lower-funnel, and custom actions, “not just conversions” — plus Additional Events and a custom type. The rows below group representative event names with the governance question each group raises. The names are standard; what they mean in your business still has to be written down.
| Funnel layer | ECAPI events (examples) | What to govern |
|---|---|---|
| Commerce | purchase · refund | Value, currency_code, and transaction_id integrity. Refunds must flow back and be subtracted, or every return-style readout overstates. |
| Cart & checkout | add_to_cart · begin_checkout · add_payment_info | Intent is not outcome — optimizing to checkout starts when purchase is the goal rewards abandonment. |
| Discovery | page_view · search · view_search_results | High-volume, low-cost signals. Weight them deliberately or they drown the funnel. |
| Lead lifecycle | generate_lead · qualify_lead · close_convert_lead | Three distinct stages — agree which one is the optimization target, and mind CRM write-back latency. |
| Accounts | sign_up | A sign_up definition — form fill or verified account — must be written down before it steers spend. |
| App & subscription | install · start_trial · subscribe | Trial-to-paid definitions, and store-reported versus server-reported truth, need explicit reconciliation. |
| Media exposure | ad_impression | An exposure logged as an event is not a viewable impression — do not conflate it with MRC viewability metrics. |
| Local & service | contact · schedule · find_location · donate | Offline handoffs confirm late. Timestamp the action, not the confirmation that eventually arrives. |
| Custom & extended | custom · Additional Events · ext objects | Naming governance — undocumented custom events become unauditable optimization inputs. |
The discipline
Do not cite exact event counts — the taxonomy is best treated as a named, extensible vocabulary. The spec’s own guidance is to start with each receiving platform’s requirements, because platforms may require specific fields.
Event payload governance.
An ECAPI event is an HTTPS POST of JSON: an event object (data_set_id, id, timestamp, event_type, value, currency_code, source, properties), a user_data object of hashed match identifiers, and consent metadata — gpp_string, gpp_sid, and the mmt_only measurement-only flag. The schema is the easy part. The fifteen-point checklist below is the part that decides whether the feed can be trusted.
- Dedup keys — every event carries a stable id, and the data_set_id + id combination is unique; duplicates inflate every downstream number.
- Event dictionary — a written mapping from each internal event to its ECAPI event_type, owned and versioned like code.
- custom_event naming — custom events follow a convention with an owner; no ad-hoc names in production feeds.
- Timestamp integrity — event time reflects when the action happened, in the expected format, with clock skew monitored.
- Value and currency — value plus currency_code validated at the source; mixed or assumed currencies corrupt return-style readouts.
- transaction_id — carried in properties for commerce events so refunds and reconciliations can be tied back.
- Refund flow — refund events actually flow, and downstream consumers actually subtract them.
- Identifier hashing — user_data identifiers hashed per the spec’s expectations before transmission; raw PII never leaves by accident.
- Data minimization — send the identifiers a match requires, not every identifier you hold.
- gpp_string per event — the Global Privacy Platform consent string travels with each event, not as a global assumption.
- gpp_sid correctness — the applicable GPP section IDs match the user’s jurisdiction.
- mmt_only enforcement — measurement-only events are flagged, and the receiving side’s use is verified where supported.
- Platform field review — each receiving platform’s required fields and guidance reviewed before launch; the spec itself says implementations should start there.
- ext discipline — platform-specific ext usage documented per integration, so the shared structure stays shared.
- Retention and audit — a log of what was sent, to whom, under what consent state, with a retention and erasure policy attached.
The point
Every object in the spec allows an ext extension object — flexibility by design. Undocumented ext usage is how a shared standard quietly fragments back into N integrations.
Consent and privacy metadata.
ECAPI’s most consequential design decision is that consent rides inside the payload. Three fields carry it — and one explicit disclaimer bounds it.
- Built into the schema
GPP travels with the event
ECAPI carries consent as data: gpp_string holds the Global Privacy Platform consent string and gpp_sid the applicable GPP section IDs — per event, not per integration. Public documentation describes these as the spec’s consent mechanism; it does not mandate TCF strings or any specific consent regime.
- The measurement fence
mmt_only
A boolean flag marking an event as measurement-only: it may inform reporting and analysis but must not be used to optimize ads delivery. It is the spec’s most operationally interesting field — a machine-readable boundary between measuring and targeting — and it only means something if both sender and receiver enforce it.
- Where liability stays
Compliance is not conferred
The specification explicitly disclaims legal-compliance guarantees. Carrying GPP fields correctly is necessary plumbing, not a legal conclusion — whether a given event flow is lawful in a given jurisdiction is the implementer’s question, answered with counsel rather than a schema.
Event APIs and clean rooms.
Event APIs and clean rooms solve adjacent halves of the same problem. An event API moves the advertiser’s outcome signal to the parties optimizing and reporting on media; a clean room joins outcome data with exposure data under controlled conditions. The loop below shows where each belongs — and where the incrementality read keeps both honest.
- Event APIs move outcomes; clean rooms join them. ECAPI standardizes the feed from advertiser systems to platforms and partners; collaboration environments govern the match between outcomes and exposure.
- Consent metadata must survive the journey — the gpp_string, gpp_sid, and mmt_only state attached to an event should constrain what any downstream join is permitted to output.
- Aggregation is not absolution. Joining event-level outcomes to exposure inside a clean room still needs output policy — a clean room without output policy is just a safer room with an unsafe door.
- Neither layer establishes cause: a joined, governed dataset is the input to incrementality work, not a substitute for it.
Agentic measurement.
IAB Tech Lab’s own announcement points here: the launch quote from its CEO references “testing agentic optimization of outcomes.” A standardized event vocabulary is exactly the structure agents need — and exactly the kind of input that fails quietly when it is wrong. The house rule: agents should not optimize against outcomes they cannot trust, interpret, or audit. Six implications follow.
- 01
A shared vocabulary is agent fuel
Named events let an agent reason across platforms without N bespoke mappings — and IAB Tech Lab’s own launch quote points here, referencing testing agentic optimization of outcomes. The structure is arriving; the governance is not automatic.
- 02
Trust is a gate, not a vibe
Schema validity, dedup keys present, timestamps sane, consent metadata attached — checked before a signal is allowed to steer budget. Signals that fail the gate inform investigation, not optimization.
- 03
Interpretation is part of the job
Value and currency normalization, refund subtraction, funnel-stage weighting. An agent that treats begin_checkout like purchase misprices everything it buys.
- 04
mmt_only is a machine-readable fence
Agents must read and respect measurement-only flags. An optimization loop that ingests mmt_only events for delivery decisions crosses a boundary the payload itself declared.
- 05
Audit lineage or it did not happen
Log which events fed which decision. If an optimization cannot be reconstructed from its inputs, it cannot be audited — and an unauditable optimization should not scale.
- 06
Close the loop with experiments
Agents optimizing raw conversions amplify their own selection effects. Periodic incrementality reads are the external honesty check that event-fed optimization cannot supply for itself.
CAPI vs ECAPI vs attribution.
These layers get conflated in roadmap decks. They answer different questions — and each carries a watch-out that the conflation hides.
| Layer | Role | Watch-out |
|---|---|---|
| Client-side tags & pixels | Browser- and app-side event collection — the original conversion plumbing | Signal loss and blocking are why server-side exists; dedup client events against server events or count twice |
| Platform CAPIs | Each platform’s own server-to-server conversion endpoint, schema, and requirements | N platforms means N integrations and N schemas; platforms retain required fields even where shared standards exist |
| ECAPI (IAB Tech Lab) | The shared standardization layer: one event structure, named taxonomy, GPP consent fields, ext for platform specifics | A container standard, not an adoption guarantee or a compliance shield — map each platform’s guidance, and treat contributor lists as contribution, not adoption |
| Attribution models | Allocate credit for outcomes across touchpoints | Models, not observations — rules differ per platform, and cross-platform attribution numbers are not comparable truths |
| Incrementality & experiments | Establish the causal impact of marketing through test-versus-control designs | Slower and costlier than dashboards — which is why they get skipped, and why event-fed optimization drifts without them |
| Marketing mix modeling | Top-down, aggregate read on budget-level effectiveness | Coarse granularity and long cycles — pairs with event-level signals rather than replacing them |
Implementation lens.
The same specification lands differently depending on where you sit in the chain. Select your company type for the version of this page that applies to you.
Own the event dictionary, the dedup keys, the refund flow, and the consent capture — those decide what every downstream number means. Map internal events to ECAPI names deliberately, and demand documentation of how each receiving platform uses what you send.
Maintain the cross-platform mapping matrix: which internal events map to which ECAPI names, which platforms require which fields, where ext objects diverge. QA the feeds you optimize against, and keep optimization targets pinned to outcomes, not intent stages.
The finalization post’s ask to platforms is to support the ECAPI format. Engineering that support means documenting required fields and ext usage, enforcing dedup on receipt, and honoring consent metadata — including keeping mmt_only events out of delivery optimization.
Conversion-rich by construction — and the same event-governance questions apply to closed-loop claims. Align event definitions with your retail media measurement vocabulary, keep refunds and returns in the loop, and treat outcome attribution claims with the same incrementality discipline.
Disclose match methodology, dedup logic, and the gap between reported and matched events. Build incrementality reads on top of event feeds rather than presenting feeds as causal evidence — and label which is which in every readout.
You are the pipes: schema validation against the spec, identifier hashing, GPP consent propagation, retry and dedup semantics, retention controls. The difference between a standard and a mess is enforced at this layer.
Sell-side teams are increasingly asked to prove outcomes, not just delivery. Understand what advertisers’ event feeds can and cannot show, and keep your outcome narratives inside what a server-to-server event actually proves — exposure-to-outcome stories still need experiments.
Event feeds are join inputs. Carry the consent metadata through the join, let mmt_only state constrain outputs, and make output policy explicit — the value of a governed join is the governance.
No Fluff POV.
ECAPI is genuinely useful standards work: it attacks the N-integrations tax on outcome signals with a shared schema, named events, and consent metadata in the payload. What it does not do is make outcome signals true. The container is standardized; the contents are still yours — definitions, dedup, refunds, consent state, and the discipline to keep measurement-only data out of optimization. Teams that adopt the schema and skip the governance get faster pipes for the same dirty water.
- Say the status precisely: announced January 20, 2026; public comment closed February 20, 2026; finalized and available for implementation per the April 28, 2026 Tech Lab post — cite the GitHub spec, not stale download-page language.
- Treat ECAPI as a container standard: it standardizes how outcome events travel, not whether the outcomes are true.
- Contribution is not adoption: contributor names in the spec are not platform commitments — validate each platform’s actual support directly.
- Wire consent in, not on: gpp_string, gpp_sid, and mmt_only are schema fields — carry them per event and honor them downstream.
- Keep measurement and optimization permissions separate: mmt_only only works if your pipeline — and your partner’s — enforces it.
- Pair event feeds with experiments: an event API reports outcomes; incrementality establishes cause — never let an agent confuse the two.
The point
Agents should not optimize against outcomes they cannot trust, interpret, or audit. ECAPI standardizes the container those outcomes travel in — the trust, the interpretation, and the audit are still built, not bought.
Primary sources to validate.
Standards, guidance, and implementation references last validated: June 2026. Specifications, public-comment status, frameworks, APIs, and implementation guidance change. Validate against official documentation before implementation.
Primary sources to validate 7 sources
- ECAPI (Event and Conversion API) Specification — standards page ↗ Official standards page
Official ECAPI landing page. Describes ECAPI as defining a set of full-funnel events of interest to advertisers, transmitted server-to-server from advertisers to advertising platforms/partners for campaign optimization and measurement. States the specification 'was in Public Comment until Friday, February 20, 2026' and links to v1.0 on GitHub. For current status (finalized, available for implementation) cite the GitHub spec and the April 2026 finalization blog post — some Tech Lab pages retain stale public-comment-era language. Supports: Definition of ECAPI, Public-comment close date (Feb 20, 2026), Server-to-server scope, Canonical spec location.
- IAB Tech Lab Announces Event and Conversion API (ECAPI) For Public Comment ↗ Official press release
January 20, 2026 announcement of ECAPI for public comment until February 20, 2026. Frames the problem: 'Many advertising platforms operate their own versions of Conversion APIs... integrating with multiple partners often requires custom development work due to differences in structure and requirements.' Quotes Anthony Katsur (CEO, IAB Tech Lab) — including a reference to 'testing agentic optimization of outcomes' — plus individuals from Meta and Publicis Sapient. Supportive quotes are not adoption commitments; no platform adoption of ECAPI is published. Supports: Announcement date and comment deadline, IAB framing vs platform-specific CAPIs, Official quotes (attributed).
- InteractiveAdvertisingBureau/ecapi (GitHub repository) ↗ Official GitHub
Canonical home of the ECAPI v1.0 specification. README: 'The Event & Conversion API (commonly known as CAPI) is designed to standardize communication of marketing-related events from advertisers' systems to advertising platforms and partners.' Contains ecapi_1.0.md, examples.md, assets/. Licensed Creative Commons Attribution 3.0. Supports: Canonical spec repo, License (CC BY 3.0).
- ECAPI 1.0 specification (ecapi_1.0.md) ↗ Official GitHub
Full spec text. Server-to-server HTTPS POST JSON transport; event object (data_set_id, id, timestamp, event_type, value, currency_code, source, properties incl. transaction_id, user_data); user_data carries hashed/match identifiers (email_address, phone_numbers, customer_identifier, uids, ifa, click_id, impression_id, etc.); consent/privacy fields gpp_string (GPP consent string), gpp_sid (applicable GPP sections), and mmt_only (boolean: measurement-only, excludes ads-delivery optimization). Named standard-event taxonomy (purchase, page_view, ad_impression, add_to_cart, begin_checkout, generate_lead, sign_up, install, subscribe, custom, etc.) plus Additional Events — avoid exact event counts. Every object allows an 'ext' extension object; dedup keyed on data_set_id + event id. Spec does not name Meta/Google as adopters; contributor individuals are listed (Meta, Google, Walmart, NBCUniversal, Paramount, Roku, etc. — contributors, NOT adoption). Legal compliance (GDPR/CCPA) is left to implementers — the spec disclaims compliance guarantees. Supports: Event taxonomy and schema structure, Consent metadata (gpp_string, gpp_sid, mmt_only), ext extension mechanism and dedup rules, Contributor list (not adoption).
-
Published April 28, 2026. States 'The ECAPI 1.0 specification has been finalized' and 'ECAPI is now available for implementation,' linking to the full spec on GitHub. Describes ECAPI as a standardization layer (not a replacement for platform CAPIs) that accommodates platform-specific fields via the ext object 'without breaking the shared structure,' covering upper-funnel, mid-funnel, lower-funnel, and custom actions — not just conversions. This blog post (not a press release) is the finalization announcement of record. Supports: Current status: ECAPI 1.0 final, available for implementation, Finalization date (April 28, 2026), Standardization-layer framing.
- ECAPI Specification — Measurement standards page (stale comment-era status language) ↗ Official standards page
Alternate ECAPI page under Measurement standards, hosting the public-comment PDF. CAUTION: this download page carried 'Open for Public Comment until February 20, 2026' status language ('Last updated: January 28, 2026') after the comment window — stale relative to the April 28, 2026 finalization. Cite the GitHub spec and finalization blog for current status, not this page's status line. Supports: Comment-window status language (historical), Public-comment PDF location.
-
The January 2026 public-comment draft of the spec; links to the CAPI Working Group page, confirming the spec was developed within IAB Tech Lab's CAPI Working Group. Historical artifact only — superseded by the finalized GitHub spec (ecapi_1.0.md) for all content citations; no post-comment changelog was published. Supports: Existence of the January 2026 public-comment draft, CAPI Working Group provenance.
Platform capabilities and naming change quickly. Last validated: June 13, 2026. Check current documentation before implementation.Standards, guidance, and implementation references last validated: June 2026. Specifications, public-comment status, frameworks, APIs, and implementation guidance change. Validate against official documentation before implementation.
Wiring outcome signals into buying systems or agentic workflows?
The operating work is to govern the event dictionary, dedup keys, consent metadata, and audit lineage before optimization scales on whatever the pipeline happens to emit — and to keep an incrementality read in the loop so the feed stays honest.