-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cycle d'emailing #35
Comments
Je viens d'avoir un feedback d'un user qui se demandait si c'était possible de ne pas recevoir un email de 24h par montre. Cette personne a du lancer 15 mesures d'affilées de toutes ses montres, du coup, il se fait littéralement spammé. Je propose donc que pour le mailing des 24h, on fasse la condition suivante :
Bien sûr ça doit être "chainé" pour le cas ou il y avait un mail prévu à 13h, un à 14h50 et un à 16h où on enverrait donc le tout à 16h. Pour le wording, le nom de la campagne etc, on garde la même chose que pour le mail des 24h de base, il faut juste rajouter le nom de toutes les montres (on peut conserver que le #watchbrand pour pas faire trop lourd) et mettre le pluriel partout. Thanks pirate ! |
Un petit commentaire sur les templates. Il me semble que l on devrait ajouter le prenom de l user en lieu et place de De meme pour les sujets, |
Complètement, c'est aussi beaucoup plus dans le ton qu'on veut avoir. |
Autre question, est-ce que tracking = tag pour mandrill ? Ou alors pour toi tracking c est |
On peut voir ça à mon retour à 19h30 ? Je suis pas sur d'avoir compris :D |
y a deux possibilite pour classer les emails dans mandrill, soit les tag, soit un nom de campagne google analytics et dans le fichier |
Juste pour être sûr, quand tu parles de "classer les emails dans mandrill", à part pour les retrouver si tu as 15 000 emails auto que tu envoies, ça sert à quoi ? Si c'est juste du "rangement", je crois que le nom de campagne GA sera suffisant pour qu'on s'y retrouve. Dans mes specs, quand je parle de code de tracking, c'est le code que je souhaite voir passer dans nos rapports GA pour qu'on puisse comprendre quels mails génèrent du trafic et qu'on puisse analyser tout ça. Je ne sais pas si j'ai rep à ta question mais je suis dispo sur Skype ce soir si besoin |
ok, parfait. Merci ! |
Bon, j ai un soucis avec cette issue. J ai termine une version event based qui va avec le schema https://github.com/MathieuNls/tw/wiki/emails%20flow. A chaque event donc, on check si ca declanche pas un email / annule pas un email qui est deja planifie / bundle ou re-bundle des emails deja planifies avec un nouveau. Le soucis c'est que la complexite du code devient trop importante pour un processus qui n est pas le core de toolwatch et que ca scale pas. Ou du moins, ca scale mal. Partiellement a cause de l API de mandrill qui refuse que je bourine. Du coup, je vais refaire une version batch based, ou toutes les x heures, un background process va checker si y a des emails a envoyer et les envoyer (tj en passant par mandrill) mais sans les plannifier a l avance. Du coup, pas besoin d annuler, pas besoin de spammer mandrill. Certains emails seront toujours declanches par des evenements, du style signup, reset password, add second watch ect. Les autres, ceux qui demande d etre bundle (check accuracy, start new measure, ect) le seront par batch (toutes les 2 heures or so). M. |
Ca m'a l'air très cool aussi en batch based ! |
Est-ce que vous pourriez me faire un batch de tests (comme on avait fait avec les mesures) histoire que j integre ca aux tests automatiques. Du coup, ca serait genre un csv avec
En vous basant sur https://github.com/MathieuNls/tw/wiki/emails%20flow. L'idee c est de creer assez d'users / mesures / montres pour couvrir tout les cas puis ajouter les emails attendus a une date. Par ex: si les emails partent le 25 Septembre a 12:45:00 alors x, y, z recoivent a, b, c emails. Bon courage :D ! |
This reset_email function truncates the email_batch table. This is purely for testing purposes and should be removed before go live
The old version of the ics helper was building correct icss. However, gmail only recongnizes icss built with Google Inc/GoogleCalendar PROID
The accuracyAge property is used in the dashboard summary in emails (views/email/generic.php). We could use it in the 'real' dashboard to (views/measures/dashboard.php)
Hello,
Nous allons étoffer notre cycle d'emailing pour améliorer notre rétention. Je te mets donc la liste des emails avec le trigger associé et le tracking et en pièce-jointe je rajoute le contenu des emails. Ce ticket est lié au #22 ;)
Les emails automatiques que nous avons déjà :
Pour ces emails auto, il faut juste rajouter l'emoji suivant à la fin de l'objet : ⌚ Ce qui donnerait pour le Welcome email : "Welcome to Toolwatch ! ⌚" et le nom de la campagne (cf #22)
Les nouveaux emails automatiques :
Trigger : 24h après le signup si l'user n'a pas ajouté une montre.
Tracking : add_first_watch_email
Trigger : 24h après l'ajout d'une montre si l'user n'a pas fait de mesure sur celle-ci.
Tracking : make_first_measure_email
Trigger : Dès que l'user obtient le résultat de sa montre
Tracking : watch_result_email
Trigger : 48h après avoir fait la toute première mesure complète (on ne doit pas recevoir ce mail à chaque mesure !) ET si l'user n'a qu'une seule montre ajoutée.
Tracking : add_another_watch_email
Trigger : 30 jours après le résultat d'une mesure.
Tracking : start_new_measure_email
Trigger : 100 jours après la dernière action (inscription, ajout d'une montre, première mesure ou résultat ET on ne doit pas recevoir ce mail qu'une seule fois)
Tracking : comeback_100d_email
Trigger : 6 jours après le 24 email si la mesure n'a toujours pas été faite
Tracking : check_accuracy_1w_email
The text was updated successfully, but these errors were encountered: