가입 8명, 스캔 3명, 재방문 0명: 초기 사용자를 붙잡으려면?

AI 요약

GazeRank는 SEO, 성능, 접근성, AI 검색 대응 상태를 점검하는 웹사이트 감사 도구입니다. 1인 창업자는 8월에 서비스를 공개했지만 본격적으로 알리기 시작한 시점은 10월 1일이라고 설명합니다. 데이터베이스에 가입 계정 12개가 있고 그중 4개는 테스트 계정입니다. 나머지 8명 중 3명이 스캔을 실행했고, 다른 날 다시 방문한 사용자는 없었습니다. 10월 1일 이후 추적한 방문은 약 30회지만 실제보다 적게 잡혔을 가능성이 있다고 덧붙였습니다. 가입자 5명은 스캔을 한 번도 실행하지 않았습니다.

유입과 초기 조사

창업자는 X에 웹사이트 285곳을 스캔한 결과를 올렸고, LinkedIn 회사 페이지에는 노출 292회, 클릭 7회, 반응 0회, 댓글 2개가 발생했습니다. SaaSHub, AlternativeTo, BetaList 등을 포함해 디렉터리 8곳에 등록을 신청했고 Product Hunt 출시를 준비하고 있습니다. 디렉터리 등록은 아직 결과를 판단하기 이르다고 했습니다.

285개 사이트는 주로 SaaS, 개발 도구, 마케팅 분야였습니다. 조사에서 54%는 콘텐츠 최신성 신호가 없었고, 52%는 읽기 쉬운 정도가 낮았으며, 51%는 보안 헤더가 하나 이상 빠져 있었습니다. 창업자는 이런 문제가 흔하다는 점은 보여주지만, 사이트 운영자가 직접 스캔하거나 수정 비용을 낼 만큼 관심을 두는지는 알 수 없다고 선을 그었습니다.

자기 사이트를 검사했을 때 성능 점수는 100점인데도 Largest Contentful Paint(LCP)가 좋지 않게 나온 경험도 소개했습니다. 문제를 수정하고 과정을 기록하면서 감사 도구는 점수만 제시하기보다 근거를 보여줘야 신뢰를 얻는다는 교훈을 얻었다고 했습니다.

댓글에서 나온 점검과 개선안

여러 댓글은 가입 8명과 방문 약 30회만으로 전환율을 판단하기 어렵다고 지적했습니다. 테스트 계정과 봇을 빼고, 쿠키 동의에 따라 방문이 누락되는지 확인하라는 경험담도 나왔습니다. 한 댓글은 자기 서비스에서 정상처럼 보이는 브라우저를 쓰는 봇이 방문과 클릭 수를 부풀렸다고 했습니다. 이는 각 댓글 작성자의 경험이며 GazeRank의 트래픽에도 같은 일이 있었다는 증거는 아닙니다.

가입 뒤 스캔을 하지 않은 5명에 대해서는 이메일로 한 가지 질문을 보내고, 가입 경로와 첫 행동을 확인하라는 제안이 이어졌습니다. 빈 대시보드 대신 가입 직후 URL 입력을 받거나 첫 스캔을 실행해 결과를 보여주면 첫 가치까지의 단계를 줄일 수 있다는 의견입니다. 홈페이지의 "Get started" 버튼이 스캔 화면이 아니라 가입 화면으로 이어지는지, 스캔이 시작된 뒤 오류 없이 실패하지 않았는지도 확인하라는 댓글이 있었습니다. 창업자는 댓글에 답하며 현재 흐름이 가입 후 빈 대시보드에서 URL을 직접 붙여 넣는 방식이라고 밝혔고, 로그와 유입 경로를 확인하겠다고 했습니다.

재방문을 어떻게 볼 것인가

감사는 출시나 사이트 변경 때 한 번 실행하는 작업일 수 있으므로, 다른 날 돌아오지 않았다는 수치만으로 유지 문제를 단정하기 어렵다는 댓글도 나왔습니다. 사용자가 실제로 결과를 활용했는지, 같은 사이트를 다시 검사해 수정 여부를 확인했는지처럼 제품의 사용 목적에 맞는 지표를 보자는 제안입니다. 주기적 알림보다 사이트 변경이나 새 문제처럼 사용자가 다시 검사할 이유가 생겼을 때 결과 차이를 보내자는 의견도 있었습니다.

Indie Hackers 반응

• @repeatform — 저도 비슷한 단계입니다. 10월 초에 출시했고 지난주 SaaSHub와 다른 몇 곳에 등록했습니다. 작은 수치를 해석하는 방식이 바뀐 점이 두 가지 있습니다. 초기 "사용자" 대부분이 제가 테스트한 계정이라 퍼널을 볼 때 먼저 제외합니다. 그리고 제 분석 도구는 쿠키 배너에 동의한 사람만 세므로 실제 방문은 몇 배 더 많을 수도 있습니다. SaaSHub에서 유입이 있었나요? 제 쪽은 아직 없습니다.
• @capo689 — 이번 주에 작게 시도해볼 만한 일이 두 가지 있습니다. 가입하고 스캔하지 않은 다섯 명에게 무엇을 얻는지 정확히 한 문장으로 설명하고, 자기 도메인이 미리 입력된 스캐너 링크를 보내세요. 사용자가 결정할 일을 없애는 겁니다. 첫 행동이 빈 입력란에서 시작하면 활성화가 막히곤 합니다. 유입 경로를 알 수 없다면 완성된 스캔 예시를 보여줘서 선택 대신 결과 읽기부터 시작하게 하세요. 재방문은 대개 공지 메일보다 스캔이 답해주는 문제가 언급된 바로 그 대화에서 생깁니다. 감사 도구라면 사용자가 자기 도메인을 매주 다시 검사해 수치가 바뀌었는지 확인하는 것이 자연스러운 이유입니다. 점수만이 아니라 근거로 신뢰를 얻는다는 교훈을 온보딩에도 적용하는 방향이 맞습니다.
• @kaushikdas — 제품을 스캔한 세 사람과 이야기해보겠습니다. 무엇을 찾으려 했는지, 무엇이 그만두게 했는지, 무엇이 다시 돌아오게 할지 물어보세요. 대화에서 얻는 교훈이 가입자 100명을 더 모으는 것보다 많을 겁니다.
• @MShahab — 홈페이지에는 첫 스캔에 가입이 필요 없다고 쓰여 있지만, 상단에는 눈에 띄는 "Get started" 버튼도 있습니다. 그 버튼이 가입 화면으로 간다면 스캔하지 않은 다섯 명이 스캔 입력란 대신 그 버튼을 눌러 빈 앱에 도착했을 수도 있습니다. 다섯 계정이 어떤 페이지나 버튼에서 왔는지 확인해보세요. 그런 경우 버튼을 스캔 입력란으로 보내는 것만으로 해결될 수 있습니다.
  • @prasibv — 좋은 지적입니다. 스캔 경험 자체에 집중하느라 홈페이지 CTA가 다른 경로로 보내는 가능성은 확인하지 않았습니다. 이번 주에 가입 흐름을 살펴보고, 가능하면 다섯 계정의 랜딩 페이지와 진입 경로를 추적하겠습니다. 홈페이지가 가입 없이 첫 스캔을 할 수 있다고 안내한다면 스캔으로 가는 경로가 분명해야 합니다.
• @OrientLabs — 접근성 인계 도구를 만들고 있어서 보고서 다음 단계도 확인하겠습니다. 사용자가 발견 항목 하나를 고르고, 영향을 받는 요소를 이해하고, 수정이 끝났는지 보여줄 근거를 말할 수 있나요? 스캔이 성공해도 다음에 뭘 해야 할지 모를 수 있습니다. 관찰하는 세션에서 도움 없이 항목 하나를 설명해보라고 하세요. 같은 페이지를 다시 스캔한다면 이전 발견 내용과 검사 조건도 새 결과와 함께 보관하세요. 전체 점수 변화만으로 특정 문제가 해결됐다고 볼 수는 없습니다. 저희 제품의 재방문 성과가 아니라 테스트 제안입니다.
  • @prasibv — 스캔 성공이 사용자가 결과를 이해했다는 뜻은 아니라는 구분이 유용합니다. 사용자가 항목이 왜 중요한지, 무엇을 바꿔야 하는지, 수정 여부를 어떻게 확인할지 설명할 수 있는지 보겠습니다. 이전 발견 내용과 검사 조건을 새 결과에 함께 남기라는 점도 중요합니다. 전체 점수가 올랐다고 특정 문제가 해결됐다는 증거는 아니니까요.
• @ranamuzamil — 가입하고도 스캔하지 않은 사람이 5명이라면 가입과 첫 결과 사이에 단계가 있을 가능성이 큽니다. 가입 화면에서 URL을 받고 앱에 도착할 때 스캔이 이미 진행 중이게 해보세요. 빈 대시보드가 아니라 자기 보고서를 먼저 보게 하는 겁니다. 다른 날 돌아오게 하려면 나중에만 생기는 이유가 필요합니다. 매주 다시 검사해 "문제 2개 해결, 새 문제 1개"라고 보내는 방식은 로그인을 기억해주길 바라는 것보다 낫습니다. 지금 제품은 한 번 검사하는 도구라 한 번 방문하는 행동이 예상 가능한 편입니다. 그래도 목록에서 가장 먼저 할 일은 스캔하지 않은 다섯 명에게 이메일을 보내는 겁니다.
  • @prasibv — 가입과 동시에 스캔을 진행하는 제안이 특히 유용합니다. 지금은 가입 후 빈 대시보드가 나오고 URL을 붙여 넣어야 하므로 마찰이 있습니다. URL 입력을 가입 화면이나 바로 다음 단계로 옮겨 자기 보고서를 먼저 보여주는 방안을 이번 주 우선순위로 두겠습니다. 주간 재검사와 "2개 해결, 1개 신규" 이메일도 이해가 됩니다. 지금은 일회성 검사에 가까워서 한 번 방문하는 게 예상 가능한 행동입니다. 다섯 명에게 이메일을 보내는 일이 새 유입 채널보다 더 많은 정보를 줄 거라는 점에도 동의합니다.
• @nissesec — 동기 문제라고 보기 전에 첫 스캔이 실제로 실행됐는지 확인해보세요. 버튼을 눌렀지만 조용히 실패해 사용자가 아무런 오류나 피드백도 받지 못하고 나간 경우를 봤습니다. 로그나 피드백 기록이 있다면 그 다섯 명의 흔적이 있는지 살펴볼 만합니다.
  • @prasibv — 좋은 지적입니다. 아직 확인하지 않은 가능성입니다. 이번 주에 다섯 계정의 로그를 살펴 스캔을 시도했는지, 시작한 뒤 조용히 실패했는지 확인하겠습니다. 조용히 실패하는 경로가 있다면 온보딩 문구를 고치기보다 먼저 해결하겠습니다.
• @alatli — 저도 여행 안내 사이트를 시작한 지 3주라 비슷한 상황입니다. 이 규모에서는 "방문"이 무엇을 세는지 먼저 확인해보세요. 제 데이터베이스에는 제휴 링크 클릭이 287회였지만 제휴사 대시보드에는 같은 달 방문자가 23명으로 나왔습니다. 대부분 정상처럼 보이는 브라우저를 쓰는 봇이었습니다. 방문 30회 정도면 봇이나 테스트 세션 몇 개가 전체 수치를 바꿀 수 있습니다. 제 IP와 세션, 스크롤이나 클릭이 없는 세션을 제외해보겠습니다. 제 분석 도구는 방문자가 7초 만에 나갔다고 했지만 탭이 숨겨질 때마다 시간을 다시 보고하는 방식 때문에 나온 오류였습니다. 실제 방문자는 약 1분 머물며 두 페이지를 읽었습니다. 잘못된 문제를 고칠 뻔했습니다.
• @usetether — 제 추측으로는 스캔 자체가 걸림돌일 수 있습니다. 가입은 공짜지만 자기 URL을 넣으면 낮은 점수를 받을 위험을 감수해야 하니까요. 요청받지 않은 사이트 285곳을 이미 스캔했다면 새 가입자의 업무용 이메일에서 도메인을 가져와 미리 검사하고, 첫 로그인에 빈 입력란 대신 자기 결과를 보여주는 방안을 고려하겠습니다.
  • @prasibv — URL 입력란이 생각보다 큰 장벽일 수 있다는 점이 흥미롭습니다. 더 많은 일을 요구하기 전에 가치를 보여주는 방법이 좋습니다. 이메일에서 도메인을 추정해 자동 검사하기보다는 발견 항목 하나를 미리 보여주고 전체 스캔을 선택하게 하는 방법을 시험해볼 수 있겠습니다.
• @Adflipr — 이런 도구에서 재방문이 0회인 것은 지표 자체의 성격과 관련 있을 수 있습니다. 감사는 출시하거나 무언가 바뀌었을 때 한 번 실행하고 결과를 읽은 뒤 떠나는 작업입니다. 습관을 만들지 않는 작업에 습관적 재방문을 기대하는 셈입니다. 일회성 도구는 정해진 일정이 아니라 변화가 생겼을 때 다시 쓰는 흐름이 더 자연스럽습니다. 사용자가 재검사 주기를 고르거나 배포, 새 페이지, 점수 하락 같은 변화에 맞춰 결과를 보내는 방식입니다. 가입 후 스캔하지 않은 다섯 명을 돕는 일이 재방문 문제보다 비용이 적게 들 겁니다.
  • @prasibv — 감사가 특정 필요가 생겼을 때 한 번 쓰는 작업일 수 있는데 습관형 제품처럼 생각했을 수 있습니다. 우선 가입부터 첫 스캔까지의 간격을 살피겠습니다. 사용자가 원하지 않는 스캔을 받지 않도록 동작을 분명히 하면서 첫 발견 항목을 보여주는 방법을 생각해보겠습니다. 장기적으로는 단순히 7일이 지났다는 이유로 알림을 보내기보다 실제 변화에 맞춘 재검사가 더 타당합니다.
• @hayeslive — 가입 8명 중 스캔 3명, 재방문 0명이라면 첫 세션에서 제품의 가치를 증명하지 못했을 가능성이 큽니다. 추가 홍보 전에 빈 화면에서 2분 안에 URL 하나를 붙여 넣고 구체적인 문제 하나를 확인하게 해보세요. 가입 수보다 두 번째 스캔을 위해 돌아왔는지를 초기 사용자 지표로 추적하겠습니다.
• @aftondesk — 스캔하지 않은 다섯 명에게 이메일을 보내는 건 좋은 방법입니다. 로그인 초대보다 사이트에서 발견한 결과를 먼저 보여주세요. 보안 헤더 누락이나 최신성 신호 같은 항목 하나를 미리 알려주면 이메일이 "내 사이트에 문제가 있나?"에 답하고 스캔은 귀찮은 시작이 아니라 확인 절차가 됩니다. 다음 주에 다시 방문하게 하려면 사이트를 일주일 뒤 재검사하고 "LCP 개선, 헤더 누락은 그대로" 같은 차이를 보여주는 흐름이 유용할 수 있습니다.

원문: Indie Hackers / 번역·요약: Trawling