Eventbrite: Pipelines de Indexación Distribuidos que Generaron ~$576K/Año en Ingresos
Como Senior Software Engineer en Eventbrite (marzo 2022 - febrero 2025), definí la dirección técnica de los sistemas Tier-1 de SEO/Growth que alimentaban el homepage principal y las superficies de discovery. Esta es la historia de ingeniería detrás de la infraestructura de indexación distribuida y sitemaps que impulsó crecimiento orgánico medible.
El contexto
Eventbrite es una plataforma global de gestión de eventos y ticketing. Millones de eventos en cientos de categorías, cada uno con su propia página que necesita ser descubierta por motores de búsqueda. El desafío no era solo tener páginas. Era asegurar que los motores de búsqueda pudieran rastrear, entender e indexar las páginas correctas en el momento correcto.
Me uní al equipo de ingeniería de SEO/Growth y rápidamente alineé a los stakeholders de Ingeniería, Producto y Growth en una estrategia compartida para indexación, rastreabilidad y rendimiento. Los sistemas existentes funcionaban, pero tenían límites de escala que se hacían visibles a medida que el catálogo de eventos crecía.
La arquitectura: Indexación distribuida y sitemaps
El pipeline: Diseñé y construí pipelines de generación de indexación y sitemaps usando Airflow para orquestación, dbt para lógica de transformación, y Snowflake como data warehouse analítico. El pipeline procesaba el catálogo completo de eventos (filtrando por elegibilidad, frescura y señales de calidad) para producir sitemaps optimizados y directivas de indexación.
Por qué Airflow/dbt/Snowflake: Eventbrite ya tenía Snowflake como warehouse y Airflow para scheduling. Construir sobre el stack existente significó cero infraestructura nueva que provisionar, cero relaciones nuevas con vendors, y un equipo que ya sabía operar estas herramientas. dbt nos dio lógica de transformación versionada que el equipo de analytics de Growth también podía leer y revisar.
Optimización de crawl budget: Los motores de búsqueda asignan un "crawl budget" finito a cada sitio. Mis pipelines priorizaban páginas de alto valor (eventos populares, categorías en tendencia) mientras depriorizaban eventos vencidos y páginas de baja calidad. Esto no era una configuración única. Era un sistema dinámico que recalculaba prioridades en cadencia regular a medida que el catálogo de eventos cambiaba.
Arquitectura de sitemaps: En lugar de un sitemap monolítico, construí un sistema de sitemaps particionados organizados por categoría, ubicación y recencia. Esto daba a los motores de búsqueda señales claras sobre qué secciones del sitio habían cambiado, reduciendo crawl budget desperdiciado en contenido sin cambios.
Experimentación controlada
Cada cambio al pipeline de indexación pasó por experimentación controlada usando Statsig. Esto era crítico porque los cambios de SEO tienen ciclos de retroalimentación con delay y ruido. Los cambios en tráfico orgánico pueden tomar semanas en materializarse y están confundidos por estacionalidad, actualizaciones de algoritmos y comportamiento de competidores.
Diseño de experimentos: Trabajé con el equipo de Growth para diseñar experimentos que aislaran el efecto de cambios de indexación de otras variables. Usamos grupos de holdout a nivel de página cuando era posible, y análisis de series temporales cuando los holdouts no eran factibles.
La disciplina: Ningún cambio de indexación se desplegaba sin un experimento. Ningún experimento se declaraba sin alcanzar significancia estadística. Esto nos frenó en el corto plazo pero previno el anti-patrón SEO común de desplegar cambios basados en "parece que el tráfico subió."
Fiabilidad a escala
Lideré la fiabilidad de los servicios distribuidos de alto tráfico que alimentaban estas superficies. Esto no era solo escribir código. Era definir los estándares con los que todo el equipo operaba.
Gobernanza de SLO/SLA: Definí y revisé los objetivos de Service Level Objective y Service Level Agreement para nuestros sistemas, participando en foros de gobernanza Staff/Principal e impulsando mitigación de incidentes cross-team. Cuando algo se rompía a la escala de Eventbrite, el radio de impacto se medía en ventas de tickets perdidas y visibilidad de eventos.
Autoridad de escalamiento: Serví como autoridad de escalamiento hasta el nivel Director/VP durante incidentes que afectaban nuestros sistemas. Esto significaba ser la persona que podía explicar qué se rompió, por qué se rompió, y qué estábamos haciendo al respecto, en tiempo real, a liderazgo no técnico.
Resultados
| Métrica | Impacto |
|--------|--------|
| Crecimiento de impresiones orgánicas | ~15% de lift (experimento controlado) |
| Ingresos incrementales | ~$576K/año (atribuidos vía experimentación) |
| LCP (Core Web Vital) | 4.6s → 2.3s (vía proyecto complementario de caching) |
| Impresiones orgánicas YoY | +482% (efecto compuesto de múltiples iniciativas) |
La cifra de ~$576K/año fue el ingreso directamente atribuible a las mejoras del pipeline de indexación a través de experimentación controlada, no una correlación amplia, sino un lift medido de cambios específicos.
El crecimiento de +482% YoY en impresiones orgánicas fue el resultado compuesto de los pipelines de indexación, el trabajo de caching/deduplicación, y mejoras de rendimiento de página aterrizando juntos. Ninguna iniciativa individual generó el número completo. Así es como la infraestructura se compone: cada capa hace la siguiente más efectiva.
Aprendizajes
La experimentación es la única forma honesta de medir impacto SEO. Antes de tener experimentos, cada cambio de SEO era seguido por "el tráfico subió" o "el tráfico bajó" sin forma de atribuir causa. Statsig nos dio el rigor para decir "este cambio específico produjo este lift específico" con confianza. La inversión en infraestructura de experimentación se pagó sola inmediatamente al evitar que desplegáramos cambios que se sentían bien pero medían mal.
La fiabilidad es una feature de producto en SEO. Si tus páginas son lentas o no están disponibles durante una ventana de crawl, el motor de búsqueda se va con un competidor. Los SLOs no son solo para el equipo de SRE. Para superficies SEO, el uptime y la latencia afectan directamente la descubribilidad. Hice este argumento repetidamente en foros de gobernanza, y los datos lo respaldaron.
La alineación cross-funcional es más difícil que el código. La ingeniería era compleja pero resoluble. Lograr que Ingeniería, Producto, Growth y Analytics se pusieran de acuerdo en qué medir, cómo experimentar y cuándo desplegar fue el verdadero desafío. Pasé tanto tiempo en conversaciones de alineación como en código. Esa fue la asignación correcta. Un pipeline perfectamente diseñado en el que nadie confía ni entiende es inútil.
Construye sobre el stack existente. Evalué herramientas de infraestructura SEO especializadas y decidí en contra. Airflow, dbt y Snowflake ya eran entendidos, operados y presupuestados en Eventbrite. Agregar una herramienta nueva habría introducido carga operacional que compensaba cualquier ganancia marginal en capacidad. El movimiento de pensamiento sistémico fue construir dentro de las restricciones, no pelear contra ellas. Apliqué el mismo principio cuando modernicé la infraestructura de datos de FlowWest: construir sobre las herramientas que el equipo ya conocía en lugar de introducir nuevas.
Trabaja Conmigo en Algo Similar
Si estás tratando de impulsar crecimiento orgánico medible a través de pipelines de datos, infraestructura de experimentación u optimización de crawl, y quieres el tipo de atribución controlada que convierte "el tráfico subió" en un número que puedas defender, trabajo exactamente en esta clase de problema. El mismo enfoque de infraestructura de contenido que ofrezco como servicio está basado en las disciplinas desarrolladas en Eventbrite.
Explorar Servicios de Consultoría de IA o enviar una consulta - respondo dentro de un día hábil.