요즘 많은 서비스를 보면 출석체크가 없는 곳이 없어요. 아무래도 앱을 꾸준히 사용하게 만들고, 방문할 이유를 제공하기 위해 많이 사용하는 방법 중 하나인 것 같아요. 출석체크는 대표적인 Gamification 기능으로, 사람들의 보상 심리(Reward Psychology)와 행동 심리학(Behavioral Psychology)을 활용한 기법이에요.
하지만 기획 단계에서 목적, 로직, 예외 상황, 운영 전략 등을 놓치면 오히려 유저 불만을 초래하거나 무용지물이 될 수 있어요. 그렇다면 출석체크를 기획할 때 어떤 점을 중요하게 생각하고, 무엇을 주의해야 할까요?
1️⃣ 출석 체크 구조의 기본 흐름
클릭해서 이미지를 올려주세요
출석 체크 기능은 보통 아래와 같은 흐름으로 구성돼요.
- 사용자가 서비스에 접속했을 때 혹은 사용자가 출석 체크 버튼을 눌렀을 때 서버에서 오늘 출석 체크를 했는지 확인 요청해요.
- 서버에서 사용자의 출석 기록을 조회하고 오늘 날짜와 비교합니다. 이 때 출석 체크가 중복으로 발생한 것은 아닌지도 같이 판단해요.
- 오늘 출석 체크 성공 시 DB에 기록을 저장해요. 보통 출석 체크 버튼을 누른 날짜와 시간까지 모두 저장해요.
- 만약 출석 체크에 대한 보상이 있다면 보상을 지급하고, 누적 출석, 연속 출석 등 기타 조건을 확인하고 추가 보상을 지급해요.
- 출석 체크 여부, 누적 횟수, 보상 정보 등 해당 결과를 사용자에게 표시해줘요.
실무 팁
흔히 알고 있는 "접속만 해도 출석”과 “버튼을 눌러야 출석”은 전략적으로 완전히 다른 기획 내용이에요. UX와 리텐션 목적에 따라 어떤 기획이 우리 서비스에 더 적합한지 판단하고 UX를 다르게 구성해야 해요.
2️⃣ 출석 체크 기획시 정해야 할 정책
1. 출석 인증 기준
- 출석 인정 시점 : 로그인, 특정 화면 진입, 버튼 클릭 등 DB에 시간을 기록하는 기준이 있어야 해요.
- 하루 기준 : 오늘 출석 체크하고 다음 출석 체크할 때의 기준이 있어야 해요. KST 혹은 UTC 기준 날짜로 계산할 수도 있고, 사용자 별로 정확히 24시간 기준으로 판단할 수도 있기 때문이에요.
- 만약 연속 출석 보상을 제공한다면, 주말을 포함할 것인지 제외할 것인지도 고민해봐야 해요.
2. 출석 실패/예외 기준
출석 인증 기준 외에도 실패 혹은 예외 기준도 명확히 정의해야 해요. 예를 들면 출석 가능한 시간대 외 접근, 출석했는데 다시 시도한 경우는 출석 체크 실패로 봐야 해요. 출석 체크는 기본적으로 최대 1회/1일/유저당이 보장되어야 해요. 하지만, 서버 오류에 의한 출석 실패, 날짜 변경 시점(23:59:59 ~ 00:00:01)에서의 처리 등은 예외 처리 방식을 정해야 해요.
