Skip to content
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

Closed
AlphonseJr opened this issue Jul 7, 2015 · 19 comments
Closed

Cycle d'emailing #35

AlphonseJr opened this issue Jul 7, 2015 · 19 comments
Assignees
Milestone

Comments

@AlphonseJr
Copy link
Collaborator

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à :

  • Welcome email
  • 24h email
  • Lost password

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 :

  • Add First watch
    Trigger : 24h après le signup si l'user n'a pas ajouté une montre.
    Tracking : add_first_watch_email
  • Make First measure
    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
  • Result email
    Trigger : Dès que l'user obtient le résultat de sa montre
    Tracking : watch_result_email
  • Add another watch ?
    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
  • Start a new measure ?
    Trigger : 30 jours après le résultat d'une mesure.
    Tracking : start_new_measure_email
  • We haven't seen you for a while ?
    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
  • 7 days emails :
    Trigger : 6 jours après le 24 email si la mesure n'a toujours pas été faite
    Tracking : check_accuracy_1w_email
@AlphonseJr
Copy link
Collaborator Author

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 :

if 24h_email doit être sent à +/- 2h d'un autre 24h_email then on envoi un seul 24h_email à l'horaire du dernier email prévu
(je voulais m'amuser avec mon homonyme, Marc Down)

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 !

@MathieuNls
Copy link
Member

Un petit commentaire sur les templates.

Il me semble que l on devrait ajouter le prenom de l user en lieu et place de there dans Hi there. Vu que nous avons l information.

De meme pour les sujets, Justin, it's time to measure your Rolex. A mon sens, c est plus engageant et ca a moins de chance d etre mis en SPAM.

@AlphonseJr
Copy link
Collaborator Author

Complètement, c'est aussi beaucoup plus dans le ton qu'on veut avoir.
Thanks !

@MathieuNls
Copy link
Member

Autre question, est-ce que tracking = tag pour mandrill ?

Ou alors pour toi tracking c est google_analytics_campaign ?

@AlphonseJr
Copy link
Collaborator Author

On peut voir ça à mon retour à 19h30 ? Je suis pas sur d'avoir compris :D

@MathieuNls
Copy link
Member

y a deux possibilite pour classer les emails dans mandrill, soit les tag, soit un nom de campagne google analytics et dans le fichier emailing auto toolwatch, tu as mis tracking : X mais du coup, je sais aps a quoi tu fais reference

@AlphonseJr
Copy link
Collaborator Author

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

@MathieuNls
Copy link
Member

ok, parfait. Merci !

@MathieuNls
Copy link
Member

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.

@AlphonseJr
Copy link
Collaborator Author

Ca m'a l'air très cool aussi en batch based !
Thanks pour le follow up :)

@MathieuNls
Copy link
Member

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

user, action, time
dupont, sign_up, 22 septembre 2015 10:00:00,
monette, add_watch, ...
monette, measure_watch 1, ...
...
...

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 !

MathieuNls added a commit that referenced this issue Nov 23, 2015
MathieuNls added a commit that referenced this issue Nov 23, 2015
MathieuNls added a commit that referenced this issue Nov 23, 2015
MathieuNls added a commit that referenced this issue Nov 23, 2015
MathieuNls added a commit that referenced this issue Nov 23, 2015
MathieuNls added a commit that referenced this issue Nov 23, 2015
MathieuNls added a commit that referenced this issue Nov 24, 2015
MathieuNls added a commit that referenced this issue Nov 24, 2015
MathieuNls added a commit that referenced this issue Jan 31, 2016
MathieuNls added a commit that referenced this issue Jan 31, 2016
@MathieuNls MathieuNls modified the milestones: Tw 1.3, Tw 1.2 Feb 2, 2016
MathieuNls added a commit that referenced this issue Feb 2, 2016
MathieuNls added a commit that referenced this issue Feb 2, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
This reset_email function truncates the email_batch table. This is purely for testing purposes and should be removed before go live
MathieuNls added a commit that referenced this issue Feb 3, 2016
The old version of the ics helper was building correct icss. However, gmail only recongnizes icss built with Google Inc/GoogleCalendar PROID
MathieuNls added a commit that referenced this issue Feb 3, 2016
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)
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 3, 2016
MathieuNls added a commit that referenced this issue Feb 4, 2016
MathieuNls added a commit that referenced this issue Feb 4, 2016
MathieuNls added a commit that referenced this issue Feb 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants