페이지 조회수 대신 구매자가 읽은 콘텐츠를 측정하세요

AI 요약

페이지 조회수나 클릭 수, 이메일 가입자 수 대신 실제 구매자가 결제 전에 어떤 콘텐츠를 읽었는지 살펴보는 분석 시스템을 소개합니다. PostHog가 방문 기록을 추적하고, Stripe가 결제 데이터를 제공하며, n8n이 매달 데이터를 가져와 OpenAI에 분석을 맡긴 뒤 Gmail로 보고서를 보냅니다.

익명 방문 기록을 사용자 계정에 연결하기

먼저 PostHog가 로그인 전 방문 기록과 가입 후 계정을 연결하도록 설정합니다. 프로젝트 폴더에서 npx @posthog/wizard를 실행해 설치를 마친 뒤, 사용자를 확인하는 시점에 posthog.identify(user.id, { email: user.email })를 호출합니다. 로그인할 때마다 같은 안정적인 사용자 ID를 써야 이전 익명 방문 기록을 계정에 연결할 수 있습니다. 로그아웃할 때는 posthog.reset()을 호출해 현재 사용자 식별 정보를 초기화합니다. 다음 단계로 넘어가기 전에 가입 전 페이지 조회 기록이 계정에 연결됐는지 확인합니다.

Stripe 결제 데이터 연결하기

PostHog의 Stripe 소스를 연결하면 고객, 결제, 구독, 청구서 데이터를 가져올 수 있습니다. Stripe 고객 정보에는 posthog_person_distinct_id 메타데이터를 넣고, 값은 posthog.identify()에 쓴 사용자 ID와 맞춥니다. 기존 고객 데이터에도 같은 메타데이터를 추가합니다. 이렇게 연결해야 콘텐츠 방문 기록과 결제를 같은 사용자 기준으로 분석할 수 있습니다.

HogQL 결과를 먼저 검증하기

자동화 전에 PostHog AI에 실제 PostHog·Stripe 스키마를 확인해 HogQL 쿼리를 작성하도록 요청합니다. 콘텐츠 페이지별로 첫 성공 결제 전에 해당 페이지를 읽은 식별 사용자를 찾고, 결제 성공의 기준이 되는 테이블·상태·시각 필드를 먼저 밝히게 합니다. 결과에는 콘텐츠 URL, 식별된 독자 수, 이후 결제한 독자 수와 비율, 해당 구매자와 연관된 매출, 식별 독자당 매출을 포함합니다. 예시 쿼리는 /blog/ 경로와 최근 180일을 기준으로 삼지만, 실제 콘텐츠 경로와 스키마에 맞춰 바꿔야 합니다.

쿼리가 맞는지 고객 10명을 골라 원천 데이터까지 따라가며 확인합니다. 콘텐츠별 매출 합계를 전체 매출로 오해해서도 안 됩니다. 한 고객이 결제 전에 여러 페이지를 읽으면 같은 매출이 각 페이지에 연결될 수 있으므로, 페이지별 매출을 더하면 중복 집계가 생깁니다.

n8n으로 월간 보고서 만들기

검증한 HogQL을 저장한 뒤 n8n에서 매달 실행하는 워크플로를 만듭니다. HTTP Request 노드로 PostHog 쿼리를 호출하고, 응답을 OpenAI 노드에 전달해 콘텐츠 주제를 묶고 독자 수는 많지만 구매 전환이 약한 주제, 독자 수는 적지만 전환이 강한 주제, 구매자와 연관된 콘텐츠에 반복해서 등장하는 주제를 찾습니다. 분석 결과에는 다음 달에 실행할 콘텐츠 작업을 정확히 다섯 가지 제안하도록 요청합니다. 정보가 부족한 URL은 억지로 분류하지 말고, 표본이 적으면 결론의 신뢰도가 낮다고 표시하게 합니다. 마지막으로 OpenAI 결과를 Gmail 메시지에 연결해 보고서를 받습니다. 전체 워크플로를 한 번 실행해 이메일을 확인한 뒤 월간 일정으로 운영합니다.

보고서는 다음에 살펴볼 대상을 좁히는 출발점입니다. 페이지가 매출을 일으켰다고 단정하지 말고 구매에 영향을 준 콘텐츠로 표현해야 합니다. 구매자 세 명 중 두 명이 읽은 페이지도 흥미로운 단서일 뿐, 표본이 작다는 한계를 함께 고려해야 합니다.

Indie Hackers 반응

• @tsutsu — 구매자가 결제 전에 무엇을 읽었는지 보는 방식이 원시 페이지 조회수보다 콘텐츠 주제를 고르는 데 더 적합합니다. PostHog와 Stripe 데이터를 월간 n8n 워크플로로 연결하면 실용적으로 운영할 수 있겠습니다. 설정을 공유해 주셔서 감사합니다!
• @filezain — 프롬프트에서 ‘상업적 영향’과 ‘매출을 일으켰다’를 구분한 점이 이 구성에서 가장 영리합니다. 데이터로 뒷받침할 수 없는 인과관계를 주장하면 콘텐츠 귀속 분석은 대부분 무너집니다. 덧붙일 점은 귀속 기간입니다. 판매 주기가 몇 주나 몇 달이라면, 결제 전에 조회했는지만 확인하는 방식은 조회 기간 밖에서 조사한 독자를 놓칩니다. 90일을 볼 때와 30일을 볼 때 어떤 콘텐츠가 중요한지 결과가 크게 달라질 수 있습니다. HogQL에 한 번 넣고 잊기 쉬운 부분입니다. 페이지 조회수는 무엇이 관심을 끌었는지 답하고, 영향 분석은 무엇이 구매 결정을 앞당겼는지 답합니다.
• @innokentyB — 페이지 조회수는 콘텐츠가 관심을 끌었는지는 보여줘도 구매자의 의사결정에 도움이 됐는지는 보여주지 않습니다. 각 콘텐츠를 문제 인식, 접근 방식 비교, 위험 완화, 사내 구매 설득처럼 고객 여정의 구체적인 역할에 연결하겠습니다. 그런 다음 모두에게 같은 전환율을 적용하지 말고 해당 역할 다음에 나타나는 관측 가능한 행동을 측정해야 합니다. 어려운 점은 익명 독서 기록과 이후 구매를 어떻게 연결하느냐입니다. 모든 접점에 과도하게 기여하지 않으려면 어떻게 처리하시나요?
  • @josuarc1307 — 누군가 읽은 모든 페이지에 주문 전체를 배정하지 않겠습니다. 고객·주문 기록 하나에 순서가 있는 페이지 방문 이력을 보관하고, 최초 접점·마지막 접점·구매 지원 콘텐츠를 따로 보고하겠습니다. 매출을 나눠 배정한다면 명시적인 규칙을 정하고 인과관계가 아니라 영향으로 표시해야 합니다. 사용자 연결에는 안정적인 내부 사용자 ID를 쓰고, 자동화 전에 일부 사례를 원천 이벤트와 대조해 검증하겠습니다.
• @austinparker — 실제로 무엇에 주의를 기울여야 하는지 깨닫기까지 시간이 걸릴 수 있습니다. 감사합니다!

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