너는 새로운 응용 프로그램을 발견했고, 너는 그것을 매우 흥분해서 사용했다.계정 생성 과정을 거쳤지만 전자 메일을 확인하기 전에 이 프로그램의 사용을 막았습니다.이것은 사용자의 여정 중의 아픔일 수도 있고, 잠재적인 사용자가 응용 프로그램 사용을 멈추는 아픔일 수도 있습니다.

사용자들이 이렇게 하는 것을 피하자.본고에서 우리는 탑승 체험에서 전자 우편 검증에 관한 체험을 어떻게 바꾸는지 중점적으로 소개할 것이다.

탑승 체험 중단

탑승 체험은 사용자가 가질 수 있는 가장 중요한 체험 중의 하나입니다.만약 체험이 매우 고통스럽다면, 사용자는 더욱 퇴출될 가능성이 있다.창조자로서 우리의 목표는 사용자를 즐겁게 하고 가치를 가져다 주는 체험을 창조하는 것이다.
대부분의 입사 경험은 응용 프로그램을 사용하기 전에 이메일을 확인해야 합니다.사용자의 참여를 유도하고 유지하기 위해 최소한의 기능 집합을 사용할 수 있도록 고려해야 합니다.사용자에게 응용 프로그램에서 벗어나 전자 우편 클라이언트로 가서 전자 우편을 찾은 후에 그들의 계정을 검증하도록 요구하면 마찰을 증가시킨다.만약 사용자가 이전의 체험에서 유혹을 받지 않았다면, 무엇이 그들의 전진을 막았을까?
사용자가 계정을 검증하기 전에 응용 프로그램을 사용할 수 있도록 하면 안전과 자원 문제가 발생할 수 있습니다.이것이 바로 샌드박스, 계정 정리, 속도 제한 등 정책을 제정하여 당신과 다른 사용자를 보호해야 하는 곳입니다.

마찰을 줄이다

따라서 우리는 사용자가 하루가 끝날 때 그들의 계좌를 검증해야 한다.우리는 사용자에게 그들의 수신함으로 돌아가서 그곳에서 검증하라고 알려줄 수 있다.이것은 많은 절차가 필요하다. 당신의 경쟁 상대는 사용자에게 같은 일을 요구할 가능성이 높다.이것은 네가 경쟁에서 출중한 기회다.
다음은 일반 경험치입니다.

1. Go through account creation journey
2. Prompt to verify account by clicking link in email
3. Open new tab
4. Go to email provider
5. Find email
6. Click the verification link

체험을 어떻게 개선하는지 봅시다.최초의 계정 생성 단계에서 우리는 그들의 전자 우편 주소를 알고 있다.만약 우리의 경험에 근거하여 우리는 그들의 전자 우편 공급자에게 링크를 제공할 수 있습니까?다음은 새로운 체험의 모습이다.

1. Go through account creation journey
2. Prompt to verify account by clicking link in email, provide a link to email provider
-3. Open new tab
-4. Go to email provider
5. Find email
6. Click the verification link

두 걸음 적게 가면 많지 않을 수도 있지만, 이것은 성공하거나 실패한 새 사용자의 차이일 수도 있다.

기술

전자 메일 주소 형식
우리는 어떻게 해야만 이 점을 할 수 있습니까?몇 가지 장면을 봅시다.

장면 1

사용자 등록 [email protected]

저희는 사용자에게 Gmail

에 대한 링크를 제공하고 싶습니다

장면 2

사용자 등록 [email protected]

우리는 사용자에게 Outlook

에 대한 링크를 제공하기를 희망합니다
네, 이 문제는 보기에 매우 간단합니다.e-메일 도메인을 보고 링크할 전자 메일 공급자를 결정할 수 있습니다.다음과 같은 효과를 얻을 수 있습니다.
영역
전자 메일 공급자
견해일반 도메인 이름 형식
https://outlook.office.com
gmail.일반 도메인 이름 형식
https://gmail.com
근데 잠깐만!가장자리 상황은 어떻습니까?

장면

사용자 등록 [email protected]

사용자에게 링크를 제공하고 싶습니다???

우리는 사용자가 사용자 정의 전자 우편 영역을 사용하는 상황을 고려하지 않았다.사용자의 전자 메일 주소 도메인만 보고 사용자가 사용하는 전자 메일 공급자를 확인할 수 없습니다.
이 예에서 우리는 호퍼를 가정한다.com은 이메일 공급업체로 Gmail을 사용합니다.우리는 어떻게 확정합니까?우리는 MX 기록을 사용할 수 있다!
Mail exchanger records (MX records)은 인터넷의 어느 서버 처리 영역의 전자 우편 발송과 수신을 알려줍니다.예를 들어 호퍼.com은 인터넷 Gmail에 전자 우편을 처리하라고 알려주는 MX 기록이 있습니다.
백엔드에서 기존 도구를 사용하여 도메인의 MX 레코드를 찾을 수 있습니다.Nix* 운영 체제를 사용하는 경우 host을 사용하여 이를 테스트할 수 있습니다.

[I] ➜ host hopper.com
hopper.com has address 198.179.227.105
hopper.com mail is handled by 5 aspmx.l.google.com.
hopper.com mail is handled by 10 alt1.aspmx.l.google.com.
hopper.com mail is handled by 15 alt2.aspmx.l.google.com.

이제 MX 레코드를 찾아 모든 사례를 다룹니다.만약 당신이 그것을 당신의 프로젝트에 추가하고 싶다면, 여기에는 몇 가지 방법이 있습니다. Node, Ruby과 Python입니다.

끝내다

우리는 다음과 같은 방법으로 전자 우편 검증 과정을 개선할 수 있다는 것을 알게 되었다.

은 사용자가 전자 우편

을 검증하기 전에 비파괴적인 방식으로 우리의 응용 프로그램을 사용할 수 있도록 합니다

은 사용자가 전자 우편 클릭을 통해 검증 링크

의 마찰을 감소시켰다

너한테는 문제야.

전자 우편 검증에는 또 하나의 난점이 있다.너는 너의 사용자에게 그들의 우편함에 들어가서 너의 이메일을 찾을 것을 요구한다.

장면 1

알림 사용자 검증 이메일

사용자가 즉시 받은 편지함에 들어갑니다.

귀하의 이메일은 그들의 우편함 맨 위에 있을 가능성이 높습니다

장면 2

알림 사용자 검증 이메일

사용자가 즉시 받은 편지함에 들어가지 않음

당신의 우편물은 아마도 n의 우편함

에 있는 우편물일 것입니다

이 두 가지 상황에서 사용자는 다른 전자메일에 신경을 써서 계정 검증을 잊어버릴 수도 있습니다.
이 문제를 해결할 방법이 있습니까?여기에 힌트가 하나 있습니다. 매개 변수를 조회합니다.