통계로 본 내용시각화
내용시각화 · 공급 탐색

통계로 본 내용시각화

잰 것, 알게 된 것, 아니었던 것

미리캔버스 내용시각화 로그로 무엇을 잴 수 있고 무엇은 못 재는지, 그리고 그 위에서 어떤 가설을 세워 어디까지 검증할 수 있는지를 모은 문서다. 확정된 결론집이 아니다. 각 장에는 반박과 한계를 같이 붙였고, 실제로 돌아가는 Databricks 쿼리를 전부 첨부했다.

1부는 컴포넌트 자체의 속성이 채택·생존을 어떻게 가르는지를 다루고(기각한 것 포함), 2부는 유저·입력·맥락 쪽 축을 다룬다. 2026-09-14 점검에서 중요도가 낮은 12장은 아카이브로 내렸다.

관측 2026-08-01 - 09-09검색 33,141 계정 13,084노출 항목 695,725컴포넌트 17,997편집 행위 743만
실측 6효과 14가설 3기각 21

← → 키·마우스 휠로 넘기고, 좌우 여백을 눌러도 넘어간다. 위쪽 1부·2부 버튼이나 아래 진행 바의 로 각 부의 시작에 바로 가고, 종류로 걸러 볼 수 있다. NEW 버튼은 이번 회차에 새로 들어온 장만 보여준다.

지도

무엇을 잴 수 있나

가설보다 먼저 와야 하는 것. 지금 손에 쥔 로그로 무엇을 어디까지 잴 수 있는가, 그리고 무엇이 막혀 있는가.

검색이 실제로 일어나는 순서

유저가 넣은 원문은 먼저 마크다운 형태의 summary 로 변환되고, 검색은 원문이 아니라 그 summary 에서 파악되는 문단 구조와 문장 길이로 이뤄진다. 그래서 원문의 형태는 직접 검색되는 것이 아니라 변환 결과를 통해서만 결과에 닿는다. 아래 여러 가설이 이 사슬 위에 서 있다.

쓸 수 있는 로그

로그단위규모
GA 이벤트 (직원 제외판)이벤트일 1.9억행
내용시각화 이벤트 3종
search / view / action_component
검색·노출·채택5개월 341만
검색 요청·요약 로그검색154,456 / 176,327
에디터 UI 로그클릭·노출 41종40일 895,458
공급 카탈로그컴포넌트31표 · 196,745
계정 생애 이력계정·일85컬럼
편집 행위 이력편집 명령40일 7.4억행
다운로드본 컴포넌트 잔존디자인·컴포넌트-

잴 수 있는 결과 지표

지표관측 가능 기간
채택 (검색 → 컴포넌트 선택)전 기간
생존 (다운로드본 잔존)전 기간
7일 내 디자인 다운로드다운로드 로그 최종일 −7일까지
7·30일 재방문관측창 끝 −7·−30일
CES 팝업 응답5월부터 안정
패널 닫기 · 최근 시각화8월 신설
데코레이션 라우트7월 신설
검색 오류 (무결과·타임아웃)7월 신설
편집 행위 (삭제·대치·색·레이아웃)전 기간
지도

무엇이 막혀 있나

막힌 것을 적는 쪽이 더 쓸모 있다. 아래 오른쪽은 지금 데이터로는 답할 수 없는 질문들이다.

검증된 조인

GA search_id ↔ 요청로그 search_key98.3%
GA action_itemcomponents.component_key98.9%
GA view_item_keycomponent_key97.8%
GA sub_search_id ↔ 요약로그78.7%
채택 design_idx ↔ 편집 이력95.1%

막혀 있는 것

수요 시그니처 ↔ 공급 시그니처0%
abtest_name·experiment_id·variant_id채움률 0%
component_search_feedback_log0행
채택 ↔ 편집의 항목 단위 귀속9/1 이전 불가 · 이후 요소 id
컴포넌트가 무엇으로 대체됐는지다음 행동으로만
검색 후보 목록(후보에서 빠짐 vs 순위에서 밀림)미로깅
장식 요소 이벤트의 항목 키채움률 0%
다운로드본 컴포넌트 기록채택 디자인의 36%

항목 단위 귀속이 막힌 이유: 채택 쪽 design_page_idx는 UUID인데 편집 쪽은 정수 페이지 번호이고, node_id는 요소 UUID 목록이 100자 조각으로 쪼개져 여러 행에 흩어져 있다. 그래서 9/1 이전 편집 분석은 디자인 × 세션 × 시각까지가 천장이다. 9/1부터는 채택 이벤트가 넣은 요소 id 목록을 싣고 에디터 편집 이벤트가 같은 id를 실어 요소 단위로 이어진다(H41).

요약

가장 날카로운 일곱

23장 중 가장 날카로운 일곱을 먼저 적는다. 일곱 모두 유효 컴포넌트의 특성(1부)이다 — 10사이클 뒤 두 번째 점검에서 다시 골랐다. 나머지는 종류·등급과 함께 각 장에서 다룬다.

요구 전체를 담으려는 컴포넌트는 진다용량이 요구 길이의 0.15–0.60배일 때 가장 잘 채택되고 1.0배를 넘으면 무너진다. 컴포넌트는 조각이지 완성품이 아니다 — 전형 요구 기준 75–300자. 썸네일에서 보이는 것만 선택을 가른다이미지는 어떤 통제에도 +1pp 안팎이 남는다. 장식은 같은 템플릿 안에서도 남는다. 구조 깊이와 색 대치 가능 여부는 차이를 만들지 않는다(H3 — 대치 범위를 두 배로 넓혀도 그대로). 장식·이미지는 노출까지 가른다같은 템플릿 안에서도 장식 8개 이상 +9.3pp, 이미지 +14.3pp 더 노출되고 상위 10위에도 더 든다. 채택(5차)과 도달(6차)이 같은 방향이다. 노출은 상위 1%에 고착돼 있다일반 컴포넌트 약 880개가 노출의 58.6%를 가져가고, 8월 전반 상위 1%의 92%가 후반에도 그대로다. 공급을 늘리는 것만으로는 노출이 바뀌지 않을 수 있다. 구조가 복잡해질수록 맞는 것이 없다요구 항목이 8개를 넘으면 채택이 무너진다. 표/차트는 표가 설명 글에 둘러싸이면 후보가 0개가 된다(H36). 랭킹이 아니라 공급 목록에 없는 것을 찾고 있다. 실패의 3/4은 이탈이 아니라 대체다채택된 컴포넌트의 23.8%만 다운로드본에 남는다. 실패 중 56.6%는 디자인은 다운로드됐는데 그 컴포넌트만 없는 경우다. 채택 뒤 다음 행동 1순위도 다른 컴포넌트(59%)다. 버려지는 컴포넌트는 내용을 앉히기 전에 버려진다같은 디자인 안에서 넣은 텍스트를 고친 채택은 68%가 남고 안 고친 채택은 15%만 남는다. 처방은 「앉히기 전에 맞다고 느끼게」 — 채택 시점에 보이는 특성이 1순위다.
1부

유효 컴포넌트의 특성

어떤 컴포넌트가 선택되고 살아남는가. 컴포넌트가 가진 속성(용량·장식·이미지·번호·구조)을 노출과 채택에 직접 붙여 본 가설들이다. 공급을 만드는 쪽이 바로 손댈 수 있는 것만 모았고, 재보니 아니었던 것도 함께 적는다.

내용 16장기각 21컴포넌트 17,997노출 항목 695,725카탈로그 조인 98.2%
컴포넌트 속성

요구 전체를 담으려는 컴포넌트는 진다

효과증거 강H29

컴포넌트 용량이 요구 길이의 0.15–0.60배일 때 가장 잘 채택되고, 1.0배를 넘는 순간 무너진다

컴포넌트가 담을 수 있는 총 글자 수를 structure_jsontotalMaxChars 합으로 구해, 그 검색의 요구 길이로 나눴다. 같은 검색·같은 스크롤 구간 안에서 비교하면 역U자가 나오고 비율 1.0을 넘으면 급격히 나빠진다. 8월 전반과 8월 후반–9월에서 같은 모양이고 생존에서도 부호가 같다. 용량을 절대값(147자 이상)으로 자르면 요구 길이 네 구간 전부에서 0 근처다 — 기준은 절대 용량이 아니다.

지지

내용시각화는 하나의 요구를 여러 컴포넌트에 나눠 담는다. 컴포넌트는 조각이지 완성품이 아니다. 요구 전체를 혼자 담을 만큼 큰 컴포넌트는 나머지 조각과 겹치거나 빈 슬롯을 남긴다. 적정 크기는 요구의 1/5 – 1/2이고, 전형 요구(summary 중앙 495자) 기준 75–300자다.

반박과 한계

표/차트 라우트 현상이다. 일반 라우트에서는 효과가 훨씬 약하고(0.15–0.30 구간 +0.03pp, ns), 2.00배 이상 구간에서는 부호가 +0.74pp(z=5.7)로 뒤집힌다. 일반 라우트에서 큰 컴포넌트는 「완성형 레이아웃」으로 읽히는 다른 기전이 있을 수 있다. 따라서 이 대역 기준은 표/차트 공급에만 적용해야 한다.

또 표의 totalMaxChars 는 셀 용량의 합이라 실제 담기는 양과 어긋날 수 있다.
컴포넌트 용량 ÷ 요구 길이 구간별 채택 효과 · 층 = 검색 × 스크롤 구간 · 항목 663,577개
컴포넌트 속성

일반 라우트에서는 썸네일에서 보이는 것만 가른다

효과증거 강H30

이미지 포함 +19%(어떤 통제에도 유지) · 장식 8개 이상 +58%(일부는 템플릿 품질의 대리) · 구조 깊이는 사라진다

컴포넌트 구조에서 장식 요소(SVG) 수, 이미지 요소 수, 컨테이너 수를 직접 세어 붙였다. 같은 검색·같은 위치·같은 용량 비율·나머지 속성 전부를 층에 넣고 비교해도 장식과 이미지는 남고, 컨테이너 수(구조 깊이)는 +0.14pp(z=2.3)로 무너진다. 라우트를 가르면 더 뚜렷하다 — 이 둘은 일반 라우트에서만 산다.

지지

유저는 썸네일만 보고 고른다. 썸네일에서 읽히는 것은 장식과 이미지이고, 읽히지 않는 것은 선택을 가르지 못한다. 색 대치 가능 여부가 두 층위에서 두 번 연속 0이었던 것(H3)이 같은 규칙의 뒷면이다. 표/차트 라우트에서 시각 신호가 죽는 것은, 거기서는 내 데이터가 들어갈 자리(H29)를 보기 때문이다.

반박과 한계

5차에서 이 반박을 직접 쟀다. 장식이 많은 컴포넌트는 실제로 잘 채택되는 템플릿에서 나온다(그 템플릿의 다른 컴포넌트 채택률 3.21% vs 2.71%). 템플릿 품질로 층을 나누면 장식 효과는 +0.4 – +0.8pp 로 준다. 그래도 같은 템플릿 안의 형제끼리 비교하면 +1.7 – +2.2pp 가 남는다(템플릿 군집 보정). 장식은 원인이지만 크기는 불확실하다.

이미지는 어떤 통제에도 흔들리지 않았다 — 템플릿 품질 층 +1.4pp · 같은 텍스트 구조 짝 +1.0pp · 같은 템플릿 형제 +2.1pp · 8월 전반과 후반 모두.
일반 라우트 · 4차 검색 내 비교 vs 5차 템플릿 품질 층 · 같은 템플릿 형제(군집 보정)
컴포넌트 속성

같은 템플릿 안에서도 장식·이미지가 있는 쪽이 노출까지 간다

효과증거 강H35

같은 구조에서 노출 확률 장식 8+ +13.2pp · 이미지 +7.5pp · 상위 10위 진입 +4.5 / +5.3pp · 번호는 −2.2pp

4·5차는 노출된 뒤의 채택을 봤다. 이번에는 노출되느냐를 봤다. 같은 텍스트 구조 셀에서 장식이 많은 컴포넌트의 노출률은 27.8% vs 14.1%, 이미지는 25.2% vs 19.0%다. 템플릿 노출률 10분위로 층을 나눠도(+11.0 / +7.4pp), 같은 템플릿 안에서 비교해도(+9.3 / +14.3pp, 군집 보정) 남고 두 기간 모두 같다.

지지

서빙 순위에는 스타일 가중(0.3)이 들어간다. 시각 요소가 풍부한 컴포넌트가 순위에서 이득을 보면 상위 10위에 들고, 그래야 노출된다. 5차에서 이미지는 채택의 원인으로 지지됐다 — 도달과 채택이 같은 방향으로 겹친다.

반박과 한계

순위 모델이 과거 채택을 반영한다면 장식·이미지는 잘 채택돼서 올라간 것이지 도달을 직접 만든 게 아닐 수 있다(순위 로직 미확인). 번호의 순위 하락은 작고(−2.2pp), 표/차트는 해당 컴포넌트가 20여 개뿐이라 판별하지 못했다.
일반 컴포넌트 · 노출 확률은 카탈로그 단위 · 순위는 10위 밖까지 스크롤된 검색 안(컴포넌트 단위)
라우트·진입

장식 요소를 찾는 사람과 컴포넌트를 고르는 사람은 거의 겹치지 않는다

실측H37

컴포넌트를 채택한 디자인의 2.4–2.6%만 장식 요소 경로를 쓴다 · 유저 단위로도 3.4–4.8%

어떻게 쟀나 — 장식 요소 이벤트는 디자인 id 가 88–92% 채워져 있다. 같은 기간 컴포넌트 채택 이벤트와 디자인 id · 유저 id 로 이어 양쪽을 함께 쓴 비율을 셌다.

7월에 생긴 장식 요소 경로(검색·노출·채택)는 8월 중순부터 주 1,400건씩 채택된다. 같은 디자인·같은 유저로 컴포넌트 채택과 이어 보면, 두 경로를 함께 쓰는 경우는 두 기간 모두 5% 미만이다. 장식 경로 디자인의 97%는 컴포넌트를 채택하지 않았다.

지지

장식이 적은 컴포넌트를 받은 뒤 장식 요소로 보충하는 신호는 보이지 않았다 — 채택 후 24시간 안 장식 채택은 속성과 무관하게 0.2–0.65%다. 컴포넌트에 장식을 넣는 효과(H30·H35)는 장식 요소 경로와 별개로 읽어야 한다.

반박과 한계

장식 요소 이벤트에는 무엇을 봤고 골랐는지가 없다(항목 키·검색 id 0%). 그래서 장식 요소 공급의 어떤 특성이 채택을 가르는지는 잴 수 없다. 보충 신호도 장식 경로 유저로 좁히면 263 디자인뿐이라 판별하지 못했다. 두 경로가 왜 갈리는지(작업 의도)는 관측되지 않는다.
07-28 – 09-09 · 두 기간 · 디자인과 유저 단위
컴포넌트 속성

이미지가 든 컴포넌트를 학생만 피한다

효과증거 강H1

같은 검색 · 같은 스크롤 구간 안에서 비학생 +25.6% · 학생 −9.4%

노출 항목 695,725개를 같은 검색의 같은 스크롤 로드 안에서 짝지어 비교했다. 이미지가 든 컴포넌트는 대체로 더 많이 채택되는데, 학생 계정에서만 방향이 반대다. 공급의 19.3%가 이미지 포함본이다.

지지

학생 산출물은 텍스트·수치 전달이 목적이고 이미지는 “채우는 것”으로 읽힌다. 게다가 학생은 대치할 자기 이미지 자산이 없어 기본 이미지가 그대로 남고, 그 어색함을 썸네일 단계에서 이미 예상한다.

반박과 한계

권한 문제 아닌가. 학생은 무료 비중이 높아 이미지 대치가 막혀 있을 수 있다. 확인했다: 트라이얼 학생 −22.7%, 결제 학생 −7.2%로 자산 접근이 열린 쪽에서 오히려 더 뚜렷하고 무결제 학생은 0이다. 권한 설명과 정반대다.

남은 한계: 유저 타입은 가입 시 자기 신고다. 학생 계정을 교사가 만들었을 수 있고, 라벨 자체의 타당성은 검증되지 않았다.
유저 타입별 이미지 포함 항목의 채택 우위(상대 %) · 층 48,822개 · 기저 채택률 3.2%
컴포넌트 속성

색 대치 가능 여부는 채택을 가르지 않는다 — 대치 범위를 두 배로 넓혀도

효과증거 강H3

같은 컴포넌트가 대치 가능하게 뜰 때와 아닐 때의 채택 차 −0.2pp · 8/4 색상 대치 개선으로 대치 가능 노출 33% → 70% · 전후 차 −0.05pp(95% ±0.2)

어떻게 쟀나 — 대치 가능 여부(color_replacement_available)는 같은 컴포넌트라도 템플릿·디자인 맥락에 따라 노출마다 달라진다. 그래서 컴포넌트를 층으로 두고 같은 컴포넌트 안에서 가능하게 뜬 노출과 불가하게 뜬 노출의 채택을 비교했다(컴포넌트 군집 보정).

1차에서는 집계 규칙에 따라 −1.8%와 +35.8%로 뒤집혀 측정이 안 되는 축으로 두었다. 8/4 배포(색상 대치를 Hue map 방식으로 전환)로 대치 가능 노출이 한 주 만에 33%에서 70%로 늘었다. 같은 컴포넌트 안 비교로 보면 가능 − 불가 채택 차는 배포 전 −0.22pp, 배포 후 −0.28pp로 둘 다 0에 가깝고, 전후 차도 없다.

지지

유저는 썸네일에서 대치 가능 여부를 알 수 없고, 보이지 않는 속성은 선택을 가르지 못한다(H30과 같은 규칙). 대치 범위를 두 배로 넓힌 사건에서도 일반 경로 노출당 채택은 3.0–3.6%로 그대로였고, 배포 로그에도 「KR 변화 없음」으로 적혀 있다. 공급 기준에 「색 대치 가능」을 넣을 근거가 없다.

반박과 한계

배포 1주 전 서빙 세대 전환(7/28)과 8/10 검색 오류가 겹쳐 전환 2주는 뺐다. 이 판정은 채택에 대한 것이고, 채택 뒤 색을 실제로 바꿨는지는 따로 잰다 — 3차에서 대치 실행은 생존과 무관했다(z=1.65). 컴포넌트 고정 속성으로 집계하면(1차 방식) 여러 번 본 항목이 섞여 결론이 뒤집히므로 쓰지 않는다.
일반 경로 · 같은 컴포넌트 안 「가능 − 불가」 채택 차 · 전 07-06 – 07-26 · 후 08-10 – 09-09
노출 중 대치 가능으로 뜬 비율 · 8/4 색상 대치 Hue map 전환
공급 구성·커버리지

노출은 상위 1%가 절반 넘게 가져가고, 그 자리는 바뀌지 않는다

실측H34

일반 컴포넌트 상위 1%(약 880개)가 노출의 58.6% · 상위 10%가 98% · 8월 전반 상위 1%의 92%가 후반에도 상위 1%

어떻게 쟀나 — 서빙 카탈로그 일반 컴포넌트마다 8/1–9/13 에 몇 번의 검색에서 노출됐는지 셌다. 검색 후보 목록은 로그에 없어서 「후보에서 빠짐 / 순위에서 밀림」은 같은 구조 셀의 노출률로 대리 분류했다.

한 번이라도 노출된 일반 컴포넌트는 20.5%다. 두 기간으로 나눠도 집중도(58.9% / 58.5%)와 상위 구성이 거의 같고, 8월 전반에 한 번도 안 뜬 컴포넌트가 후반에 처음 뜬 비율은 6.4%다.

지지

일반 경로는 검색마다 후보가 거의 늘 상한 50까지 찬다(7월까지 87%). 후보가 모자라서가 아니라 상위 자리를 소수가 계속 차지한다. 채택이 순위에 되먹임되는 구조라면 이 고착은 스스로 강해진다.

반박과 한계

미노출 원인 분류는 대리다 — 같은 구조가 거의 안 닿는 경우 4–29%, 같은 구조는 닿는 경우 16–69%로 기준에 따라 크게 움직인다. 7/28 이후 일반 경로 검색 설정이 기록되지 않아 임베딩이 도달에 관여하는지 모른다. 고착이 순위 되먹임 탓인지 원래 좋아서인지는 가를 수 없다.
일반 컴포넌트 87,974개 · 노출 점유 · 두 기간
미노출 69,931개 · 같은 구조 셀 노출률로 분류 · 기준에 따라 크게 움직인다
공급 구성·커버리지

다장은 내용을 지키려다 절반만 전달한다

효과증거 강H33

같은 내용에서 다장은 채택 −18.4pp · 채택 시 담긴 비율 0.42 vs 0.57 · 검색당 기대 담김 절반(0.15 vs 0.31)

어떻게 비교했나 — 분할은 길이가 아니라 변환기가 뽑은 섹션 수를 따라 켜진다. 그래서 원문 길이·줄 수·글머리·라우트와 summary 항목 수·길이까지 같은 층(279층) 안에서만 짝지었다. 담긴 비율 = 채택 컴포넌트의 글자 용량 ÷ summary 길이, 같은 조각의 대안은 가장 큰 것 하나만 센다.

다장은 유실을 줄이려는 제공 방식인데, 유저는 세트의 일부만 가져간다(세트 전체 채택 2장 49% · 3장 26% · 4장+ 24%). 그래서 채택해도 담긴 비율이 1장보다 낮고 채택 자체도 낮다. 디자인 다운로드는 같다(73.9% vs 73.5%) — 작업은 끝내되 우리 컴포넌트를 덜 쓴다.

지지

「다장은 1페이지가 채택을 결정하고 2·3페이지는 보지도 않는다」(Sprint917)와 맞다. 계정 고정효과 −18.9pp, 원문 칸만 쓴 비교 −21.0pp로 같은 방향이다. 세트가 빈 경우(466건)는 채택 3.6%로 거의 전멸이고, 이를 빼도 −14.3pp다.

반박과 한계

가장 궁금한 구간은 답할 수 없다 — 일반 라우트 원문 1,200자 이상은 91%가 분할돼 비교할 1장이 없다. 격차 일부는 제공 방식이 아니라 다장을 보여주는 화면 탓일 수 있다. 담긴 비율은 용량 상한이다. 5월(선행 문서 기간)에는 차이가 없었다(36.8% vs 37.2%).
같은 층 안 비교(S2) · 담긴 비율은 채택한 검색 기준 · 다운로드는 9/2 이전
장 수별 채택률 · 「세트 빔」 = 분할인데 하위 검색이 하나뿐
공급 구성·커버리지

구조가 복잡해질수록 맞는 컴포넌트가 없다

효과증거 강H23

항목 8개를 넘으면 채택이 무너지고(35.2% → 27.8%), 생존은 4배 차이가 난다

유저가 넣은 원문은 서비스 내부에서 구조화된 형태로 변환된 뒤 검색에 쓰인다. 그 변환 결과의 복잡도로 나눠 본 것이다. 항목 수가 8개를 넘으면 채택이 급락하고, 생존은 항목 0개일 때 17.0%에서 16개 이상일 때 4.5%로 떨어진다.

더 뚜렷한 것은 제목의 단계다. 대제목 아래 소제목이 또 있는 2단 구조는 채택 36.3% · 생존 7.8%인데, 1단이면 49.4% · 14.8%다.

지지

공급되는 컴포넌트는 대부분 단층 구조다. 항목이 많거나 중첩된 요구에는 맞출 대상 자체가 없다. 이건 랭킹의 문제가 아니라 공급 목록에 없는 것을 찾고 있는 상황이다.

항목 수와 제목 단계가 각각 독립적으로 같은 방향을 가리키는 것도 이 해석을 뒷받침한다.

반박과 한계

복잡한 구조를 요구하는 입력은 원문 자체도 길다. H8의 길이 효과와 뒤엉켜 있고, 여기서는 분리하지 않았다.

또 항목 0개 구간(채택 51.5%)이 가장 높은 것은 표·차트처럼 항목 목록이 아닌 형태가 섞여 있기 때문일 수 있다. 단조 관계가 아니라 8개를 넘으면 무너진다로 읽어야 한다.
변환된 구조의 항목 수별 · 검색 33,136건
변환된 구조의 제목 단계별
공급 구성·커버리지

표/차트는 표가 설명 글에 둘러싸이면 후보가 사라진다

가설증거 중H36

표/차트 요구의 5.0%는 후보 0 · 10.3%는 1–9개 · 후보 1–9개면 채택 29.9% vs 10–49개 46.4%

표/차트 경로는 구조 전용 검색이라 맞는 구조가 없으면 후보가 비어 버린다. 후보가 없는 요구는 순수 표(텍스트 1.1개)가 아니라 제목·설명·그룹이 표를 둘러싼 복합 구조(텍스트 6.5 · 그룹 8.3)였다. 표 행 수는 다르지 않다. 차트 요구는 오히려 후보가 넘친다.

지지

표/차트 카탈로그는 544개뿐이다. 복합 구조가 카탈로그에 없으면 완화 재현 전략 9종으로도 찾지 못한다. 후보가 적은 요구는 실제로 덜 채택된다.

반박과 한계

공급 쪽 복합 구조 보유율은 재지 못했다 — 원본 파생 특성이 표 안의 셀 글과 표 밖의 설명 글을 가르지 못한다. 복합 요구가 원래 까다로워 채택이 낮을 수도 있다(요구 난이도 교란).
후보 0 은 노출 자체가 없다 · 표/차트 하위 검색 20,001건(8/1 이후 · 평가 배치 제외)
요구(summary) 안 텍스트·그룹 수 · 표 행 수는 구간 간 차이 없음
공급 구성·커버리지

차트 공급을 크게 줄여도 차트 채택은 떨어지지 않았다 — 후보 0 만 늘었다

효과증거 중H38

v2 전환 때 세로 막대 차트 923 → 88 · 영역 선 150 → 0 · 채택 이중차분 −1.6pp(95% −4.5 – +1.4) · 후보 0 +2.3pp

7/28 서빙 세대가 v2로 바뀌면서 차트 컴포넌트가 종류째 줄었다. 공급이 그대로인 표 요구를 대조로 전후를 비교했다. 노출된 차트 하위 검색의 채택률은 29.6% → 29.8%, 표는 44.1% → 45.8%로 둘 다 거의 그대로다. 대신 후보가 하나도 없는 차트 요구가 4.9% → 7.5%로 늘었다(표 3.7% → 4.0%).

지지

세로 막대 차트는 노출 컴포넌트가 143개에서 53개로 줄었지만 노출당 채택률은 4.42% → 4.44%였다. 차트 요구에서 공급의 양은 채택의 병목이 아니었다. 줄일 때 조심할 것은 양이 아니라 종류가 통째로 사라지는 것이다.

반박과 한계

같은 날 다른 변경이 겹쳤을 수 있다(서빙 세대 전체 교체). 대조군 표도 같은 전환을 겪었으므로 이중차분은 「차트에만 있던 변화」만 잡는다. 채택 하락이 없다는 판정은 4.5pp 보다 큰 하락은 없다는 뜻이고, 그보다 작은 하락은 가를 수 없다.
노출된 하위 검색의 채택률 · 전 07-06 – 07-26 · 후 07-28 – 09-09
하위 검색 중 후보가 하나도 없는 비율
공급 구성·커버리지

무결과 오류는 숙련자를 두 배 크게 잃는다

효과증거 강 · 8월 단독H10

CV 2-5회 −8.3pp · 6회+ −15.2pp · 오류 검색의 생존은 정확히 0

무결과·타임아웃이 난 검색은 생존이 0이다(당연하다. 고를 게 없다). 흥미로운 건 잃는 절대량이 숙련자에게 두 배라는 것이다. 숙련자는 그 검색에서 원래 15.4%를 건졌을 텐데 전부 잃는다.

지지

숙련자는 이 기능이 무엇을 할 수 있는지 알고 온다. 기대가 구체적일수록 무결과가 깎는 신뢰의 양이 크고, 그 검색에서 원래 얻었을 가치도 크다.

반박과 한계

숙련자가 오류를 더 겪는 이유가 더 어려운 입력을 넣기 때문일 수 있다. 오류율은 300-599자에서 5.8%, 0-49자에서 1.8%로 입력 길이와 함께 오른다. 그렇다면 “어려운 입력”이 오류와 낮은 생존을 동시에 만든 것이고 오류는 원인이 아니다.

길이·줄 수를 층화한 뒤에도 남았으나 층 안의 잔여 난이도까지는 배제하지 못했다. 그리고 9월에는 오류 표본이 거의 없어 8월 단독 결론이다.
CV 검색 경험량별 · 무결과 오류가 발생한 검색의 생존 손실
공급 구성·커버리지

서빙 세대의 구조 정보가 비어 있다

실측H32

슬롯 표 결손 99.9% · 임베딩 표 결손 100% · 요소 수·깊이 NULL 99.4%

여기서 「구조 정보」란 — 컴포넌트 원본(structure_json, 요소 트리 전체)에서 미리 계산해 별도 표·컬럼에 넣어둔 파생 정보다. 텍스트 칸(슬롯)과 칸별 용량(component_slots), 검색용 임베딩(component_embeddings), 요소 수·깊이. 원본을 매번 파싱하지 않으려 만든 것이라 이 표가 비면 원본이 멀쩡해도 쓰는 쪽이 눈을 잃는다

카탈로그는 2026-07-28에 v2로 전환됐고 지금 노출되는 것은 전부 v2다. 그런데 component_slots 는 2026-04-23 이후 갱신이 없고 component_embeddings 와 함께 v1만 담고 있다. 요소 수·깊이도 v2에서 99.4%가 비어 있다. 원본은 v2도 전량 있는데 파생본만 없다.

지지

파생 적재가 세대 전환을 따라오지 못했다. 둘이 따라 나온다. ① 「임베딩 보유 55%」는 공급 결손이 아니라 세대 구성비였다(v1 99.3% / v2 0%). ② 슬롯 용량 기준으로 내리는 판정이 있다면 서빙과 어긋난다. H29의 용량 지표는 원본에서 직접 파생해 우회한 것이다.

반박과 한계

이것이 bronze 적재 지연일 뿐이고 원천 DB에는 v2 슬롯·임베딩이 있을 수 있다. 그렇다면 문제는 공급이 아니라 분석 자산이다. 판별은 원천을 직접 보는 것뿐이고 아직 하지 않았다.
서빙 세대(v2 · 88,518건)의 파생 정보 결손률 · 원본 structure_json 은 결손 0%
성과 정의

실패의 3/4은 이탈이 아니라 대체다

실측H17

생존 23.8% · 컴포넌트만 버려짐 56.6% · 작업 중단 19.6%

여기서 「실패」란 — 분모는 채택이 일어난 검색 10,404건(다운로드 관측이 가능한 2026-09-02 이전). 채택한 컴포넌트가 그 디자인의 다운로드본에 남으면 생존, 아니면 실패다. 실패는 둘로 갈린다 — 디자인은 7일 안에 다운로드됐는데 그 컴포넌트만 없으면 컴포넌트만 버려짐, 디자인 자체가 다운로드되지 않았으면 작업 중단. 실패는 76.2%이고 그중 74%가 버려짐이다.

지금까지 “실패”는 한 덩어리였는데, 실패의 74%는 디자인이 다운로드까지 갔는데 그 컴포넌트만 빠진 경우다. 유저를 잃은 게 아니라 경쟁에서 진 것이고, 이탈 대응과 대체 대응은 다른 예산이다.

지지

채택률만 보면 56.6%의 실패가 통째로 안 보인다. 지표를 채택률에서 생존률로 옮겨야 하는 직접적 근거다.

반박과 한계

「버려짐」 판정이 잔존 판정의 정밀도에 의존한다. 심하게 편집하면 못 알아볼 수 있고, 그러면 살아 있는데 버려진 것으로 셈된다. H11에서 편집이 많을수록 생존이 높게 나온 것은 반대 방향이라 다소 완화되나 배제되진 않았다. 그리고 무엇으로 대체되었는지는 로깅되지 않는다.
채택 이후

버려지는 컴포넌트는 내 내용을 앉히기 전에 버려진다

실측H41

같은 디자인 안에서 넣은 텍스트를 고친 채택은 68%가 다운로드본에 남고, 안 고친 채택은 15%만 남는다 · 넣은 요소를 골라 지우는 손질은 2.3%

어떻게 쟀나 — 9/1부터 채택 이벤트가 디자인에 넣은 요소 id 목록을 싣고, 에디터 편집 이벤트가 같은 id를 싣는다. 둘을 이어 컴포넌트가 넣은 요소 하나하나가 이후 고쳐졌는지·지워졌는지를 셌다(9/1–9/13 · 10,310 채택 · 요소 31만).

한 디자인에 여러 컴포넌트를 받는 경우가 많다. 같은 디자인 안에서 텍스트를 고친 채택과 고치지 않은 채택을 나란히 두면, 다운로드본에 남는 비율이 68.1% 대 14.8%로 갈린다(158 디자인 · 군집 z 14.5). 넣은 요소를 일부만 골라 지우는 손질은 요소의 2.3%로 드물다. 채택 뒤 60분 안의 다음 행동 1순위는 다른 컴포넌트를 또 고르는 것(59%)이었다.

지지

3차의 「채택했지만 버려진 56.6%」는 내 내용을 채우는 단계까지 가지 못한 것이 대부분이라는 뜻이다. 공급 쪽 처방은 앉히기 전에 맞다고 느끼게 — 채택 시점에 보이는 특성(이미지 H30 · 용량 적합)이 여전히 1순위다. 요소가 많아 골라 지운다는 신호는 약하다.

반박과 한계

방향은 가를 수 없다 — 남길 것이라 텍스트를 고쳤을 수도 있다. 다운로드 이벤트의 컴포넌트 기록은 채택이 있는 다운로드 디자인의 36%에만 있어 기록 기준이 확인되지 않았다. 컴포넌트째 지우는 삭제는 요소 id로 이어지지 않아 보이지 않을 수 있다. 요소 이벤트가 13일치뿐이다.
같은 디자인 안 채택끼리 · 다운로드본에 컴포넌트가 남은 비율 · 채택 9/1–9/6
채택 뒤 60분 안 같은 디자인에서 한 일 · 비분할 검색 8,609 채택
성과 정의

노출 수는 공급량이 아니라 스크롤 깊이다

실측H20

스크롤 1→5회에 평균 노출 6.8 → 17.1 → 28.0 → 38.6 → 53.1개 · 정확히 10개씩

가장 밟기 쉬운 함정이다. “많이 보여줬더니 채택이 늘었다”는 관계는 거의 전부 이것으로 설명된다. 결과 목록은 10개 단위 무한 스크롤이고 서버 상한이 50이라, 노출 수는 유저가 얼마나 내렸는지의 함수다. 공급 레버가 아니다.

지지

“노출이 많을수록 채택이 높다”는 관계는 이것 하나로 대부분 설명된다. 스크롤을 내린 것은 관심의 결과이지 원인이 아니다.

이 사실이 뜻하는 것

공급 수량을 레버로 쓰려면 유저 행동과 무관하게 상한이 바뀌는 상황이 필요하다. 서버 상한 변경 같은 외생 변동이다. 현재 데이터에는 없다.

그래서 “결과가 많으면 재방문이 는다”(40개 이상에서 +5.5pp)는 관측도 주장으로 세우지 못했다. 「많이 본 유저가 재방문한다」와 구분되지 않는다.
스크롤 로드 횟수별 평균 노출 항목 수 · 10개 단위가 그대로 보인다
기각

세웠다가 무너진 것들 - 컴포넌트·공급

“이미 확인했고 아니었다”는 남의 시간을 아끼는 자산이다. 세웠다가 무너진 것들 · 무너진 이유가 다음 분석에 더 쓸모 있다.

세웠던 가설첫 관측무너진 이유
번호가 붙은 표/차트 컴포넌트는 순위에서 크게 밀린다−16.1pp반복 노출 착시 · 해당 컴포넌트가 23개뿐이라 같은 컴포넌트가 수만 번 세어졌다. 컴포넌트 단위로 다시 재면 +11pp(유의하지 않음)
번호 요소는 두 검색 경로 모두에서 채택을 올린다+0.45pp대리분이 절반 · 5차에서 목록 크기(반복 패턴 수)를 맞추면 +0.28pp 로 준다. 같은 템플릿 안에서는 유의하지 않고 표/차트 경로는 설계마다 부호가 뒤집힌다. 판별 불가로 내렸다
여러 장으로 주면 내용 유실이 준다0.34 vs 0.18원시 비교였다 · 같은 층에서 대안 중복을 걷어내면 담긴 비율 0.42 vs 0.57로 반대. 유저가 세트의 일부만 채택한다(H33)
타이틀 요소가 있으면 더 채택된다+1.87pp부분집합 착시 · 타이틀이 없는 컴포넌트가 47개뿐이다. 원시 채택률은 무타이틀 3.66% > 1-2개 3.31%로 부호가 반대
구조가 깊은 컴포넌트가 더 채택된다+0.66pp대리 · 나머지 속성을 층에 넣자 +0.14pp로 붕괴. 장식 요소 수의 대리였다(H30). 깊이에 드는 비용은 회수되지 않는다
텍스트 슬롯이 많을수록 더 채택된다+0.36pp대리 · 용량을 층에 넣자 +0.17pp. 대체로 용량의 대리다
용량이 큰 컴포넌트가 더 채택된다−0.14pp기준이 아니다 · 절대 용량으로 자르면 요구 길이 네 구간 전부에서 0 근처. 기준은 요구 대비 비율이다(H29)
임베딩이 없는 45%가 발견 병목이다55.0%세대 구성비였다 · 임베딩 표가 구세대만 담고 있어 생긴 수다(v1 99.3% / v2 0%). 공급 결손이 아니다(H32)
이미지 대치 가능 여부가 선택을 가른다-판별 불가 · 한 검색 안에서 값이 갈리는 층이 없다. 항목별 속성이 아닐 가능성
노출이 많을수록 채택이 는다-역인과 · 노출 수는 스크롤 깊이의 함수다(H20). 스크롤을 내린 것은 관심의 결과이지 원인이 아니다
2단계(depth2) 컴포넌트가 5.3배 채택된다+29.4pp역인과 · depth2 항목의 98.8%가 1단계 항목보다 나중에 등장하고 순번 컬럼이 없다. 유저가 파고든 결과다
같은 템플릿 출처 컴포넌트를 부스트하면 된다+74%부분집합 착시 · 두 조건이 한 검색에 섞여 나온 1%의 검색에서만 나온 값이었다. 직접 비교하면 −1.2pp(무의미)이고, 공급의 67%가 이미 동일 출처라 올릴 여지도 없다
기각

세웠다가 무너진 것들 - 그 밖

유저·입력·채택 이후 축에서 세웠다가 무너진 것들. 무너진 이유가 다음 분석에 더 쓸모 있다.

세웠던 가설첫 관측무너진 이유
세션 내 재검색이 생존을 올린다+8.4pp유저 구성 · 계정 고정효과에서 +1.9pp(저활동)·−0.4pp(고활동)로 붕괴
삭제가 많으면 컴포넌트가 버려진 것이다−4.7pp정의 오류 · 채택 후 삭제의 중앙값이 39초다. 폐기가 아니라 대치 과정에서 원본을 지우는 행위다. 계정 내에서도 무의미
과편집이 생존을 깎는다−5.3pp유저 구성 · 계정 고정효과에서 −1.6pp(무의미)
첫 검색 채택 성공이 재방문을 만든다+7.5pp선택편의 · 유저가 고르지 않은 처치(무결과 오류)는 채택을 −37.1pp 깎지만 30일 재방문은 −3.6pp(무의미). 95% 구간이 +7.5pp를 배제한다
첫 편집 후 30분 지나 검색하면 결과가 좋다+4.3pp시기 불안정 · 8월 +6.0(z=6.4) → 9월 +0.8(z=0.6)
150-299자가 최적이고 600자+는 붕괴한다-재현 실패 · 다시 재니 50자 미만 페널티 하나뿐이었다(H8)
계정 생애 이력 8종이 채택을 가른다-스크리닝 단계에서 전량 탈락. PPT/AI PPT 누적·30일 로그인·결제·트라이얼 전부
세션 UI 지표(패널 닫기·호버·CES 노출)를 결과로 쓴다-전부 「세션이 길었다」의 대리. 검색 단위 결과 지표로 부적합
유무료 격차가 채택을 가른다17.5pp통제 후 3.2pp. 실체는 팀 보유였다(H19)
2부

그 밖의 가설

누가 · 무엇을 넣고 · 그 다음에 무엇을 했는가. 컴포넌트 자체의 속성이 아니라 유저·입력·진입 맥락·채택 이후 행동이 결과를 가르는 축들이다. 공급을 바꿔서 움직이는 것은 아니지만, 1부의 효과가 어디서 커지고 어디서 사라지는지를 정한다.

내용 7장검색 33,141계정 13,084편집 행위 743만
라우트·진입

표/차트 라우트의 이점은 초심자 전용이다

효과증거 강H5

내용시각화 첫 검색 +14.1pp · 2-5회 +5.2pp · 6회+ 0 (ns)

“표/차트 라우트의 채택률이 높다”는 알려진 사실이다. 새로 확인된 것은 그 이점이 어디에 있느냐다. 내용시각화를 처음 쓰는 계정에서는 14pp 차이가 나고, 6회 이상 쓴 계정에서는 사라진다. 8월·9월 모두 초심자에서 +13pp대로 재현된다.

지지

표/차트는 입력(숫자·행렬)이 결과 형태를 스스로 규정해 무엇이 나올지 예측 가능하다. 일반 컴포넌트는 구조 매칭 결과를 미리 그릴 수 없어, 기대할 것을 모르는 초심자가 판단을 못 한다. 숙련자는 일반 라우트에서도 결과를 예측하므로 격차가 사라진다.

반박과 한계

초심자의 일반 라우트 채택률이 낮은 게 라우트 탓이 아니라 초심자의 입력에 애초에 구조가 없기 때문일 수 있다. 실제로 H7(3줄 이상 입력)의 효과도 초심자에게 두 배 크다. 그렇다면 표/차트 라우트는 “입력을 구조화하도록 강제하는 UI”로서만 기능한 것이고, 처방은 라우트 노출이 아니라 입력 스캐폴딩이어야 한다.
CV 검색 경험량별 표/차트 라우트의 채택 우위 · 길이·줄수·기기·월 층화
입력 유도

줄을 나눠 쓰게 하면 초심자에게 두 배 남는다

효과증거 강H7

3줄 이상 입력 · 첫 검색 +9.9pp · 2-5회 +9.9pp · 6회+ +4.7pp

줄바꿈은 구조 기반 검색에서 항목 경계 신호다. 3줄 이상 쓴 검색은 채택이 뚜렷하게 높고, 그 이득은 초심자에게 두 배다. 같은 계정 안에서 비교해도 효과가 오히려 커진다(+13.5pp) · 같은 사람이 줄을 나눠 쓴 날이 안 나눈 날보다 낫다.

지지

검색은 원문이 아니라 원문을 변환한 summary 의 구조로 이뤄진다. 줄이 나뉘어 있으면 변환기가 원문의 경계를 그대로 옮기면 되지만, 한 줄이면 구조를 지어내야 한다(H22). 숙련자는 줄을 나누지 않아도 변환이 잘 되는 문장을 쓰지만 초심자는 못 쓴다. 줄 나눔이 그 격차를 메운다. 계정 고정효과에서 효과가 커진 것이 이 해석을 뒷받침한다.

반박과 한계

3줄 이상 쓰는 초심자는 애초에 정리된 내용을 가진 유저일 수 있다. 줄 수가 준비도의 대리라면 줄을 강제해도 효과가 없다.

계정 내 통제로 이 반박은 상당히 약해졌지만 완전히 사라지진 않았다. 같은 사람도 “정리가 된 날”에 줄을 나눠 쓸 수 있다.
CV 검색 경험량별 3줄 이상 입력의 채택 우위 · 길이·라우트·기기·월 층화
입력 유도

한 덩어리로 붙여넣으면 없는 구조가 지어진다

가설증거 중H22

줄바꿈 없는 원문은 87자에서 384자로 23.6배 부풀려 변환된다. 채택 32.0% ↔ 줄바꿈 있으면 49.1%

검색은 원문이 아니라 원문을 변환한 summary 의 구조로 이뤄진다. 원문의 형태는 변환기가 무엇을 만들어내는가를 통해서만 결과에 닿는다. 줄바꿈 없는 한 덩어리 원문은 평균 87자인데 변환 결과는 384자다. 없던 구조를 지어낸 것이고, 그렇게 지어진 항목 5.9개와 2단 구조(50.8%)로 검색이 돌아간다. 줄바꿈이 있으면 확장은 3.4배로 떨어진다.

지지

원문에 경계가 없으면 변환기가 구조를 추측해서 만들어야 한다. 추측이 빗나가면 유저가 원한 적 없는 구조로 검색이 돌아간다. 확장 배수 23.6배가 그 추측의 양이다.

경계가 있으면 변환기는 지어낼 필요가 없다. 글머리 기호가 있는 원문의 확장은 2.6배로 가장 낮다.

반박과 한계

글머리 기호가 줄바꿈보다 낮은 것(45.7% vs 49.1%)은 착시였다. 글머리를 쓰는 원문은 더 길고(398자) 변환 항목도 8.4개로 가장 많아 H23 의 복잡도 페널티에 걸린다. 항목 수를 고정하면 오히려 글머리 쪽이 낫다(4-7항목 57.0% vs 53.6%).

남은 한계 - 형태와 길이가 강하게 얽혀 있다(87 / 262 / 398자). 형태만의 효과는 같은 길이 안에서 다시 봐야 한다.
원문 형태별 변환 결과. 한 덩어리는 23.6배로 부풀려진다
변환 결과의 복잡도를 고정하면 한 덩어리만 일관되게 낮다
채택 이후

채택은 끝이 아니다. 손대지 않은 컴포넌트는 사라진다

효과증거 강H11

채택 직후 방치하면 생존 −11.3pp · 작업 중단 +12.7pp (계정 + 창 길이 통제)

채택 직후 귀속 창 안에서 편집이 5회 미만인 경우를 “방치”로 정의했다. 전체의 10.0%다. 통제를 걸수록 효과가 커진다. 원시 −3.1pp에서 창 길이 통제 −4.3pp, 계정까지 넣으면 −11.3pp다.

지지

채택은 “후보를 캔버스에 놓는 것”이지 “내 것으로 만드는 것”이 아니다. 자기 내용이 들어가지 않은 컴포넌트는 껍데기로 남고, 작업이 진행되면서 밀려나거나 작업 자체가 멎는다.

같은 계정 안에서 갈린다는 점이 중요하다. 유저 성향으로는 설명되지 않는다.

반박과 한계

“그 세션이 진지하지 않았다”의 대리 아닌가. 부분적으로 방어된다. 세션 편집 300회 이상(과편집)은 계정 내에서 효과가 사라진다(ns). 몰입도 단일 축이라면 그쪽도 양수여야 한다. 또 방치율이 낮은 층(로그인 고빈도)이 오히려 생존률 자체는 낮다.

남은 한계: 항목 단위 귀속이 막혀 있어 이건 “그 컴포넌트를 만졌는가”가 아니라 “그 시간대에 무언가를 만졌는가”다.
통제 수준별 방치의 생존 손실. 통제가 강해질수록 효과가 커진다
채택 이후

임계는 60초다

효과증거 강H12

채택 후 첫 편집이 60초를 넘기면 생존 −3.8pp · 중단 +3.2pp

방치는 이항 판정이라 처방으로 옮기기 어렵다. 첫 편집까지의 지연을 연속형으로 재니 60초에 꺾인다. 30초 안에 손댄 경우 생존 25.7%, 1-3분이면 19.9%, 3-10분이면 15.9%다.

지지

삽입 직후가 “이걸 쓸지” 판단이 열려 있는 유일한 구간이다. 그 안에 자기 내용이 들어가면 그때부터는 자기 것이고, 넘기면 캔버스 위의 남의 물건으로 남는다.

반박과 한계

지연이 긴 케이스는 유저가 자리를 비운 세션일 수 있다. 그러면 60초는 개입 임계가 아니라 자리비움 탐지선이다.

다만 3-10분 구간에서 15.9%까지 떨어졌다가 10분 이상에서 24.6%로 되돌아오는 비단조성이 있어 자리비움만으로는 설명되지 않는다. 마지막 두 구간이 n=182·57로 작아 확정하지 못한다.
채택 후 첫 편집까지 걸린 시간별 생존률과 작업 중단률
채택 이후

고칠 게 너무 많으면 디자인은 남고 컴포넌트만 빠진다

효과증거 강H24

채택 후 편집량과 생존은 역U자다. 5-19회에서 31.0%로 최고, 60회 이상이면 18.8%로 반토막

채택한 다음 그 작업을 얼마나 고쳤는지로 나눈 결과다. 양 끝이 모두 나쁜데 나빠지는 방식이 다르다.

거의 안 고치면(5회 미만) 작업 자체가 중단된다(36.1%). 반대로 많이 고치면(60회 이상) 디자인은 다운로드까지 가지만(83.7%) 우리 컴포넌트는 남지 않는다(생존 18.8%). 고칠 게 너무 많다는 것은 애초에 맞는 것을 주지 못했다는 뜻이다.

지지

두 실패가 서로 다른 원인을 가리킨다는 것이 이 그림의 핵심이다. 왼쪽 끝은 착수 실패(H11·H12와 같은 이야기), 오른쪽 끝은 적합 실패다. 오른쪽 끝에서 다운로드율이 가장 높다는 것이 결정적이다. 유저는 포기하지 않았고, 우리 것만 버렸다.

반박과 한계

편집 횟수는 그 작업의 크기에 비례한다. 페이지가 많고 복잡한 디자인은 자연히 편집이 많고, 그런 디자인에서 특정 컴포넌트 하나가 남을 확률은 원래 낮다.

또 편집 귀속이 항목 단위로 되지 않으므로 여기 세는 편집은 그 컴포넌트에 대한 편집이 아니라 그 시간대의 편집이다. 작업 규모를 층으로 넣은 재검증이 필요하고, 아직 하지 않았다.
채택 직후 귀속 창 안의 편집 횟수별 · 검색 10,404건
유저·세션 맥락

첫 검색이 실패해 첫날 채택을 잃은 계정도 비슷하게 돌아온다

NEW 10차가설증거 중H42

검색 장애로 첫 요청이 실패한 신규 계정은 첫날 채택이 −29.5pp · 14일 재방문 차는 −0.8pp(±6.4) · 첫 채택 1건의 재방문 효과는 −19 – +24pp로 판별 불가

어떻게 쟀나 — 첫 채택 성공과 재방문은 같은 유저 성향이 함께 만든다(3차에서 선택편의로 기각). 그래서 계정이 고르지 않은 실패를 도구로 썼다. 검색 요청 로그의 실패 구간(7/6 주 · 8/26–27 장애)에 처음 온 계정 중 첫 요청이 실패한 155 계정과, 같은 구간 · 같은 시간대에 성공한 1,051 계정을 비교했다.

실패는 첫날 채택을 크게 떨어뜨렸다(−29.5pp, 두 구간 모두 약 −24pp). 그런데 14일 안에 다른 날 다시 요청한 비율은 거의 같았다. 첫날 채택을 30pp 잃은 계정이 재방문을 1pp도 잃지 않았다면, 첫 채택 성공이 재방문을 크게 끌어올린다는 경로는 이 데이터와 맞지 않는다.

지지

유효 컴포넌트의 가치는 그 세션의 채택·다운로드에서 재야 한다. 「좋은 컴포넌트 → 재방문 → 장기 성장」을 공급 기준의 근거로 쓰기는 이르다. 따로 본 기술 통계에서도 이미지 있는 컴포넌트로 시작한 계정이 30일 재방문이 4.8pp 낮았다(z −2.4, 코호트 한쪽만 유의) — 첫 채택 속성과 재방문의 관계는 방향부터 불안정하다.

반박과 한계

실패 계정이 155개뿐이라 효과 범위가 넓다 — 20pp 넘는 효과만 배제된다. 실패 요청은 입력 원문이 비어 있어 두 군의 요구를 비교하지 못했다. 재방문은 이 기능의 재요청만 센다(서비스 전체 방문 아님). 계획상 30일 창이 쌓이는 10월 중순보다 이르게 쟀다.
같은 구간 · 같은 시간대 · 신규 계정 · 7/6 주와 8/26–27 실패 구간
방법

종류 · 증거 등급 · 거친 관문

전부 같은 무게로 읽으면 사고가 난다. 장마다 종류를 먼저 가르고, 효과·가설에는 통과한 관문으로 등급을 매겼다.

증거 등급이 뜻하는 것

실측 수치 자체가 결론 · 효과 통제·반박을 거쳐 남은 차이 · 가설 차이는 보이나 원인은 추정 · 기각 세웠다가 무너진 것 · 제안 다음 실험. 등급은 효과·가설에만 붙는다. NEW 이번 회차에 새로 들어온 장·행(매 회차 갱신) · 갱신 이번 회차에 판정이 바뀐 장.

증거 강계정 내 또는 검색 내 고정효과 통과 + 8월·9월 재현
증거 중층화 통제 통과, 고정효과 미적용 또는 검사 불가
증거 약통제는 걸었으나 반박이 살아 있다
판별 보류측정 자체가 불안정해 결론을 낼 수 없다

거친 관문

  1. 세그먼트 39종 × 결과 10종 주효과 스크린
  2. 처치 20종 × 세그먼트 16종 × 결과 4종 효과 이질성
  3. 길이·줄수·라우트·기기·월 층화 Mantel-Haenszel
  4. Greenland-Robins 정식 분산 + 8월/9월 분리 재현
  5. 계정 고정효과 · 같은 계정 안에 처치·대조가 모두 있는 경우만

5관문에서 살아남은 것만 「강」이다. 4번에서 z가 10배 부풀었던 적이 있어 분산식을 다시 세웠고, 5번에서 후보의 절반이 무너졌다.

한계

이 문서가 말할 수 없는 것

이 문서의 장들은 결론이 아니다. 무엇을 못 하는지 아래에 적는다.

이 문서가 말할 수 없는 것

  • 인과가 아니다. A/B 테스트 컬럼의 채움률이 0%라 무작위 배정 근거가 없다. 전부 관측 데이터 위의 통제된 비교다
  • 컴포넌트 품질은 직접 재지 않았다. 잰 것은 이미지·장식·분할 같은 구성이고, 품질은 템플릿의 다른 컴포넌트 채택률로 대리했을 뿐이다(H30)
  • 무엇에 졌는지는 다음 행동으로만 안다. 9/1부터 채택 뒤 같은 디자인에서 한 일을 요소 단위로 볼 수 있지만(H41), 「대체」와 「추가」를 아직 가르지 못한다
  • 9/1 이전 편집은 항목 단위로 귀속되지 않는다. 채택 이후 장들(H11·H12·H24)의 결론은 “그 컴포넌트를 만졌다”가 아니라 “그 시간대에 무언가를 만졌다”이다. 9/1부터는 요소 id로 이어진다(12차에서 다시 쓴다)
  • 관측 창이 장마다 다르다(가장 넓게 5/1–9/13). 계절성·기능 릴리스 주기를 넘어서는 안정성은 확인하지 못했다. 8–10차는 계획한 적재 기간보다 이르게 쟀다
  • 재방문과 장기 성장은 말하지 못한다. 첫 채택 성공의 재방문 효과는 범위가 넓어 판별되지 않았다(H42)
  • 다운로드본의 컴포넌트 기록은 일부 디자인에만 있다. 채택이 있는 다운로드 디자인의 36%에만 기록 행이 있어, 컴포넌트 단위 잔존은 같은 디자인 안 비교로만 쓴다

8/11 릴리스 이후 채택률이 5.7pp 떨어졌다. 경보이지 결론이 아니다

길이·줄수·라우트 통제 후 8/12-8/23 채택 41.1% vs 8/1-8/11 45.7%(z=−7.3). 그런데 같은 날 세 가지가 동시에 바뀌었다. 입력가이드 팝오버 자동 노출 중단, 외부데이터 붙여넣기 넛지 도입, 최근 시각화 출시. 일 검색량도 367 → 946으로 뛰었다(로깅 확대 가능성). 단일 처치로 분해되지 않아 인과 결론으로 쓰지 않는다.

1 / 44