1097152 - [project] add newsletter signup to Marketplace

Status: RESOLVED WONTFIX

(Tracking :: User Story, defect)

Description

[David Bialer [:dbialer]]

+++ This bug was initially created as a clone of Bug #1048522 +++
As bug 1048522 was too prescriptive and limited to the about:apps page, this is a project tracker to add newsletter signups to Marketplace.

Firefox OS users should be able to sign up for the new Firefox OS newsletter with a registered interest in Marketplace Apps.

Firefox for Android and Desktop users should be able to sign up for the Firefox and You newsletter with an interest in Marketplace Apps for their specific platform (Android or Desktop)


PRD: https://docs.google.com/document/d/1ZwOtOhkSSvB6an8fFklT7tBk3Y-KiueOzapef4U_CyA/edit?usp=sharing

Comment 1

[Elizabeth Hunt[:ezoehunt]]

Can we confirm the double opt-in requirement again? I just signed up for the general Moz newsletter and the Devhub newsletter. Neither of these asked me to double opt-in.

Jessilyn and David B: Please confirm this requirement. If it's required, provide an example implementation of it. For UX/design, we need the following:
What does the email to user say? 
What links does it contain? 
What page does user go to confirm opt-in? 
Is this a new page or an existing one? 
If existing, are any changes required in order to support this project.

Thanks.

Comment 2

[Elizabeth Hunt[:ezoehunt]]

Please confirm the privacy policy we should link to. See also the above questions.

For reference:
Mozilla.org newsletter signup links to this:
https://www.mozilla.org/en-US/privacy/

Devhub newsletter signup links to this:
https://www.mozilla.org/en-US/privacy/websites/

Comment 3

[Jessilyn Davis]

Hello!

Apologies on the delay.

As a best practice, all newsletters should have a double opt-in process. There is a feature that needs to be tested to unlock this capability (Bug 1099367 - Custom confirmation email for newsletter).

Firefox & You is currently the only newsletter with a double opt-in process, but this signup form should use the double opt-in process as well.

The best way to see all the steps is to go to https://www.mozilla.org/newsletter/  and signup with a unique email address (never before used in ExactTarget), and follow the steps:

1) sign up
2) receive confirmation email
3) click on the confirmation link
4) be taken to confirmation landing page
5) receive welcome email to Firefox & You (currently in EN only at the moment)

The changes in our system that have to happen to support this project are documented in Bug 1062523 - Email Engagement Program - Redesign 2014 


For designing the opt-in and implementing the opt-in code,no changes will need to be made at the moment on your end. Everything else is testing the new basket infra, email infra, and making sure that the right welcome and confirmation emails are sent based on passing through the subscription to Firefox & You (desktop & android) or Firefox OS Newsletter (OS).

Please use the privacy policy for the main newsletter: https://www.mozilla.org/newsletter/

that links to:

https://www.mozilla.org/privacy/

Comment 4

[Jessilyn Davis]

After Bug 1093185 goes live, here's how to test the form:


Scenario 1 -  Sign up on Marketplace form via desktop or Android (form field should use ID: "mozilla-and-you")

1) Go go <link of Marketplace signup form>
2) Signup in EN, HTML with unique email address
3) Make note of email address
4) Check email inbox for confirm email (make sure it arrived in right lang + email format)
5) Click on confirmation link
6) Make note of TOKEN in mozilla.org/newsletter/confirm/TOKEN
7) Receive Firefox & You welcome email (generic - not Marketplace nor Firefox OS specific)
8) Go to mozilla.org/newsletter/existing/TOKEN 
9) Make sure all these are checked as Y/subscribe:

Firefox & You (MOZILLA_AND_YOU)
 - and all interest areas:
 - Desktop (FIREFOX_DESKTOP)
 - Mozilla (general) (MOZILLA_GENERAL)
 - Android (ABOUT_MOBILE)
 - Marketplace Desktop (MARKETPLACE_DESKTOP)
 - Marketplace Android (MARKETPLACE_ANDROID)
 - Firefox OS launches (FIREFOX_OS)

10) Look up subscriber in Double_Opt_In data extension to make sure all flags and date fields are set correctly. (Subscriber will not be in Master_Subscribers until the nightly join query runs.)

11) Look up subscriber in Master_Subscribers data extension to make sure the new subscriber is NOT in Master_Subscribers yet (i.e. the double opt-in setting worked in basket). 

* Bonus Step 12) Wait till the next day (after the nightly join query runs) - or manually run Double_Opt_In_Join query - THEN, check Master_Subscribers for subscriber and make sure all flags are set appropriately.


Scenario 2 - Sign up on Marketplace form via a Firefox OS device (form field should use ID: "marketplace")

1) Go go <link of Marketplace signup form>
2) Signup in EN, HTML with unique email address
3) Make note of email address
4) Check email inbox for confirm email (make sure “Firefox OS” branded confirm email arrived in right lang + email format)
5) Click on confirmation link
6) Make note of TOKEN in mozilla.org/newsletter/confirm/TOKEN
7) Receive Firefox OS newsletter branded welcome email 
8) Go to mozilla.org/newsletter/existing/TOKEN 
9) Make sure all these are checked as Y/subscribe:

Firefox OS News (FIREFOX_OS_NEWS)
 - and all interest areas:
Firefox OS (FIREFOX_OS_USER)
Firefox OS (MARKETPLACE)
Mozilla (general) (MOZILLA_GENERAL)


10) Look up subscriber in Double_Opt_In data extension to make sure all flags  and date fields are set correctly. (Subscriber will not be in Master_Subscribers until the nightly join query runs.)

11) Look up subscriber in Master_Subscribers data extension to make sure the new subscriber is NOT in Master_Subscribers yet (i.e. the double opt-in setting worked in basket). 

* Bonus Step 12) Wait till the next day (after the nightly join query runs) - or manually run Double_Opt_In_Join query - THEN, check Master_Subscribers for subscriber and make sure all flags are set appropriately.

Comment 5

[Elizabeth Hunt[:ezoehunt]]

Here's the UX we decided on yesterday (11/20/14) -
http://people.mozilla.org/~ehunt/newsletter_signup_Nov14/newsletter_v1.7.pdf

Next step: visual design!

Comment 6

[Jessilyn Davis]

Exciting!

Quick feedback from my scanning:

1) Mozilla copy style: Titles shouldn't have first letter of every word capitalized:

Thanks for Signing Up! -> Thanks for signing up!


2) I'd recommend changing: "Sign up for the Mozilla newsletter" to something more like:

Sign up for our newsletter
Get Firefox news

There are many "Mozilla" newsletters at Mozilla - including the Foundation's newsletter program.


3) It looks like the current mockups are for linking text links to a landing page that has the form fields there? If possible, a better signup experience would be to include the fields on the page itself that advertises the link to go signup for the newsletter. 

For example, the form here includes all the info you need to signup: https://www.mozilla.org/en-US/firefox/new/

vs. a link that says "Sign up for our newsletter" and goes to: https://www.mozilla.org/en-US/newsletter/

Comment 7

[Elizabeth Hunt[:ezoehunt]]

Re #3 in Jessilyn's comment above:

The suggested approach doesn't work for mobile. Also we need a stand-alone newsletter signup form page, because it will be linked to from multiple locations.

We want to move forward with the approach shown in the wireframes. In the future, we can consider expanding the CTA banner to include the form.

Comment 8

[Elizabeth Hunt[:ezoehunt]]

Also the blue banner at the bottom of the viewport is promotional only. It will live there for some duration of time, e.g., one month. It is not meant to be a permanent placement and will go away at the end of the "get people to sign up" campaign. 

Users will always be able to sign up via the footer link (desktop) or via My Acct/Acct Settings (desktop + mobile). Those are permanent placements.

We did it this way to plan for the future, eg we will want to drive signups from multiple locations, e.g., a different newsletter, "ads" you might place elsewhere, Tiles, or other locations.

Comment 9

[David Bialer [:dbialer]]

This isn't a campaign with a start and stop time.  There is a start and stop duration for an individual user - so that new users are offered this opportunity.  The intent is not to temporarily promote the newsletter as in a campaigin.  It should be a permanent feature - to create awareness of the Mozilla newsletters (and the fact that there is an Marketplace section), and to offer the opportunity to sign up for it.  

Jessilyn: On signup - does MP receive a TOKEN back from the API call so that it can store the token, and we can then have a manage preferences link?

Comment 10

[Elizabeth Hunt[:ezoehunt]]

The "campaign" element has been removed from this. Now we have a signup form in the footer on desktop and in the My Account area on mobile.

Updated wireframes: 
http://people.mozilla.org/~ehunt/newsletter_signup_Nov14/newsletter_v1.8.pdf

Comment 11

[Jessilyn Davis]

(In reply to David Bialer [:dbialer] from comment #9)

> Jessilyn: On signup - does MP receive a TOKEN back from the API call so that
> it can store the token, and we can then have a manage preferences link?

This is a great question for pmac.

Comment 12

[Paul [:pmac] McLanahan]

(In reply to David Bialer [:dbialer] from comment #9)
> Jessilyn: On signup - does MP receive a TOKEN back from the API call so that
> it can store the token, and we can then have a manage preferences link?

You can have that happen. If you use HTTPS and pass a valid API KEY (which we can give you) then you can use the "sync=Y" parameter which would cause basket to do things synchronously instead of async which would take more time per request but would give you back the token.

The other method is to ask for the token later when/if you need it also using an API Key and the email address. This would be the method I'd suggest, but both are valid and should work.

Comment 13

[David Durst [:ddurst]]

Paul --

Seems like being able to get user info should be a requirement. Can we please get an API key?

Comment 14

[David Durst [:ddurst]]

Actually, as I'm looking at the documentation, I think that's incorrect. Because we aren't actually specifying newsletters in our form submission (but rather meaningful strings for basket), it sounds like: if we have a link for the user to click on from their account settings page that says "manage your subscriptions" (and we do, it goes here: https://www.mozilla.org/en-US/newsletter/existing/cfa06343-b2e5-4c33-9132-b2b95b21166e/), we need to pass along their email address as a GET param (I assume) and that page can use that to retrieve & show their data?

Comment 15

[David Durst [:ddurst]]

...and Mark has set me at least partially straight. The link in use is https://www.mozilla.org/en-US/newsletter/existing, which prompts you for your email address. Obviously, we'd like to not prompt them if possible (and if they're logged in, it should be possible).

Comment 16

[Paul [:pmac] McLanahan]

I'm confused about what you need David. The /newsletter/existing/{TOKEN}/ page on mozilla.org shows the user their current subscriptions and allows them to unsubscribe or subscribe to more. Adding an email via a query parameter won't do anything that I'm aware of. The {TOKEN} bit above is what identifies the user since allowing management of preferences via only email address would open everyone to having their account modified by anyone who knew their email. These links with the TOKEN are included in every newsletter email.

All that said, please let me know what you're interested in doing. It sounds like you want to allow people to manage their subscriptions from within marketplace? Since they can do that from the newsletter emails I'm not sure why this would be a requirement, but like I said above we can allow you to get the user's TOKEN via an authenticated call.

Comment 17

[David Durst [:ddurst]]

We need to provide them a link on marketplace's account settings page with their token included. So it sounds like we need to request that token (either upon login or just async on the account settings page) and then build the link with it.

Comment 18

[Paul [:pmac] McLanahan]

You'll need an API key and to use the lookup-user endpoint. If this is a python service, you can use our basket client (http://basket-client.readthedocs.org/en/latest/install.html), provide the API key in the settings and...

```
import basket

user_data = basket.lookup_user('[e-mail]')
token = user_data['token']
```

If it's not python the API docs for basket should help:

http://basket.readthedocs.org/en/latest/newsletter_api.html#news-lookup-user

Comment 19

[David Durst [:ddurst]]

Actually, let me confer with UX on this. There's a disconnect between the subscription email address and the FxA email address. The flow we have now may have to stick for a while.

Comment 20

[David Bialer [:dbialer]]

I think you can get a token on subscription possibly:

http://basket.readthedocs.org/en/latest/newsletter_api.html#news-subscribe

sync is an optional field. If set to Y, basket will ensure the response includes the token for the provided email address, creating one if necessary. If you don’t need the token, or don’t need it immediately, leave off sync so Basket has the option to optimize by doing the entire subscribe in the background after returning from this call. Defaults to “N”, 

I don't see a description of the response format.

Comment 21

[Paul [:pmac] McLanahan]

You can indeed. I mentioned this (albeit not as clearly) in comment #12. It'd be better for us though if you only requested tokens for those that want to use this feature since subscribing with sync=Y is significantly slower and more error prone since it directly relies on an external service instead of adding a task to our queue which we can manage and retry if the service is having problems.

Comment 22

[David Durst [:ddurst]]

Yes, but the issue is that a user isn't necessarily logged-in when they subscribe, so we can't necessarily attach a token to a known user. So this only gets us so far. Let's discuss it offline. (or someone can correct me if I'm overcomplicating this)

Comment 23

[David Bialer [:dbialer]]

We could:
a) if user is logged in when they subscribe, get the token with sync=y
  - if it is a new account, we will get the token back and store it with the account.
  - if an account already exists with that email address, we get the token and we should store that with the account.  Though I am not sure if we can verify that this user actually owns that account unless we only allow them to use their fxa email address when subscribing.
b) if the user is not logged in when they subscribe, we do sync=n and do not store a token.

c) there is a case that a user has a newsletter account, but logs into marketplace and doesn't have the token yet as the account was created elsewhere.  They would need to subscribe from Marketplace to manage their newsletter preferences.  OR we could do a lookup of tokenless logged in users, when they log in or go to account settings in marketplace.  But I don't think we should worry too much about this case and am fine if we just don't cover it.

Comment 24

[Elizabeth Hunt[:ezoehunt]]

Durst and I just talked about the newsletter signup launch. To clarify:

We are launching WITHOUT the newsletter management piece. We're not able to make the various solution ideas work by next week. So users will manage their email preferences via the email that is sent to them. This is fine; it's what they do right now for mozilla.org emails.

In the meantime, we will work toward a solution that allows users to access newsletter preferences via Marketplace Settings.

See here for updated ux doc - pages 11, 15, and 16 show the updated desktop and mobile Settings pages.
http://people.mozilla.org/~ehunt/newsletter_signup/newsletter_v1.9.pdf

Comment 25

[Sylvestre Ledru [:Sylvestre]]

Firefox os isn't a thing anymore. Closing.