Cómo codificar un feed de Twitter dinámico en vivo en un correo electrónico HTML

Publicado: 2015-05-26

Cuando comenzamos a definir la logística de Litmus Live (anteriormente, la Conferencia de diseño de correo electrónico) en 2015, comenzaron las conversaciones sobre cómo hacer que nuestro correo electrónico de lanzamiento sea más grande y mejor que el del año pasado. ¿Cómo superamos la técnica de fondo de video HTML5 en el correo electrónico? Mediante el uso de contenido dinámico: un feed de Twitter en vivo.

Sí, un feed de Twitter en un correo electrónico .

Nuestros objetivos eran dos: generar interés en la conferencia y utilizar una técnica innovadora e inspiradora en el correo electrónico para hacerlo. Después de muchas sesiones de lluvia de ideas, decidimos utilizar el enfoque común de contenido dinámico, pero con un giro.

tedc15-email

Ver correo electrónico completo en el navegador →

También puede ver el código completo aquí y los resultados de la prueba de Litmus aquí para ver cómo se muestra en más de 40 clientes de correo electrónico.

Contenido dinámico en el correo electrónico

El contenido dinámico en el correo electrónico no es un concepto nuevo. De hecho, se usa con frecuencia para crear correos electrónicos personalizados y dirigidos. Históricamente, el contenido dinámico se ha implementado estrictamente mediante el uso de texto o imágenes, y se ha extraído mediante etiquetas o variables de combinación mediante un ESP. Las imágenes dinámicas están vinculadas a un solo archivo de origen, que se sobrescribe dinámicamente para mostrar una nueva imagen para un determinado subconjunto de suscriptores en función de parámetros de personalización predefinidos. Ambos métodos le permiten crear una experiencia de correo electrónico única y personalizada para sus suscriptores.

Usamos imágenes dinámicas en nuestro correo electrónico de lanzamiento para hacer que el feed de Twitter dinámico en vivo funcione en varios clientes de correo electrónico populares. Sin embargo, también utilizamos un método completamente nuevo para implementar contenido dinámico: CSS dinámico.

Si bien el CSS dinámico funcionaba para los clientes de WebKit, necesitábamos implementar un respaldo adecuado utilizando imágenes dinámicas para nuestros suscriptores que utilizan clientes que no son de WebKit. Dicho esto, la transmisión en vivo de Twitter fue admitida (¡de una forma u otra!) En las siguientes bandejas de entrada:

  • Correo AOL
    Imagen dinámica
  • Correo de Apple
    CSS dinámico
  • iOS (aplicación de correo electrónico nativa)
    CSS dinámico
  • Outlook (2000-2013)
    Imagen dinámica
  • Outlook para Mac (2011 y 2016)
    CSS dinámico
  • Outlook.com
    Imagen dinámica
  • Thunderbird
    Imagen dinámica
  • Telefono windows
    Imagen dinámica
  • Correo de Windows
    Imagen dinámica
  • Windows Live Mail
    Imagen dinámica
  • Yahoo! Correo
    Imagen dinámica

Contenido CSS dinámico para clientes de correo electrónico de WebKit

Si bien podríamos haber usado imágenes dinámicas para todos los clientes de correo electrónico, optamos por usar CSS dinámico para la mejora progresiva en los clientes de correo electrónico de WebKit, como los clientes de correo electrónico nativos de iPhone y iPad, para hacer que el feed de Twitter se sienta más realista.

Entonces, ¿cómo lo hicimos funcionar? Usando los quince tweets más recientes que incluían el hashtag # TEDC15, mostramos los primeros 5 tweets por defecto, luego animamos los tweets restantes uno por uno durante un lapso de un minuto. Esto nos permitió hacer que la transmisión de tweets se sintiera en tiempo real y tuvo el beneficio adicional de mantener a las personas involucradas durante más tiempo.

Si bien actualizamos el archivo CSS cada 10 segundos, el contenido real del correo electrónico no se pudo actualizar de la misma manera; se necesitaba una actualización completa del documento para funcionar. Los usuarios debían volver a abrir el correo electrónico o actualizar la versión web para ver los tweets actualizados. Aunque no es ideal, ¡en realidad resultó ser muy atractivo!

Para que funcione el feed de Twitter en vivo, usamos HTML y CSS que solo se mostrarían en los clientes de WebKit. Para lograr esto, creamos <div> y <span> vacíos y usamos la propiedad CSS de contenido para agregar el contenido de los nombres, identificadores, marcas de tiempo y copia de tweets de los usuarios de Twitter.

Aquí está el HTML:

 <div class="tweet"> <div class="tweet-avatar-wrapper"> <div class="avatar"></div> </div> <div class="tweet-wrapper"> <span class="name"></span> <span class="handle"></span> <span class="timestamp"></span> <span class="copy"></span> </div> </div>

Para sobrescribir dinámicamente el CSS, confiamos en una hoja de estilo externa que se actualizaba cada 10 segundos y se incluía en nuestro correo electrónico así:

 <link href="http://assets.insights.litmus.com/campaigns/tedc-2015/assets/tweets.css" type="text/css" rel="stylesheet" />

Aquí está el CSS correspondiente, con la información del tweet en la propiedad de contenido:

 #tweet-1 .name::before { content: "Kevin Mandeville"; } #tweet-1 .handle::after { content: "@KevinMandeville"; } #tweet-1 .copy::before { content: "I'm excited for #TEDC15! Who's going?"; } #tweet-1 .timestamp::after { content: "1m"; }

El CSS de los tweets estaba envuelto en una consulta de medios que nos permitió mostrarlo solo en clientes de correo electrónico basados ​​en WebKit:

 @media screen and (-webkit-min-device-pixel-ratio: 0) { /* Insert CSS here */ }

Al usar <div> vacíos para la estructura predeterminada, el contenido no se mostró para los clientes de correo electrónico que no son de WebKit. Luego recurrimos a una imagen del feed dinámico de Twitter para suscriptores que no son de WebKit.

La única desventaja de usar la orientación de WebKit y la propiedad de contenido es que algunos clientes de correo electrónico, como Airmail y la aplicación Outlook para iOS y Android, admitirían la consulta de medios dirigida a WebKit pero no la propiedad de contenido, lo que haría que los tweets fueran invisibles. Pero, dado que estos clientes de correo electrónico son una parte muy pequeña de nuestra audiencia (menos del 1%), este fue un sacrificio que valió la pena.

Imágenes dinámicas para clientes de correo electrónico que no son de WebKit

Para los clientes de correo electrónico que no son de WebKit, utilizamos el método más tradicional de mostrar imágenes dinámicas, ya que la propiedad de contenido CSS no es compatible con los clientes de correo electrónico fuera de WebKit.

En el correo electrónico, hicimos referencia a una imagen dinámica del feed de Twitter:

 <img src="/uploads/article/137983/1JLxfeWJnz4EGtoE.jpg" width="600" height="902" border="0" class="webkit-hide" alt="tweet #TEDC15 to show up in the live feed!"/>
tuitea # TEDC15 para aparecer en la transmisión en vivo.

Creamos una página web simple de solo el feed de Twitter usando el mismo HTML y CSS del correo electrónico. Simplemente tomamos una captura de pantalla del feed con las mismas dimensiones de 600 × 902 a través de la utilidad de línea de comandos wkhtmltoimage y actualizamos dinámicamente esa misma imagen cada 10 segundos.

Como estábamos usando HTML y CSS para la vista de WebKit, ocultamos la imagen en WebKit para evitar feeds duplicados:

 @media screen and (-webkit-min-device-pixel-ratio: 0) { .webkit-hide { display: none; } }

Con esta técnica, la transmisión en vivo de Twitter funcionó incluso en los clientes más problemáticos (ejem, Outlook) y permitió que la mayoría de nuestros suscriptores se unieran a la diversión.

El único inconveniente importante de esta implementación de imágenes dinámicas es que Gmail almacena sus imágenes en caché. Como resultado, los usuarios de Gmail no experimentaron la transmisión de Twitter en vivo. En cambio, vieron ocho de los tweets más recientes y un mensaje especial para ver la versión web del correo electrónico para ver el efecto completo:

gmail-twitter-feed

Cómo construimos la integración dinámica de Twitter

Kevin Thompson, nuestro desarrollador de marketing, fue el cerebro detrás de la integración real de Twitter. Creó una aplicación muy simple construida en el marco de Sinatra y alojada en Heroku. Puede consultar el código y probarlo usted mismo siguiendo las instrucciones en Github. Esta prueba inicial demostró que era posible generar los tweets en CSS, cargar la hoja de estilo externa en un puñado de clientes de correo electrónico y que esos clientes podían obtener el último CSS cada vez que se abría el correo electrónico.

A partir de ahí, la aplicación comenzó a volverse un poco más compleja. Debido a que Twitter impone límites en la cantidad de solicitudes que realiza a la API, necesitábamos estar seguros de que no excederíamos el límite de 150 solicitudes por 15 minutos asignados para consultas de búsqueda. Para abordar este problema, agregamos un segundo proceso a nuestra aplicación Heroku. Este proceso se ejecutó en segundo plano, obteniendo tweets cada 10 segundos y almacenándolos en un caché. El proceso de aplicación principal luego cargaría tweets desde la caché en lugar de buscarlos directamente a través de Twitter.

Kevin también tuvo que tener en cuenta la escalabilidad y la velocidad. Si bien teníamos una solución para mantenernos dentro de los límites de la API de Twitter, nuestro único servidor probablemente no podría procesar la cantidad esperada de solicitudes de los más de 200,000 destinatarios de nuestro correo electrónico. Para resolver esto, implementamos la CDN de Amazon CloudFront, lo que nos permite admitir muchas más solicitudes de nuestros activos y también distribuirlos a nivel mundial para garantizar que los archivos se carguen rápidamente para toda nuestra audiencia. En nuestra aplicación Sinatra, Kevin también agregó encabezados Cache-Control, que indicaban a CloudFront que expirara los activos después de 10 segundos. Esto lo obligó a solicitar contenido nuevo de nuestra aplicación con mayor frecuencia.

Para mantener los resultados lo más actualizados posible sin exceder los límites de velocidad de la API de Twitter, renderizamos y almacenamos en caché el CSS dinámico y los archivos de imagen cada 10 segundos con los resultados de nuestra búsqueda de Twitter.

Para administrar el contenido de los tweets, tanto los términos de búsqueda de Twitter como el contenido / usuarios bloqueados se controlaron mediante variables de entorno. Aunque cambiar las variables de entorno en Heroku significaba que nuestra aplicación tendría que reiniciarse, debido a que los activos se distribuían a través de la CDN y la aplicación era tan simple, un reinicio solo tomó unos segundos y sería completamente imperceptible. Además, debido a que Heroku proporciona una interfaz de usuario para editar variables de entorno, nuestro equipo de marketing pudo realizar cambios en los términos de búsqueda y bloquear contenido según fuera necesario.

Si estos métodos le parecen demasiado complicados o le llevan mucho tiempo, existen empresas de terceros como Movable Ink, LiveClicker, PowerInbox y Avari que se especializan en contenido dinámico para correo electrónico.

Filtrado de tweets incorrectos

Una gran preocupación para nosotros al incorporar un feed de Twitter dinámico en vivo fue ceder el control del contenido de nuestro correo electrónico, lo que resultó en la aparición de algunos "tweets malos" en la transmisión. Algunas personas en Twitter señalaron esto:

Al mismo tiempo, queríamos proporcionar un flujo de tweets lo más cercano posible a un feed de tweets sin procesar y sin filtrar para mantener el factor "sorpresa". Nuestra hipótesis era que los tweets malos serían un escenario de caso límite y se eliminarían del feed a través de una actividad constante. Por lo tanto, inicialmente confiamos en los filtros de búsqueda de Twitter para eliminar el contenido menos que ideal.

Pero queríamos tener filtros adicionales, por lo que también nos dimos la capacidad de bloquear nombres de usuario específicos y cadenas de texto después de obtener los resultados de Twitter. En última instancia, decidimos no permitir que las fotos de tweets estuvieran en la transmisión, ya que eso podría haberse vuelto rebelde y más dañino que solo el texto. Además, es imposible inyectar vínculos dinámicamente a través de la propiedad CSS del contenido, por lo que tampoco funcionaron los vínculos en los tweets; simplemente se mostraban como texto. Todos los tweets se vincularon directamente al flujo de tweets # TEDC15.

Como última medida a prueba de fallos, teníamos la opción de deshabilitar por completo los resultados de búsqueda de Twitter en tiempo real, volviendo a una lista filtrada de tweets favoritos de nuestra cuenta de Twitter @emaildesignconf. Al final, solo hubo un par de tweets malos que debían eliminarse. Y, hasta el momento, tampoco hemos tenido que utilizar el último a prueba de fallos de cambiar a los tweets favoritos: ¡choca los cinco con #emailgeeks!

¿La clave? Asegurándonos de probar todo de arriba a abajo. Asegúrese de que sus diseños se vean geniales en las bandejas de entrada que usan sus suscriptores con Litmus.

Prueba todo de arriba a abajo

Obtenga una vista previa de los correos electrónicos en 50+ y respire aliviado cuando intente incluso las hazañas de correo electrónico más locas, como un feed de Twitter en vivo.

Prueba Litmus gratis →

Una reacción abrumadoramente positiva

A nuestra audiencia definitivamente le encantó esta divertida y única implementación en el correo electrónico. De hecho, hizo que el correo electrónico fuera una experiencia interactiva y comunitaria en la que todos pudieran participar. Las reacciones de Twitter no tienen precio e incluso siguieron algunos temas similares.

Algunas personas cuestionaron si en realidad era real:

Muchos simplemente lo miraron:

https://twitter.com/hannahsmeznik/status/601464682180816896

Un grupo dijo hola a los demás:

https://twitter.com/WebDevRich/status/601669735483363328

Hubo varias menciones de magia, brujería y Harry Potter:

https://twitter.com/oompt/status/601495402962116611

También se produjo una gran cantidad de tonterías y travesuras:

https://twitter.com/MrMoon123/status/601658129349214209

https://twitter.com/capitocapito/status/601458692161019904

Para colmo, muchas personas se volvieron locas:

https://twitter.com/adamrandazzo/status/601450740964466688

https://twitter.com/MattRoxo/status/601782360460251137

Una mirada al rendimiento

¡Quedamos impresionados con los resultados de esta campaña! Más del 53% de nuestras aperturas se realizaron en un cliente de correo electrónico de WebKit, por lo que muchos de nuestros usuarios vieron la versión mejorada progresivamente. En total, hubo más de 750 tweets sobre # TEDC15 en las primeras 24 horas después de enviar el correo electrónico. Además, el correo electrónico ayudó a atraer a más de 4,000 nuevos visitantes a nuestro sitio web y generó más de 1,000 nuevos prospectos en la misma cantidad de tiempo. Sin mencionar que este correo electrónico obtuvo la mejor participación que hemos visto en cualquier correo electrónico que hayamos enviado: ¡casi el 60% de los usuarios vieron el correo electrónico durante más de 18 segundos!

Captura de pantalla 26/05/2015 a las 3.48.42 p.m.

Si tiene alguna pregunta, no dude en preguntar en los comentarios a continuación, únase al hilo de la comunidad Litmus sobre el tema o envíe un tweet a @KevinMandeville y @KevinThompson.

Reciba correos electrónicos increíbles

No se pierda nuestro próximo correo electrónico alucinante: regístrese para recibir noticias e información sobre todo lo que sucede en Litmus.