ブログ
Shopify・WooCommerce ストアのサーバーサイドタギング:何が発火し、何が発火せず、何をインストールすべきか
公開 · 読了 6 分
サーバーコンテナは、ストアに購入を報告させるものではありません。ブラウザが送信したものを、Google のホスト名ではなくあなた自身のホスト名から転送するだけです。それでも価値はあります。広告ブロッカーと Safari を合わせると、ストアのコンバージョンのかなりの割合が落とされているからです。ただし購入はまず送信されなければならず、大半のストアが動いている 2 つのプラットフォームでは、初期状態で何もそれを送信しません。これは、すべてのお客様に初日に渡せていればと思う記事です。
7 つのイベントと、それらに共通するただ 1 つのこと
GA4 は購入ファネルに 7 つのイベントを定義しています。view_item_list、view_item、add_to_cart、remove_from_cart、begin_checkout、add_payment_info、purchase です。名前は GA4 のものであってプラットフォームのものではなく、同じ 7 つが Shopify でも WooCommerce でも自作のショップでも通用します。
共通しているのは仕組みです。それぞれは、ページの dataLayer への、正確にその名前での、GA4 形式の ecommerce オブジェクトを伴うプッシュです。タグマネージャーのトリガーがその名前を待ち受け、GA4 イベントタグが ecommerce オブジェクトを読んで送信します。名前を綴り間違える、オブジェクトを 1 階層深く入れ子にする、間違ったページでプッシュする — いずれの場合も、タグはエラーを出さずに永遠にそこに座っているだけです。購入のプッシュはこのような形です:
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: 'ORD-10442',
value: 89.90,
currency: 'EUR',
items: [
{ item_id: 'SKU-118', item_name: 'Trail jacket', price: 89.90, quantity: 1 }
]
}
});先に ecommerce: null をプッシュするのは飾りではありません。これがないと前のイベントの items が次のイベントに漏れ込み、3 ページ前の view_item が purchase の中に現れます。
Shopify:テーマからチェックアウトは見えない
Shopify のテーマにインストールしたコンテナは、ストアフロント — 商品ページ、コレクション、カート — で読み込まれます。チェックアウトとサンクスページでは読み込まれません。それらは Shopify が自社ドメインと自社テンプレートで配信しているからです。したがってテーマにインストールしたコンテナは view_item と add_to_cart を送信できますが、どんな設定をしても begin_checkout、add_payment_info、purchase は決して送信しません。
その 3 つは Custom Pixel から来ます。Shopify のピクセルサンドボックスはチェックアウトイベント(checkout_started、payment_info_submitted、checkout_completed)を公開しており、ピクセルが独自の dataLayer へプッシュできます。小さなスクリプトで、それぞれを上記の GA4 イベント名と形式に対応付けます。ストアフロントのイベントは引き続きテーマから来るので、完全な構成には両方が必要です。閲覧側には dataLayer アプリかテーマのスニペット、チェックアウト側には Custom Pixel です。
もう 1 つ決めることがあります。Shopify の Google & YouTube チャネルは、コンテナを介さずに GA4 イベントを直接送信できます。そこで GA4 プロパティを接続し、かつ同じプロパティをコンテナ経由でも流すと、すべての購入が二重に数えられます。どちらか一方を選んでください。目的がファーストパーティでの収集なら、選ぶべきはコンテナで、チャネル側のアナリティクス接続はオフのままにします。
WooCommerce:コアは何もプッシュしない
WooCommerce 自体は dataLayer を一切書きません。書くのはプラグインで、多くの人が使うのは GTM4WP です。その GA4 e コマースオプションは、7 つのイベントを正しい形式で正しいページに生成します。商品ページで view_item、ボタンで add_to_cart、チェックアウトページで begin_checkout、注文完了ページで purchase です。
WooCommerce の典型的な不具合は purchase の二重計上で、原因ははっきりしています。注文完了ページが再読み込みされるのです。訪問者が更新する、決済プロバイダから戻ってくる、テーマが 2 回リダイレクトする — そのたびに同じ transaction_id で purchase が再びプッシュされます。GA4 はセッション内では transaction_id で購入を重複排除するため大半は防げますが、翌日の再読み込みは防げません。プラグインの「注文ごとに 1 回だけ発火」設定はオンにする価値があります。フラグをサーバー側に保持するので、再読み込みではリセットされません。
SignalHost が構築するもの
ウィザードにサイトがショップだと伝えると、ウェブコンテナに 7 つのイベントそれぞれのカスタムイベントトリガーと GA4 イベントタグ — 合計 14 のエンティティ — が追加されます。すべて SH という接頭辞付きなので、既存のものと衝突することはありません。各タグは ecommerce オブジェクトを dataLayer から直接送信するため、items、value、currency、transaction_id はフィールドごとの変数なしで通り、測定 ID は継承ではなく明示的に指定されます。
あなたのストアには何もインストールされません。トリガーは待ち受けるだけで、プッシュはプラグインかピクセルのものです。「オンラインショップなし」を選ぶと 14 のエンティティが省かれるだけで、他は何も変わりません。ページビュー、scroll、その他の標準イベントは、いずれにせよコンテナを経由します。
サーバー側にはイベントごとの設定はありません。サーバーコンテナの GA4 タグは、名前が何であれ受け取ったすべてのイベントを転送するので、サイト側の新しいイベントに対して当社側の変更は不要です。Meta Conversions API と TikTok Events API の送信先を接続した場合も、同じ 7 つの名前を自動で対応付けます。同じプッシュから、purchase は Meta では Purchase、TikTok では CompletePayment になります。
テスト注文 1 件で確認する
テストモードで実際の注文を、あるいは後で返金する安価な注文を 1 件行い、コンテナページのイベントリストを見てください。順に view_item、add_to_cart、begin_checkout、add_payment_info、purchase が、それぞれ 1 回ずつ現れるはずです。Shopify で purchase がなければ Custom Pixel が未インストールかプッシュしていません。WooCommerce で begin_checkout がなければ、たいていプラグインのチェックアウトイベントが無効になっています。
Google 広告のコンバージョンをコンテナ経由にしている場合、purchase がコンバージョンイベントで、その値・通貨・トランザクション ID は同じ ecommerce オブジェクトから読み取られます。value のない purchase のプッシュは、価値ゼロのコンバージョンを記録します。レポート上ではれっきとした数字ですが、間違った数字です。
