A1GROWTH ／ 社内ドラフト
日経 HeatUX｜KPI設計と計測要件
提案書（2026/9/10版）と9/22の柴田さんとの打合せを踏まえ、①KGI・KPIの定義と計算式、②それをどう計測するか、③9/28に先方へ確認すべきことを整理しました。
結論として、いま最優先で潰すべきは「成果保有率の分母」「集計時点」「日経IDハッシュのログ実装」の3つです。計測は後から足せないため、10月中旬が実質のタイムリミットになります。
SECTION 01KPIツリー
事業KGIと体験KGIを、1本の行動指標（ブースチェックイン）でつなぐ
KGIは提案書どおり2つ置きます。ただし両者は別々のものではなく、同じ1つの行動（ブースチェックイン）から生まれます。来場者は出展社のためにQRを出すのではなく、自分の記録を残すために出す。その副産物として、出展社に返せるデータが貯まる。この構造がツリーの背骨です。
タップすると原寸（3400×2520px）で開きます。スマートフォンではピンチで拡大してご覧ください。／ ベクター版（SVG）
体験KGI（North Star Metric）
観測窓：会期初日 〜 会期最終日+14日。分母は次のセクションで決めます。
事業KGI
ただし、この数字が動くのは2027年3月の日経メッセ以降です。A1グロースの契約は2026年12月までのため、契約期間内の評価は別建てにする必要があります。Phase1〜2でコミットする条件として、以下の3つを提案します。
- 計測要件がベンダー実装に反映され、エコプロで実際にログが取れたこと
- エコプロでT1・T2別の基準値が全KPIで埋まったこと
- 日経メッセ向けの目標水準を1月に合意できる状態になったこと
SECTION 02成果保有率の分母をどう置くか
提案書内で定義が2種類あり、かつ未決。「展示会に来場した人に限定して分析したい」という論点への回答
提案書p.27では「アプリ起動者」、p.32では「ログイン者」と、同じ指標に2つの分母が書かれています。ここを先に確定しないと、同じ指標名で違う数字が出回ります。候補を6つ並べて比較しました。
← 横にスクロールできます
| 分母候補 | 取得可否 | T1/T2で割れるか | 評価 | 使い方 |
|---|---|---|---|---|
| 来場登録者 | ◎ | ◎ | No-show（登録したが来場しなかった人）が分母に入る。展示会のNo-showは一般に2〜4割あり、アプリと無関係な要因で率が上下する | 獲得ファネルの最上段としてのみ |
| 実来場者（入場ログあり） | 要確認 | ◎ | 「来た人のうち何%が手ぶらで帰らなかったか」が言える。No-showの影響を除去でき、事業側への説明力が最も高い | ★KGIの分母の第一候補 |
| アプリDL者 | ✗ | ✗ | ストアの数字は集計値のみで個人にも経路にも紐づかない | 使わない（実数を参考値で見るのみ） |
| 初回起動者 | ◎ | △ | DLの実質的な代理指標。ただしログイン前はIDがなくT1/T2に割れない | DL到達率の分子として |
| ログイン者 | ◎ | ◎ | 転換率の改善に直結し施策のPDCAを回しやすい。ただし「アプリの中だけの話」になり事業側への説明力が弱い | 施策改善用の分母 |
| 当日起動者 | ◎ | ◎ | 分母が最も小さく、改善の余地が見えにくい | ガードレールとしてのみ |
推奨：分母は1つに絞らず「2本立て」で出す
分子は同一・分母だけ2種類にすることで、「アプリを配れていない問題」と「アプリが使われていない問題」を切り分けられます。対外・社内説明はK1-A、週次のPDCAはK1-Bを見る、という使い分けです。
前提条件：K1-Aには受付の入場スキャンログを個人単位で取得できることが必要です（ヒアリング B-07）。取れない場合はK1-Aを来場登録者ベースに落とし、No-show率を別途注記する運用にします。
SECTION 03集計時点（観測窓）の定義
「いつ時点の数字か」を先に決めないと、同じ指標で違う数字が出回る
提案書の「成果物を1件以上持って退場した人」という定義には矛盾があります。AIレポート生成を促す通知はT1が会期3日目、T2が翌日。つまり成果物は退場した時点ではなく会期後に発生します。窓を明示的に定義します。
← 横にスクロールできます
| 指標グループ | 集計開始 | 集計締め | この窓にする理由 |
|---|---|---|---|
| 獲得（DL到達率・ログイン率） | 登録受付開始日 | 会期最終日 24:00 | 会期後のDLは獲得施策の成果ではない |
| 利用の質（チェックイン・メモ） | 会期初日 00:00 | 会期最終日 24:00 | 当日行動のため会期内で閉じる |
| 成果保有（L2・KGI） | 会期初日 00:00 | 会期最終日 +14日 | T1=会期3日目／T2=翌日の通知からの生成ラグを拾い切る |
| 資産活用（L3・書き出し） | 会期初日 00:00 | 会期最終日 +14日 | 同上 |
| 会期後再アクセス | 会期最終日 +1日 | 会期最終日 +7日 | 提案書の定義どおり |
| 出展社アンケート | 会期最終日 +3日 | 会期最終日 +21日 | 会期直後は出展社が繁忙。3日空けて3週間で締める |
暫定値と確定値の運用ルール
- すべてのレポート・シートに必ず「as of YYYY-MM-DD」を明記する
- 成果保有率は会期中も日次で出すが、確定日までは「暫定」と明示する
- 確定値が出たあとに遡って数字を書き換えない。確定値は別列に持つ
- エコプロ（12/2-4）の確定日は12月18日。ここで出す基準値が日経メッセの目標設定の土台になる
SECTION 04成果物の3階層（L1／L2／L3）
「成果物1件以上」のままでは緩すぎて、施策の良し悪しが指標に出ない
資料DL1件でも成果保有にカウントすると、ログインした人はほぼ全員が達成してしまいます。逆にAIレポート生成だけに絞ると厳しすぎて、母数の小さいエコプロでは差が読めません。3階層に分けます。
L1 ── 記録が残った
ブースチェックイン ≧1。前提条件であり、ここが0なら以降はすべて0になります。
L2 ── 持ち帰れる形になった ★NSMの分子
AIレポート生成 ≧1 または 資料DL ≧1。測定が確実で、かつ施策の差が出る粒度。
L3 ── 社内に出た／戻ってきた
PDF書き出し・共有、または会期後7日以内の再アクセス。柴田さんが本命とおっしゃった「社内にレポートを共有した人」に最も近い階層で、事業KGIへの橋になります。
なぜNSMをL3にしないのか
本来の価値の瞬間はL3です。ただし共有はアプリの外で起きるため完全には測れません（OS標準の共有シート経由だと共有先が取得できない可能性があります）。そこで、確実に測れるL2をNSMに置き、L3は「PDF書き出し率」で代理観測する二段構えにします。
SECTION 05計測アーキテクチャと最大の技術リスク
全指標を「日経IDのハッシュ値」1本で突合する
データソースの構成
- 来場登録データ（NEON等）── T1/T2判定フラグ・属性・登録日時・経路
- 入場スキャンログ── 実来場者の特定（分母の確定に必要）
- アプリ行動ログ（Firebase → BigQuery）── 起動・ログイン・画面遷移
- アプリ業務DB── チェックイン・ブックマーク・資料DL・レポート生成・PDF書き出し
- メール／プッシュ配信ログ── 配信・開封・クリック・許諾
- 会期後アンケート── 出展社の成果実感率・次回出展意向率
最優先の実装要件
Firebase単体では「誰が」が追えません。ログイン時に nikkei_id_hash と target_segment を user property としてセットしてもらうことが必須です。これが入らないと全指標をT1/T2に割れず、提案の骨子そのものが成立しません。
あわせて、A1グロース側は生の日経ID・氏名・メールアドレスを持たない設計を提案します。個人情報の委託範囲を最小化することで、先方の稟議も通りやすく、こちらの運用制約も減ります。
⚠ 最大の技術リスク：「経路別DL率」は素直には測れない
App Store Connect / Google Play Console のインストール数は集計値のみで、個人にも経路にも紐づきません。Firebase Dynamic Links も2025年にサービス終了済みです。つまり提案書の「登録者DL率」「メール経由DL率」「出展社別QR経由DL数」は、このままでは取得できません。
← 横にスクロールできます
| 案 | 方法 | 精度／コスト | 判断 |
|---|---|---|---|
| A | 山場ごとに ?src= 付きの中間LPを挟み、LP到達数を分母にする | 中／小 | 第一候補（全経路） |
| B | 計測SDK（AppsFlyer / Adjust等）で deferred deeplink を使う | 高／中〜大 | 別途契約・費用。費用対効果次第 |
| C | QR／リンクごとにワンタイムトークンを発行し、初回ログイン時にアプリへ引き渡す | 高／中 | 出展社別QRを測るなら必須 |
| D | 経路別は諦め、日次DL数の時系列と施策実施日を重ねて間接評価 | 低／0 | 最終手段 |
推奨：案A（全経路）＋ 案C（出展社別QRのみ）。あわせて「登録者DL率」の実運用定義を、インストールではなく初回起動者 ÷ 分母に置き換えることを提案します。
SECTION 069/28 ヒアリング項目
データ観点。◎これが決まらないと計測設計が止まる ○早めに欲しい △持ち帰り可
A. データ基盤・アーキテクチャ
◎アプリの計測は Firebase Analytics で確定か。GA4連携と BigQuery export は有効化されているか
ここが無いとログ分析基盤がゼロから
◎チェックイン・資料DL・レポート生成などの業務データはどのDBに入るか。Firebaseログと業務DBのどちらを正とするか
二重計上・欠損の切り分けができない
◎業務DBから分析基盤への連携は既に設計されているか。頻度は
モニタリングの更新頻度が決まる
○ER図・データディクショナリ・イベント設計書はあるか。無ければA1G側で作成してよいか
無ければ泉が作成する
○開発・UX・データ基盤の各ベンダーはどこか。窓口は誰か。定例はいつか
計測要件の投げ先が決まる
B. 来場登録データと T1/T2 判定・来場実績
◎来場登録フォームの実際の設問・選択肢（来場目的／役職・決裁／行動スタイル）を見せてほしい
T1/T2判定ロジックが本当に組めるか確定させる
◎「行動スタイル（指名型／回遊型）」を問う設問は現状あるか。無ければ追加できるか。締切は
提案の分母そのもの。無いと4象限が成立しない
◎エコプロの来場登録フォームにもT1/T2判定設問を入れられるか。エコプロとメッセでフォーム・基盤は同じか
NoだとPhase2の出口条件（T1・T2別基準値）が成立しない
◎判定フラグをアプリ側・メール配信側・行動ログ側の3箇所すべてに連携できるか
訴求の出し分けと分母の切り分け、両方に必要
◎受付の入場スキャンログを個人単位で取得できるか。登録ID・日経IDと紐づくか。紙QR入場や招待客も同じログに載るか
成果保有率の分母を「実来場者」にできるかの分岐点
○昨年実績（来場登録者数・実来場者数・当日登録比率・招待客比率）とNo-show率
母数試算と有意差の見込み計算に使う
C. 日経ID連携・名寄せ
◎アプリログインは日経IDのみか。日経IDと来場登録レコードは必ず1:1で紐づくか
分母の定義が変わる
◎行動ログに日経IDのハッシュ値を user property として載せられるか。ハッシュ方式は誰が決めるか
最優先の実装要件。これが無いと全指標がT1/T2に割れない
○日経ID側から使える属性は何か（業種・規模・役職・関心テーマ）。出展社レポートに使ってよいか
「来訪者の質の可視化率」が実現できるか
△同一人物の複数端末・再インストール時の名寄せ方針
ユニークユーザー数のブレ幅
D. アプリ機能と計測（現在の設計状況）
◎現時点の設計で、どのアクションがログとして残る想定か。既存イベント一覧をください
不足分だけを追加要求できる
◎計測タグ・カスタムイベントの実装は、いつまでに要件を出せば12月エコプロに間に合うか
逆算スケジュールの起点。全体の締切を決める
◎チェックインは「出展者スキャン」「本人スキャン」の両方か。ログ形式は同じか
共通行動指標の定義が揺れる
○AIレポートの生成トリガー・生成単位・再生成の扱い
L2のカウント方法
○PDF書き出し・共有はアプリ内で完結するか
L3の代理指標として使えるかどうか
○オフライン時のチェックイン一時保存は実装されるか
会場の電波状況によるログ欠損リスク
△ブース滞在時間は取得可能か
出展社レポートの中身が1段深くなる
E. 出展社側データ
○出展社マスタ（出展社ID・カテゴリ・小間番号）はどこにあるか。アプリ側と同一IDか
出展社指標の集計単位
○出展者当日I/F（スキャン端末）のログはどこに溜まるか
リード数の正はどちらか
○出展社別QRを発行できる仕組みはあるか。無ければA1Gで発行してよいか
山場④の計測ができるか
○出展社の資料アップロード状況を率で把握できるか
資料DL数の上限を決める変数
△昨年の出展社数・継続率・出展単価
事業KGIの現在地
F. 配信基盤（メール・プッシュ）
◎メールの配信基盤は何か。A/B配信と判定フラグによるセグメント配信ができるか
提案の柱である「訴求の出し分け」が成立するか
◎開封・クリックのログをA1Gが見られるか（管理画面の権限 or CSV提供）
メール経由DL率が測れるか
○申込完了画面はT1/T2で出し分けられるか
山場①のA/Bの可否
○プッシュ通知の配信基盤は何か。セグメント配信・配信日時指定ができるか
施策3-2（T1は3日目／T2は翌日）が実現できるか
○プッシュ未許諾者への同文メール送付は可能か
許諾率の天井を補える
G. 個人情報・セキュリティ・分析環境 ★稼働工数に直結
◎A1G側が触れるデータの範囲はどこまでか。ハッシュID＋属性カテゴリ＋行動集計まで、という設計で問題ないか
ここを最小化できれば以降の制約がほぼ消える
◎分析はどの環境で行うか。BigQueryにA1Gのアカウントを発行してもらえるか。専用端末・VDI・常駐の縛りはあるか
縛りが付くと工数が数倍になる。見積り前提が変わる
◎個人データの再委託・取扱いに関する手続き（覚書・NDA範囲・安全管理措置）は何が必要か
12月に間に合わせるには10月中の着手が必要
○生成AIツールの業務利用可否。可の場合、投入してよいデータ種別の線引きは
作業速度と見積り前提が変わる
○出力物（モニタリングシート）の格納先・共有範囲の指定はあるか
BIツールの選定に影響
H. モニタリングの出し方 ／ I. 資料・アクセス権
○日次モニタリングの閲覧者は誰か（事業統括室のみ／各事業部／出展社まで）
粒度と匿名化レベルが決まる
○BIツールの指定はあるか（Looker Studio / Tableau / スプレッドシート）
構築方式
○会期中に当日中の数字が必要か（初日夜の打ち手差し替えに使う）
ストリーミングexportの要否＝コストに影響
◎アプリ概要資料・App Design Figma・App機能差分 Figma・IA Figma の泉宛アクセス権
中身を読まないとイベント設計を実データに寄せられない
◎イベント設計書・計測設計書・ER図（あれば）
A-04と対
○ベンダー定例への参加枠と、コミュニケーションチャネル
計測要件を継続的に差し込むため
SECTION 07未決論点
9/28で潰すもの、10月中に決めるもの
← 横にスクロールできます
| 論点 | 何が問題か | 提案 | 決める人 | 期限 |
|---|---|---|---|---|
| 成果保有率の分母 | 提案書内で2種類。柴田さんも未決 | 2本立て（事業説明用＝実来場者／施策改善用＝ログイン者） | 柴田・貴社 | 10月上旬 |
| 集計時点が未定義 | 「退場した人」だと会期後のレポート生成を拾えない | 成果保有は会期初日〜最終日+14日。日次は暫定値 | 柴田・貴社 | 10月上旬 |
| 経路別DL率が取得不能 | ストアのDL数は集計値のみ | 案A（中間LP）＋案C（出展社別QRはトークン） | 開発ベンダー | 10月中旬 |
| 日経IDハッシュの実装 | 無いと全指標をT1/T2に割れない | ログイン時に user property をセット | 開発ベンダー | 10月中旬 |
| アプリの価値の証明方法 | 「使った人は翌年も来る」は相関であって因果ではない | 属性を揃えた準実験デザイン（完全なランダム化は運用上できない） | 泉 | 11月中旬 |
| エコプロの判定設問 | 入らないとPhase2の出口条件が成立しない | フォーム締切を確認。間に合わなければ属性ベースの簡易推定へ | 貴社 | 9/28 |
| 分析環境と個人情報 | 専用端末・常駐の縛りが付くと工数が数倍 | A1Gは生ID・氏名・メールを持たない設計を提案 | 貴社 | 10月上旬 |
| 出展社アンケートが未設計 | 成果実感率・次回出展意向率はアンケートでしか取れない | 10月中に設問ドラフト。12月の出展社説明で予告 | 泉 | 10月末 |
SECTION 08逆算スケジュール
エコプロ（12/2-4）で基準値を取るところから逆算する
9月28日
先方ヒアリング
◎項目を潰す。その場で答えが出ない項目は「いつまでに誰が回答するか」まで握る
〜10月上旬
KGI/KPI定義の確定
分母・観測窓・L1/L2/L3を合意。あわせて各種アクセス権を受領
〜10月中旬
計測要件書 v1 をベンダーへ
実質のタイムリミット。イベント設計＋user property＋経路計測方式
〜10月末
来場登録フォームの判定設問を確定
エコプロ分の締切に注意。出展社アンケートの設問ドラフトも
〜11月中旬
実装完了・計測QA
テスト端末で全イベントの発火を確認する
〜11月末
モニタリングシート構築
ダミーデータで疎通まで済ませる
12月2〜4日
エコプロ本番（内部テスト）
日次で数字を見て、初日の夜に打ち手を差し替える
12月中旬
エコプロ基準値レポート
確定日は12月18日。日経メッセ向けの改善要件もあわせて提出
この逆算の意味
9/28のヒアリングでA〜Dの◎が埋まらないと、計測要件の提出が後ろ倒しになり、エコプロで基準値が取れません。基準値が取れなければ1月の目標水準も合意できず、Phase3（日経メッセ）の判定基準がないまま本番を迎えることになります。9/28は「聞く場」であると同時に「締切を握る場」です。