完了画面での JavaScript によるトラッキングが多重に行われる

[seasoftjapan]

下記でも $this->httpCacheControl('nocache'); を行うべき。

• LC_Page_Shopping_Complete (GA eコマーストラッキングが多重計上され事象があった)
  • f73a268 テンプレート変数 $tpl_order_id で分岐することで、重複計上を回避できるようになる。
• LC_Page_Regist_Complete (GA コンバージョントラッキングが多重計上される懸念がある)
  • f73a268 により、テンプレート変数 $tpl_customer_id で分岐することで、重複計上を回避できるようになる。
• LC_Page_Contact_Complete (GA コンバージョントラッキングが多重計上される懸念がある)
  • LC_Page_Contact_Complete は、ID の連携がないため、 f73a268 の対応では不十分。コンバージョン計測する人も少ないと思うので、本件では黙殺する予定。

会員登録は、会員IDの連携が不完全だった。少なくともデフォルトでは完了画面に引き継がれない。この不具合も同時に改修した(f73a268)。値渡しを、URLの問い合わせ文字列から、セッション変数に変更する。これにより、この値の信頼性は高まると期待するが、本当に頼って大丈夫かは未検証である。

[ttsuru]

@seasoftjapan
eコマースタグはIDベースでの集計なので重複コンバージョンにはならないかと思います。

nocacheがあることで逆にリロードなどの挙動の際に複数形状される可能性があるのではないでしょうか。

[seasoftjapan]

@ttsuru

eコマースタグはIDベースでの集計なので重複コンバージョンにはならないかと思います。

私もそう考えていましたが、実際に検証したところ、なりました。金額・数量が2倍・3倍と増加する事象を確認済みです。

nocacheがあることで逆にリロードなどの挙動の際に複数形状される可能性があるのではないでしょうか。

最終的にはコンバージョンの JavaScript として何を送出するか次第ですが、EC-CUBE の注文番号のセッション変数は1回目でクリアされています。その場合に、eコマース計上されないように、カスタマイズするのは自然では無いでしょうか。

[so-amuamu]

nocacheの弊害が無いか確認したい

[seasoftjapan]

nocacheの弊害が無いか確認したい

当該画面は、GET で表示し、且つ、何度もロードできるので、支障ないと考える。あえて、重隅するなら、アクセスログには計上されやすくなるため、(本件で想定している JavaScript ではなく) WEB サーバーのログベースで追跡する場合にはノイズが増えるかもしれない。

また、類似した画面である LC_Page_Entry_Complete は、現況で $this->httpCacheControl('nocache'); を行っている。

[so-amuamu]

異論が他の人から出なければnocacheで行きましょうか