Adopter une approche basée sur les données pour maintenir à jour les emails

Ce blog a été rédigé par Roy Young. Roy, développeur Ruby qui perfectionne ses compétences à la Tealeaf Academy.

Ah, la table « users ».

On pourrait affirmer qu’il s’agit de l’un des atouts les plus importants d’une start-up. Les cyniques ont du mal à croire qu’ Instagram (une application de partage de photos !) ait été rachetée pour 715 millions de dollars par Facebook ou que Mailbox, un client de messagerie mobile pour Gmail (et encore en version bêta à bien des égards), aurait été racheté pour près de 100 millions de dollars par Dropbox.

Cette vision cynique résulte souvent d’une focalisation excessive sur le produit ou la technologie, ce qui pousse facilement à considérer ces valorisations comme absurdes. Cependant, il faut également tenir compte de la valeur de tous ces utilisateurs et de la croissance de cette base d’utilisateurs. Ces valorisations astronomiques sont toujours associées à un produit doté d’une base d’utilisateurs vaste et en croissance rapide. Il est donc logique que maintenir à jour votre table d’utilisateurs avec des informations de contact correctes soit un bon investissement pour votre entreprise. Bien sûr, le plus difficile est de générer cette croissance… Vous devrez donc payer pour obtenir ces informations.

Ce conseil sur la « partie facile » est cependant gratuit. Dans cet article, je vais vous présenter une bonne méthodologie pour maintenir à jour les adresses email de vos utilisateurs, à une époque où de nombreuses personnes possèdent plusieurs adresses, y compris des adresses jetables pour certains services.

Lorsque vous envoyez un email à une adresse email qui n’existe plus, le destinataire (par exemple Gmail ou Yahoo) vous renverra un rebond. En analysant ces rebonds, votre application peut réagir de manière appropriée, créant ainsi une excellente expérience utilisateur tout en gardant votre base de données client à jour. Cet article présente un exemple d’application construite sur Heroku qui utilise Mailgun pour écouter ces emails avec rebond, afin que les utilisateurs avec des adresses email erronées puissent continuer à recevoir les emails de facturation mensuels. Cette même logique pourrait s’appliquer à n’importe lequel de vos emails, garantissant ainsi que vos utilisateurs restent engagés et informés de l’actualité de votre entreprise par email.

J’ai créé un site de démonstration pour cet article et rendu le code source disponible sur GitHub. Cette démo guide les personnes débutantes tout au long du processus de configuration de cette fonctionnalité. Cliquez ici si vous souhaitez passer directement à l’intégration de webhooks de rebond dans votre application.

Pour envoyer des factures mensuelles à vos utilisateurs, vous devrez écrire du code pour :

• Déployer des emails de facturation personnalisés auprès de vos centaines, milliers ou millions de clients et clientes.
• Planifier concrètement le déploiement de ces emails.

Examinons chacun de ces points.

Déployer des emails de facturation personnalisés

Pour les besoins de ce tutoriel, je pars du principe que vous possédez déjà un compte Mailgun. À partir de là, vous devrez envoyer votre liste de clients à Mailgun, avec toutes les variables que vous souhaitez insérer dynamiquement dans les emails sous forme de fichier JSON, ainsi que le corps HTML ou texte de l’email. Voici le code.

                                

                                    class MailgunGateway include Rails.application.routes.url_helpers def send_batch_message(users) RestClient.post(messaging_api_end_point, from: "Mailgun Demo ", to: users.map(&:email).join(", "), subject: "Monthly Billing Info", html: billing_info_text, :"h:Reply-To" => "billing@#{ENV["mailgun_domain_name"]}", :"recipient-variables" => recipient_variables(billing_recipients) ) end private def api_key @api_key ||= ENV["mailgun_api_key"] end def messaging_api_end_point @messaging_api_end_piont ||= "https://api:#{api_key}@api.mailgun.net/v2/#{ENV["mailgun_domain_name"]}/messages" end def billing_recipients @users ||= User.where(locked: false) end def recipient_variables(recipients) vars = recipients.map do |recipient| ""#{recipient.email}": {"name":"#{recipient.fullname}"}" end "{#{vars.join(', ')}}" end def billing_info_text <<-EMAIL  Hi %recipient.name%, <p> Your bill for the current month is now available, please click on <br /> #{billing_url} <br /> to see details. </p> <p>Reply to this email directly</p>  EMAIL end end
                                
                            

Examinons ce que nous avons fait.

Dans la méthode sendbatchmessages, nous utilisons des variables de destinataire afin de pouvoir définir des variables pour personnaliser chaque email. Vous remarquerez que nous insérons le prénom de l’utilisateur dans l’email. Vous pouvez rédiger un email de facturation qui inclut des détails tels que le numéro de compte, le compte de facturation, ou tout ce que vous souhaitez, mais je préfère faire simple.

Envoyer automatiquement des emails de facturation mensuels avec Heroku Scheduler

Une fois notre méthode pour créer et déployer des emails via Mailgun prête, nous devons écrire du code qui déclenche automatiquement cette méthode. J’ai choisi de déployer cette application sur Heroku et j’utilise Heroku Scheduler car cet outil fait l’affaire, est un module complémentaire gratuit et est facile à intégrer.

Heroku Scheduler exécutera une tâche Rake spécifiée à une heure définie. Ici, nous devons donc créer une tâche Rake pour envoyer des emails de facturation à l’aide de Mailgun dans lib/tasks/scheduler.rake.

Tout d’abord, lorsque nous envoyons des factures aux utilisateurs, nous devons trouver les adresses email des clients à facturer.

Dans le schéma de base de données très simple de cet exemple d’application, nous avons un attribut :locked qui est défini sur True lorsqu’un email a déjà fait l’objet d’un rebond (nous y reviendrons plus bas). Notre requête récupère donc simplement tous nos utilisateurs pour lesquels ce champ est défini sur False.

Pour envoyer l’email, j’utilise Mailgun Envoi par lot. Le nombre maximum de destinataires autorisés par appel API étant de 1 000, nous utilisons findinbatches pour envoyer les emails de facturation à Mailgun par lots de 1 000 destinataires.

                                

                                    desc "This task is called by the Heroku scheduler add-on"
task :send_billing_info => :environment do
  if DateTime.now.mday == 1
    User.where(locked: false).find_in_batches(batch_size: 1000) do |group|
      MailgunGateway.new.send_batch_message(group)
    end
  end
end
                                
                            

Le paramètre « FREQUENCY » de Heroku Scheduler ne disposant que de trois options (« daily, hourly, every 10 mins »), nous devons vérifier si le jour actuel est le premier jour du mois en utilisant if DateTime.now.mday == 1. Si c’est le cas, l’email est envoyé. Sinon, aucun email n’est envoyé.

Lorsqu’un email fait l’objet d’un rebond, Mailgun envoie un POST via le webhook de rebond à notre application. Vous devez définir l’URL de rappel sous « Bounces » dans le panneau de configuration de Mailgun. Dans cette démo, mon URL de rappel est "http://mailgun-demo.herokuapp.com/api/bounced_mails"

Lorsque l’application reçoit la notification de rebond, elle recherche l’adresse email dans la base de données client et définit le statut de l’utilisateur sur « locked », de sorte que l’application n’enverra pas d’email de facturation à cet utilisateur tant qu’il n’aura pas mis à jour son adresse email.

                                

                                    class Api::BouncedMailsController < ApplicationController
  skip_before_filter :verify_authenticity_token
  def create
    if verify(ENV["mailgun_api_key"], params[:token], params[:timestamp], params[:signature])
      user = User.find_by_email(params[:recipient])
      if user && params[:event] == "bounced"
        user.lock!
      end
      head(200)
    end
  end
  private
  def verify(api_key, token, timestamp, signature)
    signature == OpenSSL::HMAC.hexdigest(
      OpenSSL::Digest::Digest.new('sha256'),
      api_key,
      '%s%s' % [timestamp, token])
  end
end
                                
                            

La méthode user.lock! sert à définir le statut de l’utilisateur sur « locked », afin que notre tâche Rake n’envoie jamais d’emails à cet utilisateur. Cette méthode est définie dans le modèle User.

                                

                                    class User < ActiveRecord::Base
  …
  def lock!
    self.locked = true
    save(validate: false)
  end
end
                                
                            

La méthode verify sert à vérifier que le webhook provient bien de Mailgun, faute de quoi n’importe qui pourrait envoyer un faux POST pour verrouiller les utilisateurs de votre application.

Pour plus de détails sur la configuration des webhooks, vous pouvez lire la documentation de Mailgun – Événements/Webhooks.

Enfin, nous renvoyons un en-tête 200 pour indiquer à Mailgun que cette interaction est réussie, sinon Mailgun pensera que notre serveur est en panne et continuera d’essayer d’appeler notre webhook.

Une fois que l’application sait quels utilisateurs ont une adresse email erronée, nous devons leur afficher un écran lors de leur prochaine connexion avec une invite pour vérifier leurs informations de contact enregistrées.

                                

                                    class SessionsController < ApplicationController
  def new
    redirect_to home_path if current_user
  end
  def create
    user = User.find_by_email(params[:email])
    if user && user.authenticate(params[:password])
      session[:user_id] = user.id
      if user.locked
        flash[:error] = "Your Email Address is invalid, please update it."
        redirect_to edit_user_path(current_user)
      else
        redirect_to home_path
      end
    else
      flash[:error] = "Incorrect email or password. Please try again."
      redirect_to sign_in_path
    end
  end
  def destroy
    session[:user_id] = nil
    redirect_to root_path
  end
end
                                
                            

Une fois leur adresse email mise à jour, nous redéfinissons l’attribut « locked » sur False afin qu’ils continuent à recevoir des emails.

C’est tout. Désormais, lorsque les emails de vos utilisateurs font l’objet d’un rebond, vous pouvez les inviter à mettre à jour leurs informations, offrant ainsi une excellente expérience utilisateur tout en gardant vos données client à jour.

Auteur·trice: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!