Growth/Personalized first day/Engagement emails/ko

이 문서는 성장 팀의 "참여 메일"에 대한 설명입니다. 이 프로젝트는 "개인화된 첫 날"이라는 작업의 일부입니다. 이 문서에는 조요 요소, 디자인, 결정 사항을 나열하고 있습니다. 대부분의 순차적인 업데이트는 성장 팀 업데이트에 게시되며, 대규모 업데이트가 이곳에 기록됩니다.

성장 팀은 사용자에게 이메일을 보내는 데 있어 개인 정보 보호와 보안 등 많은 고려 사항이 있다는 것을 알고 있습니다. 성장 팀은 위키미디어 재단의 법률 관련 팀과 보안 관련 팀과 협업하여 개인정보가 적절하게 처리되도록 하고 있습니다. 또한 성장 팀은 공동체의 의견을 통해 이 기능이 "위키미디어"의 방식으로 개발되도록 노력하고 있습니다. 저희는 이메일의 좋은 기능과 도움이 되는 기능을 활용하고 싶지, 이메일의 짜증나는 부분과 부담되는 부분을 활용하고 싶지는 않기 때문입니다.

이 프로젝트는 현재 계획/디자인 절차에 있으며, 코딩은 시작되지 않았습니다. 현재 목표는 첫 이메일을 2019년 3월 말에 보내는 것입니다.



현재 상태

 *  - * 2018-12-06: 새 사용자의 첫 경험을 개인화하기 위한 아이디어에 관한 공동체 의견을 수렴하였습니다.
 *  - 성장 팀이 "참여 메일"과 "새 사용자 홈페이지"를 작업하기로 결정함.
 *  - * 다음: 디자인과 엔지니어링 조사, 코딩 작업 개시.
 *  - In collaboration with the Marketing Team and the Fundraising Team, the Growth team started working on Engagement emails.
 *  - Welcome emails experiment analysis published

요약
우리는 연구를 통해 새 사용자들이 특정한 목적을 가지고 위키에 온다는 것을 알고 있습니다. 목적을 달성하지 못하면 위키를 떠난 후 돌아오지 않죠. 환영 설문에서 우리는 새 사용자들에게 무엇을 달성하고자 하는지 물어봄으로써 그들이 목적을 달성하는 데 필요한 도움을 받을 수 있도록 하고자 했습니다. 이메일이 그러한 도움을 주기 위한 방식 중 하나입니다.

We also want to encourage people who provide their emails to the Wikimedia Foundation to edit. It is the case of donors, who give provide their email to get a donation receipt: they might be interested to an invite to edit the wikis when they are thanked for their domation.

달성하고자 하는 것:


 * 새 사용자가 열고, 링크를 클릭할 만한 이메일을 보냅니다.
 * 사용자에게 유용하고 참여할 만한 활동을 제공합니다.
 * 이메일의 콘텐츠를 새 사용자 홈페이지의 콘텐츠와 연동합니다.
 * 더 많은 새 사용자의 편집 지속

다음 사항을 원치 않습니다:


 * 너무 많은 이메일을 스팸처럼 보냅니다.
 * 새 사용자가 위키 안에서 어떻게 소통할지 배우지 못하도록 합니다.
 * 너무 많은 개인화로 이메일이 무섭게 느껴지지 않도록 합니다.
 * 새 사용자의 영향이 낮았다고 함으로써 새 사용자의 의욕을 저하시키지 않도록 합니다.
 * 사용자를 위키 안의 애매모호한 문서로 넘기지 않습니다.
 * 성장 팀의 프로젝트와 다른 팀의 프로젝트를 섞지 않습니다.

이메일가능성: 이메일을 보내기 위해서는 새 사용자가 인증된 이메일을 등록하고 이런 이메일을 받도록 옵트인해야 합니다. 이러한 옵트인 기능을 추가하는 것과 더불어 이메일 주소를 더 쉽게 추가하고 인증할 수 있도록 하는 여러 방법을 고려하고 있습니다. 새 사용자에게 이메일을 등록하도록 강요할 생각은 없지만, 이메일을 등록하고 인증하는 것의 장점을 명확하게 나열하고 더 쉽게 인증하도록 할 수 있는 방법이 있다고 생각합니다.

Why this idea is prioritized
Once a newcomer leaves the wiki after their first day — whether they do or do not accomplish their goals — it is likely that they are never encouraged to contribute again. This is because all existing communication channels are on wiki, even though the newcomer is no longer on the wiki. We can use email as a proactive communication vector to reconnect with new users off-wiki to help them to make their first edits or to continue making edits.


 * Community members were positive in their feedback on the idea.
 * Reach users no longer on wiki: emails enable communication with users who may likely no longer be active on wiki (and would therefore not see activity on Talk pages and Notifications).
 * Communicate with new users unfamiliar with Talk pages: automated communications exist in the wikis in the form of bots that post on new user talk pages.  While in some cases, those postings generate emails, email is not being fully utilized to get the attention of newcomers, who are usually not accustomed to how Talk pages work. Wikipedians who have experience mentoring newcomers have had success using email to communicate, since it is a medium they understand.
 * Email campaigns are a proven means of engaging users of software: email is used by virtually all other community contribution platforms (e.g. TripAdvisor, Google Maps/Locals, Wikia) to engage users.
 * Newcomers care about impact: many interviews with Wikipedians have surfaced that new editors first become enthusiastic about Wikipedia when they realize that others are reading their contributions.  Email can be a way to make users aware of their impact. There have been example of success in showing Impact data in other Wiki projects such as the Outreach dashboard (see comment here).

Comparative review
To learn how best to design engagement emails, our team's designer reviewed the way that other platforms (e.g. TripAdvisor, Wikia, Google) send emails to newcomers. While the experience we want to give newcomers is definitely different than other platforms (we want to give newcomers an optional, lightweight, non-invasive experience), we also recognize that there are best practices we can learn from other software. The comparisons are recorded in detail on this Phabricator task.


 * Takeaways from looking at emails
 * Show impact via celebration of milestones/achievements of a recipient’s contribution statistics or social impact (x people read your review) to motivate continued/re-engagement
 * Appeal to prosocial behavior (your contribution helps others)
 * Appeal to social proof encourages emulation (testimonials or examples of others participating)
 * Provide personalized recommendations that target specific interests of individuals reduces effort for someone to find out how to participate according to their interests
 * Personalized messaging in general is important (e.g., subject lines, copy, when the email is sent)
 * Provide onboarding help anticipates issues faced by newer recipients on how to get started, as well as remind them of the value of the sender’s product/service
 * Time messages to a relevant or meaningful event or timeframe (for example, an ‘impact’ email for the year sent at the end of the year)
 * Subject lines are direct, succinctly encapsulating the email’s intended purpose/message
 * Short, text-lean messages
 * Personalized, informal language is generally used
 * Usually contain a single, main call to action that is specific and prominent
 * Requests for specific follow up and feedback are sometimes shown towards end of messages
 * Optimize for mobile - commonly by using simple, single column layouts with centered text
 * Branding is prominent shown at the top of the email
 * Scorecards and ranking illustrations (leaderboards, badges, etc) are often used in impact emails
 * Minimal use of graphics, predominantly visual clean messages on white
 * Use of photography depicting people used in appeals to social proof and prosocial behavior
 * Takeaways from looking at industry metrics and benchmarks
 * Welcome emails are generally the best performing in terms of being the most opened (82.57%) and clicked (22.76%) type of email type.
 * Triggered emails such as an email when a user expresses interest in being contacted for mentorship perform second-best to Welcome emails, and have a much lower unsubscribe rate.
 * Autoresponder emails like a weekly or monthly “Impact” email have lower open and click rates, but also have a much lower unsubscribe rate.

Design
In order for emails to help users accomplish their goals, they need to be tailored to the things that we know about them from the welcome survey and from their editing history. Preliminary designs have been made for six email campaigns, but we will start with three, which are in bold:


 * Welcome: a generic orientation email that links to their newcomer homepage.
 * Impact: tell newcomers how many pageviews the pages they've edited have had.
 * Mentorship: send newcomers an automated message from a mentor they can contact for help.
 * Task recommendations: send newcomers a set of tasks related to their topics of interest or past edits.
 * Neighborhood activity: send newcomers a list of editing activity that has happened on articles related to their topics of interest or past edits.
 * New article: send newcomers who said they intend to create a new article a couple of pointers and link to tutorial.
 * Quiz: send newcomers a quiz with a series of questions to determine "what kind of editor are you?" Here is an example from Codeacademy.

General requirements

 * Should be possible to include rich content.
 * Be sent based on rules that incorporate welcome survey responses, edit history, and time.
 * Allow people to unsubscribe.
 * Allow us to know how often the emails are replied to.
 * Have a noreply@ from address or allow users to reply somewhere that their message will be seen.

Emailability
In order to send engagement emails to newcomers, they need to have verified email addresses associated with their accounts and they need to opt-in to receiving this content. The analysis our team did in this Phabricator task shows that a remarkably low number of users end up with verified email addresses. See the table below. Only 25% of Czech and 14% of Korean newcomers have verified emails. When we wondered why these numbers are so low, we realized that there are many moments during account creation where we could increase a user's understanding of what's going on, making it more likely they'll add an email if they want to. Here are some ideas we're working on:


 * Adding language to Special:CreateAccount that explains that email addresses are required for account recovery. T216087.
 * Adding a notification to Special:CreateAccount letting people know to look for a verification email. T216087.
 * Re-designing the verification email itself so that it is clearer what to do with it, and is less confusing. T215665.
 * When users try to create their account without an email, ask if they are sure. T215633.

Measurement
As with everything the Growth team does, it is important for us to be able to measure how users do and do not engage with the feature -- that's the only way to stick to strategies that are working and abandon the ones that aren't. We want to be able to measure how often users open and click on the emails we send them, but we know that instrumenting emails is new territory. We'll need to careful to safeguard privacy and security, and we will work with other Foundation teams to do so. We may need to come up with detailed solutions to learn what we need to learn without recording too much data, like the approach our team took with the "Understanding first day" project in which we obfuscated the names of articles viewed by newcomers.