Emails transaccionales

Un artículo que explica que son los emails transaccionales, que valor aportan a nuestras aplicaciones web y cuales son los mejores servicios disponibles.

Los emails transaccionales son una de esas muchas cosas de las que no te preocupas hasta que no tienes una web seria y, sin embargo, son una parte crítica de tu experiencia de usuario.

No he encontrado ningún artículo en castellano con toda la información sobre mensajes transaccionales que he necesitado. Así que he decidido escribir una entrada que detalle de forma sencilla sus características más importantes y cuáles son los principales proveedores de servicios.

Proveedores Mails Transaccionales

¿Qué es un email transaccional?

Pues, básicamente, cualquier correo que no forma parte de un envío masivo y discriminado, sino que es remitido como consecuencia de un evento relacionado con el destinatario, sea este o no el causante del mismo.

Un mensaje transaccional es, por ejemplo, el típico mail que suelen mandar las webs cuando nos registramos como usuarios para confirmar nuestra dirección de correo. Pero también son correos transaccional los mails que nos envía Twitter cuando nos escriben un mensaje directo; o Facebook cuando alguien quiere convertirse en nuestro amigo sin que nosotros hayamos hecho nada por recibirlo.

¿Y a mí qué? ¿Por qué es eso tan importante para mi web?

Nuestros emails transaccionales deben cumplir dos características básicas:

  1. Rapidez en el envío. Si tardamos 2 minutos en enviar un correo de confirmación que permita que un nuevo usuario comience a usar nuestra aplicación, hay muchas posibilidades de que dicho usuario se canse, abandone nuestra web y no vuelva nunca más.
  2. Maximizar la seguridad en la entrega. Si no enviar un correo de confirmación en el registro de una web es un problema, no conseguir entregar un correo de confirmación de reserva de una habitación de hotel, por ejemplo, puede ser un PROBLEMÓN.

Por supuesto, podemos implementar nuestro propio servicio de mensajes transaccionales, pero la casuística a cubrir es inmensa (envíos, reenvíos, alertas…) y, además, debemos resolver problemas de fontanería pura que escapan a nuestro control, como la posibilidad de que nuestro servidor de correo haya sido incluido en una lista negra por haber enviado mensajes de SPAM.

Proveedores de Servicios

Iba a hacer una comparativa de los principales proveedores de servicios de gestión -y, creedme, hay muchos- hasta que di con una completísima comparativa en Social Compare que me ha ahorrado el trabajo.

Hay soluciones para todos los gustos, desde un servicio sencillo como SES -construido como complemento de Amazon AWS– a sistemas más completos como Mandrill, el servicio de emails transaccionales de Mailchimp, pasando por soluciones “todo en uno” como Mailjet.

Mandrill, el gestor de correos transaccionales de Mailchimp

Entre los distintos valores añadidos que podemos encontrar están, desde completos sistemas de reporting para conocer las estadísticas de correos abiertos y contestados, hasta la posibilidad de contratar una IP dedicada para asegurarnos de que la reputación de nuestros correos no se vea comprometida por los mails de otros clientes del proveedor de servicios.

La mayoría de proveedores cobran por uso, con un precio base que incluye un número máximo de correos y un cargo por mails suplementarios enviados. Y muchos tienen un plan gratuito para un número limitado de correos al mes, más que suficiente para probar el servicio.

Si la mayoría de las empresas ya no se plantean siquiera gestionar por sí mismas su servicio de correo, ¿de verdad lo vas a hacer tú con tus emails transaccionales?

Bola Extra

Tremenda currada la que se ha pegado el amigo Janote, en el comentario de aquí abajo. Unas 10.000 veces mejor que el artículo en si. ¡Kudos para ti Jano!

  • Nosotros hemos hecho pruebas con CritSend y va muy bien en cuanto a entregabilidad, facilidad de integración, campañas de email masivo con parámetros personalizados, etc.

    Como tú señalas, estos emails son claves en ciertos momentos de interacción con el usuario y, aunque parece que con las configuraciones adecuadas, se puede conseguir que lleguen a tiempo, correctos y a la persona adecuada, no sé si conviene depositar tanta confianza en un tercero.

    Nosotros, en el registro de nuestra web, hemos decidido implementar una pequeña lógica para permitir cuentas sin confirmar durante un período de tiempo determinado tras el registro (nada nuevo, muchos sitios lo hacen ya). Es un comportamiento enfocado sobre todo a la etapa de lanzamiento en la que no podemos permitirnos perder ni un solo usuario por cosas tan ridículas como saturación de la red, un mail en la carpeta de spam o que el usuario no pueda entrar en ese momento a su correo personal.

    La comparativa de Social Compare es fantabulosa.

    • Ostris, pues sería interesante experimentar ese proceso de registro lean y aprender del mismo ¿Puedes postear la URL de la web por aquí?

      • Claro, cuando lancemos, en Febrero, habrá ración de autobombo 😀

  • jomarmen

    Hola, no conocía este concepto de mail transaccional. Los mails que pueden mandarse como avisos, recordatorios o avisos para que los usuarios hagan una determinada acción se considerarían también transaccionales?

    • Si, no tienen porque ser causados por una acción sino también por una ausencia de la misma. Como correo transaccional se califica todo aquel que se envía siguiendo una lógica de negocio.

  • Hace unos días me encontré en la misma situación. Necesitaba comparar las ofertas de los servicios de envío de Transactional Emails (features, pricing…). Aprovecharé aquí para compartir algunos de los recursos que me parecieron más interesantes.

    Lo primero de todo, como ya ha explicado David, es saber diferenciar entre Transactional Email (notificaciones de tu app) de Bulk/Marketing Email (comunicaciones comerciales masivas tipo newsletter).

    Los motivos de por qué usar un servicio específico para Transactional Email y no tu propio servidor de correo ya los ha explicado David: bounces, mail server blacklisted IP, analytics… O como dicen en Postmark, “Because right now you’re blind”.

    Una vez entendida la diferencia y utilidad, deberás saber cuáles de estos servicios ofrece cada proveedor. Por ejemplo, una misma empresa puede tener un producto diferente para cada caso (como el caso de The Rocket Science Group, que ofrece Mandrill para Transactional, y Mailchimp para Bulk), o un mismo producto para los dos casos (como Mailjet o Amazon SES).

    Otro punto importante a tener en cuenta es conocer qué interfaces ofrece el servicio. Generalmente existen dos: SMTP, y API.

    La gran ventaja de SMTP es la facilidad de migración. Es decir, si ya estás usando una librería (PHP, Java, Ruby, Python…) para el envío de tus emails via SMTP, tan sólo necesitarás cambiar la configuración de conexión al servidor SMTP, usando los valores del nuevo servicio. De ésta manera la migración/implantación será lo más ágil y transparente posible.

    Eso sí, has de tener en cuenta que cada servicio puede imponer diferentes límites para el número de destinatarios por email, número de BCC o CC, tamaño de adjuntos… Por lo que es posible que tengas que revisar tu código si estás superando esos límites (dividiendo en batches los CC/BCC, enlazando en vez de adjuntando…).

    Pero si realmente quieres aprovechar al máximo todo lo que ofrecen estos servicios, deberás usar su API, en vez de la más simple y limitada interfaz SMTP. De hecho, en algunos servicios la interfaz SMTP lo consideran como un mecanismo de fácil despliegue, mientras vás desarrollando la integración con su API. Cabe mencionar, que las librerías populares de envío de email, cuentan con extensiones para las APIs de algunos de estos servicios.

    Los servicios más populares están incluidos en la comparativa que enlaza David.

    A estos sólo añadiré algunas comparativas adicionales que encontré:

    http://blog.ombud.com/2012/05/21/price-comparison-transactional-email-delivery/
    http://cloudspring.com/email-as-a-service-part-2-sendgrid-mailgun-and-postmark/
    http://blog.willj.net/2011/11/30/email-provider-price-comparison/
    http://www.quora.com/Jon-Lim/answers (trabajaba para PostageApp, tiene respuestas interesantes)

    Otro punto que querrás conocer es el modelo de pricing, es “Pay-as-you-go” (pagas sólo el consumo real) o debes comprar Packs por adelantado?

    Una opción que me pareció interesante, por precio y por cubrir tanto Transactional como Bulk, es Amazon SES. Soporta SMTP y API, y con una herramienta como Sendy podrás gestionar tus Newsletters con una interfaz digna (no al nivel de Mailchimp o CampaignMonitor, pero mucho más económico).

    También existe la alternativa completamente gratis, enviar desde Google Apps. Pero deberás tener en cuenta sus limitaciones, y además tampoco tendrás todo los servicios añadidos de los anteriores. Si las sobrepasas, todavía te queda la opción de crearte una aplicación para envío de correo en Google App Engine, donde los límites son consdierablemente superiores (de pago).

    Ya por último comentar que el problema del envío de emails desde tus apps no acaba aquí, ya que si tienes un gran volumen de notificaciones que procesar y no quieres hacerle esperar a tu usuario mientras navega ni ocupar una conexión al servidor web por demasiado tiempo, deberás implementar algún sistema de cola de tareas/mensajes (Job/Message Queue), los hay basados simplemente en DB + CRON (desaconsejado), o con servidores propios como God manda (Gearman, Beanstalkd, RabbitMQ, Amazon SQS…).

    ACTUALIZACIÓN 09/12/2012

    Si estás pensando en integrar el servicio de correo de Google Apps for Business, ten en cuenta lo siguiente:

    Casualidad, la misma semana que hice este comentario Google decidió cambiar su política de precios para Google Apps for Business. Se acabó el “café para todos”. A partir de ahora tendrás que pagar $50/año por cada usuario. Ten en cuenta que un usuario de Google Apps, es toda dirección de correo electrónico con inbox propio. Es decir, si necesitas 5 direcciones de email, pagarás $250/año, aunque desconozco como afecta esta media a alias y redirecciones. Aún y todo me sigue pareciendo un buen servicio (25GB de inbox por cuenta, soporte 24/7, uptime del 99.9%…).

    También se comenta que si te creas un cuenta de Google App Engine, tendrás una cuenta de correo gratuita. Pero sólo una.

    • ¡Ole tus huevos morenos Jano! Tu comentario es oro puro, para ponerse a excavar y no parar.

      A mi me tira Postmark por la sencilla razón de que ya está validado por @Molpe y, si lo dice Molpe, es Ley 😛

      Mandrill me llama porque ya uso Mailchimp y es awesómico, tú ya sabeh, bueno… y también porque como este último, se puede empezar a utilizar gratis…

      • Como ya he dicho en la respuesta a Alberto… mil gracias David por tus palabras!

        En el proyecto actual pensábamos arrancar simplemente con Google Apps for Business, y algo más adelante integrar alguno de estos servicios.

        Como a tí, a nosotros también nos llegó la misma recomendación de Postmark. 🙂 Pero vía La Personnalité en referencia a la experiencia de Linking Paths con dicho servicio.

        Ahora que Google Apps for Business es de pago ($50/año por usuario/cuenta de email), quizás nos planteemos salir ya con un servicio dedicado de Transactional Email. Y la cosa andará por ahí, Amazon SES, Postmark, Mandrill, Mailgun… cualquiera que cubra las pocas features que realmente necesitamos, al precio más interesante, con un bue servicio/soporte, y que sea menos coñazo de integrar.

    • Gracias por el comentario Jano. Me lo apunto todo porque es muy útil 🙂

      • De nada Alberto, me alegro que te resulte útil!

        Tenía ganas de compartir lo poco que había podido aprender recientemente sobre Emails Transaccionales. Y desde luego que uno se anima así a hacerlo… mil gracias David por tus palabras! 🙂

        Seguiré intentando aportar mi granito de arena, siempre que el tema me lo permita.

  • demosc

    [Offtopic del copon]

    Hola Bonilla, un par de preguntas:

    – Por casualidad se grabo tu conferencia el otro día sobre los programadores?

    -La segunda es mas una petición, podrías poner tu ‘bonilista’ como post? es que mas de una vez me gustaría opinar y si la pusieras en tu blog se podría hacer.

    • Offtopicón de Aviñón!

      No, no se grabó la charla… puedo compartir la presentación, pero no creo que se entienda desde la 2ª slide, donde sale… Mi Pequeño Pony.

      A veces, en raras ocasiones, copio la Bonilista y la hago post ¿Cuando? Pues básicamente cuando muchos de vosotros lo pedís, sin más.

  • Carlos Hernández

    Nosotros estamos usando Mandrill. Va como la seda, excelente interfaz de usuario, muy bien documentado y su API es la bomba. Y encima puedes enviar 12k de emails/mes de forma totalmente gratuita.

  • Vanessa Ramos

    My 2 cents sobre el tema de los emails transaccionales (aunque en realidad muchas de estas cosas se pueden aplicar a cualquier email que enviemos, no sólo a los transaccionales): http://vramosp.wordpress.com/2009/12/19/escribiendo-emails-transaccionales/

    En Masterbranch utilizamos Google Apps con varias cuentas, pero llegó un momento en que costaba escalar…. Por otro lado, empezamos a usar Mailchimp para las newsletters, que está muy bien, y como muchos de estos servicios tiene la ventaja de que marca el remitente como seguro, sistemas de estadísticas, etc. Pero a la hora de integrar Mailchimp con los emails transaccionales (es decir, cuando decidimos dejar de usar Google Apps y usar Mailchimp para los emails transaccionales), evaluamos otras alternativas y al final optamos por Sendgrid, por dos motivos: la integración era mil veces más fácil, y es más barato. Sendgrid está muy muy bien, si aún estáis a tiempo, echadle un vistazo.

  • Daniel Brandi

    Gracias tanto a David como a Jano por artículo y comentarios. Muy interesante.

    Para emails transaccionales yo me quedo con Amazon SES. Es sencillo de integrar vía API, es barato y bastante fiable. A través del API te permite gestionar los rebotes y spam.

    Por otro lado, estoy totalmente de acuerdo con Jano en cuanto a que usar una pseudo cola en DB+cron es una mierda, pero quizá sea el punto más sencillo para empezar. Si tienes toda la infraestructura en Amazon (como hemos hecho para etece.es) lo mejor es usar Amazon SQS pero requiere algo más de conocimientos de las APIs de Amazon.

    Un saludo

  • David Bolufer

    Yo solo diré una cosa … AMAZON SES sucks! Creo que es de lo peor que he visto. ¿Por qué? Imposible que un email enviado desde SES llegue al inbox de Hotmail. Y por supuesto, el soporte es inexistente.

    La verdad es que montarse uno mismo cuando empieza el sistema de envío de los mails transaccionales es una locura! Este gran post de 37signals indican como lo hacen ellos y como se implementa como dios manda. http://37signals.com/svn/posts/3096-behind-the-scenes-giving-away-the-secrets-of-email-delivery

    Nosotros en chicisimo, usamos elasticemail para los envíos transaccionales y muy contentos

    • Buenas David,
      Nosotros estamos buscando un sistema de envío, lo que comentas de SES sólo te ha pasado con Hotmail o has tenido algún problema más?

      Saludos

      • David Bolufer

        Pues pasa con hotmail únicamente y tengo clarísimo que es un problema de SES, pues hemos seguido todos los pasos que hay que hacer para maximizar la famosa deliverability configurando los registros SPF y DKIM.

        Hotmail (y solo hotmail) devuelve un error al verificar el DKIM del dominio. Pienso que por eso va al JUNK, pero esto del envío del email y que llegue al inbox es magia (en serio).

        • Gracias, creo que vamos a probarlo a ver cómo va.

        • Gustavo Lopez

          Buenas. Te comento que cuando el usuario agrega al remitente como contacto es que comienzan a llegar los emails al Inbox. Al menos así lo pude ver yo. Otro punto es qué dominio utilizas.

  • Pingback: Entrevista Cristian Hernández - Eniti Media - maketing online()

  • Miguel

    Hola david, esto lo puede implementar en un sitio web de un politico? por ejemplo que si se unen con su voto les llegue un correo electronico tuipo confirmación.

  • no se olvide de limpiar su lista de correo

  • Bienvenido Sáez Muelas

    Buenas a todos, en cuanto a la LOPD vigente, ¿cual usáis para cumplirla?