Privacy: teacher sign-up has email preference

[breville]

Teacher sign-up now has an option to choose email preference. A choice is not required to submit the form at this time. Choosing "yes" or "no" writes the choice as an EmailPreference, while choosing neither does not write an EmailPreference.

The option is shown as a drop-down, though a hidden alternative uses radio buttons. An A/B test is able to show this alternative using something like this:

  $("#optin-container").remove();
  $("#optin2-container").show();

This change also loads Optimizely on the sign-up page.

dropdown

radio button alternative

[sureshc]

After I merge #22277, this would change to EmailPreference::REGISTRATION

[tanyaparker]

@breville Just confirming that for the radio button the default is neither selected?

@poorvasingal is it desired behavior that selecting neither Yes/No submits them as No? Can't we continue to keep it as NULL like past signups? That way we can also track what percentage of people are completing this question as well as the percentage of people who say Yes/No?

[breville]

@tanyaparker Correct, neither radio button is selected by default, and the form can be submitted with neither selected.

[tanyaparker]

Oh I thought in your description but not choosing "yes" will default to an email preference opt-in choice of "no". meant not answering = "no"

[breville]

Not answering does mean recording their opt-in choice as "no" in the database, though subject to the full business logic in #22277. I was just answering the first question about radio button behaviour. :)

[tanyaparker]

Oh ok, thanks for clarifying. Will wait to hear Poorva's preference for what we save in the DB when they don't answer.

[poorvasingal]

@sureshc mentioned that we * have * to submit a "Yes" or a "No." That's a bummer, because I agree with you Tanya that I'd want to know how many people are leaving this blank. My guess is that we're going to get a lot of "Nos" just because people aren't filling out this question.

How widely are we releasing this? To everyone in the US? We should make sure we don't test this in the EU yet since we can't yet track what text they saw when opting in.

[sureshc]

@breville You could skip invoking EmailPreference.upsert! when the user has not answered yes or no. A query of all teachers who registered after this question was added to the form, outer joined to email_preferences by email address would then get a list of yes/no/didn't-answer teachers.

[tanyaparker]

Gotcha, Poorva. Since it's a technical limitation, no worries.

[poorvasingal]

Sounds like we will still have a way to see how many people aren't answering? yay, thanks for checking Suresh!

[breville]

Ah, this is good information. In this case I'll hide the email preference option completely and we will have to show the one we want using Optimizely, targeting at US visitors. I'll also update so that we only write to EmailPreference if we get an explicit yes or no.

[breville]

Update: we will rely on Optimizely to show variants for US users, and will use it to determine success rate of the variants. Non-US users will see the strings as shown in the screenshots in this PR, with no variants, and we will record "yes" (if they choose "yes") or "no" (if they choose "no" or ignore the option), and we will record the "form_kind as "0" so that we know which option UI they were presented with.

[breville]

Update: we will rely on Optimizely to show variants for US users, and will use it to determine success rate of the variants. Non-US users will see the strings as shown in the screenshots in this PR, with no variants. We will record "yes" if they choose "yes", "no" if they choose "no", and will not write anything to EmailPreference if they ignore the option. We will record the "form_kind as "0" so that we know which options they were presented with.

[sureshc]

I merged #22277. If you pull the latest staging and merge into this branch you can change this to:

source: EmailPreference::ACCOUNT_SIGN_UP,

Here's the full list of source types based on @poorvasingal 's comment last night:

code-dot-org/dashboard/app/models/email_preference.rb

Lines 25 to 32 in 624df5d

	SOURCE_TYPES = [
	ACCOUNT_SIGN_UP = 'Teacher account sign up',
	ACCOUNT_TYPE_CHANGE = 'Student account change to teacher',
	ACCOUNT_EMAIL_ADD = 'Add email to teacher account',
	ACCOUNT_EMAIL_CHANGE = 'Update teacher account email',
	FORM_HOUR_OF_CODE = 'Host Hour of Code form',
	FORM_VOLUNTEER = 'Volunteer form'
	].freeze

[breville]

Thanks. I want to get this change in today so we can start a/b testing immediately but will make this fix in a follow-up.

[tanyaparker]

Where are we storing the strings that the user sees? Not sure if I understood your comment correctly. If non-US answers and we save them as form_kind = 0, that means they had the 0th version of the string? How will we know what the actual string was?

[breville]

Non-US users will see the string that's in our source code. I'm just using 0 as the reference for the default string as we are first shipping this UI to them.