En général, les gens n'aiment pas recevoir des e-mails non sollicités. Néanmoins, ils s'abonnent parfois à des newsletters afin d'obtenir une réduction ou de se tenir au courant des nouveaux produits. Cet article présentera une approche pour concevoir une base de données de newsletter.
Pourquoi s'inquiéter des e-mails de newsletter ?
Les abonnés à la newsletter représentent un groupe de clients extrêmement précieux - ils sont intéressés par nos produits, ils nous font confiance et ils passent du temps à examiner nos offres et promotions. De plus, l'envoi d'e-mails aux clients est l'un des outils les moins chers du marketing en ligne. Cependant, cela doit être fait avec soin - les données doivent être mises à jour quotidiennement (car les gens s'abonnent et se désabonnent) et être de haute qualité (nous ne voulons pas envoyer d'e-mails indésirables, car cela a un impact négatif sur l'image de marque).
La question se pose donc de savoir comment gérer ce processus d'obtention de données de qualité et de mise à jour quotidienne. Il y a beaucoup d'options ...
Et le gagnant est...
Analyse client ! De nos jours, le facteur le plus important pour garder une longueur d'avance sur la concurrence est de trouver des informations à partir des données et de prendre des décisions commerciales sur cette base. Ne serait-il pas formidable de parcourir l'historique des envois de newsletters et d'analyser leur intensité et leur efficacité ? Pour chaque client ? Et ensuite, associez-les aux données d'achat, découvrez les intérêts du client, préparez des recommandations individuelles et envoyez-les via des e-mails personnalisés ?
Une telle approche augmenterait sûrement notre taux de conversion (CR). Le taux de conversion est l'un des indicateurs de performance clés du marketing en ligne les plus importants; il montre combien de personnes effectuent un achat après avoir vu certains de nos supports promotionnels (publicités, newsletters, etc.). Un CR élevé signifie une efficacité commerciale accrue.
Maintenant que nous comprenons une partie du marketing impliqué, passons au modèle de données !
Commençons à modéliser une base de données de newsletter !
En creusant droit, nous voyons que les deux tables principales du modèle sont le client et newsletter tableaux.
Comme nous serons principalement intéressés par l'analyse client, le client la table doit rester au centre du modèle. Dans ce tableau, chaque client a son propre id unique . Nous stockerons également des informations telles que le first_name du client et last_name , coordonnées (email , phone_number , adresse), birthday , create_date (lorsque la fiche du client a été saisie dans la base de données) et son source_id - c'est-à-dire s'ils se sont inscrits sur notre site ou si un partenaire commercial nous a fourni leurs données.
La newsletter table stocke des données concernant chaque création de newsletter. Les newsletters peuvent être identifiées en fonction de leur id unique . Chacun est décrit par un name (par exemple "Nouvelle collection de vêtements pour femmes - Automne 2016"), e-mail subject ("Les vêtements les plus à la mode pour elle - achetez maintenant !"), html_file (le fichier contenant le code HTML pour cette newsletter particulière), newsletter type (par exemple "nouvelle collection", "bulletin d'anniversaire") et la create_date .
Consentements marketing
Pour envoyer des informations marketing (par courrier, téléphone, e-mail ou SMS), une entreprise doit obtenir le consentement de ses clients. Dans notre modèle, les consentements sont stockés dans une table distincte nommée marketing_consent . Il conserve des informations sur l'ensemble actuel de consentements marketing pour tous nos clients. Les consentements sont codés sous forme de variables booléennes - TRUE (accepte la communication marketing) ou FALSE (n'est pas d'accord).
Il est très important de stocker des informations concernant le moment où un client a accepté de recevoir des publicités via chaque canal de communication. Il est également avantageux d'enregistrer quand ils ont retiré leur consentement pour chaque canal. À ces fins, le consent_change tableau a été conçu.
Chaque modification a un id unique et est attribué à un client particulier par son client_id . Lorsqu'un client demande à être retiré des e-mails de la newsletter, la newsletter id depuis le channel table sera également stocké dans le consent_change channel_id de la table attribut. Le new_consent L'attribut est une valeur booléenne (TRUE ou FALSE) et représente de nouveaux consentements marketing.
La update_date La colonne contient la date à laquelle un client a demandé un changement. Cette structure nous permet d'extraire un ensemble de consentements pour tous les clients un jour donné. C'est extrêmement utile si un client se plaint de recevoir un e-mail alors qu'il s'est déjà désabonné de notre newsletter. Avec ces informations dans le dossier, nous pouvons vérifier quand le désabonnement a eu lieu et, espérons-le, confirmer que cela a été fait après l'envoi de la newsletter par e-mail.
Garder les envois dans l'ordre
Concevoir un modèle de base de données parfait pour l'envoi de newsletters n'est pas un jeu d'enfant. Pourquoi? Eh bien, évidemment, nous devons être en mesure d'identifier chaque création de newsletter (c'est-à-dire la mise en page, les graphiques, les produits, les liens, etc.). On sait aussi qu'une création peut être envoyée plusieurs fois :les managers peuvent décider qu'un bucket d'e-mails sera envoyé le matin à la moitié des clients et le soir à l'autre moitié. Il est donc crucial d'enregistrer quels clients ont reçu quelle newsletter et quand. C'est pourquoi cette partie du modèle se compose de trois tableaux :
- La
newslettertable - que nous avons décrit précédemment. - La
newsletter_sendouttable – qui identifie une seule émission. Par exemple, la newsletter de Noël (id ="2512") a été envoyé par e-mail le 10 décembre à 18 heures. Cette tenue de registres permet aux responsables marketing d'envoyer la même newsletter à des groupes de clients distincts à des moments différents. - Les
sendout_receiverstable – qui collecte des données sur les destinataires de chaque envoi. Il y aura un enregistrement pour chaque e-mail de chaque envoi. Chaque ligne comporte trois colonnes :id(identifiant l'événement d'envoi d'un email à un client),client_id(identifiant les clients de notre base de données) etnl_sendout_id(identifiant un envoi de newsletter).
Voici le modèle complet de newsletter :
Des idées pour améliorer ce modèle ?
Une façon possible est d'ajouter une response table. Cela stockerait les réactions des clients - qu'ils aient ouvert l'e-mail, cliqué sur la publicité ou n'aient jamais vu le message car il était marqué comme spam. Où devrions-nous ajouter la response table à notre modèle et quelle relation appliquer ? Partagez vos impressions dans la section des commentaires ci-dessous.
