拡張eコマースの商品インプレッションは画面に表示した時点で送信する

Google Analyticsの拡張eコマースで商品インプレッションを計測するなら、商品データをページ読込時にすべて送信せず、商品が画面に表示された時点で送ります。ページに存在する商品と、利用者が見られる位置まで進んだ商品は別だからです。

ページの下方にある商品まで読込時に送ると、利用者がそこまでスクロールしなくても表示回数へ加わります。その数字から商品の配置を判断すれば、下にある商品を実際より多く見られたものとして扱うことになります。

ページに読み込んだ商品と画面に表示した商品を分ける

商品一覧を作る処理は、ページへ配置する商品を知っています。しかし、Google Analyticsへ送りたい商品インプレッションは、利用者が画面で見られる位置へ入った商品です。

Google Analytics公式ブログの解説は、ページ読込時に商品objectの配列をdataLayerへ加える方法では、画面の下にある商品まで送信される問題を示しています。解説では、商品を一時保存し、最初に見える商品だけを送り、スクロール後に新しく見えた商品をまとめて送ります。

ここで分けるべきものは三つです。

読込済みを表示済みと同じにしないことが、最初の条件です。表示済みとクリック済みも別です。商品が見えた回数と選ばれた回数を分けなければ、一覧の配置を評価できません。

最初の表示とスクロール後の表示を同じ規則で拾う

計測処理は、ページを開いた直後とスクロール後で、同じ表示判定を使います。

1. ページへ配置した商品を、送信前の一覧へ保持します。
2. ページを表示したら、画面内にある商品を調べます。
3. 初めて画面へ入った商品だけを送信対象へ加えます。
4. スクロールが止まった時点で、追加された商品をまとめてdataLayerへ渡します。
5. 同じページで送信済みの商品は記録し、上へ戻っても再送しません。

スクロールするたびに一商品ずつ送る必要はありません。公式ブログの解説も、新しく見えた商品をまとめて送る方法を示しています。送信回数を増やすことより、表示判定と商品IDの対応を崩さないことを優先します。

説明用の仮例です。一覧に30商品があり、最初の画面へ8商品が見えるとします。読込時に30商品を送れば、残り22商品も表示済みになります。最初に8商品だけを送り、スクロールで次の6商品が見えたときにその6商品を送れば、利用者が到達した範囲を数字へ反映できます。

商品の重複送信をページ内で防ぐ

利用者は下へ進むだけでなく、比較のために上へ戻ります。表示判定のたびに同じ商品を送ると、一人の一回の閲覧でインプレッションが増え続けます。

送信済みの商品IDをページ内で保持し、次の表示判定では未送信の商品だけを選びます。商品IDだけでなく、どの一覧のどの位置にあったかも実装側で対応を保ちます。同じ商品が「おすすめ」と「検索結果」の両方へ出る場合は、二つの一覧を混ぜないためです。

ただし、重複防止の範囲を無条件に広げないでください。別ページへ移動したあとに同じ商品が表示された場合まで消すと、別の一覧で生じた表示を記録できません。まず、一ページの表示中に同じ商品を二度送らない規則から始めます。

画面幅と商品配置を変えて送信結果を確かめる

実装後は、レポートを見る前に送信内容を確認します。同じページでも、広い画面と狭い画面では最初に見える商品数が変わります。画像の読込や商品列の組み替えがあるページでは、表示位置も変わります。

確認では、次の四つの操作を一つずつ行います。

• ページを開き、最初に見える商品のIDだけが送られるか
• 下へ進み、新しく見えた商品のIDが追加されるか
• 上へ戻り、同じ商品が再送されないか
• 画面幅を変え、表示されていない商品が混ざらないか

解析の担当者は、何を表示済みとするかを決めます。制作担当者は、その判定をコードへ実装します。サイト運営側は、商品ID、一覧名、商品位置が販売管理上の名称と対応しているかを承認します。計測作業を委託しても、どの状態を数字として残すかまで外部へ預けない方が、変更時の検証が速くなります。

商品が画面に入った事実は、商品名を読んだことや購入を検討したことの証明ではありません。商品インプレッションは表示機会の指標です。クリックやカート投入、購入と組み合わせ、一覧のどの位置から次の行動へ進んだかを見ます。

最初の一手は、商品一覧を一ページだけ選び、ページ読込時に送っている商品IDと、最初の画面に見える商品IDを並べることです。二つが違うなら、表示判定を送信前へ追加します。