Closed Bug 841894 Opened 12 years ago Closed 12 years ago

[basket] [Exact Target] welcome email HTML vs. TXT logic

Categories

(www.mozilla.org :: General, defect, P1)

Product:
www.mozilla.org
Component:
General
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jdavis, Assigned: pmac)

References

Details

(Whiteboard: u=user c=email p=)

Based on the great points made in Bug 772788 and in the mozilla.privacy google group, we should honor HTML vs. TEXT email format for new signups when sending them the welcome email. This means: 1) Basket needs logic to send more than the default ID "39" EN welcome email in HTML - Bug 829278 2) Basket needs logic to determine when someone signs up for the EN newsletter and selects Text, basket should fire this welcome email ID: "Welcome_Email_EN_TXT"
Depends on: 772788
Adding a dependency here for flicks. We need #1 to send the flicks specific sign up.
Blocks: 829278
No longer depends on: 829278
Assignee: nobody → pmac
Priority: -- → P1
When basket triggers the send of the welcome email, it passes the same info that it does to the default data extension. So the trigger send is getting the preferred email format. Is there no way to have a single welcome email ID respect this preference, or do we have to have a separate email ID for text and HTML emails?
Flags: needinfo?(jdavis)
Hey Paul - excellent question. The main snag that prevents us using a single campaign ID is that we do not want link tracking on for our text emails - and link tracking is turned on/off my email ID. This means we have to have 2 separate email IDs: 1 for HTML emails with link tracking on (which has a plain text MIME counterpart for people who's computers prefer to display the text version) 1 for Text with link tracking off (and is only a plain text email - no MIME) -------------- There is a potential alternative that uses 1 Campaign ID, but I think the complexity of the workaround may be more work than creating this logic in basket. The alternative is: 1) using AMPScript in the text email part of the HTML/Text email to prevent link tracking (I don't know how to make this work - I'd have to get Exact Target to set it up for us) 2) find a way to sync the information we send to the main data extension for email_format to the All Subscribers List in Exact Target so that ET understands which version of the email to send. For step 2 we'd have to change basket to not only have an API call to pass info through to the data extension, but also to pass through the info to All Subscribers List, and then trigger the welcome campaign ID. With this setup, we'd have to make sure that Exact Target looks at the All Subscribers entry before the welcome ID is sent. (Currently the subscriber is added to All Subscribers *after* they are sent the welcome email and email_format is not updated in All Subscribers.) There may be an option to get the welcome email to fire not by API call, but by adding the subscriber to a particular list in All_Subscribers. I'd need to make sure there wouldn't be any account capacity problems with firing the emails from a list inside of All Subscribers. We'd definitely need to make sure that they're still added to the data extension for our segmentation and query capabilities. We currently do all of our email sending based on segmentation of our main data extension rather than their list functions. We only use their list function to keep up with bounce and spam complaint list management. We have our account set up this way b/c our database is so large (and to have complete control over our link tracking + email format settings). --------- Let me know if this makes sense or if I can help clarify further. Also let me know if you're interested in checking out the alternative. These are the steps: 1) Jess to talk with Exact Target to see if it's feasible (does AMPScript work and will we have any capacity problems with using a List) 2) Jess to get Exact Target to set up the AMPScript for our welcome email's text version 3) Jess to give API call info for adding a new subscriber to the right list 4) pmac/team to update basket so that in addition to adding the subscriber to the main data extension, they are also added to a list in ET - and the welcome email API trigger is removed
Flags: needinfo?(jdavis)
I don't think the alternative is necessary. Keeping the logic in basket is fine and more flexible for us. I would like to ask if we can keep with an email naming convention however. Will we always have an html and txt version of the welcome emails? If so, can we name them consistently? I propose: "email ID" + "_" + Format Where Format is "H" or "T" for HTML or text respectively. If we can modify our current emails for this (or make copies) and use this for all future welcome message IDs, then this will be easy to maintain in basket. Otherwise we'll have to hard-code all the various versions of the email IDs and maintenance will be much harder for us.
Awesome - thank you :) We can definitely edit the naming convention of our current campaigns and make sure we follow the convention going forward. Right now the "email ID" isn't always a number...ex: "fr_confirmation_email" "Firefox_Flicks_Welcome" What's the format you'd like for the "email ID" part? I can dump all of the current IDs in an etherpad if you'd like to see them all and rename them in a basket friendly way.
Basket doesn't really care about the naming convention apart from it being the same for the "H" and "T" varieties. I personally prefer a descriptive name so that it's easy to tell what's going on, but that's not a hard requirement. We could do "39_H" and "39_T" if we wanted, but I wouldn't recommend it. If I were asked what to do, I'd go with something like "welcome_firefox_flicks" for an ID. I'd put the kind of email first (welcome) so that sorting would be nice in the ET interface. I'd have them lower case with underscores just be cause I like that better than title caps when we can't use spaces, and it will make the "H" or "T" at the end stand out. But it's really up to you ET admin users what works best as long as it's consistent. Having a list of the IDs would probably be nice. I'd like to also add a mapping of newsletter ID to welcome email ID so that client code wouldn't have to change if we wanted a newsletter to use a diffent welcome message.
Hey pmac, I started this etherpad to take stock of our current list of triggers: https://etherpad.mozilla.org/basket-welcomeIDs The snag for renaming is going to be timing: we don't want to lose people in the process (if possible) when pushing the basket code live and re-naming the internal newsletters. Do you know of a way we can minimize subscriber trigger welcome loss during the naming switch? (especially for l10n emails who have to confirm their email address from the welcome email before they are subscribed to the email list.)
Speaking of the confirmation emails for various languages... do those also need HTML and text versions? And after they confirm, should they be sent a regular welcome message - and so should that be translated too?
(In reply to Jessilyn Davis from comment #7) > The snag for renaming is going to be timing: we don't want to lose people in > the process (if possible) when pushing the basket code live and re-naming > the internal newsletters. > > Do you know of a way we can minimize subscriber trigger welcome loss during > the naming switch? (especially for l10n emails who have to confirm their > email address from the welcome email before they are subscribed to the email > list.) My only thought is to copy the existing ones to new names, then delete the old ones after we're done with the push. How hard would it be to make copies of them? Otherwise, we may have to do some coordination with you and IT to make things happen as simultaneously as we can.
Whiteboard: u=user c=email p=
Blocks: 772788
No longer depends on: 772788
Blocks: 829282
pmac - instead of adding a _T and _H - could we just make sure the text only versions have _T and the HTML versions don't have any _H at the end? That would save us from having to recreate and rename the current HTML emails. Not a huge deal if not.
Hey Dan - excellent questions - see inline. (In reply to Dan Poirier [:dpoirier] from comment #8) > Speaking of the confirmation emails for various languages... do those also > need HTML and text versions? Yes - I'm working on creating the text only versions. > > And after they confirm, should they be sent a regular welcome message - and > so should that be translated too? Right now - no. They just see an instant confirmation message on the confirmation link landing page that thanks them for confirming and to keep an eye out for upcoming newsletters.
(In reply to Jessilyn Davis from comment #10) > pmac - instead of adding a _T and _H - could we just make sure the text only > versions have _T and the HTML versions don't have any _H at the end? That'll work fine. The main thing is that they match for the first part. Just to demonstrate that I'm understanding correctly, if we currently have "Firefox_Flicks_Welcome", what we'll have is: HTML Version: Firefox_Flicks_Welcome Text Version: Firefox_Flicks_Welcome_T As long as the first part matches, it doesn't matter what it is. All I'll be doing is tacking a "_T" onto the end of whatever message ID I'm given and expecting it to exist.
\o/ Rockin - I can do that. Thank you! :D
Any status on setting up the new welcome messages?
Welcome messages are set up and live! :D Let me know if you find one that's missing from the gdoc "list" - I added in the "ET newsletter ID (text ends in _T)" col.
Depends on: 730388
This is now fixed in production!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
\o/ Looks GREAT!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.