Je travaille sur le processus d'intégration d'une webapp d'entreprise. L'un des éléments d'intégration est une série d'e-mails pour aider l'utilisateur à être opérationnel et à utiliser efficacement l'application. Mon expérience personnelle a été que si une entreprise me harcèle trop après m'être inscrite, je me désengage et commence juste à supprimer les e-mails. Existe-t-il des preuves qui permettent de pointer vers une fréquence efficace de courrier électronique d'inscription (c'est-à-dire quotidiennement, hebdomadairement, ...)?
Je ne fournis aucune preuve ou preuve de bonnes pratiques, mais j'ai remarqué une bonne chose sur TripAdvisor. Je me suis inscrit il y a plus d'un an, je n'y ai pas beaucoup réfléchi et j'ai reçu un ou deux e-mails. Comme je m'en fichais, l'e-mail a cessé de venir.
Cependant, j'ai commencé à publier des informations sur TripAdvisor après notre dernier voyage combiné en Islande et à New York (juste pour mémoire :)), TripAdvisor a commencé à interagir avec moi. Il y a des e-mails de "hé, votre dernière critique a obtenu un vote utile" et "Saviez-vous que votre critique de X a 500 lecteurs" et tout ce genre de e-mail positif.
Excellent travail de TripAdvisor, mais il faut beaucoup de travail pour mettre en place toutes ces règles. Mais avec un peu d'analyse Web, un service SMTP et une logique de conception, vous êtes sur la bonne voie.
Conseil? Suivez la fréquence de vos utilisateurs. S'ils se connectent 4 fois par semaine, vous pouvez envoyer 2 e-mails. S'ils ne le font pas, qu'ils le soient.
En règle générale, j'adopterais le principe "assurez-vous qu'ils sont toujours en vie":
Envoyez-leur un e-mail lors de leur inscription. Cela peut être un e-mail de confirmation ou simplement un e-mail de bienvenue.
Envoyez-leur plus quand ils interagissent avec le site, comme le mentionne Benny. Mais pas trop - beaucoup d'emails sont ennuyeux. Si vous devez vraiment envoyer des lots, offrez une option pour les désactiver.
S'ils cessent d'interagir, arrêtez d'envoyer des courriels - jusqu'à un certain point. Après quelques mois (ou quoi que ce soit), vous voudrez peut-être leur envoyer un autre e-mail en disant "Hé, êtes-vous toujours en vie? Ou tu ne veux pas de ton compte? Parce que s'ils n'ont plus besoin du compte et ils le confirment, vous pouvez le supprimer de vos serveurs et économiser de l'espace.
Ma plus grande recommandation serait de penser moins aux e-mails eux-mêmes, et plus à ce que vous voulez qu'ils fassent faire aux gens.
Par exemple, s'il est impossible d'obtenir de la valeur de votre application sans prendre trois étapes initiales (par exemple, créer un projet, télécharger votre logo et le partager avec un client), alors je chercherais à synchroniser les e-mails en fonction du moment où chacun de ceux-ci pourraient raisonnablement être accomplis, et n'envoyer le second qu'après le premier, et le troisième après le second, etc.
Rappelez-vous, vous envoyez des courriels pour ramener les gens dans l'application (avec une activité utile), pas seulement pour dire "salut".
Bien sûr, cette recommandation est remplacée par une recommandation encore plus grande, qui consiste à configurer n'importe quoi et à itérer en fonction de ses performances. Heureusement, vous pouvez aller encore plus bas qu'un test A/B typique simplement en mesurant les ouvertures/clics/désabonnements (pas l'approche la plus scientifique, mais une bonne première étape!).