Day 14 — 184명 독자, 평균 읽는 시간 3:21, 신규 팔로워 0명, 판매 0건
Source: Dev.to
번역을 진행하려면 번역하고자 하는 전체 텍스트를 제공해 주세요. 텍스트를 주시면 요청하신 대로 한국어로 번역해 드리겠습니다.
Metric (last 7 days)
| 지표 | 수 |
|---|---|
| 독자 | 184 |
| 평균 읽는 시간 | 3:21 |
| 반응 | 1 (고유 사용자 1명으로부터) |
| 댓글 | 2 |
| 북마크 | 0 |
| 새 팔로워 | 0 |
| dev.to 내부 알고리즘 트래픽 | 2 조회 |
| bing.com SEO 트래픽 | 30 조회 |
| 외부 리퍼러 | 152 조회 |
184명의 독자가 각각 3분 21초씩 읽었다는 것은 보이지 않음이 아니라, 내가 쓴 글에 총 약 10시간의 주의가 집중된 것입니다. 하지만 전환은 거의 없습니다: 팔로우도, 북마크도, dev.to에서 추적된 판매도 없습니다.
내가 기대했던 것 vs 실제 상황
나는 병목 현상이 발견 가능성이라고 가정했다. 더 많은 글을 작성하고, 태그를 넓히고, Hashnode와 Reddit에 교차 게시하고, 알고리즘이 하나를 선택하길 바랐다. 데이터는 발견 가능성이 병목이 아니라는 것을 보여준다. dev.to의 내부 피드가 7일 동안 2번의 방문을 보냈다 — 알고리즘은 이미 결정을 내렸다. 184명의 독자는 전혀 다른 곳에서 온다:
- 152 외부 리퍼러 — GitHub README 링크, gist, GitHub Topics 페이지 항목, Apify Store 목록
- 30 bing.com — 특정 기술 문구에 대한 SEO 인덱싱 (“refresh-token-only OAuth Apify Actor”, “per-feature KVS quota”)
- 2 dev.to 내부 — 사실상 없음
즉, 글은 신뢰성 표면으로서 역할을 하고 있다 (누군가 GitHub 저장소에 들어가 dev.to 시리즈의 16개 빌드‑로그 포스트를 보고 이것이 실제라고 판단한다). 하지만 발견 표면으로서는 역할을 하지 못한다 (dev.to 알고리즘이 내 포스트를 누구의 피드에도 밀어넣지 않는다).
내가 잘못 이해한 부분
나는 내 시간을 dev.to가 복리 효과를 낼 것처럼 가격을 매겼다 — 13개의 글을 쓰고, 14번째가 배포되고, 15번째가 배포되고, 눈덩이처럼. 데이터는 그렇지 않다. 각 글은 이미 레포를 알고 있던 사람에게 한 번의 인바운드일 뿐이다. 184명의 독자는 184명의 새로운 잠재고객이 아니라, 같은 겹치는 GitHub 방문자 풀에서 클릭해 읽은 184번의 방문이다.
즉, 내가 더 일찍 물어야 했던 질문은: 내 실제 타깃 독자가 GitHub 레포를 어떻게 발견하게 되는가? “dev.to 알고리즘의 사랑을 어떻게 더 얻을까”가 아니다. 다른 문제, 다른 퍼널, 다른 레버이다.
무엇이 바뀌나요
dev.to 게시 빈도를 존경할 만한 신호‑공간 수준으로 줄입니다 — 매일이 아니라 할 말이 있을 때만 글을 씁니다. 현재까지 dev.to에서의 결과는 다음과 같습니다:
- 13개의 글이 게시됨
- 1개의 GitHub 스타 획득 (다시 한 번 감사드립니다 @kuerdy)
- 1개의 반응, 2개의 댓글, 팔로워 0명
이것이 현재 상황입니다. 13개의 글 + 주당 184명의 독자가 팔로워 증가 0명으로 이어진다면, 하루에 하나씩 글을 쓰는 속도를 유지한다는 것은 스스로에게 거짓말을 하는 것이겠죠. 14일 차가 이 시리즈의 마지막 일일 게시물이 될 수도 있습니다; 다음 포스트는 실제 신호 변화가 있을 때 작성될 것입니다.
무엇이 행동을 바꾸는가
6시간 CSV 측정 루프가 계속 실행됩니다. Apify Store 키워드 순위(익명, 토큰 인증 개인화 함정 없음)는 실제 방문자가 제품을 찾는지를 실제로 예측하는 상위 지표입니다. 그 숫자가 제가 첫날부터 주시했어야 할 것이며, “오늘 게시했는가”가 아니라는 뜻입니다.
원시 데이터
- 지난 13일간의 모든 배포된 표면, 모든 참여 수치, 모든 감사 결과를 한 요약에:
- 액터 자체: (무료, MIT, 빌드 0.1.36).
Cohort note: u/tino8383 on Indie Hackers 가 동일한 형태를 방금 올렸습니다 — 84명의 방문자, 0명의 판매, 3주. 솔로 런칭에서는 반복되는 패턴이 있습니다: 신뢰성을 확보해 주는 표면은 발견을 돕지 못하고, 측정하기 쉬운 지표(방문자)는 수익을 가져오는 지표(팔로우 / 저장 / 구매)를 예측하지 못합니다. 이 패턴에 해당한다면, 스레드를 읽어볼 가치가 있습니다 — 댓글에서 여러 관점으로 함정을 풀어냅니다.
Build 0.1.38 shipped while writing this:
// reply_metrics output now includes a `priority_band` field on every over‑SLA thread
// HOT (just past SLA), WARM (1.5‑3× over), COLD (3×+, use the news‑grounded `reengage_angle` workflow)
// Summary block returns:
// priority_breakdown: { HOT: 3, WARM: 5, COLD: 12 }그래서 금요일 트리아지는 days_since_last_reply 숫자를 일일이 살펴보는 대신, 한 줄짜리 긴급도 구분으로 시작합니다. 16/16 테스트가 통과했습니다. 변경 로그: