세그먼트는 모두 좋아졌는데 전환율은 떨어졌다: 결제 퍼널 분석

세그먼트마다 결제 성과를 개선했는데도 전체 비율은 오히려 나빠질 수 있습니다. 이런 전환율 하락은 재시도를 늘려 개별 시도의 성공률이 낮아지면서도 완료된 주문은 더 많아지는 경우에도 나타납니다. 라우팅이나 화면을 바꾸기 전에 측정 단위, 고객 구성, 그리고 결제가 완료되기까지 허용한 시간을 먼저 확인하세요.

전체 비율이 무고한 연동을 탓할 때

별도의 학습용 예시를 보겠습니다. 첫 번째 기간에 세그먼트 A는 주문 900건에 전환율 90%, 세그먼트 B는 주문 100건에 전환율 60%를 기록했습니다. 성공 주문은 810 + 60 = 870건, 즉 1 000건 중 87%입니다.

두 번째 기간에 A는 92%로 개선됐지만 주문은 200건뿐입니다. B는 65%로 개선됐고 주문은 800건입니다. 성공은 184 + 520 = 704건, 전체 전환율은 70,4%입니다. 두 세그먼트가 모두 성장했지만 트래픽 구성이 바뀌면서 전체 결과는 16,6%p 낮아졌습니다.

검증하려면 세그먼트 가중치를 같게 두고 기간을 비교하세요. 이전 비중인 90%와 10%를 적용하면 새 결과는 89,3%가 됩니다: 0,9 × 92% + 0,1 × 65%. 이것은 분석용 재계산이지 두 번째 기간의 실제 전환율이 아닙니다. 두 숫자를 모두 이름을 붙여 보여 주세요. 실제 합계는 비즈니스에 필요하고, 비교 가능한 구성은 프로세스 자체의 변화를 평가하는 데 도움이 됩니다.

하나의 예시, 네 가지 결과

1 000건의 고유 주문이 결제 화면까지 도달한 가상의 쇼핑몰을 생각해 봅시다. 그중 800건에서 구매자가 최소 한 번 결제 시도를 보냈습니다. 반복 행동까지 합쳐 시도는 총 940건이었고, 이 가운데 680건이 승인에 성공했으며 서로 다른 680건의 주문에 해당했습니다. 선택한 관찰 기간이 끝날 때까지 660건의 주문에서 capture 단계가 완료됐습니다. 즉 판매자가 앞서 승인된 금액의 청구를 확정했습니다.

• 결제 시도로 넘어간 비율: 800 / 1 000 = 80%.
• 결제를 시도한 주문 중 승인 성공 비율: 680 / 800 = 85%.
• 개별 시도의 성공률: 680 / 940 ≈ 72,3%.
• 결제 화면을 연 주문 중 capture까지 완료된 비율: 660 / 1 000 = 66%.

이 지표들은 서로 다른 질문에 답합니다. 첫 번째는 화면과 결제 수단의 가용성을 살펴보는 데 쓰입니다. 두 번째는 허용된 재시도 이후 주문 단위의 결과를 보여 줍니다. 세 번째는 시도 자체의 특성을, 네 번째는 선택한 상업적 결과를 나타냅니다. 별도의 capture 단계 없이 대금이 청구되거나 계좌이체를 쓰는 경우에는 해당 수단에 맞는 확정 결과를 따로 정의하세요.

주문, 시도, 이벤트를 분리하라

데이터 모델에는 안정적인 주문 식별자, 별도의 시도 식별자, 이벤트 식별자가 필요합니다. 하나의 시도가 여러 알림을 만들 수 있고, 하나의 주문에 여러 시도가 들어갈 수 있습니다. 이를 섞으면 고객의 실제 행동은 그대로인데 분자나 분모만 커집니다. P2P 프로세스에서는 개별 신청 건이 주문에 해당할 수 있지만, 그 경계는 미리 정해 두어야 합니다.

Stripe는 같은 결제 흐름을 재개할 때 PaymentIntent를 재사용하라고 권장합니다. 이런 객체는 실패한 시도들을 하나의 장바구니나 세션에 묶는 데 도움이 됩니다. 이는 비즈니스 객체와 결제 프로세스를 연결하는 한 가지 예일 뿐, 모든 PG사에 통하는 보편적 구조는 아닙니다. 출처: Stripe, Payment Intents.

최소한의 이벤트 맵

결제 화면 열기, 결제 수단 선택, 시도 전송, 추가 인증 필요 여부, 그 인증의 완료, 확정된 결과를 기록하세요. 각 이벤트마다 발생 시각과 수신 시각, 식별자, 금액, 통화, 결제 수단, 연동 버전을 저장합니다. 분석용 필드에 카드 정보나 불필요한 개인정보를 넣을 필요는 없습니다.

결과는 연동에서 제공하는 검증된 서버 측 확인으로 판단하세요. 사용자가 성공 페이지로 돌아오는 것은 화면을 평가하는 데는 유용하지만, 그것만으로는 결제의 증거가 되지 못합니다. 반대로 브라우저를 닫았다고 해서 거래가 실패했다는 뜻도 아닙니다. 이 두 상황은 분석 검증 시나리오에 반드시 포함돼야 합니다.

Stripe는 webhook 이벤트가 중복 전달될 수 있고 순서가 보장되지 않는다고 경고합니다. 핸들러는 중복을 고려하고 수신 순서와 관계없이 상태를 갱신해야 합니다. 출처: Stripe, Webhooks.

관찰이 끝난 코호트끼리 비교하라

예를 들어 하루 동안 처음으로 결제 화면을 연 주문처럼 그룹을 만드는 규칙을 정하고, 모두에게 같은 관찰 기간을 주세요. 기간의 길이는 결제 수단과 구매 주기에 맞춰 정합니다. 기간이 끝나기 전에는 잠정 결과와 대기 중인 거래의 비중을 함께 보여 주세요. 늦게 확정된 결제는 원래 코호트를 갱신해야 하며, 임의의 날짜에 새로운 성공 시도를 만들어서는 안 됩니다.

세분화에도 규율이 필요합니다. 비슷한 결제 수단, 기기, 통화, 고객 유형끼리 비교하세요. 전체 비율은 더 까다로운 세그먼트의 비중이 커진 것만으로도 낮아질 수 있습니다. 새 연동 버전을 탓하기 전에 트래픽 구성의 변화와 관찰 건수가 충분한지 확인하세요.

Adyen의 Received payment details report에는 승인 및 거절된 결제, 처리 참여자 간 상호작용과 응답에 대한 데이터가 포함됩니다. 이 리포트는 퍼널의 서버 측 부분을 대사하는 데 유용하지만, 결제를 아예 보내지 않은 방문자는 설명하지 못합니다. 출처: Adyen, Received payment details report.

미완료 거래를 위한 자리를 따로 두라

잠정 결과를 억지로 성공과 실패로 나눌 필요는 없습니다. 결과가 대기 중이거나 알 수 없는 거래를 별도로 분류하세요. 오늘 이런 거래가 늘었다면 수치 하락은 구매자를 최종적으로 잃었다기보다 확인 지연을 반영한 것일 수 있습니다. 판단하려면 대기 시간과 같은 관찰 기간이 지난 뒤의 결과가 필요합니다.

실험 전에 무엇을 바꾸는지, 누가 비교 대상에 들어가는지, 무엇을 완료로 볼지 적어 두세요. 재시도할 때 하나의 주문이 그룹 사이를 옮겨 다니지 않는지 확인하세요. 분모, 관찰 기간, 화면을 동시에 바꾸지 마세요. 그러면 실제 개선이 있어도 설명하기 어려워집니다.

최종 분석에서는 추가로 완료된 주문 수 옆에 처리 비용, 환불, 이중 청구 문의를 함께 두세요. 이런 지표는 첫 결제보다 늦게 드러날 수 있으므로, 초기의 긍정적인 결과는 정해 둔 품질 검증 전까지 잠정적인 것으로 남습니다. 필요한 개선은 출시 당일 보기 좋은 숫자가 아니라 이 검증을 통과하는 개선이어야 합니다.