A1GROWTH ／ 社内ドラフト

日経 HeatUX｜KPI設計と計測要件

v1・2026年9月22日　／　作成：泉（データ担当）　／　9月28日 先方ヒアリング用

提案書（2026/9/10版）と9/22の柴田さんとの打合せを踏まえ、①KGI・KPIの定義と計算式、②それをどう計測するか、③9/28に先方へ確認すべきことを整理しました。

結論として、いま最優先で潰すべきは「成果保有率の分母」「集計時点」「日経IDハッシュのログ実装」の3つです。計測は後から足せないため、10月中旬が実質のタイムリミットになります。

SECTION 01KPIツリー

来場者側のKPIを、成果保有率を頂点に「率の掛け算」で分解する

今回は来場者側に絞って整理しました。成果保有率は、DL到達率 × ログイン率 × 記録発生率(L1) × 成果転換率(L2) という4つの率の掛け算に分解できます。各段の分母が1つ上の段の分子になっているため、掛け合わせると L2到達者 ÷ 実来場者 に戻ります。施策はすべて、このどれかの項を上げに行くものとして位置づけられます。

ツリーの末端には対応する施策番号を入れてあります。どの施策がどの数字を動かしに行くのかが、この1枚で追えるようにしています。オレンジで囲ったチェックイン転換率だけは、後述のとおり出展社側の価値にも直結する要の行動です。

なぜ「成果保有率」をトップに置くのか

提案書ではKGIを2つ置いていますが、来場者側の頂点をDL率ではなく成果保有率にしている理由は4つあります。

1　アプリの存在理由がそこにある

HeatUXのコンセプトは「持ち帰るのは資料ではなく、ビジネスを動かす次の一手」。T1・T2の「工数を割いたのに何も得られない」「情報はあるが資産化されていない」を解くことが目的です。

提案書 序章・p.27
2　DL率を目標に置くと歪む

入れた人数を増やしても中身は伴いません。提案書自身が「DL率は指標として見るが目標には置かない」とし、ガードレール指標（通過しないと先に進めないが、高めても収益は動かない指標）に分類しています。

提案書 p.11・p.27
3　直近のゴールの定義と一致する

「イベントが終わって終わりではなく、社内に共有できるようなレポートや資料が残る状態にするのが一番のゴール」── つまり来場が徒労に終わらないことを、そのまま率にしたのが成果保有率です。

9/22 柴田さんとの打合せ
4　事業側とつながる行動から生まれる

成果保有はブースチェックインを原資とします。同じ行動が出展社に返すデータになるため、体験KGIを上げる打ち手が、そのまま事業KGIの材料になります。

提案書 p.27 共通の行動指標
日経HeatUX KPIツリー

タップすると原寸（4600×2460px）で開きます。スマートフォンではピンチで拡大してご覧ください。／ ベクター版（SVG）

体験KGI（North Star Metric）

成果保有率 ＝ L2到達者（T1・T2） ÷ 【分母】（T1・T2）

観測窓：会期初日 〜 会期最終日+14日。分母は次のセクションで決めます。

事業KGI

出展料収入 ＝ 出展社数 × 出展単価 × 翌年継続率

ただし、この数字が動くのは2027年3月の日経メッセ以降です。A1グロースの契約は2026年12月までのため、契約期間内の評価は別建てにする必要があります。Phase1〜2でコミットする条件として、以下の3つを提案します。

  • 計測要件がベンダー実装に反映され、エコプロで実際にログが取れたこと
  • エコプロでT1・T2別の基準値が全KPIで埋まったこと
  • 日経メッセ向けの目標水準を1月に合意できる状態になったこと

SECTION 02成果保有率の分母をどう置くか

提案書内で定義が2種類あり、かつ未決。「展示会に来場した人に限定して分析したい」という論点への回答

提案書のなかで同じ指標に2つの分母が書かれています。p.9（戦略の全体像）と p.32（モニタリングシート）は「ログイン者」、p.27（KGI全体像）は「アプリ起動者」。3箇所中2箇所はログイン者なので、提案書の実質的な立場はログイン者です。ここを先に確定しないと、同じ指標名で違う数字が出回ります。候補を6つ並べて比較しました。

なお「実来場者を分母にする」というのは提案書からの変更提案です。柴田さんの「展示会に来場した人に限定して分析できるようにしたい」というご要望を満たすには、提案書の定義のままでは足りません。

← 横にスクロールできます

分母候補取得可否T1/T2で割れるか評価使い方
来場登録者◎◎No-show（登録したが来場しなかった人）が分母に入る。展示会のNo-showは一般に2〜4割あり、アプリと無関係な要因で率が上下する獲得ファネルの最上段としてのみ
実来場者（入場ログあり）要確認◎「来た人のうち何%が手ぶらで帰らなかったか」が言える。No-showの影響を除去でき、事業側への説明力が最も高い★KGIの分母の第一候補
アプリDL者✗✗ストアの数字は集計値のみで個人にも経路にも紐づかない使わない（実数を参考値で見るのみ）
初回起動者◎△DLの実質的な代理指標。ただしログイン前はIDがなくT1/T2に割れないDL到達率の分子として
ログイン者◎◎転換率の改善に直結し施策のPDCAを回しやすい。ただし「アプリの中だけの話」になり事業側への説明力が弱い施策改善用の分母
当日起動者◎◎分母が最も小さく、改善の余地が見えにくいガードレールとしてのみ

推奨：分母は1つに絞らず「2本立て」で出す

K1-A 事業説明用　成果保有率 ＝ L2到達者 ÷ 実来場者（T1・T2）
K1-B 施策改善用　成果保有率 ＝ L2到達者 ÷ ログイン者（T1・T2）

分子は同一・分母だけ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 04L1・L2・L3の関係

3つは並列の指標ではなく、同じ人が「どこまで進んだか」の段階

提案書の「成果物を1件以上持って退場した人」という定義のままでは、資料DL1件でもカウントされてしまい、ログインした人はほぼ全員が達成します。それでは施策の良し悪しが指標に出ません。逆にAIレポート生成だけに絞ると厳しすぎて、母数の小さいエコプロでは差が読めません。そこで3段階に分けます。

重要なのは、L1・L2・L3が別々の指標ではないことです。同じ人が順に通過していく段階で、L3に到達した人は必ずL2もL1も通っています。そして各「率」は、隣り合う段の人数の比にすぎません。

実来場者（T1・T2）入場ログあり ── KGIの分母
DL到達率 × ログイン率
ログイン者日経IDでログイン
記録発生率（L1）
L1　記録が残ったブースチェックイン ≧1
成果転換率（L2）
L2　持ち帰れる形になった　★NSMの分子AIレポート生成 ≧1 または 資料DL ≧1
資産活用率（L3）
L3　社内に出た／戻ってきたPDF書き出し・共有 または 会期後7日以内の再アクセス
成果保有率（NSM）＝ 実来場者 〜 L2 までの区間。 つまり L2到達者 ÷ 実来場者 です。SECTION 01 の掛け算（DL到達率 × ログイン率 × 記録発生率 × 成果転換率）は、この区間を段ごとに分解したものです。L3は掛け算に含まれません。

提案書との差分：L2の分子から「履歴」を外しています

提案書 p.27・p.32 の定義は「AIレポートや資料・履歴を持ち帰った割合」です。ただし履歴（タイムライン）はチェックインすれば自動で貯まるため、これを分子に入れるとL2がL1とほぼ同義になり、段を分けた意味が消えます。

そこでL2の分子は、来場者が能動的に起こす行動（AIレポート生成・資料DL）に限定しました。これは提案書からの明示的な変更なので、先方合意が必要です（未決論点 I-12）。履歴はL1の確認用に別途モニタリングします。

演算子の意味（ここを外すと数式として成立しない）

  • ＋＝排反な経路の和。同じ人が2つの経路で同時にDLすることはない（初回起動を1経路に帰属させる前提）
  • ×＝段の積。各段の分母が1つ上の段の分子になっているときだけ成立する
  • または＝和集合。AIレポート生成と資料DLは同じ人が両方やりうるため、＋ではなく重複を除いて数える

同じ理由で、ブックマーク率は掛け算の因数に入れていません。ブックマークしていない人もチェックインするため、ブックマーク率 × チェックイン率 では記録発生率(L1)になりません。先行指標として横に置いています。

なぜNSMをL3で切らないのか

本来の価値の瞬間はL3です。柴田さんが本命とおっしゃった「社内にレポートを共有した人」はまさにここにあたります。それでもNSMをL2で切るのは、共有がアプリの外で起きるため完全には測れないからです（OS標準の共有シート経由だと共有先が取得できない可能性があります。ヒアリング D-05 で確認します）。

測れない指標を目標に置くと、達成判定ができないまま会期が終わります。そこで確実に測れるL2をNSMに置き、L3は「PDF書き出し率」で代理観測する二段構えにします。L3は目標ではなく、L2が本物だったかを確かめる検証用の指標という位置づけです。

L3のその先：翌年再登録率

L3まで到達した人が翌年も来場するか。ここをアプリ利用者と非利用者で層別比較することが、アプリの価値そのものを検証する唯一の準実験デザインになります。他事業部への横展開はこの数字で説得することになるため、設計は11月中に固めます（未決論点）。

SECTION 05計測アーキテクチャと最大の技術リスク

全指標を「日経IDのハッシュ値」1本で突合する

データソースの構成

最優先の実装要件

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 を使う高／中〜大別途契約・費用。費用対効果次第
CQR／リンクごとにワンタイムトークンを発行し、初回ログイン時にアプリへ引き渡す高／中出展社別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）で基準値を取るところから逆算する

  1. 9月28日

    先方ヒアリング

    ◎項目を潰す。その場で答えが出ない項目は「いつまでに誰が回答するか」まで握る

  2. 〜10月上旬

    KGI/KPI定義の確定

    分母・観測窓・L1/L2/L3を合意。あわせて各種アクセス権を受領

  3. 〜10月中旬

    計測要件書 v1 をベンダーへ

    実質のタイムリミット。イベント設計＋user property＋経路計測方式

  4. 〜10月末

    来場登録フォームの判定設問を確定

    エコプロ分の締切に注意。出展社アンケートの設問ドラフトも

  5. 〜11月中旬

    実装完了・計測QA

    テスト端末で全イベントの発火を確認する

  6. 〜11月末

    モニタリングシート構築

    ダミーデータで疎通まで済ませる

  7. 12月2〜4日

    エコプロ本番（内部テスト）

    日次で数字を見て、初日の夜に打ち手を差し替える

  8. 12月中旬

    エコプロ基準値レポート

    確定日は12月18日。日経メッセ向けの改善要件もあわせて提出

この逆算の意味

9/28のヒアリングでA〜Dの◎が埋まらないと、計測要件の提出が後ろ倒しになり、エコプロで基準値が取れません。基準値が取れなければ1月の目標水準も合意できず、Phase3（日経メッセ）の判定基準がないまま本番を迎えることになります。9/28は「聞く場」であると同時に「締切を握る場」です。