What’s wrong with the Conversion API?

We need a “write once, read many” approach to conversions

Conversion API: A problematic solution

If you’re in the digital marketing or advertising world, you’ve undoubtedly encountered the Conversion API, or “CAPI.” Originally conceived primarily for capturing offline conversion events (like in-store purchases) and feeding them back to online advertising platforms, CAPI has quickly become a common standard in advertising. It allows advertisers to send customer actions directly from their servers to platforms like Meta, Google, TikTok, and others, aiming to improve ad targeting, measurement, and optimization, especially in a world of shrinking cookie utility.

Not every company is going to have this many CAPIs to integrate with; however, large enterprises looking for an omnichannel approach already, or soon will, feel this pain.

How does CAPI typically work? An advertiser collects conversion data (e.g., a purchase, a lead sign-up). They then make an API call to each relevant publisher or platform, “pushing” this event data. The platform / publisher ingests it, processes it, and (hopefully) uses it to make your ads work better.

The scope of CAPI has exploded. It’s no longer just for offline events, and it’s not just for the social media platforms; it’s increasingly used for all types of conversions by many publishers and adtech, both online and off, as a more robust alternative to client-side pixel tracking.

That said, CAPI, in its current common implementation, is riddled with problems:

• Multiple API Integrations & Destinations: Advertisers often work with numerous platforms. Each CAPI integration is a separate development effort, a distinct data pipeline to build and maintain. There is no standardization among publishers/platforms either. Keeping up with varying specs, authentication methods, and updates across a dozen APIs is a costly, time-consuming nightmare.
• Rampant Copies of Data: Every time you push a conversion event to a new API endpoint, you’re creating another copy of that data. This is massively inefficient from a data storage and processing perspective. Think about the duplicated compute cycles and storage — it’s not just inefficient, it’s arguably bad for the environment with all the redundant energy consumption.
• Not Inherently Privacy-Forward: While CAPI can be more privacy-centric than third-party cookies by allowing more control over what’s sent, the “push” model often means spraying sensitive conversion data across multiple third-party systems. While this data transfer might be unavoidable for measurement and optimization with those specific partners, especially Walled Gardens, it’s still a concern as it doesn’t properly protect the consumer data.

The Quest for a Better CAPI

In a nutshell, this is a data engineering problem. At Snowflake, we’ve commonly turned to Secure Data Sharing to solve data engineering problems when two or more parties are collaborating on data. Data sharing allows one Snowflake account to share data and logic to other Snowflake accounts without actually copying or moving the data. It’s a “zero-copy” approach where the consumer(s) gets live, read-only access to the provider’s data.

TTD REDS logs are available as a Secure Data Share in the advertiser / agency Snowflake account.

A prime example is how The Trade Desk provides REDS logs (their raw event data) back to advertisers using Snowflake data sharing — advertisers get their impression data directly in their Snowflake instance without cumbersome ETL.

An advertiser uses one conversions table for CAPI to TTD, but can also use that same conversions data for a publisher’s Data Clean Room.

In this case, we’ve tried the “other direction” to some success. This is where the advertiser created a conversions table and shared that to multiple publishers / adtech platforms. The publisher or platform can securely access the advertiser’s (buy-side) conversion data directly from the advertiser’s data warehouse in a zero-copy fashion. Using this method, the advertiser writes their conversions once into a designated share, and it can be used many times by various authorized publishers / platforms.

The big bonus: You could share your first-party conversions directly with a publisher for their CAPI needs, or you could use that same centrally-managed conversion dataset as an input into a Data Clean Room (DCR) for privacy-preserving analyses.

While popular with both advertisers and publishers, there are some friction points to adoption:

• Solutions like data sharing are fantastic, but as much as I wish it to be, not everyone is on Snowflake. This isn’t as helpful if publishers or advertising platforms are on different cloud data platforms or if you’re dealing with walled gardens that have their own prescribed methods.
• Often, even if data is “shared” across, publishers are merely just taking it and calling their own traditional CAPI endpoints with the data. While it eases the burden on the advertiser, which in turn is good for the publisher to get access to this data, it is merely a “better data pipeline” for both the advertiser and the publisher.

Towards a Truly Interoperable, Better Conversion Workflow

The ambition for a “better CAPI” isn’t misguided; we just needed to address these shortcomings. How do we fix this?

We need a system where advertisers (the buy-side) can write their conversions once, in a standardized way, that can then be securely consumed by many publishers (the sell-side) or other partners, like adtech platforms.

This ideal system should be:

1. Secure and Governable: The advertiser must maintain control, explicitly granting access and defining usage terms for their partners.
2. Fully Interoperable: It shouldn’t matter if the advertiser is on AWS, Google Cloud, or Azure, or what data platform the publisher uses. Openness is key.
3. Scalable: It needs to handle large volumes of conversion data efficiently.
4. DCR-Friendly: It should work beyond direct conversion sharing — it should also seamlessly integrate with Data Clean Rooms where advertisers can run their own analyses.

One naive idea: What if advertisers just maintained a CSV file in cloud storage (e.g. S3) for publishers to read from? The concept would be similar to ads.txt in nature, but instead will host conversions.

“conversions.txt”

While simple and straightforward, the “conversions.txt” idea falls apart very quickly. CSV files are not easily governable (who accessed what, when?), not scalable for frequent updates or large datasets, and lack schema enforcement, transactionality, or performance features needed for robust data sharing.

The real idea: What if advertisers (or someone on their behalf) maintained an Iceberg Table in their cloud storage for publishers to read from?

The Conversions Table

In the next blog, we’ll go into more technical details of how this will work with Apache Iceberg, and why it’s the right solution to future-proof CAPI and make it interoperable with Data Clean Rooms.

Special thanks to Myles Younger from Uof.Digital for the “conversions.txt” framing.