Hacia un nuevo estándar: ‘Conversions Table’ con Apache Iceberg

En el artículo de ayer expusimos los límites estructurales del modelo actual de Conversion API (CAPI). Hoy, vamos a ir un poco más allá de la crítica y vamos a plantear cómo se puede construir un sistema más eficiente, interoperable y privacy-forward desde la base de datos, no desde la API. La propuesta es muy clara: pasar de un modelo de múltiples “push” redundantes a un sistema “write once, read many”, sustentado por una Conversions Table compartida. Y para hacerlo realidad, Apache Iceberg es quizá una de las tecnologías más prometedoras.

¿Por qué Apache Iceberg?

Apache Iceberg es un formato de tabla abierto diseñado para el proceso de grandes volúmenes de datos analíticos en entornos distribuidos. No es una base de datos, sino una capa sobre el almacenamiento que permite que múltiples sistemas lean y escriban sobre una misma tabla con garantías de integridad, consistencia y gobernanza. Lo que lo hace especialmente atractivo para un modelo de conversión compartida es:

• Versionado de datos: cada inserción o modificación crea un nuevo snapshot auditable.

• Lectura incremental: los consumidores (publishers) pueden leer solo los datos nuevos desde la última lectura, sin sobrecargas.

• Multi-cloud y agnóstico: puede montarse sobre S3, GCS, Azure Blob o incluso on-prem. Compatible con engines como Snowflake, BigQuery, Dremio, Trino, Spark, etc.

• Soporte para esquemas evolutivos: permite modificar el esquema sin interrumpir la lectura.

• Integración natural con Data Clean Rooms: las mismas tablas pueden usarse en entornos colaborativos y controlados para análisis conjuntos.

¿Cómo funcionaría la Conversions Table en la práctica?

1. El anunciante mantiene una tabla Iceberg en su almacenamiento cloud: Este es la “fuente de la verdad”. La tabla contiene todos los eventos de conversión de forma estructurada y gobernada. Puede estar en un bucket de S3, GCS o Azure.

2. Cada Publisher accede a esa tabla como consumidor: Los Publishers acceden con permisos específicos (lectura, segmentación por marca o campaña, filtros temporales). Pueden conectarse vía motores compatibles o usar ETLs livianos.

3. El anunciante controla todo desde su lado: Puede revocar accesos, modificar el esquema, auditar accesos, definir qué campos se exponen (con hashing si es necesario) y limitar usos vía contratos o governance frameworks.

4. Opcional: integración con Data Clean Rooms: Las mismas tablas pueden conectarse a Data Clean Rooms para análisis de incrementalidad, LTV, path-to-conversion, sin necesidad de duplicar pipelines ni exponer datos innecesarios.

¿Es esto una utopía? No

Ya existen implementaciones parciales en marcha. Algunos grandes anunciantes están compartiendo eventos vía Iceberg (o formatos similares como Delta Lake o Hudi) con partners selectos. Otros están experimentando con integraciones en motores como Snowflake, Databricks o BigQuery. El reto no es técnico sino político y organizacional. Para que esto funcione a escala los publishers deben aceptar cambiar su modelo de ingestión de datos, los anunciantes deben invertir en data engineering, no solo en marketing tech y las plataformas deben colaborar en estándares abiertos de compartición de eventos.

Iceberg no es la única opción, pero quizá es la más robusta actualmente para lograr interoperabilidad y gobernanza real. En próximos artículos podemos analizar cómo implementar este modelo en entornos multi-cloud o cómo un framework legal (con logs, contratos y auditoría) puede reforzar la confianza entre partes, porque lo que está en juego no es solo eficiencia operativa, es la arquitectura misma del marketing basado en datos para la próxima década.

Puntos clave:

• Iceberg permite compartir datos sin copias ni fricción: Lectura incremental, versionado y control de acceso hacen que múltiples partners puedan consumir conversiones desde una misma fuente.

• La arquitectura es multi-cloud y abierta: Compatible con S3, GCS, Azure y múltiples motores de lectura (Snowflake, Trino, BigQuery, etc.), facilita la interoperabilidad sin depender de un vendor único.

• La Conversions Table es el puente hacia las Data Clean Rooms: usar la misma tabla para medición directa y análisis colaborativos (DCRs) reduce redundancias y fortalece el control sobre los datos sensibles.

Este resumen lo ha creado una herramienta de IA basándose en el texto del artículo, y ha sido chequeado por un editor de PROGRAMMATIC SPAIN.