Time to Value ／ チーム共有版
TTV ── お客さんが nanco に登録してから、
「在庫が動いた！」と実感するまでの時間
PLG（Product-Led Growth）戦略の中核 KPI です。 この時間が短ければ短いほど、 24時間以内に活性化する人が増え、 結果として有料化率と継続率が上がります。 nanco の現在の数字、 どこで詰まっているか、 何を直すべきかを、 PdM・エンジ・マーケ・デザイナーが同じ理解になるように整理しました。
TL;DR TTV 中央値 11 分 / 24h 活性化率 34.8%。 9 ステップファネルで 3 つのボトルネック（OB-1 サインアップ後 / OB-2 初期登録 / OB-3 招待）。
TTV の定義
nanco における TTV は次の式で計測しています。
Formula
10_register→30_update_count の経過時間
10_register = サインアップ完了。 30_update_count = 初めて在庫の数を動かした瞬間（クイック・ウィン）。 つまり「登録してから、初めて在庫が動いた！と実感するまでの中央値」を TTV と呼んでいます。 集計期間は直近30日コホート。
TTV が短いと、その後の数字すべてが伸びる
短い TTV は活性化率を上げ、 活性化率はリテンションを上げ、 リテンションは LTV を上げる。 PLG の連鎖反応の最初のスイッチが TTV です。
01
活性化率の天井を決める
登録から 24時間以内に「価値」を体験しないと、 多くの人は二度と戻りません（PLG提案書の文献データ）。 TTV が長いと、 24h 以内の体験に間に合わない人が増えます。
02
広告 ROI を直接動かす
広告で連れてきた人が活性化しなければ、 CPA を回収できません。 Traction の SEM が成立する前提として、 PLG の活性化率（=TTV 短縮の結果）が必要です。
03
プロダクト品質の指標になる
TTV はオンボーディング、 UI、 用語、 初期データの 4つすべての品質を1つの数字で表します。 改善のレバーが多く、 小さな修正の積み重ねで動かせます。
現状（2026-04-28 計測）
直近30日コホート（2026-03-28 〜 04-27 にサインアップした 23人）。 nanco-analytics の改善版 ttv_metrics.py による計測です。
TTV 中央値
約11分
655秒。 PLG 目標 3分以内の 3.6倍。 ここを 70% 短縮するのが 12ヶ月目標。
活性化率（コホート期間内）
39.1%
23人中 9人。 これ自体は悪くないが、 Mobile と Web で大きな差あり。
24h 活性化率
34.8%
7日活性化率と同じ。 24時間以内に動かなかった人は 7日経っても戻ってきません。
真の最大離脱点
-74%
登録（23人） → 初回アイテム追加（6人）で 17人脱落。 ここが現状最大の壁。
この数字をどう読むか
登録した 23人のうち、 9人が活性化（39.1%）、 そのうちのほぼ全員が 24時間以内に活性化（34.8% = 8人前後）。 つまり「24時間以内に動くか、二度と戻らないか」の二択になっています。 TTV を短縮できれば、 この境界線をもっと多くの人が超えられるはずです。
9ステップの詳細ファネル
改善版 ttv_metrics.py で workspace 作成の中間ステップまで含めて見えるようになりました。 「真の最大離脱点」を視覚化します。
セグメント別の差
同じオンボでも、 デバイスとロールによって結果が大きく違います。 母数は小さいので、 90日コホートで再確認する前提です。
Device 別
Mobile TTV 中央値 3.4分、 Web TTV 中央値 24.9分。 Web のほうが時間はかかるが、 最後まで残る人の率が高い。
Role 別
招待されたメンバーは 0%。 母数 2人と少ないが、 仮説: Owner が既にアイテムを登録している環境に入るため、 自分で追加する動機が薄い。
この計測から見えた 3つの発見
特に重要な発見を絞っています。 それぞれが別の施策につながります。
FINDING 01
「24時間で勝負が決まる」── 7日経っても戻ってこない
24時間活性化率（34.8%）と 7日活性化率（34.8%）が完全に同じ。 つまり、 サインアップから 24時間以内に初回入出庫まで到達しなかった人は、 1週間経っても戻ってきません。 PLG 提案書 03章で言及されている文献データ「サインアップユーザーの 40〜60% は一度も再訪しない」とほぼ一致しています。 オンボメール B（利用ガイド）の配信タイミングを 24時間以内に前倒しすべき強い根拠になります。
FINDING 02
真の最大離脱点は「登録 → 初回アイテム追加」 ── ここで 74% が脱落
サインアップ完了（23人） → 初回アイテム追加（6人）で 17人脱落（-74%）。 ファネルの中で群を抜いて大きな壁です。 ワークスペース作成までは 91% が進むので、 詰まっているのは「ワークスペースができた後に、 自分の在庫を入れ始める」その瞬間。 ここを エンプティステート ／ ウェルカム ／ 3ステップツアーで受け止めるのが、 Phase 3+ プロダクトバンパーの最優先実装です。
FINDING 03
意外: Web の活性化率（57.1%）が Mobile（31.3%）の約 2倍
直感とは逆の結果。 Mobile の方が触りやすいはずなのに、 活性化率は半分以下です。 仮説: Mobile は触りやすい分「ちょっと触って戻る人」が多く、 Web は PC を開く手間がある分、 動機が強い人だけが残る。 ただし母数が Web 7人 / Mobile 16人 と少ないため、 90日コホートで再確認する必要があります。 もし傾向が確かなら、 Mobile のオンボ動線を Web 並みに磨き直すレバーが見えてきます。
目標値の段階
PLG 戦略書で姉崎判断済みの段階目標です。 「今」と「3ヶ月後」のギャップが、 5月から動かす施策の出力指標になります。
| 指標 | 現状（2026-04） | 3ヶ月（7月末） | 9ヶ月（来年1月） | 12ヶ月（2027年4月） |
|---|---|---|---|---|
| TTV 中央値 | 約11分 | 3分以内 | Phase 0 比 50% 短縮 | 70% 短縮 |
| 24h 活性化率 | 34.8% | 50% 以上 | ─ | 60% 以上 |
| 無料 → 有料 CVR | TBD | +30% | ─ | +100% |
| 月次チャーン率 | TBD | 維持 | ─ | 5% 以下 |
改善施策 ／ プロダクトバンパー
Phase 3+（6月下旬 〜 9月）で実装する 6種類のバンパー。 ICE 優先順（Impact / Confidence / Ease の合算）で並べています。 一番上から順に着手します。
エンプティステート
アイテム 0個のとき、 リスト画面の中央に「最初のアイテムを追加しましょう」を大きく表示。 真の最大離脱点（-74%）を直接受け止める。
ウェルカムメッセージ
初回ログイン時の歓迎ダイアログ。 「最初の 1分でやること」を 1文で示す。
プログレスバー
オンボの 3ステップを「1/3 完了」のように可視化。 「あと少しで価値体験」を伝える。
チェックリスト
「フォルダを作る」「アイテムを 1つ入れる」「数を動かす」の 3項目チェックリストを画面右下に常駐。
プロダクトツアー
3ステップのガイド付きツアー。 スキップ可能、 戻れる。
ツールチップ
主要 UI 要素にホバー or タップで説明。 専用機能（バーコードスキャン等）の発見性を上げる。
招待メンバー（Path D）専用フロー
FINDING 03 と紐づき、 招待メンバー（Invitee）の活性化 0% を改善するため、 オンボメール v2 の Path D を新設します。 Owner と同じメールでは届かないので、 「あなたが招待されたチームのアイテムを、 まず 1件触ってみましょう」というメッセージに変えます。 Phase 1+ オンボメール v2 設計時に着手。
計測の仕組み
どこから数字が来て、 どこに溜まり、 どこで見るか。 1枚で把握できる状態にしておきます。
Source
nanco-flutter ／ nanco-next
アプリ内で logServerEvent を発火
Collect
PostHog (HogQL)
イベント生ログを保存
Aggregate
nanco-analytics
tasks/timeseries.py で first_update_count_at を永続化（個人別 TTA）
View
dashboard (Next.js)
トップに OnboardingFunnelChart、 ユーザー詳細に KpiCard "TTA (在庫更新まで)"
計測に使っているイベント一覧
| イベント名 | 意味 | Mobile（Flutter） | Web（Next） | TTV での役割 |
|---|---|---|---|---|
10_register |
サインアップ完了 | 発火 | 発火 | TTV の開始点 |
03_submit_otp |
メール認証 | 発火 | 発火 | SSO 等で経由しない仕様（ノイズ扱い） |
20_create_workspace |
ワークスペース作成 | 発火 | 発火 | ファネル中盤 |
30_item_add |
初回アイテム追加 | 発火 | 発火（2026-04-28 追加） | 真の最大離脱点 |
30_update_count |
初回入出庫記録 | 発火 | 発火 | TTV の終了点 = クイック・ウィン |
30_barcode_scanned |
バーコードスキャン | 発火（2026-04-28 追加、3画面） | Web 版にスキャン機能なし | クイック・ウィン昇格候補 |
2026-04-28 の発見と訂正
当初の調査では「nanco-next では機能イベントが発火されていない」と誤判定していました。 再調査の結果、 30_update_count は既に nanco-next で発火されており、 不足していたのは 30_item_add だけ（同日に追加実装）。 また 30_barcode_scanned を nanco-flutter の 3つのスキャン画面（qr_scan / check_qr_scan / item_barcode_scan）に新設しました。 これでクイック・ウィン定義をより精緻にできる状態になっています。
2026-05-11 確認: TTV ＝ TTA（用語が違うだけで完全に同じ指標）
この日の点検で、 nanco-analytics 側は flows/ttv_metrics.py ではなく TTA (Time to Activation) という名前で完全実装済みであることが判明しました。 個人別 TTA は tasks/timeseries.py 内で first_update_count_at として永続化されており（一度計算されたら上書きされない設計）、 ダッシュボードのトップ dashboard/app/page.tsx の OnboardingFunnelChart でファネル / コホート / タイミング（ステップ別 median）の 3ビューが既に見られます。 ユーザー詳細ページにも KpiCard label="TTA (在庫更新まで)" で個人別が表示されています（NANCO-698）。
つまり nanco-knowledge では TTV (Time to Value)、 nanco-analytics では TTA (Time to Activation) と呼ばれていますが、 定義は完全に同じです（登録から最初の 30_update_count までの時間）。 次のアクション: (1) ダッシュボードを起動して 5/11 時点の最新数字を見る（ cd nanco-analytics/dashboard && npm run dev ）、 (2) baseline-2026-04 と nanco-knowledge の表記に「TTA = TTV」と注記 or 用語統一の姉崎判断。
チーム別の動き方
TTV を 11分 → 3分にするために、 誰が何をやるかを役割別に整理します。 すべての施策は ICE 優先順で並べた Phase 3+ プロダクトバンパー実装に紐づきます。
PdM ／ 姉崎
- TTV / TTA の用語統一を判断（baseline-2026-04 を TTA に揃えるか、 nanco-knowledge 側に注記を入れるか）── 今週中
- 毎月のトリプル A スプリント主導（4時間 ／ 月、 死守）
- 6種類のバンパーを ICE 優先順で並べ替えする責任
- 90日コホートで再計測する判断（Web の高活性化率の確認）
- 招待メンバー Path D の文面ディレクション
エンジニア
- TTA コホート別 median が dashboard で見られるか確認 ── 既存
OnboardingFunnelChartの timing ビューで足りるか、 追加実装が必要か判断（今週中） - Phase 3+ プロダクトバンパー実装（6月下旬 〜 9月、 上から順）
- エンプティステート（最初に着手、 真の最大離脱点を直接受け止める）
- 必要なら dashboard に TTA 月次サマリーセクションを追加（Mobile vs Web / Owner vs Invitee の cohort median）
- 新規イベント追加時の発火確認（PostHog で 1スキャン 1イベント、 デバウンス済み）
デザイナー
- エンプティステートの UI 設計（テキスト + イラスト + CTA）
- ウェルカムメッセージの文面とレイアウト（消費者アプリ並みの体験）
- プログレスバーとチェックリストの統合 UI（重複しないよう）
- オンボの 10ステップ仕分け（緑/黄/赤）の入力をフロー再設計に反映
マーケ ／ 深石
- オンボメール v2（3トラック × 7通）の設計と配信
- 24時間以内のメール配信前倒し（B / E メール）
- 招待メンバー Path D の新設（活性化 0% への対処）
- 月次レビュー時に TTV と CVR の連動を analyst（agent）と確認
来週から動かせる Quick Win（30分 〜 1時間）
大きなバンパー実装を待たずに今すぐ動かせるもの: (1) オンボメール B / E の配信タイミングを 24時間以内に前倒す設定変更、 (2) 既存ユーザーへの「料金ページ 5秒テスト」3人実施、 (3) 90日コホートで make run-ttv 再実行（Mobile / Web の差を確認）。 どれもエンジ大規模実装を待たずに進められます。