앱 리퍼럴과 공유 설계 (추천이 일어나는 조건 만들기)

🤔 혹시 이런 생각 해본 적 없나요?

• "친구 초대 기능을 넣었는데 아무도 쓰지 않는다."
• "광고 없이 들어오는 설치를 늘리고 싶은데 어디부터 만져야 할지 모르겠다."
• "초대 링크로 온 가입이 얼마나 되는지 세어 본 적이 없다."

딥링크 실전에서 공유와 초대는 받는 쪽의 기기와 설치 여부를 알 수 없는 대표적인 경우라고 했습니다. 이번 클래스는 그 링크가 오가게 만드는 쪽, 곧 추천이 일어나는 조건을 설계하는 이야기입니다.

🗣️ 광고보다 힘이 센 유입은 아는 사람의 한마디입니다

리퍼럴과 공유 설계는 기존 사용자가 아는 사람에게 앱을 추천하게 만드는 계기와 보상을 제품 안에 심어, 광고 없이 이어지는 유입 경로를 만드는 작업입니다.

동네에서 소문난 맛집을 떠올리면 구조가 보입니다. 전단지를 보고 간 가게보다 친구가 진짜 맛있다고 데려간 가게를 더 믿게 되고, 가서 좋았다면 나도 다른 친구를 데려갑니다. 신뢰하는 사람의 추천은 광고가 넘기 힘든 문턱, 그러니까 이걸 설치해도 되는지 의심하는 마음을 대신 넘어 줍니다. AARRR 퍼널의 네 번째 R인 Referral이 이 단계이고, 잘 돌기 시작하면 획득 비용 없이 새 사용자가 들어오는 길이 하나 생기는 셈입니다.

다만 순서가 있습니다. 서비스가 쓸 만하지 않은 상태에서 초대 보상만 크게 걸면, 보상만 받고 떠나는 유입이 몰려 리워드 캠페인에서 본 문제가 제품 안에서 재연됩니다. 추천은 만족의 결과이지 만족의 대체재가 아닙니다.

📐 공유가 일어나는 세 가지 조건

공유 기능이 있다는 것과 공유가 일어난다는 것은 다릅니다. 잘 도는 서비스들의 공통 조건은 세 단어로 정리됩니다.

• 편리하게: 공유까지의 동작 수가 적어야 합니다. 링크 복사, 카카오톡 공유처럼 두세 번의 터치로 끝나야 하고, 딥링크가 깔려 있어 받는 쪽이 헤매지 않아야 합니다.
• 자주: 공유할 계기가 서비스 사용 중에 반복해서 나와야 합니다. 일 년에 한 번 나오는 초대 팝업보다, 쓰다 보면 자연스럽게 마주치는 계기가 힘이 셉니다.
• 자연스럽게: 공유가 사용자 자신에게도 의미가 있어야 합니다. 함께 쓰면 좋아지는 기능, 자랑하고 싶은 결과물처럼 공유 자체가 사용 경험의 일부인 경우입니다.

버튼을 놓는 자리도 이 조건을 따라갑니다. 가장 간편한 곳에, 가장 필요한 곳에, 가장 당연한 곳에 두는 것이 원칙입니다. 가계부 앱이라면 월말 결산 화면에, 게임이라면 기록 달성 화면에, 지도 앱이라면 장소 상세 화면에 공유가 있어야 그 순간의 마음과 버튼이 만납니다.

반대로 조심할 것이 기능 자랑입니다. 이것도 되고 저것도 된다는 안내를 쏟아부으면 추천할 이유가 많아지는 것이 아니라, 무엇을 추천해야 할지 모르게 됩니다. 추천은 한 가지 확실한 좋음에서 나옵니다.

🎁 보상은 양쪽으로, 행동에 붙여서

보상 설계의 기준을 보여 주는 오래된 교과서가 드롭박스의 추천 프로그램입니다.

공식 도움말 기준으로 무료 사용자는 추천 1명당 500MB를 받고, 추천으로 가입한 친구도 500MB를 추가로 받습니다. 여기서 읽을 것은 용량이 아니라 구조 두 가지입니다.

1. 양쪽 보상입니다. 초대한 쪽에만 보상이 몰리면 받는 사람에게 그 초대는 친구의 영업이 됩니다. 받는 쪽에도 이득이 있어야 초대가 부담이 아니라 선물이 되고, 보내는 쪽도 떳떳해집니다.
2. 보상이 서비스 그 자체입니다. 저장 공간은 드롭박스를 더 쓰게 만드는 보상입니다. 현금성 포인트처럼 서비스 바깥으로 나가는 보상보다, 서비스를 더 쓰게 만드는 보상이 리텐션까지 함께 끌어올립니다.

보상의 방향에 따라 초대가 어떻게 받아들여지는지 비교하면 이렇습니다.

공짜 혜택으로 노골적으로 유도하기보다, 적절한 행동에 적절한 보상을 붙여 자연스럽게 배우게 하는 쪽이 오래갑니다. 초대를 완료하면 주는 것이 아니라 초대받은 친구가 첫 사용을 마쳤을 때 주는 식으로, 보상 조건을 진짜 행동에 거는 것도 같은 원리입니다. 가짜 가입으로 보상만 채가는 어뷰징을 거르는 안전장치이기도 합니다.

🔄 캠페인과 맞물릴 때 생기는 순환

리퍼럴은 광고의 반대말이 아니라 광고와 맞물리는 톱니입니다. 이 코스의 앞부분과 이어 보면 순환 구조가 보입니다.

1. 캠페인이 첫 사용자를 넣습니다. 앱 캠페인과 메타, 리워드로 들어온 유입이 출발점입니다.
2. 들어온 사용자가 만족하면 초대가 나갑니다. 초대는 광고비 없이 다음 사용자를 넣습니다.
3. 초대로 온 사용자는 잔존이 좋은 편이라 회수가 빨라지고, 그만큼 캠페인에 다시 쓸 여력이 생깁니다.

이 순환이 도는 서비스와 돌지 않는 서비스는 같은 광고비로 얻는 결과가 달라집니다. 초대 한 사람이 평균 몇 명의 가입을 만들어 내는지를 재 보면 순환의 세기를 숫자 하나로 잡을 수 있습니다. 이 값이 0.2라면 광고로 100명을 넣을 때 추천으로 20명이 따라오는 구조이고, 캠페인 성과를 계산할 때 이 몫까지 넣으면 적정 CPI 산정의 상한선이 그만큼 올라갑니다.

런칭 구간에서는 이 결합이 특히 힘을 냅니다. 여러 매체로 알려진 상태를 만들어 두면, 초대를 받은 사람이 어디서 들어 본 앱이라 설치의 문턱이 한 번 더 낮아지기 때문입니다. 광고가 만드는 익숙함과 추천이 만드는 신뢰가 서로의 부족한 쪽을 채우는 관계입니다.

📏 측정: 초대 링크에 이름표를 붙입니다

리퍼럴은 감으로 운영하면 있는지 없는지도 모르는 채 끝납니다. 측정의 재료는 앞 클래스에서 이미 갖췄습니다.

• 초대 링크는 딥링크로 만들고 경로 값을 붙입니다. 어떤 화면의 공유 버튼에서 나간 링크인지 구분 값을 담아 두면, 어느 계기가 실제 초대로 이어지는지 보입니다.
• 초대받은 사용자를 코호트로 봅니다. 코호트 분석의 방법 그대로, 초대로 들어온 집단과 광고로 들어온 집단의 잔존을 비교합니다. 추천으로 온 사용자는 아는 사람이 이미 쓰는 서비스에 들어온 것이라 잔존이 좋은 경우가 많고, 그 차이가 리퍼럴에 투자할 근거가 됩니다.
• 초대 수보다 초대 성공률을 봅니다. 보낸 링크 대비 가입 완료의 비율이 낮다면 받는 쪽 경험, 곧 링크의 도착 화면부터 점검합니다.

❓ 보상 없이도 리퍼럴이 일어날 수 있나요?

일어날 수 있습니다. 함께 쓰면 좋아지는 기능이나 자랑하고 싶은 결과물처럼 공유 자체가 사용 경험의 일부인 서비스에서는, 보상 없이도 초대가 자연스럽게 나갑니다.

이 경우 설계의 초점은 보상이 아니라 계기와 동선입니다. 공유하고 싶어지는 순간의 화면에 버튼을 두고 동작 수를 줄이는 것만으로 초대가 늘어나는지 먼저 확인한 뒤, 보상은 그 위에 얹을지 결정합니다.

❓ 초대 보상만 노리는 어뷰징은 어떻게 막나요?

보상 조건을 진짜 행동에 겁니다. 초대 링크로 가입만 하면 주는 것이 아니라, 초대받은 친구가 첫 사용이나 첫 주문 같은 유의미한 행동을 마쳤을 때 지급하는 방식입니다.

여기에 한 사람이 받을 수 있는 보상의 상한을 두고, 같은 기기나 결제 수단으로 반복 가입하는 패턴을 걸러 내면 가짜 가입으로 보상만 챙기는 우회가 어려워집니다.

📋 3줄 요약

1. 리퍼럴과 공유 설계는 기존 사용자가 아는 사람에게 앱을 추천하게 만드는 계기와 보상을 제품 안에 심는 작업입니다.

2. 공유는 두세 번의 터치로 끝나고 쓰다가 계기를 반복해서 만나며 공유가 사용자 자신에게도 의미가 있을 때 일어납니다.

3. 드롭박스는 추천한 쪽과 추천으로 가입한 친구 모두에게 500MB를 줬는데 양쪽 보상은 받는 사람은 영업이 아니라 선물로 받아들입니다.

참고 자료

• Dropbox를 친구에게 추천하는 방법, Dropbox 공식 도움말
• Android 앱 링크 안내, Android Developers