La technologie derrière le marketing par e-mail dynamique

La technologie derrière le marketing par e-mail dynamique

Le marketing par e-mail est un moyen efficace d’atteindre les clients, mais il s’accompagne d’une variété de défis qui peuvent être difficiles à surmonter. La nature de l’e-mail est statique après sa livraison : une fois que le message a quitté votre serveur de messagerie, vous avez très peu de contrôle – ou avez-vous ? Jetons un coup d’œil à une technique qui peut fournir un certain niveau de contrôle dynamique après vous envoyez votre e-mail.

Imaginez que vous envoyiez un e-mail avec trois offres. Vous ne savez pas quelles offres fonctionneront le mieux. Une fois l’e-mail envoyé, vous aurez une image très claire – qui a le meilleur taux de clics et la meilleure fréquence. La mentalité de troupeau est une chose très réelle dans le commerce électronique. Dire à un utilisateur qu’un article est “chaud” ou “populaire” peut donner un sentiment de confiance dans l’article et nous pouvons le communiquer via un “badge”. Mais pour être efficace, il doit être en temps réel et non d’un cycle précédent.

Pour y parvenir, nous utiliserons Redis et un serveur Node.js ainsi que tout outil que vous utiliseriez pour envoyer normalement vos e-mails. Le cœur de cette technique consiste à pointer à la fois l’URL de l’image de votre badge et l’URL de l’élément non pas vers l’image ou la page Web réelle, mais vers des URL intermédiaires.

L’URL du badge intermédiaire calcule la “hotness” et la popularité de l’élément avec les données de Redis, puis renvoie une demande de transfert HTTP 307 au client de messagerie. L’avant est pointé vers la bonne image de badge – une pour le chaud, une pour le populaire et une image spéciale vide/transparente pour les éléments qui ne sont ni chauds ni populaires.

L’URL intermédiaire de l’élément est un peu plus simple : cette URL enregistre qu’une visite s’est produite à un moment précis et incrémente un compteur pour le nombre de clics. Une fois terminé, il redirige toujours vers la même URL de destination.

Voici un schéma de l’ensemble du processus :

1
C’est moins compliqué qu’il n’y paraît.

Comment nous allons calculer la chaleur

Pour les besoins de ce script, un élément est considéré comme “chaud” s’il a été accédé plusieurs fois au cours des dernières minutes. Pour déterminer la «chaleur», il fallait compter les minutes et compter les bits.

Redis est capable de retourner des bits individuels dans une chaîne et nous pouvons exploiter cette fonctionnalité pour être extrêmement granulaire dans un espace de stockage minimal.

Chaque “élément” est représenté par une chaîne dans Redis avec une clé dérivée à la fois de la campagne et d’une certaine forme d’identifiant d’élément. Nous allons faire en sorte que la clé ressemble à ceci :

deals:august17:camera
^^^^^ ^^^^^^^^ ^^^^^^
|     |        |----> the item ID is "camera"
|     |----> the campaign is "august17"
|----> The "root" of the key

Nous devons commencer à compter à partir d’un point fixe dans le temps – un peu comme le système de temps d’époque UNIX, nous utiliserons juste un point. Pour cet exemple simple, nous choisirons simplement le 1er juillet 2017 à minuit (GMT) — le compterEpoque. Nous allons comparer cela avec l’horodatage actuel en utilisant le date-utils Module Node.js.

minutesSinceEpoch = countEpoch.getMinutesBetween(new Date())

Par exemple, à 1h du matin le 1er juillet 2017, le minutesDepuisEpoque serait 59 (et non 60, à cause du comptage à partir de zéro). Nous allons retourner un seul bit chaque fois qu’une personne interagit avec un élément. Notez que si deux utilisateurs interagissent avec le même élément au cours de la même période de minutes, il n’est compté qu’une seule fois – nous obtenons l’activité plutôt que le décompte dans ce cas. Ceci est très économe en espace et fournit des données très riches avec une empreinte de stockage minimale. Chaque jour depuis le compterEpoque consommerait 180 octets, ~ 5,4 Ko par mois ou ~ 65 Ko par an. Pas mal.

1 QqO tbdW9hasJmpgf3GERA

Pour inverser les bits, nous pouvons utiliser la fonction Redis SETBIT le décalage étant le minutesDepuisEpoque et la valeur étant un 1, représentant une visite. Donnez l’exemple ci-dessus (1h du matin le 1er juillet), notre commande Redis ressemblerait à ceci :

> SETBIT deals:august17:camera 59 1

SETBIT est une commande peu coûteuse en calcul, étant O (1) et sinon au niveau de l’application, nous avons juste besoin de faire une petite soustraction pour obtenir le minutesDepuis l’époque.

Interroger les bits “chauds” nécessite un peu plus de travail. Nous pouvons utiliser la commande Redis BITCOUNT. Avec cette commande, nous pouvons trouver le nombre de 1 définis pour une chaîne donnée. Bien que cela soit utile en soi, nous voulons ajouter une récence – pour notre application, il n’est pas pertinent de déterminer que l’élément a été en interaction il y a 2 mois – nous devons trouver uniquement l’activité récente. Avec BITCOUNT, nous pouvons fournir les arguments optionnels de début et de fin pour ne découper qu’une petite partie des données. Les arguments de début et de fin “s’enroulent” également avec des nombres négatifs, de sorte que vous ne pouvez compter que les bits à la fin des données. Dans notre exemple, travaillons avec les trois derniers octets :

> BITCOUNT deals:august17:camera -3 -1

Bien que cette commande définisse des bits, il est important de comprendre que Redis ne traite que les octets dans les arguments de plage de BITCOUNT. Cela introduit un peu de négligence dans le calcul : réfléchissez si vous définissez le 17e octet dans l’exemple ci-dessous :

01234567|01234567|01234567
--------+--------+--------
00000110|00001010|1

L’exécution de la commande ci-dessus compterait cinq 1 bits des 3 derniers octets, ce qui n’est pas parfaitement 24 minutes car 3 octets pourraient vous faire penser. Donc, nous disons en fait que 5 des 16 à 24 dernières minutes étaient actives. Dans notre cas d’utilisation, nous essayons vraiment d’obtenir une sensation relative de chaleur et non un absolu, donc c’est acceptable compte tenu de l’efficacité espace/temps.

Calculer la popularité

Dans notre cas d’utilisation, nous allons trouver l’élément avec le plus grand nombre de clics, quel que soit le temps. Il s’agit d’un processus simple dans Redis. La structure de données de l’ensemble trié excelle dans la création de classements – notre popularité est calculée en trouvant le meilleur élément parmi tous ceux du groupe.

Pour enregistrer la popularité, il nous suffit d’incrémenter le score d’un élément dans un ZSET à chaque fois qu’il est cliqué. Nous pouvons y arriver en utilisant le ZINCRBY commande. Il s’agit d’une clé unique pour toute la campagne et le membre est l’ID de l’article. Nous voulons l’incrémenter de un. Dans Redis, nous ferions quelque chose comme ceci :

> ZINCRBY deals:pop:august17 1 camera

Pour être clair, le score agit simplement comme un compteur. Alors, si le caméra article dans le 17 août campagne a été cliqué 47 fois, 46 le premier jour et une fois de plus le jour 400, le score serait de 47.

Pour chaque badge, nous vérifierons si le ID de l’article est le plus populaire. Nous pouvons le faire en exécutant:

> ZREVRANGE deals:pop:august17 0 0

Si la réponse de ceci correspond à la ID de l’article alors l’article est le plus populaire.

Problèmes de performances

Comme vous l’avez peut-être remarqué dans le diagramme de processus, cela produit un système très “bavard” avec plusieurs pièces mobiles. Les transferts HTTP ajoutent un aller-retour réseau supplémentaire et un temps de transit supplémentaire. Il est essentiel de minimiser le temps passé à la fois à enregistrer et à calculer la popularité. Redis est bien connu pour sa faible latence et sa rapidité à calculer les valeurs.

La dynamique de ce type d’e-mails livrés à une grande liste de clients en même temps présente également des défis. Disons que votre e-mail est livré à 500 000 destinataires en peu de temps et qu’ils commencent à interagir avec et à afficher l’e-mail simultanément. Avec une seule instance de Redis, vous pourrez peut-être résister à la tempête, mais la nature à thread unique du serveur pourrait créer des latences plus élevées que souhaitées sous charge. De plus, nous créons un point de défaillance unique qui est risqué. Un bon match pour ce cas d’utilisation serait Entreprise Redis. Redis Enterprise peut fournir une haute disponibilité avec basculement automatique pour garantir que vos actifs de messagerie n’ont pas de point de défaillance unique et il peut également fournir un clustering qui peut répartir la charge sur plusieurs threads et/ou machines réduisant la latence.

Prochaines étapes et autres utilisations

Au-delà de ces autres cas d’utilisation, les données peuvent être exploitées d’autres manières. Les données “hotness” sont un bitmap qui peut être calculé pour voir combien d’heures d’activité un élément donné a sur une plage de temps donnée en utilisant BITCOUNT avec des décalages basés sur les minutes calculées. Vous pouvez également agréger l’activité de plusieurs éléments à l’aide de BITOP:

> BITOP AND camera-and-watch deals:august17:camera deals:august17:watch

Ensuite, vous pouvez découper une période de temps donnée de caméra-et-montre pour déterminer la chaleur pendant un laps de temps.

La technique de shimming Node et Redis entre vos points d’interaction et vos actifs ne se limite pas à diffuser des images d’e-mails, mais peut être intégrée à n’importe quelle plate-forme pour modifier dynamiquement les images au fur et à mesure que les données changent. Dans son état actuel, il pourrait être appliqué à un système de commerce électronique avec très peu de modifications pour fournir les mêmes informations de “badgeage”. L’intégration avec d’autres données pourrait faire varier le badge résultant en fonction de plus que de la « popularité » et de la popularité, mais également de variables telles que le stock d’articles (« Presque disparu ! ») ou les remises (« Économisez 20 % »). De plus, associé à un système utilisateur, il pourrait être bon pour des offres personnalisées (“Recommander” ou “Notre choix pour vous”). Imaginez même intégrer les conditions d’emplacement du client (“Beat the Heat” sur un climatiseur si l’emplacement du client est chaud).

Le code source se trouve sur GithubGenericName.

(Ce message a paru à l’origine dans le Noeud / Redis série sur Medium)

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *