これは未検証記事です。gtagを使った生タグとGTMを利用した設定を比較すべきですが、現在生タグ側の検証をしていません。(ローカルでも出来るのですが...)
前提
Google Analytics v4では「測定機能の強化」として今まで個別にイベントを設定する必要があったものについても特に設定が不要で、タグを埋めるだけでデータが取得出来るようになりました。
確認した事象
タグマネージャー(GTM)を利用した場合、「測定機能の強化」の「ページビュー数」項目で書かれている以下の部分がうまく動いていないのではないか?と思いました。
閲覧履歴のイベントに基づいてイベントを送信するかどうかを指定できます。この測定オプションでは、pushState、popState、replaceState を検知(イベントリスナー)します。
確認する事
GTMのプレビューモードでpushStateが発生した際にページビューイベントが発火しているかどうか?
事象
GTMのプレビューでは発火しているように見えなかった。
プレビューなのでGTMが発火させたタグ以外は見えないのかな?と思ったため、次にChromeで実際にcollectが飛んでいるかを確認するも、こちらも飛んでいるように見えなかった。
生タグの gtag.js に依存しているのでは?という思いもありますが、ここは検証してみなければ何とも分からないポイントです。
現象を解消するため通常の検索履歴に関する発火を仕込みました。
GAv4のイベントで通常page_viewイベントで飛ぶはずのpage_locationとpage_referrerパラメータを追加してみましたが、page_title等実際にpage_viewイベントをフルで返してあげても良いかもしれません。(現在様子見)
事象確認中に新たに気づいた点
GAv4のResource PriorityがLowest設定となっている関係上、実際にデータが送信されるまでの時間が長い(データ送信タイミングが非常に遅い)。
上のイメージは順にdoubleclick、GAv3、GAv4ですがGAv4のPriority設定がLowestになっており実際の送信は遅い(数秒単位で遅いように見える)
Lowest設定となっているため恐らくどこかにprefetchが書かれているのでは?と思いますが、ソースは見つけられず。HTTP status 204でデータが投げっぱなしになるからか?とも思いましたが投げて見ないと分からないので多分関係ない。
ただGAv4自体はとても処理が多くsetTimeoutとか色々複雑に絡み合ってしまっていて、実際の実行タイミングも `timer fired` ステータスとなるなどしており、なかなか事象の確認はツライところがある。
本事象もタグの発火順云々の問題とは関係なさそうなので、引き続き確認が必要かもしれない。
※本事象はいつも会話している方を通じて調べてもらう事に...。フロントからネットワーク、ブラウザ処理まわりまでの知識が多少必要そうで一応調べた事と知っている限りのことは伝えたため、リセラーの方じゃないけどGoogleまで質問が届くといいなぁ...(回答来るかは未定
(追記)本事象、setTimeoutの `5E3` って5秒(5000)ということだったんですね。たしかに。chromeでtimer firedステータスとなっていることも納得。
知識不足でしたが仕様ということでTwitter Timeline上では指摘されているようで。とりあえず解決していました。
0 コメント:
コメントを投稿