eVar／prop／イベントの設計入門

スコープの違い／命名と枯渇対策／よくある落とし穴

対象読者： GA4＋GTM経験があり、Adobe Analytics（AA）実装設計をこれから行う担当者。
目的： eVar／prop／イベント（成功イベント）の役割・スコープ・設計手順を整理し、実装のやり直しやデータ歪みを未然に防ぐ。

このページでわかること
1. まず押さえる：eVar／prop／イベントの役割とスコープ
1. 1.1 スコープ早見表
2. 1.2 eVarの「持続」と「割当（Allocation）」
2. 設計手順：SDR（Solution Design Reference）を起点に
3. 枯渇対策：スロットを節約し、運用を長寿命に
4. よくある落とし穴（と回避策）
5. 検証の進め方（チェックリスト）
6. 設計テンプレート
7. 図解アイデア
8. まとめ
1. 付録：SDR（Solution Design Reference）テンプレ（CSV想定カラム）

このページでわかること

スコープの考え方（ヒット／訪問／訪問者）と eVar・prop・イベントの正しい役割分担
命名規約と設計ドキュメント（SDR）雛形、将来の枯渇対策（スロット消費の最小化）
よくある落とし穴（持続期間の誤設定・重複カウント・大小表記の揺れ等）と検証手順

1. まず押さえる：eVar／prop／イベントの役割とスコープ

要旨：

prop＝ヒット単位の“現象の記録”（ページ名、クリック対象など）。パス分析に強い。
eVar＝“値を持続”させて成果にひも付ける（流入、会員属性、キャンペーン等）。帰属に強い。
イベント（成功イベント）＝“数える・合計する”KPI（購入数、売上、CV数、スクロール回数など）。指標そのもの。

1.1 スコープ早見表

ヒット＝1回のビーコン送信、訪問＝セッション、訪問者＝ユーザー（期間内でユニーク）

項目	スコープ	代表用途	持続/有効期限	パス分析	注意点
prop（トラフィック変数）	ヒット	ページ名、カテゴリ、クリック対象	なし（都度送信）	◯（標準対応）	値は次ヒットへ持続しない。帰属用途は不向き。
eVar（コンバージョン変数）	訪問／訪問者／時間などで設定	流入、会員種別、キャンペーン、検索語	設定で持続（例：訪問終了まで等）	×（原則）	持続設定・割当（Allocation）の誤りで帰属が歪む。
イベント（成功イベント）	ヒット（発生時）	購入件数、売上、CV、スクロール回数	―	―	重複送信・二重カウントに注意（後述）。

1.2 eVarの「持続」と「割当（Allocation）」

持続（Expiration）：ヒット／訪問／訪問者／期間（日・週・月）など。
例）「流入キャンペーン」は訪問で持続、「会員ランク」は訪問者で持続。
割当（Allocation）：同一スコープ内で複数値が入ったときのどれを成果に紐づけるか。
代表例：Most Recent（最新上書き）／Original（初回）。
例）同訪問内でA→Bの順にキャンペーンを跨いだ場合、Most RecentならBに帰属、OriginalならAに帰属。

ポイント：eVarは“値を保持して成果に結び付ける器”。持続×割当の設計が帰属の肝。

2. 設計手順：SDR（Solution Design Reference）を起点に

2.1 SDRの基本カラム

種別	変数名/イベント名	目的/分析観点	データ定義（型/例）	取得元（Data Layer/DOM/URL）	持続/割当	値の正規化	備考
eVar	eVarXX: marketing_campaign	流入施策のCV帰属	文字列（utm_campaign 等）	dataLayer.campaign	訪問 / Most Recent	lowercase, trim	自然検索は“organic”に統一
prop	propYY: page_category	パス分析（回遊導線）	文字列（/mens/shoes など）	dataLayer.page.category	―	lowercase, slash統一	トップは“/”で統一
event	eventZZ: form_submit	フォームCV件数	カウント（+1）	クリック時に発火	―	―	重複送信制御（後述）

2.2 命名規約（推奨）

英小文字＋下線（page_category, marketing_campaign, member_rank）。
辞書（用語集）を維持：同義語・大小表記を吸収（“Paid Search”/“paid search”→paid_search）。
プレフィックスで概念を揃える：
- usr_（ユーザー属性）、sess_（訪問属性）、page_（ページ属性）、tx_（トランザクション）
値の正規化（Processing Rules）：lowercase／trim／N/A→(not set) などを一律適用。

2.3 データレイヤー優先

取得元はdataLayerのルール（キー・型・サンプル値）を先に決め、DOM依存を最小化。
バリエーションが多いページはテンプレ化（例：記事詳細の共通dataLayerスキーマ）。

3. 枯渇対策：スロットを節約し、運用を長寿命に

目的別の“設計パターン”でスロット消費を抑える。

3.1 1値=1 eVar を乱立させない

多態の概念は分類設計で吸収：
例）「施策ID」（eVar）＋分類（Classification）で「施策名／媒体／地域」に展開。
キー=値の汎用eVar：key:valueを1つのeVarに入れて、分類で展開（将来拡張に強い）。

3.2 propとeVarの住み分け

パス分析が必要＝prop。帰属が必要＝eVar。
両方欲しい場合はペアで実装（page_category を prop＋eVar 併用）。
- ただし本当に両方必要かをレビュー。レポート要件が満たせる最小構成に。

3.3 イベントの節約

単なる比率は計算指標で作る（例：離脱率、CVR）。
同種イベントは汎用イベント＋分類／ディメンションで表現（例：event: download＋file_type）。

3.4 リスト型の活用（必要時）

1ヒットで複数値を持ちたい場合はリスト変数（list eVar / list prop）を検討。
値の区切り文字・最大値数・正規化ルールをSDRに明記。

4. よくある落とし穴（と回避策）

eVarの持続・割当の誤設定

例：キャンペーンを“訪問者持続×初回割当”にしてしまい、次回訪問のCVまで初回施策に帰属。
対策：要件に沿って訪問持続×最新割当などに。公開前にケース別テスト（A→B→CV 等）。

購入やフォームの二重カウント

ページリロードや二重クリックでイベントが再送。
対策：イベントの重複防止（一意IDの送信・クリック後ボタン無効化・サーバ側バリデーション）。
- ECはpurchaseID（決済ID）でシリアライズし、同IDの再カウントを防止。

propで帰属しようとする

propは持続しないため、CVとのひも付けに不向き。
対策：eVarに保持し、イベントに帰属させる。パス分析はprop側で。

大小・表記ゆれによる分断

“Spring_Sale”と“spring_sale”で別集計。
対策：Processing Rules で lowercase/trim/正規化を強制。

データレイヤー未整備でDOM依存

仕様変更でセレクタが変わり、計測が静かに崩壊。
対策：dataLayer優先。契約（スキーマ）をバージョン管理。

テスト/本番の混線

ステージングのビーコンが本番RSIDへ。
対策：環境変数で送信先の厳格分離＋公開フローで承認必須。

5. 検証の進め方（チェックリスト）

ビーコン検証：Debugger／Network で
- eVar/prop/event のキー/値、持続が想定通りか（次ページに値が残るか）
- イベント重複なし、購入はID単位で一意
Workspace検証：
- テスト期間セグメントで CV数＝イベント数、eVarの割当と整合
- propのパス分析で想定導線が再現される
ケース網羅：
- 新規/再訪、直帰/複数ページ、施策跨ぎ、フォーム再送、決済戻り
データ品質監視：
- 設定変更後は数日トレンド監視。異常閾値の通知（急増/急減）を用意。

6. 設計テンプレート

6.1 命名規約（抜粋）

・英小文字+下線（snake_case）／半角英数のみ
・ディメンション名は“概念_属性”（例：campaign_name, page_category）
・イベント名は“動詞_対象”（例：submit_form, add_to_cart）
・値の正規化：lowercase, trim。未設定は (not set) に統一

6.2 eVar設定の指針（例）

流入キャンペーン：訪問持続 × Most Recent
会員ランク：訪問者持続 × Most Recent（ログインで上書き）
検索語：訪問持続 × Most Recent（内部検索/外部検索で区別）

6.3 イベント設計の指針（例）

purchase（購入件数）：+1（シリアライズ必須）
revenue（売上）：数値送信（通貨・小数点ルールを統一）
form_submit（送信）：+1（送信成功タイミングのみ）
scroll_depth（スクロール）：25/50/75/100%（閾値はサイト共通）

7. 図解アイデア

「prop→パス分析」「eVar→帰属」の分業図：
ヒットごとに prop.page_category、訪問開始で eVar.campaign を保持 → イベント（purchase）発生時に eVar へ帰属。

持続×割当マトリクス：
行＝持続（ヒット/訪問/訪問者/期間）、列＝割当（最新/初回）。ユースケースをセルに配置。

8. まとめ

propは“今このヒットの状況”、eVarは“継続して成果に結び付ける文脈”、イベントは“KPIのカウント”。
持続（Expiration）×割当（Allocation）の設計が帰属精度を左右。
枯渇対策は「分類の活用」「汎用eVar化」「計算指標優先」でスロット節約。
導入時はSDR作成→dataLayer設定→正規化→検証の順で、やり直しコストを最小に。

付録：SDR（Solution Design Reference）テンプレ（CSV想定カラム）

type,name,purpose,data_definition,source,expiration,allocation,normalization,notes
eVar,eVarXX marketing_campaign,流入CV帰属,string(utm_campaign),dataLayer.campaign,visit,most_recent,lowercase|trim,自然検索はorganic
prop,propYY page_category,パス分析,string(/mens/shoes),dataLayer.page.category,-,-,lowercase|trim,トップは/
event,eventZZ form_submit,フォームCV,count(+1),click(trigger),-,-,-,重複防止