GTM4WP – A Google Tag Manager (GTM) plugin for WordPress

変更履歴

2.0.1

• 修正: ブロックベースのストアで、お買い物カゴページを開くと、操作がなくても add_shipping_info と add_payment_info がデータレイヤーにプッシュされ、さらに購入手続きページでも両方のイベントが再度発火していました。ブロックトラッカーはこれまで、WooCommerce の支払いデータストアの有無によって 2 つのページを区別していましたが、WooCommerce はこのストアをお買い物カゴページにも登録するため、判別が正しく機能していませんでした。現在は、お買い物カゴページと購入手続きページのそれぞれに専用のコンテキストが割り当てられ、購入手続きステップのイベントは購入手続きページでのみ発火します。
• 修正: 設定画面が空白になったとき、その理由が示されないままになることがなくなりました。一部の広告ブロッカーやプライバシーブロッカーのフィルターリストは、プラグインフォルダー配下のすべてをブロックします。これにはブラウザーで設定画面を構築するファイルも含まれるため、設定ページが何の説明もないまま空になっていました。設定アプリを起動できなかった場合は、数秒後に静的な通知が表示され、最も可能性の高い原因と回避策 (サイトの管理画面でブロッカーを一時停止するか、除外を追加する) を説明するようになりました。

2.0.0

プラグインの大幅な書き直しです。アップグレードする前に、gtm4wp.com のお知らせ記事を必ずお読みください !

アーキテクチャと要件

• 変更: 完全なオブジェクト指向による書き直し。すべての機能がモジュールになり、サードパーティ製プラグインは gtm4wp_register_modules アクションを通じてこれを拡張できるようになりました。公開テンプレート関数 (gtm4wp_the_gtm_tag() など)、フィルター / アクション名、wp-config の定数、gtm4wp-options ストレージキーはすべて変更されていないため、既存の統合はそのまま動作し続けます。
• 変更: 最小要件が PHP 8.0 と WordPress 6.3 に引き上げられました。WordPress 7.1 まで対応しています。
• 更新: フロントエンドのスクリプトは、可能な場合は defer 戦略で読み込まれるようになりました。
• 変更: メインのプラグインファイルは、WordPress によって読み込まれるのではなく直接リクエストされた場合、実行を拒否するようになりました。これはプラグイン内の他のすべての PHP ファイルと同様です。
• 非推奨: $gtp4wp_plugin_url、$gtp4wp_plugin_basename、$gtp4wp_script_path のグローバル変数 (1.x から引き継がれたタイプミスである gtp4wp_ というつづりに注意)。プラグイン内部でこれらを読み取る箇所はありません。1.x 向けに書かれたサードパーティ製コードのためだけに設定されています。このバージョンでも引き続き動作しますが、GTM4WP 2.1 で削除される予定です。代わりに plugin_dir_url( GTM4WP_PLUGIN_FILE )、plugin_basename( GTM4WP_PLUGIN_FILE )、plugin_dir_url( GTM4WP_PLUGIN_FILE ) . 'build/' を使用してください。これらはいずれも管理画面・フロントエンドのリクエストの両方で動作します。$gtp4wp_script_path はすでに build/ を指すようになっており、1.x の dist/js/ ではない点にも注意してください。そのため、これを基にスクリプト URL を組み立てているコードは、いずれにせよ更新が必要です。非推奨の関数とは異なり、グローバル変数は非推奨通知を発生させることができないため、この項目がその唯一の警告になります。

設定画面

• 追加: 左ペインのナビゲーション、タブ分けされたオプショングループ、オプション検索、フィールドごとのインライン検証を備えた、React ベースの最新の設定画面を導入しました。この画面はスマートフォンでも使用できます: タイトルと「設定のエクスポート」/「設定のインポート」/「変更を保存」ボタンは画面からはみ出さず、縦に積み重なります。設定セクションの一覧は検索フィールドと画面上部に固定されたドロップダウンになるため、セクションを切り替えるために画面いっぱいのセクション名をスクロールして通り過ぎる必要がなくなりました。画面幅より広いオプショングループのタブの行は、単語ごとに列へ押し込められて最後のタブに手が届かなくなる代わりに、各タブが1行に収まった状態で横スクロールします。そして、コンテナテーブルは、スマートフォンの画面幅に6列を詰め込む代わりに、各列がそれぞれのフィールドの上にラベル表示された、コンテナごとに1枚のカードになります。選択中のオプショングループタブは、どの画面サイズでも常に表示されたままになるため、ブックマークや管理通知のリンクを開いても、タブの並びが誤ったタブを指したままになることがなくなりました。
• 追加: 管理通知が、該当するオプションに直接リンクするようになりました。通知をクリックすると、モジュールが開き、その設定があるタブに切り替わってハイライト表示されるため、たとえば信頼するプロキシアドレスがページ変数 -> 訪問者データの下にあることを、設定画面に放り出されて自分で突き止める必要がなくなりました。
• 追加: 設定画面がアドレスバーを常に最新の状態に保つようになったため、どのモジュールやタブもブックマークしたり同僚に送ったりでき、開き直すと直前にいた場所がそのまま再現されます。戻るボタンは今までどおり設定画面から単純に離脱するだけで、タブを切り替えるステッパーにはなりません。
• 追加: すべてのオプションへのヘルプリンク。各設定セクションのヘッダーにドキュメントへのリンクが表示されるようになり、プラグインの110個のオプションすべてに「?」アイコンが追加され、クリックするとその設定について説明する gtm4wp.com のページ (データレイヤーで何が変わるか、初期状態では何に設定されているか、いつ変更する価値があるか) が開くようになりました。これまでもドキュメントは存在していましたが、設定画面のどこにもそれを指し示すものがなかったため、たとえば「この期間内の注文のみ追跡する」のページを見つけるには、サイト内を検索する必要がありました。リンクは新しいタブで開き、クリックしても設定は変更されません。まったくドキュメントページが無かった3つのセクション (Google タグ マネージャーコンテナ設定、AMP、タグの制限) にも、ドキュメントページが用意されました。独自のモジュールを追加するプラグインは、設定スキーマに完全な URL を指定するか、新しい gtm4wp_admin_doc_url フィルターを使用することで、それぞれのオプションを独自のドキュメントに関連付けられます。
• 追加: プラグイン設定のエクスポートとインポート (Google タグ マネージャー設定画面の「変更を保存」の隣)。「設定のエクスポート」を実行すると、GTM4WP のすべてのオプションが JSON ファイルとしてダウンロードされます。「設定のインポート」を実行すると、そのファイルを別のサイト (または同じサイト) で読み込めます。インポートは信頼できないものとして扱われます。ファイル内のすべての値は、何かが保存される前に、通常の保存時と全く同じフィールドごとのサニタイザーを通して処理されます。不明なキーは破棄され、すべての値は各フィールドが想定する型に正規化され、サイズが大きすぎるファイルは拒否され、ファイルは json_decode() でのみ解析されます (unserialize や eval は使用されません)。そのため、手動で編集された、または悪意のあるファイルが安全でないデータを注入することはできません。どちらのエンドポイントにも設定用の権限と nonce が必要です。値のセットはスキーマ駆動のため、現在および将来のすべてのオプションが自動的にカバーされます。

Google タグ マネージャーコンテナとタグの制限

• 追加: すべての Google タグ マネージャーコンテナ ID に、独自の環境パラメーター (gtm_auth/gtm_preview)、カスタムドメイン、カスタムパスが設定できるようになり、データテーブル (新しい gtm-containers オプション) で管理されるようになりました。既存の設定は自動的に移行されます。サードパーティ製コードやダウングレードのために、1.x のフラットなオプションキーは引き続き同期されます。
• 変更: 環境パラメーターが設定されている場合に、すべてのコンテナが読み込まれるようになりました (1.x ではこの場合、最初のコンテナのみが読み込まれていました)。出力を最初のコンテナのみに限定するのは、ハードコードされた wp-config の環境定数を使用している場合のみになりました。
• 追加: コンテナテーブルにおける、コンテナごとの「コンテナ ID を省略」オプション。カスタムパスが設定されている場合 (サーバーサイド GTM)、これをオンにすると、コンテナがそのパスで選択される構成において、読み込み URL からコンテナ ID が省略されます (gtm.js?id='+i+dl ではなく gtm.js?'+dl)。
• 追加: プラグインを無効化することなく、複製またはステージング用のサイトコピーで Google タグ マネージャーコンテナの読み込みを止めるキルスイッチ。新しい「本番環境でのみコンテナを出力」オプション (Google タグ マネージャーコンテナ → 詳細設定) は、WordPress が環境タイプを「production」として報告している場合にのみコンテナを出力します (本番環境以外のコピーには WP_ENVIRONMENT_TYPE を設定してください)。WP_ENVIRONMENT_TYPE は wp-config.php またはサーバー設定内にあり、管理画面からは見えないため、このオプションの説明には、このサイトで実際に WordPress が返している環境タイプと、その結果コンテナが読み込まれるか抑制されるかが表示されます。これには、未設定の WP_ENVIRONMENT_TYPE が「production」にフォールバックするため、このオプションが気付かないうちにコンテナを読み込み続けてしまうというよくある落とし穴も含まれます。mu-plugin や wp-config.php からホスト側で制御したい場合は、新しい gtm4wp_output_container フィルター (デフォルト true) を使って PHP からコンテナの出力を拒否できます。どちらの場合も、データレイヤーは有効なまま維持され、コンテナの <script> / <noscript> だけが抑制されます。これは「オフ」の配置とまったく同じです。デフォルトではオフ (実験的機能)。
• 変更: wp-config.php 内の GTM4WP_HARDCODED_GTM_ENV_AUTH または GTM4WP_HARDCODED_GTM_ENV_PREVIEW の値が不正な形式の場合、すべてのコンテナの読み込み URL に書き込まれるのではなく拒否されるようになり、設定画面には問題のある定数名を示す警告が表示されます。これまではハードコードされたコンテナ ID のみがチェックされていたため、環境定数の入力ミスはそのまま適用されてしまい、原因を示すものがどこにもありませんでした。受け付けられる形式は、コンテナテーブルが要求する形式と同じです (gtm_preview は env-3 のような形式です)。設定画面には、正しいハードコード定数が何を行うかも表示されます: 定数によって固定されるコンテナテーブルの該当部分は、実際に使用されている値とともに読み取り専用で表示されます (単一の環境列のみの場合と、定数が読み込むコンテナ自体も決定する場合はテーブル全体になる場合とがあります)。また、フィールドの説明には編集すべき定数の名前が示されます。この裏側で、保存済みのコンテナ設定はそのまま保持されており、wp-config.php から定数を削除すればすぐに再び使用されます。1.x ではハードコードされたコンテナ ID が読み取り専用フィールドに表示される一方、保存のたびにその値が保存済みのオプションに書き込まれていました。拒否された定数は出力時には何も変更しないため、テーブルは編集可能なままになります。
• 修正: データレイヤー変数名オプション (Google タグ マネージャーコンテナ -> 詳細設定) が、プラグインの出力するすべてのスクリプトを壊してしまう名前を受け付けていました。このフィールドはハイフンを許可していましたが、JavaScript はハイフンを減算演算子として解釈するため、my-layer のような名前がそのまま保存され、ページには var my-layer = my-layer || []; として出力されていました。これは構文エラーとなり、GTM4WP のスクリプトブロック全体を巻き込んでいました。コンテナ自体は引き続き読み込まれていたため、見た目上は接続されているように見えましたが、実際にはデータレイヤーの内容は一切プッシュされていませんでした: ページ変数も、eコマースイベントも、メディアイベントも送信されていませんでした。このフィールドは現在、JavaScript が変数名として受け付ける形式 (英字、_、$ のいずれかで始まり、続けて英字、数字、_、$ を使用できる形式。$ は今回新たに許可されたもので、以前は拒否されていました) のみを受け付けます。旧バージョンで保存された、この条件を満たさない名前は無視され、デフォルトの dataLayer が使用されるためコンテナは引き続き動作します。また、設定画面には拒否された値が表示されるため、修正が可能です。
• 変更: タグ制限リストが、Google がドキュメントで示しているキー名である gtm.allowlist と gtm.blocklist の下でデータレイヤーに書き込まれるようになりました。従来プラグインが使用していた gtm.whitelist / gtm.blacklist という古い名前は、この機能に関する Google の現在のドキュメントのどこにも登場せず、対応・非推奨などいかなる記載もありません。Google タグ マネージャーは今もどちらのキーも読み取ります (まずドキュメント記載の名前を確認し、無ければ古いほうにフォールバックします) ので、これ自体で何かが壊れるわけではありません。ただし、ドキュメントに記載の無いキー名は、もし将来削除された場合にサイレントに失敗し、設定画面では制限が有効と表示されたまま、すべてのタグが無制限に動作してしまう可能性があるという点が問題です。gtm.whitelist または gtm.blacklist をもとにデータレイヤー変数、トリガー、カスタムテンプレートを作成している場合は、GTM の設定を確認してください。これらのキーはもう出力されません。代わりに gtm.allowlist / gtm.blocklist を参照してください。制限の設定自体は変更されておらず、対応は不要です。
• 更新: タグ制限の設定が、Google の現在の用語を使用するようになりました。2つの制限モードは「選択したエンティティをブロックリストに登録」と「選択したエンティティを許可リストに登録」という名称になりました (以前は「ブラックリスト」と「ホワイトリスト」でした)。これは Google 自身のドキュメントと、プラグインが出力する gtm.blocklist / gtm.allowlist キーの両方に合わせたものです。保存済みのモードと選択したエンティティはそのまま維持され、ラベルのみが変更されています。制限可能なエンティティも、これまでの1つの長いリストではなくなりました: 折りたたみ可能なタグ、トリガー、変数、エンティティグループの各セクションにグループ分けされ、それぞれ選択済みの件数が表示されます。また、これらをまとめるタブの名称は「エンティティ」になりました (以前は「タグ」という名称でしたが、実際には常にトリガーと変数も含まれていました)。
• 修正: ブロックリストモード (このバージョンより前は「ブラックリスト」と呼ばれていました) でタグ制限リストを有効にすると、選択したものだけでなく、コンテナ内のすべてのタグ、トリガー、変数がブロックされていました。プラグインはすべてのページで両方の制限キーを出力し、選択されていないほうを空のリストとして残していました。しかし Google タグ マネージャーにとって空の許可リストは「許可リストが無い」ことを意味せず、何も許可しない許可リストを意味するため、結果としてすべてがブロックされていました。この不具合はサイレントに発生し、制限が単に非常に厳格に機能しているように見えるため気付かれにくく、エラーは一切発生せず、設定側は「タグの展開に影響する可能性がある」という通常の警告を表示するだけでした。許可リストモードは影響を受けていません。現在は選択したモードのキーのみが出力されます。ブロックリストモードでタグ制限をオンにしていて、タグが発火しなくなっていた場合、原因はこれでした。制限リスト自体は常に正しく、変更の必要はありません。
• 更新: タグ制限のエンティティリストを、Google の制限に関するドキュメントに基づいて更新しました (Google タグ / GA4 タグと Google Analytics Settings 変数を追加し、Universal Analytics を削除)。Mouseflow は引き続き制限可能です。Google が現在もドキュメントに記載しています。
• 追加: タグ制限リストが、Google タグ マネージャーの sandboxedScripts グループクラスを通じて、サンドボックス化されたスクリプト (カスタムタグ / 変数テンプレート) を制限できるようになりました。1.x にはこのための「カスタムタグ / 変数テンプレート」チェックボックスがありましたが、コンテナには一切出力されておらず効果がありませんでした。現在は制限リスト内で正しく機能するエントリーになっています。
• 修正: 「除外するユーザー権限グループ」オプション (Google タグ マネージャーコンテナ → 詳細設定) が、除外対象のユーザー権限グループについてコンテナコードの半分だけでなく、全体を除外するようになりました。これまではページの head からコンテナの <script> は除去されていましたが、開始 body タグの直後に配置される <noscript> iframe はそのまま出力されていました。この iframe こそが JavaScript が動作しない場合にコンテナを読み込むものであるため、そのようなリクエスト (プリフェッチャー、クローラー、またはスクリプトを無効にしたブラウザー) では除外対象のユーザーが引き続きカウントされていました。<noscript> の部分も <script> の部分とあわせて抑制されるようになり、コンテナが存在しない理由を説明するブラウザーコンソールの警告も両方の箇所に表示されます。データレイヤーは、これまでどおり除外対象のユーザーに対しても引き続き有効です。
• 修正: コンテナコードが存在しない理由を説明するブラウザーコンソールの警告が、壊れた JavaScript にならなくなりました。コンテナが抑制されている場合 (配置が「オフ」に設定されている、本番環境限定のキルスイッチが働いている、または除外対象のユーザー権限グループに該当する場合)、GTM4WP はその旨を伝える短い console.warn のメモをページに書き込みます。コンテナコードの <noscript> 部分では、このメモがアンパサンドのエンコードを元に戻されないまま WordPress の HTML サニタイザーを通過していたため、&& がブラウザー側では && として届き、警告ブロック全体が構文エラーになっていました: 説明は表示されず、代わりに JavaScript エラーが報告されていました。この警告は意図どおりに動作するようになり、コンテナの <noscript> iframe の URL は正しい & エンコード形式のまま保たれます。
• 修正: コンテナコードの配置 (Google タグ マネージャーコンテナ → 一般) が「オフ」に設定されている場合に、赤色の「GTM4WP を使用開始するには GTM ID を入力してください」という通知が表示されなくなりました。この配置はデータレイヤーのみを意味し、コンテナコードは意図的に省かれ、コンテナは独自のコードによって読み込まれます。そのため入力すべきコンテナ ID が存在せず、設定画面で何を変更してもこの通知を消すことはできませんでした。この通知を閉じることだけが唯一の回避策であり、それもクリックしたその管理者ユーザーの、そのブラウザーでのみ通知を消せるというものでした。それ以外の配置ではこの通知の動作は変わりません。そこではコンテナ ID が未入力であることが、実際に何も追跡されていないことを意味するためです。
• 修正: HTML5 対応を宣言していないテーマで、プラグインの <head> スクリプトブロックから type="text/javascript" 属性が除去されなくなりました。このブロックは属性の許可リストに照らしてサニタイズされていましたが、そのリストに type が含まれていなかったため、そのようなテーマではプラグインが追加したばかりの属性が、ページに出力される過程で再び除去されていました。コンテナ自身の <script> タグは影響を受けていませんでした。
• 変更: コンテナの非表示の <noscript> iframe に必要な CSS 権限を WordPress の HTML サニタイザーから取得する処理が、ページ読み込み全体ではなく、GTM4WP が自身のコンテナマークアップをサニタイズする間だけに限定して適用されるようになりました。ページに出力されるコンテナコード自体はバイト単位で変更されていません。それ以外の箇所では WordPress 本来のインラインスタイルのルールが適用されます。そのため、これまでサイト内のコンテンツのどこかで display や visibility の宣言が生き残っていた場合は、代わりにテーマのスタイルシートから設定してください。
• 修正: PHP が JSON に変換できない値が1つあるだけで、スクリプトブロック全体が巻き込まれてしまう問題を修正しました。データレイヤー、purchase イベント、追加のデータレイヤーへのプッシュ、購入手続きの合計金額、購入の重複防止ガード、設定画面は、それぞれ変換結果をそのままスクリプトに貼り付ける形で値を書き込んでいました。この変換が失敗すると、PHP は空文字列を代わりに使用するため、var dataLayer_content = ; のような、ブラウザーが解析を拒否する行が残ってしまいます。その結果、値が1つ失われるだけではなく、ブロック全体が失敗し、データレイヤーやその内部のコンテナスニペット、それ以降のすべてが巻き込まれて機能しなくなっていました。この変換が失敗するのは、GTM4WP のフィルターを通じて他のプラグインがデータレイヤーに書き込める一部の値に限られます。たとえば、ゼロ除算による数値の結果や、PHP の上限を超えて深くネストされた値などです。現在では、影響を受けた値だけが除外され、ブロックの残りの部分は通常どおり出力されます。イベントを書き込めなかった purchase は追跡済みとしてマークされなくなったため、注文が失われることなく、次のページビューで再試行されます。
• 修正: 数値のように見えるテキスト値が、データレイヤーで数値に変換されなくなりました。メインのデータレイヤー JSON は PHP の JSON_NUMERIC_CHECK フラグを使ってエンコードされており、この構造内のあらゆる場所にある数値のように見える文字列を、JSON の数値へ強制的に変換していました。たとえば 000035180 のような SKU は、cartContent 内では先頭のゼロが失われる一方、同じ商品でも(このフラグを使わない経路で生成される)ecommerce.items 内では正しい文字列のまま保持されるという不整合が生じていました。注文番号、郵便番号、電話番号も型が変わってしまい、gtm4wp_compile_datalayer フィルターを通じて追加されたカスタム値も同様に変更されていました。この問題は wordpress.org のサポートフォーラムでも報告されていました。識別子のような値は、これで常に変更されていない文字列として Google タグ マネージャーに届くようになりました。一方、本来数値であるべき値(価格、カート / 注文の合計金額、数量、件数、ID。Unix タイムスタンプのページ変数である pagePostDateUnix / pageModifiedDateUnix、投稿数、投稿者 ID を含みます)は、生成元の時点で実際の数値型として扱われるため、GA4 と Meta は引き続き数値の price / value を受け取ります。次の値を数値と比較する設定を GTM 側で行っている場合は、確認してください: orderData.attributes.order_number、item_id / sku 内の数値の SKU、数値のように見える郵便番号 / 電話番号、ゼロ埋めされた日付の各要素(pagePostDateMonth は今後 "07" となり、7 ではなくなります)は、この修正後は文字列として届きます。GTM の「greater/less than」比較を使うトリガーは数値として比較されるため引き続き動作しますが、ゼロ埋めされていない数値(例: 7)に対する「equals」比較は、ゼロ埋めされた文字列(07)に更新する必要があります。

キャッシュセーフなデータレイヤー

• 追加: 新しい実験的機能の設定「キャッシュセーフなデータレイヤー」(issue #398)。フルページキャッシュを使用しているサイト(LiteSpeed、WP Rocket、Varnish、Cloudflare APO)では、ある訪問者向けに生成された HTML がすべての訪問者に配信されるため、データレイヤーに焼き込まれた訪問者固有の値が漏えいする可能性があります。典型的な例は、ログイン中の編集者のメールアドレス / ユーザー名 / 権限グループを含んだページがキャッシュされ、匿名訪問者に配信されてしまうケースです。この設定をオンにすると、訪問者データやセッションデータは一切キャッシュ対象の HTML に出力されなくなります。該当するすべての値は、代わりに同じデータレイヤー変数名でクライアント側から配信されるため、Google タグ マネージャーのタグはそのまま動作し続けます。デフォルトではオフ(実験的機能)。オフの場合、データレイヤーは従来とまったく同じです。このグループの残りの項目では、オンにした場合の動作について説明します。
• ブラウザー自身で算出できる値、検索語句と参照元ページ(siteSearchTerm、siteSearchFrom)は、クライアント側で直接プッシュされるようになり、これにより反射型 XSS の攻撃面も取り除かれます。
• 訪問者の IP、Cloudflare の国情報、ログイン中のユーザーのデータ(ログイン状態、権限グループ、メールアドレスとそのハッシュ、登録日、ユーザー名、ID)は、新しいファーストパーティのセッションエンドポイントから取得されます。このエンドポイントは no-cache ヘッダー付きで現在のリクエスト自身のデータのみを返します(ユーザー ID やセッション ID を受け取らないため、ある訪問者が他の訪問者のデータを要求することは決してできません)。IP と国情報はセッションごとに1回だけ取得され、ブラウザーにキャッシュされます。ユーザーデータはログイン状態が変化したときのみ取得されるため、キャッシュされたページ上の匿名訪問者はフェッチを行うことも、ユーザーデータを受け取ることもありません。
• WooCommerce の顧客データブロックとカートデータブロックは、WooCommerce がカートの変更のたびにすでに更新している cart-fragments レスポンスに相乗りするため、GTM4WP はこれらのために独自のリクエストを発行しません。ただし、そのレスポンスが確実に発生するようにする処理は行います: WooCommerce がカート更新用のスクリプトを読み込むのは、クラシックの「お買い物カゴ」ウィジェットが使われている場合のみで、しかもお買い物カゴページと購入手続きページではそこでさえ読み込まれません(ブロックのミニお買い物カゴはこのスクリプトをまったく読み込みません)。そのため、ほとんどのストアでは通常のページビューで顧客データとカートデータの変数がまったく届かないことになります。GTM4WP はこのモードがオンになっている間、このスクリプトを自身で読み込むことでこれに対処します。これまでこのスクリプトを読み込んでいなかったストアでは、ブラウザーのタブごとに WooCommerce のカート更新リクエストが1回追加で発生することを意味します(タブごとになるのは、WooCommerce がレスポンスをそのようにキャッシュしているためです。すでに読み込み済みのタブでは、その後のページビューでリクエストは発生しません。また、ブラウザーのストレージをブロックしている訪問者の場合は、ページビューごとに1回リクエストが発生します)。このリクエストが発生するのは、すでにカートに商品があるか、ログイン済みの訪問者に限られます。WooCommerce のカート更新スクリプト自体には、カートが空の場合の近道処理が用意されていないため、この条件がなければ、ショップに一度も触れたことのない訪問者にまで、カートが空であることを伝えるためだけのリクエストが発生してしまいます。これによってデータの到着が遅れることはありません: 訪問者が実際に何かをカートに追加した瞬間、WooCommerce 自身の add-to-cart レスポンスがそのデータを運んできます。すでにどこかにミニお買い物カゴを表示しているストア(大多数のストアが該当します)では、何も変わりません。
• これらの値はページビューの内部ではなく、ページビューのあとに到着するようになったため、これらを読み取るタグは Custom Event トリガーに割り当ててください。変数のグループごとに1つのイベントがあるため、イベント名だけでどのデータが届いたかが分かり、トリガー条件を設定する必要はありません。gtm4wp.visitorData には、訪問者およびログイン中のユーザーの変数(siteSearchTerm、siteSearchFrom、visitorIP、geoCloudflareCountryCode、visitorLoginState、visitorType、visitorEmail、visitorEmailHash、visitorRegistrationDate、visitorUsername、visitorId)が渡され、gtm4wp.customerData には WooCommerce の customer* 変数が、gtm4wp.cartData には cartContent 変数が渡されます。複数のグループに反応する必要がある場合は、gtm4wp\.(visitor|customer|cart)Data に一致する「Some Custom Events」トリガーを使用してください。
• 3つのイベントはそれぞれ、自身のデータが変化し、かつそれを生成するオプションが有効になっている場合にのみ発火します。そのため、カートの数量を変更すると gtm4wp.cartData のみが発火し、購入手続きで請求先フィールドを編集すると gtm4wp.customerData のみが発火します。正しく理解しておくべき点が2つあります。1つ目は、カートが空の場合でも送信されるという点です(商品リストが空の cartContent — これによってカートが空になったことを確認できます)。そのため gtm4wp.cartData が届かない場合は、カート内容オプションがオフになっているか、カートがまだ読み込まれていないことを意味し、カートが空であることを意味するわけではありません。2つ目は、gtm4wp.visitorData は該当する変数が1つもないページでは完全にスキップされるという点です。そのため、この2つの WooCommerce イベントで発火するタグは、visitor* 変数がすでに設定されていることを前提にしてはいけません。gtm4wp.visitorData が発火する場合は必ず最初に発火するため、後続のイベントからその変数を読み取ることは可能です。
• WooCommerce の単発イベントのうち2つ、カートに商品が戻されたときに発火する add_to_cart(カートの「元に戻す」)と、注文受付ページに到達しなかった場合(カスタムページやリダイレクトのサンキューページ)に purchase を復元する、信頼性の高いフォールバックは、必ず1回だけ発火する必要があるため、それぞれ異なる方法で配信されます。いずれかがキューに入れられると、GTM4WP は短期間だけ有効なイベント Cookie を設定します。ブラウザーはこの Cookie が設定されてから初めてフェッチを行い(注文または再追加を URL パラメーターからではなく、常にこのセッションから解決します)、イベントを1回だけ発火させてから Cookie を削除します。キャッシュされたページ上の匿名訪問者はこの Cookie を持たないため、フェッチを行うことはありません。
• purchase イベントのフォールバックは、既存の重複排除の仕組みをそのまま再利用します。注文受付ページが書き込む、注文番号をキーとする gtm4wp_orderid_tracked ブラウザーガードと、サーバー側の _ga_tracked 注文フラグです。この注文フラグは、フォールバック配信の後、ブラウザーが認証済みの POST ビーコンを1回送信することで設定されます(注文 ID は購入者自身のセッションからのみ取得され、リクエストボディからは決して取得されません)。そのため、同じ注文に対するフォールバックの発火と、注文受付ページでの実際の purchase が、同一の端末でも複数の端末にまたがっても、両方カウントされることは決してありません。カートへの再追加は、イベントごとのトークンによって重複排除されます。
• 「注文に追跡フラグを立てない」オプションは、最初から最後まで確実に反映されます(マーカーもビーコンもフラグも生成されません)。また、すべてのリクエストヘッダーの値と注文番号は16進数エンコードされた状態で往復するため、悪意のある値がそこから抜け出すことは決してできません。
• 確認ビーコンは、自サイト内のページから送信されたリクエストのみを受け付けます: WordPress の REST nonce とリクエストの Origin の両方を検証します。nonce だけでは不十分です。ログアウト中のすべての訪問者に対して同じ値になるため、自サイトの購入手続きページと第三者のページを区別できないからです。一方、Origin は外部のページが偽装できない部分です。この Origin はリクエスト自体のヘッダーからのみ読み取られ、呼び出し元が URL に追加できるパラメーターから読み取られることは決してありません。
• 本プラグインの REST ルートは、他のウェブサイトから読み取ることが一切できません。WordPress はデフォルトで、要求してきたどのサイトに対しても、訪問者自身の Cookie を使って REST レスポンスを読み取ってよいと伝えます。GTM4WP はこの許可を自身のルートに限って撤回します。他のプラグインには影響がなく、自サイトのページにも影響はありません。これは設定用のルートを含む GTM4WP のすべての REST ルートに適用され、キャッシュセーフなデータレイヤーがオンかどうかにかかわらず有効です。また、WordPress はルートアドレスの大文字・小文字を区別せずに応答するため、ルートアドレスの大文字・小文字表記に関係なく適用されます。

ページ変数

• 追加: 「コンテンツとエンゲージメントデータ」グループに、行動トラッキングや GA4 のコンテンツグルーピングに役立つ新しいページ変数オプションを追加しました。コンテンツの単語数 (pageContentWordCount) と推定読了時間 (pageReadingTime。gtm4wp_reading_time_wpm フィルターで調整可能) は、キリル文字、ギリシャ文字、ヘブライ文字、アラビア文字を含むあらゆる言語、およびスペースを使わない中国語、日本語、韓国語の文字体系でも正しくカウントされます。最終更新日 (pageModifiedDate および pageModifiedDate* ファミリー) と日単位のコンテンツの経過日数 (pageContentAgeDays)。コメント数とステータス (pageCommentCount、pageCommentStatus)。ページテンプレート (pageTemplate)、アイキャッチ画像の有無 (pageHasFeaturedImage)、ページ階層 (pageParentID、pageDepth)、先頭固定表示フラグ (pagePostSticky)。メインカテゴリー (pagePrimaryCategory、pagePrimaryCategoryName) は Yoast SEO / Rank Math から検出され、先頭のカテゴリーをフォールバックとして使用し、gtm4wp_primary_category_term_id フィルターで上書き可能です。ページの言語 (pageLanguage) は WPML / Polylang から検出され、サイトのロケールをフォールバックとして使用し、gtm4wp_page_language フィルターで上書き可能です。
• 追加: ページ変数の投稿者データに PublishPress Authors 対応を追加しました。PublishPress Authors を使用しているサイトでは、1 件の投稿に複数の投稿者 (共同投稿者やゲスト投稿者) を設定できます。これは E-E-A-T の観点で重要です。PublishPress Authors が有効な場合、pagePostAuthor / pagePostAuthorID はそこから取得されるようになります。これは ゲスト投稿者が単独で設定されている投稿でも同様で、これまでは代わりにその投稿を作成した WordPress ユーザーが報告されていました。また、そのような投稿に複数の投稿者がいる場合、GTM4WP は pagePostAuthors (投稿者名のリスト) と pagePostAuthorIDs (投稿者 ID のリスト。ゲスト投稿者は負の ID を使用) も出力します。単一値の変数は後方互換性のために残されており、主要な (最初の) 投稿者を指します。この 2 つの配列は、gtm4wp_page_post_authors と gtm4wp_page_post_author_ids でフィルタリングできます。既存の「投稿者名」/「投稿者 ID」オプションが、オン / オフの切り替えとして使われます。PublishPress Authors が有効でない場合、動作は変わりません。
• 追加: 独立した 「投稿のカスタムフィールド (meta)」 オプション (ページ変数 → 投稿データ) を追加しました。これまで「投稿のターム」オプションは、まったく異なる 2 つの処理を行っていました。投稿のタクソノミー値を追加するだけでなく、アンダースコアで始まらない名前を持つすべてのカスタムフィールドを、その値とともに公開ページのデータレイヤーに公開していたのです。オプションの説明にはタクソノミーのことしか書かれていなかったにもかかわらずです。カスタムフィールドはプラグインやテーマが独自のデータを保持する場所であるため (Advanced Custom Fields もこの方法で値を保存します)、これによって内部メモ、ID、価格、連絡先情報などが、サイト所有者に知らされることなく、訪問者なら誰でも読めるページに掲載されてしまう可能性がありました。この 2 つは現在、別々のオプトインとなり、カスタムフィールド用のオプションでは何を公開するかが明確に示されるようになりました。既存サイトでは、ほぼ何も変わりません: 「投稿のターム」を有効にしていた場合、アップグレード時に新しいオプションも自動的にオンになるため、これまでと同じカスタムフィールドが引き続き pagePostTerms.meta の下に届きます。唯一の違いは、この後で説明する値のパック形式と構造の修正のみです。カスタムフィールドを公開するつもりがなかった場合は、新しいオプションをオフにしてください。その下にある 「投稿のカスタムフィールド – 公開するキーのみを指定」 ボックスを使うと、コンテナに実際に必要なわずかなフィールドだけを指定できるため、プラグインやテーマ、編集者が後から追加したフィールドが、勝手に公開ページに表示されるようなことはなくなります。空欄のままにすると、これまでどおりすべてを公開し続けます。個別のキーは、引き続き gtm4wp_post_meta_in_datalayer フィルターを使ってコード側で除外できます。
• 追加: 「カテゴリーリストに親カテゴリーを含める」という任意設定 (ページ変数 → 投稿データ) を追加しました。デフォルトでは、pageCategory データレイヤー変数には、現在の投稿またはアーカイブに直接割り当てられたカテゴリーのみが一覧表示されます。この設定をオンにすると、各カテゴリーの親 (祖先) カテゴリーも追加されます。直近の親から最上位のカテゴリーまでが対象で、リストは重複排除されます。この設定は、親オプションである「現在の投稿 / アーカイブのカテゴリーリスト」がオフになっている間、設定画面上でグレーアウトされます (どのオプションも、このような依存関係を宣言できるようになりました)。デフォルトではオフのため、有効にするまでは現在の出力は変わりません。オリジナルパッチを提供してくれた @twentyfortysix に感謝します (#220)。
• 変更: ブラウザー、OS、端末のデータは、User-Agent Client Hints を使用してブラウザー内で収集され、gtm4wp.deviceData イベントとしてプッシュされるようになりました (同梱されていた WhichBrowser ライブラリを置き換えるもので、Safari と Firefox では取得できる詳細情報が少なくなります)。
• 修正: テーマやプラグインが単一ページでグローバルな post オブジェクトを未設定のままにしているサイトで、PHP の警告 (Attempt to read property "post_author" on null) が繰り返し発生する問題を修正しました。投稿から導出されるページ変数 (投稿タイプ、カテゴリー / タグのリスト、投稿者データ、日付、ターム一覧、単語数と読了時間、コンテンツの経過日数、コメントデータ、ページテンプレート、アイキャッチ画像フラグ、ページ階層、先頭固定表示フラグ、メインカテゴリー、投稿 ID、投稿フォーマット) はすべて、このようなリクエストではプレースホルダー値として出力される代わりに、単純に省略されるようになりました。また、メインクエリーのグローバル変数が利用できない場合は、postCountOnPage / postCountTotal 変数も同様に省略されます。これは投稿者アーカイブでも同様です。pagePostAuthor / pagePostAuthorID は、投稿者オブジェクトが設定されていない場合、空の名前と投稿者 ID 0 として送信される代わりに省略されます。wordpress.org のサポートフォーラムで報告があったもの …