Building a Marketing Engineering Platform using Next.js, Cloudflare, and Contentful

Encontrar el equilibrio adecuado entre ingeniería y marketing siempre ha sido un reto. En los proyectos de ingeniería, uno se centra principalmente en la experiencia del usuario (UX) y, posteriormente, en la experiencia del desarrollador (DX) que se necesita para llegar a ella. Pero cuando se añade el marketing a la ecuación, hay que tener en cuenta la experiencia de las partes interesadas en el marketing, incluidos el equipo de contenidos y los diseñadores.

Históricamente, el marketing en DoorDash ha estado dividido por el mercado tripartito de DoorDash con Consumidor, Dasher (repartidores) y Comerciante, todos con sus propios sitios web, contenido, diseño y apoyo de agencias externas. A medida que crecía el número de sitios web de marketing externos, la calidad, la coherencia y la capacidad de gestión de estos sitios web externos comenzaron a resentirse.

Como los primeros ingenieros contratados dentro del grupo de Marketing de Crecimiento de DoorDash, empezamos con la tesis de que la velocidad, el rendimiento, la unificación y la incorporación de las mejores prácticas de ingeniería al marketing son principios importantes. Pasamos 2021 construyendo una plataforma escalable y de alto rendimiento que permitiera a los profesionales del marketing estandarizar y escalar a nivel internacional -sin necesidad de ingenieros o diseñadores después de la configuración inicial- todo en una plataforma unificada, agnóstica para equipos multi-tenant.

Simplificar y luego aligerar (problemas de los CMS heredados)

El marketing en DoorDash en septiembre de 2020 era una época más sencilla. A la empresa le quedaban unos meses para su oferta pública inicial (OPI) y COVID-19 había cambiado por completo el panorama de la restauración para peor. La misión inicial era crear un equipo web y gestionar el sitio web de adquisición de comerciantes(get.doordash.com), responsable de más del 50% de las inscripciones de restaurantes para la empresa.

El CMS heredado estaba siendo llevado al límite. Los problemas incluían:

• Plantillas y reutilización mínimas: los componentes, navegadores, encabezados y pies de página estaban desincronizados y eran incoherentes tras años de ediciones manuales.
• No hay coherencia de marca ni de interfaz de usuario/UX entre los sitios web.
• El 99% del contenido no se tradujo
• Las analíticas fallaban: etiquetas duplicadas y errores de consola.
• Los eventos y las consultas no estaban documentados
• Las páginas se clonaron y se conectaron manualmente a las campañas de Salesforce.

Además del sitio web de adquisición de comerciantes, había casi dos docenas de otros sitios web en un estado similar dentro de DoorDash. No es de extrañar que los equipos tuvieran la costumbre de recurrir a agencias externas para lanzar micrositios aislados en una mareante variedad de plataformas externas. 

Todos estos equipos intentaban hacer demasiado, de forma demasiado manual y demasiado lenta. Teníamos que cambiar de marcha y crear una plataforma que estableciera barandillas de UI/UX y promoviera las mejores prácticas de ingeniería, ayudando a la empresa a ampliar sus sitios web de marketing a escala mundial.

Construcción de un Ferrari (o generación de sitios estáticos con Next.js)

DoorDash es una tienda de React y TypeScript, con un sistema de lenguaje de diseño y una biblioteca de componentes de interfaz de usuario compartida llamada Prism, gestionada por nuestro equipo de diseño. Querríamos elegir una pila que fuera coherente, manejable y alineada con los valores de otros equipos de ingeniería; recuerda, el objetivo de este proyecto es la unificación, no la división.

Empezamos con el sitio web de adquisición de comerciantes y estábamos decididos a construir un "Ferrari" que estuviera optimizado en cuanto a velocidad y rendimiento, y necesitábamos construir una plataforma que pudiéramos reutilizar y aprovechar para otros sitios web huérfanos más adelante.

Con las actualizaciones del algoritmo de Google (Web Vitals) en el horizonte, habría un enfoque renovado en el rendimiento, la velocidad de la página y la experiencia del usuario. La generación de sitios estáticos era el camino obvio a seguir, y nuestras opciones se redujeron rápidamente a Gatsby y Next.js.

Hicimos pruebas de concepto para ambos frameworks y quedamos impresionados con la velocidad de generación de sitios estáticos. Sin embargo, la experiencia del desarrollador de Next.js se sentía mucho más como una extensión natural de React, y fue amor a primera prueba, por varias razones:

• Listo para la producción (estamos en buena compañía con otros usuarios empresariales)
• Gran apoyo comunitario
• Compatibilidad con TypeScript

Denominaríamos internamente a este proyecto "Proyecto Ferrari". A continuación, tendríamos que encontrar un sistema de gestión de contenidos (CMS) que pudiera seguir el ritmo.

Navegar por el panorama de la gestión de contenidos 

Dejando a un lado la pila, sabíamos que necesitaríamos un CMS sin cabeza para que los profesionales del marketing y la redacción pudieran crear y gestionar contenidos sin la ayuda de un ingeniero y un diseñador.

Redujimos la lista de candidatos a un puñado de sistemas de gestión de contenidos, de los que sólo unos pocos cumplían nuestros estrictos requisitos de seguridad y cumplimiento de normativas, y aún menos nos parecieron tan completos, documentados y veteranos como Contentful, con las siguientes características que hicieron que la decisión fuera sencilla:

• Traducción y localización (i18n y l10n)
• Integración de SAML SSO para la gestión centralizada de permisos de cuenta
• Certificaciones de seguridad (ISO 27001 y/o SOC2 Tipo II)

Una vez definida la pila tecnológica y el sistema de gestión de contenidos, necesitábamos alinearnos con los objetivos técnicos del proyecto.

Definición de los objetivos técnicos del proyecto

Necesitábamos asegurarnos de que la plataforma que estábamos construyendo fuera fácilmente reutilizable y escalable más allá del sitio web de adquisición de comerciantes que estábamos utilizando como piloto inicial. Pensando en nuestros objetivos a largo plazo para el proyecto, sabíamos que necesitábamos:

• Cree una plataforma web multiarrendatario y agnóstica para equipos
• Centralizar la gestión de contenidos en todas las principales propiedades web de marketing
• Centrarse en la creación de plantillas y en compartir componentes para lograr una interfaz de usuario y una interfaz de usuario unificadas.
• Normalizar y documentar los análisis y el seguimiento de eventos
• Optimización del rendimiento: Google Web Vitals, velocidad de la página y SEO
• Vivir y respirar la accesibilidad(a11y), la internacionalización(i18n) y la localización(l10n)

Internacionalización (i18n) como inclusión

Cuando empezamos este proyecto, DoorDash estaba oficialmente en funcionamiento en Estados Unidos, Canadá y Australia, y presionamos a los vendedores para que empezaran a pensar en la internacionalización como inclusión: todas las campañas lanzadas en Estados Unidos debían incluir tanto inglés como español. Al mismo tiempo, Canadá exigía tanto el inglés como el francés (con una aplicación estricta en Québec).

En 2021, también nos lanzamos en Japón y Alemania: nuestras necesidades lingüísticas en la web crecían exponencialmente, mucho más rápido de lo que el equipo podía gestionar manualmente en la antigua plataforma.

Fortunately, Contentful has built-in connectors for popular services such as Memsource or Smartling, making it easy for marketers to manage translations and localization directly in the CMS (see Figure 1 below). In the code, we went with an extremely lightweight package (<300 bytes, including dependencies) called Rosetta (Next.js code example here).

Configuración de CI/CD y alojamiento

En este punto, estábamos tratando de averiguar dónde alojar nuestro proyecto Next.js. Supongamos que tuviéramos que aprovechar la infraestructura existente en DoorDash. En ese caso, tendríamos que dockerizar Next.js, integrarlo con las canalizaciones de CI/CD de Jenkins existentes y encontrar una forma de alojarlo en AWS, lo que requeriría contratar ingenieros de DevOps adicionales para ayudar a configurar y administrar esta infraestructura, una tarea y un alcance mucho mayores de lo que nuestro pequeño equipo de ingeniería de marketing podría manejar.

Tenía que haber una manera más fácil. Simplemente queríamos enviar código a un repositorio, activar una compilación (automáticamente con webhooks) y desplegar un sitio web en cuestión de minutos. 

También queríamos que nuestro equipo pasara más tiempo trabajando en proyectos de marketing en lugar de dedicarse a gestionar la infraestructura de CI/CD. Y lo que es más importante, era urgente que nuestro trabajo repercutiera directamente en los restaurantes y los comerciantes con mayor rapidez (nos encontrábamos en la oleada pandémica del invierno de 2021 y los restaurantes volvían a cerrar sus puertas).

Despliegue en la periferia

Por casualidad, nos tropezamos con un debate en Hacker News sobre una entrada del blog de Cloudflare titulada "Presentamos Cloudflare Pages: la mejor forma de crear sitios web JAMstack". En los comentarios, había respuestas interesantes de ingenieros y jefes de producto de Cloudflare. Después de investigar un poco, nos pusimos en contacto con ellos para preguntarles si nos podían dar acceso a la versión beta de Cloudflare Pages.

Cloudflare Pages se encarga del proceso de creación y despliegue con un simple "git push" y ya sabemos que las páginas estáticas generadas por Next.js son rápidas... Pero, ¿y si pudiéramos crear y desplegar páginas estáticas directamente en el borde de la red global de Cloudflare (véase la Figura 2 a continuación)? 

Exactamente 18 minutos después de ponernos en contacto con Cloudflare, recibimos una respuesta de un responsable de producto con luz verde y cuentas de prueba. Y esa ha sido nuestra experiencia y relación con Cloudflare desde entonces: rápida, enérgica, colaborativa y abrumadoramente positiva. Por fin teníamos el camino despejado.

Medición del rendimiento y Web Vitals

Los meses de febrero a abril transcurrieron con el acelerador afondo y completamente borrosos. Nuestro equipo se encargó del diseño UI/UX y de las maquetas, utilizando Prism. Pero pronto nos dimos cuenta de que nuestro pequeño equipo no sería capaz de crear y migrar miles de páginas de marketing antes del verano.

Como era de esperar, nuestros accionistas querían ver qué tiempos de vuelta podía conseguir nuestro supuesto Ferrari (en producción) antes de comprometerse con toda la migración y nos animaron a realizar una prueba A/B.

Para probar y realizar un seguimiento de nuestro rendimiento en el mundo real, tendríamos que estandarizar los eventos de análisis y medir la experiencia del usuario y la conversión de registros en el sitio web. Utilizamos la llamada a la API "track" de Segment.io con la siguiente carga útil del proyecto "web-vitals":

const WebVitalNameMap = {
 ['FCP']: SegmentEventName.WEB_VITALS_FCP,
 ['LCP']: SegmentEventName.WEB_VITALS_LCP,
 ['CLS']: SegmentEventName.WEB_VITALS_CLS,
 ['FID']: SegmentEventName.WEB_VITALS_FID,
 ['TTFB']: SegmentEventName.WEB_VITALS_TTFB,
}
 
export function trackWebVital(name: string, id: string, value: number): void {
 const segment = useSegment()
 const eventName = WebVitalNameMap[name]
 
 if (eventName) {
   segment.track(eventName, {
     version: SegmentEventVersions.NewMxWebsite,
     page_name: window?.location?.pathname || '',
     page_url: window?.location?.href || '',
     id,
     value,
   })
 } else {
   console.warn(`Web Vital Name Map Missing: ${name}`)
 }
}

A continuación, transferimos los datos de los eventos a Amplitude (véase la figura 3), donde podemos crear fácilmente gráficos para realizar un seguimiento del rendimiento. Obsérvese que la tendencia a la baja en rojo es positiva (estamos añadiendo ligereza y reduciendo los tiempos de vuelta de nuestras métricas Core Web Vitals con cada versión de código):

Pruebas A/B con Cloudflare Workers

Ahora que todas las piezas estaban en su sitio, era el momento de lanzar la primera versión de nuestro nuevo sitio web de forma controlada. Creamos una prueba A/B para nuestra página de mayor tráfico y el punto de entrada para la incorporación de comerciantes en get.doordash.com.
Pero, ¿cómo podíamos dividir eficazmente el tráfico al 50/50 entre nuestro antiguo CMS y un nuevo CMS y plataforma en una pila completamente diferente, a la vez que utilizábamos sin problemas la misma estructura de URL y subdominio? Cloudflare Workers y el equipo de ingeniería de tráfico de DoorDash al rescate:

// https://developers.cloudflare.com/workers/examples/ab-testing
 
function handleRequest(request) {
 const NAME = "experiment-0"
 
 // The Responses below are placeholders. You can set up a custom path for each test (e.g. /control/somepath ).
 const TEST_RESPONSE = new Response("Test group") // e.g. await fetch("/test/sompath", request)
 const CONTROL_RESPONSE = new Response("Control group") // e.g. await fetch("/control/sompath", request)
 
 // Determine which group this requester is in.
 const cookie = request.headers.get("cookie")
 if (cookie && cookie.includes(`${NAME}=control`)) {
   return CONTROL_RESPONSE
 }
 else if (cookie && cookie.includes(`${NAME}=test`)) {
   return TEST_RESPONSE
 }
 else {
   // If there is no cookie, this is a new client. Choose a group and set the cookie.
   const group = Math.random() < 0.5 ? "test" : "control" // 50/50 split
   const response = group === "control" ? CONTROL_RESPONSE : TEST_RESPONSE
   response.headers.append("Set-Cookie", `${NAME}=${group}; path=/`)
 
   return response
 }
}
 
addEventListener("fetch", event => {
 event.respondWith(handleRequest(event.request))
})

En cuestión de semanas, el equipo de análisis de DoorDash ondeó la bandera a cuadros y confirmó que nuestra nueva plataforma se tradujo en un aumento del +12,12% en la conversión de clientes potenciales y del +21,33% en la tasa de conversión de ventas cerradas (con una significación estadística del 99%).

Más allá de la conversión de registros, mejoramos el tiempo de permanencia en el sitio en un +95,5% y elevamos las Web Vitals en general, disminuyendo el LCP en un 30,5% (véase la Figura 4). La métrica Largest Contentful Paint, según Google, "es una métrica importante y centrada en el usuario para medir la velocidad de carga percibida, ya que marca el punto en la línea de tiempo de carga de la página en el que es probable que se haya cargado el contenido principal de la página...".

Los resultados de la prueba A/B superaron con creces las expectativas y supusieron una validación muy necesaria de meses de duro trabajo. Ahora que nos habíamos probado a nosotros mismos y nuestra plataforma, pasaríamos al largo y arduo proceso de crear, probar y desplegar una biblioteca de componentes de interfaz de usuario reutilizables, documentación y formación del equipo de marketing sobre cómo utilizar Contentful para crear páginas sobre la marcha, sin necesidad de que un ingeniero o diseñador creara código personalizado o maquetas para todos y cada uno de los proyectos.

Spinning up a new website is now only a matter of minutes – simply add a project to the monorepo, provision Contentful accounts, setup a Cloudflare Worker, and you're off to the races! Did we somehow manage to capture the bleeding-edge performance of a Ferrari with the long-term vision, scalability, and reliability of The Toyota Way?

Ampliación de la plataforma

Dado el éxito del sitio web inicial, quedó claro que el objetivo global del equipo de Ingeniería de Marketing sería ampliar y gestionar nuestra plataforma multiinquilino, independiente del equipo, que podría ayudar a todos nuestros equipos de marketing a unificar su presencia en la web y ampliarla.

A medida que la plataforma crecía (véase la Figura 5), ayudamos a la empresa a expandirse más allá de los restaurantes a otros sectores verticales (como alimentación, alcohol, conveniencia, flores, etc.) y a lanzarse a nuevos mercados internacionales (Japón y Alemania), poniendo a prueba cada uno de los pilares estratégicos que integramos en cada componente de nuestro código base:

• Análisis e informes : utilizamos Segment.io para el seguimiento de eventos y la transmisión de los datos a Amplitude para que tanto los profesionales del marketing como los ingenieros puedan crear fácilmente gráficos significativos; también utilizamos Google Analytics, Google Tag Manager y una herramienta de terceros para el cumplimiento de la GDPR.
• Formularios y atribución - integración con un ESP y Salesforce CRM tanto para el correo electrónico como para el enrutamiento y la atribución específicos de la campaña
• Rendimiento y Web Vitals : optimización de la base de código, reducción de scripts y píxeles de terceros, medición de Web Vitals y desarrollo para mobile-first.
• Internacionalización (i18n) y localización (l10n) - integración de nuestro servicio de traducción directamente en Contentful
• Accesibilidad (a11y) - utilizando la puntuación de accesibilidad de Lighthouse (parte de Web Vitals), la herramienta de evaluación de la accesibilidad web (WAVE), el contraste de colores, la navegación con teclado, etc.
• Pruebas A /B y CRO : aprovechamiento de Optimizely para lanzar rápidamente pruebas A/B y pruebas bandit multibrazo.

Estamos orgullosos de haber participado activamente en toda la empresa y de haber influido enormemente en la mejora de los procesos de incorporación, la transparencia de los precios, la privacidad y el GDPR, la fiabilidad de nuestras API y la redoblada apuesta por la accesibilidad, la internacionalización y la localización para todos.

¿Cuál es el futuro de la Ingeniería de Marketing?

Para 2022, estamos empezando a compartir la plataforma y los componentes para el multi-tenancy, permitiendo a otros equipos como Dasher, Caviar, Chowbotics (y más) trasladarse a nuestra infraestructura.

Nuestro pequeño pero poderoso equipo también está creciendo (ahora somos tres ingenieros en marketing, con el apoyo de dos analistas de Salesforce y un estratega de ciencia de datos y pruebas). La necesidad de Ingeniería de Marketing para ayudar a la empresa a escalar internacionalmente y para negocios más allá de los restaurantes es ahora más fuerte que nunca. Desde entonces no hemos frenado nuestro impulso ni hemos levantado el pie del acelerador.