オジサン世代向け GA4 新機能 2022

Google Analytics (GA4) の新イベント “form_start” と “form_submit”。 つまるところ「これからのコンバージョン・イベント定義」は画面遷移（page_view）に頼るべきではないというコト？？ つまるところ「ワークフローを開始させる公開フォーム」にも GA4 タグを仕込むべきというコト？？？ イロイロな疑問が湧いてくる2022年の年の瀬…。

今どきの Google Analytics (GA4) は「フォーム・インタラクション」も「トラッキング」シマス！　それらの Events は、”Form interactions” 〔フォームの操作〕と総称されます。

具体的には、、、

• “氏名フォーム” といった form 要素への 『入力開始の操作』
  • Event: event_name == "form_start"
• それら（FormData）の 『送信の操作』 〔submit ボタン〕
  • Event: event_name == "form_submit"

という２種類の Event がカウントされるようになりました。（もちろん、プライバシーが保護された状態で）

ただ、、、これらは、2022年の夏、こっそり “追加” された Event 達です（驚）。しかも “オプション計測扱い” の Event です。したがって、その “紹介記事” や “目撃情報”（？）はマダマダ少ない状況です。　（←トラッキング開始には「計測オン」の設定が必要です）

• ▽2022-08-12 https://twitter.com/makitani/status/1557921011563376640
  • ◇GA4の拡張計測に追加された「フォームの操作 (form interactions)」…
• ▽2022-10-01 https://ga4-quick.and-aaa.com/archives/3319
  • ◇GA4 拡張計測機能の新顔「フォームの操作」 form_start, form_submit
• ▽2022-10-28 https://bunkyudo.co.jp/ga4-enhanced-measurement-form-t-h/
  • ◇【GA4】新しい拡張計測機能であるフォームの操作を紹介します。

※要するに、2022年5月時点（GA4ブログを書いた時点）に「11」だった “ウェブ Event 種類数” が、2022年8月下旬ごろ「13」にシレっと増えた、、、（増えていて驚いた）、、、というハナシです。

• 2022-04-21: オジサン世代向け GA4 概説
• 2022-05-12: オジサン世代向け GA4 Conversion 概説

※オフィシャルドキュメント的には、2022年8月下旬ごろに ★★加筆★★ されました。（下図参照）

• ［GA4］自動的に収集されるイベント (公式Page “Analytics Help”)
  • click (outbound link)
  • file_download (pdf,xlsx,docx,,,)
  • first_visit
  • page_view
  • scroll
  • session_start
  • user_engagement
  • video_complete
  • video_progress
  • video_start
  • view_search_results
• ［GA4］拡張イベント計測機能 (公式Page “Analytics Help”)
  • page_view　←これまでの主役
  • scroll
  • click
  • view_search_results
  • video_start
  • video_progress
  • video_complete
  • file_download
  • ★★ form_start ★★
  • ★★ form_submit ★★　←これからの主役？

つまるところ、2つの Event

• form_submit （フォームを送信した）
• form_start （入力を開始した）

の数の差分が「途中で挫折したヒトの数」になります。（＝「Form 入力を開始したものの Submit しなかったヒト」）

ちなみに、Event form_start （入力開始した数）には、「いっさい何も入力しなかったヒト」〔どの form 要素も更新しなかったヒト〕はカウントされません。また一方、Event form_submit （送信した数）には、「必須項目の入力モレがあるのに Submit した回数」がカウントされてしまいます。

つまり、細かく分析したい方は、『Event page_view の数との比較』や『別途設定した Custom Event の数との比較』などが必要になってきます。たとえば “必須入力モレのリトライ” をカウントしたい場合、Custom Event form_submit_retry といった Event を別途設定し、計測カウントする必要があります。

• Event form_submit_retry
  • event_name equals "form_submit"
  • page_referrer contains “http s://example.com/form/“

一般的に、

• 購入した
• 資料請求した
• 体験版を申し込んだ

といった Event が「コンバージョン」として格付けされます。

したがって、Event form_submit は、「コンバージョン・イベント」の設定において、とても便利な Event だと言えます。

• Event sign_up （←推奨に従った命名）
  • event_name equals “form_submit"
  • page_location startsWith “http s://example.com/trial/form“

しかも “より細かい分析” も可能となります。たとえば『Form Start から Form Submit までが10秒以内の申込』（※）をカウントすることも容易に実現できるようになります。

※『迷いのない Sign up』の数！ 『リセットマラソン中』の数！？ 『RPAの仕業』の数？？

• Event sign_up_within_10s
  • event_name equals “form_submit“
  • page_location startsWith “http s://example.com/trial/form“
  • engagement_time_msec isLessThan “10000“

※ engagement_time_msec パラメータ: ページがフォーカス状態にあった時間の長さ

しかしながら一方、”従来は存在しなかった Event” です。

「コンバージョン」は基本的に、同じルールで計測されるべき存在です。「コンバージョン・イベント設定」をコロコロと変更していたのでは、その計測値が好調値なのか不調値なのか、過去比較できなくなってしまいます。

• Event sign_up （←推奨名）
  • event_name equals “page_view“
  • page_referrer startsWith “http s://example.com/trial/form“
  • page_location startsWith “http s://example.com/trial/thanks“

もし、「サンクスページ画面への遷移」をコンバージョン・イベントと設定している（格付けしている）なら、その設定を破棄してまで急いで設定し直す必要は無いような気がします。（”年度の区切りなどの機会に見直す” のはイイように思います）

※ “新規に GA4 を立ち上げる”（UA から GA4 に移行する）なら、「多くのコンバージョンは form_submit ベースで設定されるべき」なんだろうと思います。

• 参考：form_start パラメータ （オフィシャルマニュアルとはチョットチガウ？）
  • engagement_time_msec　←入力着手にまで要した時間ミリ秒（←ばっくり）
  • first_field_id　←最初に改編されたフォーム要素（form field）
  • first_field_name
  • first_field_position
  • first_field_type
  • form_destination
  • form_length　←Form要素の数（←ばっくり）
  • ga_session_id
  • ga_session_number
  • page_location　←FormページのURL
  • page_referrer　←データが無い場合も
  • page_title
• 参考：form_submit パラメータ
  • engagement_time_msec　←着手から完了にまで要した時間ミリ秒（←ばっくり）
  • form_destination
  • form_length　←Form要素の数（←ばっくり）
  • ga_session_id
  • ga_session_number
  • page_location
  • page_referrer　←リトライの場合は page_location と同じに（←ばっくり）
  • page_title

パブリックに公開された起動フォーム（Questetra用語で言う所の『メッセージ開始イベント(Form)』）の form_submit も集計可能です。

そもそも、Questetra BPM Suite では、［マイタスク］の “処理フォーム画面”（タスクForm）に JavaScript を仕込むことができます。（←ただし、Professional edition でプログラミング知識を持っておられる方）

したがって、『Google タグ』（旧 『グローバル サイトタグ』）（gtag.js）が読み込まれるワークフロー設定にしておけば、各工程が処理される度に各種 Event がトラッキングされるようになります。具体的には、

<script src="https://www.googletagmanager.com/gtag/js?id=G-YourGA4MeasurementId"></script> 
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-YourGA4MeasurementId');
</script>

といった JavaScript (GA4タグ) が読み込まれるよう設定します。

（＠ワークフローアプリ設定＞［データ項目］＞［説明／Description］）

• M213: 処理フォーム画面をデコレーションする（HTML/JavaScript）
  • データ項目の［説明］を設定すれば、入力フォームの下部に “注記” として表示されるようになります。プレーンテキストだけでなく HTML や JavaScript も設定できるので、”業務上の注意” を強調させる、”関連サイトの URL” のリンク表示させる、”入力文字数カウンタ” を表示させるなど、業務効率を上げる様々な工夫を実現できます。

※なお、2022年12月現在、大人の事情で async 属性（グローバル属性）が付けられない、などの制限があります。また、今後、更なる「大人の事情」が追加されるかも知れません。したがって、当面においては　 “参考値程度の位置づけで（POC的試行版として）計測運用を開始する（してみる）” 　が良いと思います。

ちなみに、従来（←Event form_submit が計測されていなかった時代）から JavaScript の設定は可能でした。しかし、「コンバージョンイベント」（Submit の完了）の計測（捕捉）は現実的ではありませんでした。（←画面遷移直後のページにて『Google タグ』を読み込ませる設定ができないため）　ところが、Event form_submit が計測対象になったため、状況が一転した（かなり簡単に「コンバージョン」をカウントできるようになった）というハナシです。

（平たく言えば、、、 Google フォーム では計測できない Submit コンバージョンが、Questetra BPM Suite ではカウント可能になりました！！）

ツラツラ書いてみましたが、ただでさえ「Analytics大変革」な折なのに、なんとも分かりにくいハンシですね。もし、何か「疑問点」や「修正すべき点」あれば遠慮なく、（あるいは「感想」や「ミミヨリ新情報」等あれば奮って）、下の『コメントを残す』などから御一報ください。よろしくオネガイシマス。