購入手続きでキャンペーンの流入元が失われる場所を調べる

キャンペーンのレポートには訪問が記録され、ショップにも注文完了の記録がある。それなのに、分析レポートでは多くの購入が決済サービスからの流入になっていたり、どのキャンペーンから来たのか分からなくなっていたりします。どの記録も実際の出来事を示している可能性があります。欠けているのは売上そのものや短縮リンクの動作ではなく、システム間の引き継ぎであることが少なくありません。

ドメインをまたぐ購入のアトリビューションを調べるには、訪問者がサイトに入り、支払い、戻ってくるまでをたどります。短縮リンクサービスが観測できるのは自分のリダイレクトであり、それだけで別ドメインの購入者まで自動的に特定できるわけではありません。追跡パラメータを増やしたり、特定の管理画面が間違っていると決めたりする前に、どこでつながりが切れたかを確かめましょう。

ドメインをまたぐ購入経路を図にする

通常の購入で通るアドレスを並べます。キャンペーンの入口、ランディングページ、ショップ、外部の購入手続き画面、決済確認、領収書のページです。それぞれを管理する担当と、計測が設置されている場所を記します。サブドメイン、別のショップドメイン、第三者の決済ページでは、実装上の制約が異なる場合があります。

次に、各レポートが実際に数えているイベントを特定します。リダイレクトのリクエスト、ランディングページのセッション、購入手続きの試行、支払い確定は同じではありません。再試行、プレビュー用クローラー、ブラウザの制限、カート放棄によって、故障がなくても件数は異なります。流入元を調べる前に、支払い済み注文の正本にする記録を決めてください。

キャンペーン収益を明確なデータで測る方法は、この定義の整理に役立ちます。今回の調査では各境界に、何を渡すべきか、実際には何が届くか、どの権限を持つシステムが保存してよいか、という具体的な問いも加えます。曖昧な報告の問題を、一つずつ確認できる引き継ぎに分解できます。

決済より先に最初の到着ページを確認する

機密性がなく、見分けやすい値を使ったテスト用キャンペーンから始めます。新しいブラウザ環境で配布用アドレスを開き、最後の到着ページを確認します。意図した参照元、メディア、キャンペーンの値が、リダイレクトを通過しても残っているかを調べてください。最初の計測情報が届いていなければ、購入手続き側の設定で未取得の証拠を復元することはできません。

テスト中に選んだ同意設定も記録します。任意のアクセス解析を拒否した訪問者と、許可した訪問者で計測の残り方が違うのは、意図された結果かもしれません。ブラウザの保護機能や拡張機能も収集に影響します。イベントがないことをすべて実装ミスとせず、レポートを埋めるために本人の選択を回避しないでください。

サイト内の移動でキャンペーン情報が上書きされていないかも確認します。内部プロモーションのラベルには計測設計が必要です。購入ボタンすべてに新しい流入パラメータを無造作に付けると、元の参照元が分かりにくくなります。UTMによるコンバージョン計測では、ツール間で比較する前にキャンペーン名をそろえる考え方を説明しています。

クロスドメイン計測でつながる範囲を理解する

Google Analyticsには、条件を満たすサイトで計測情報を共有するためのクロスドメイン設定があります。設定したドメイン間を訪問者が移動するときに、リンカーパラメータを使います。リダイレクトや到着先のコードが必要なパラメータを削除すると、この処理が途切れることがあります。必要な設定は解析とサイト実装の側にあり、公開短縮URLだけで完了するものではありません。

ただし、すべての外部購入画面を一つの連続したセッションにまとめられるわけではありません。決済事業者がページを管理し、スクリプトを制限していたり、別の連携方法を用意していたりします。訪問者が通る先々に追跡を設置しようとせず、提供元が許可する方法を確認してください。経路によっては、サーバー側の注文記録と、利用が認められた連携イベントで照合する必要があります。

製品の役割も区別しましょう。Lumeraya Linksはキャンペーンの入口として使えますが、それを使うだけでショップと決済システム間のGoogle Analytics設定が済むわけではありません。二つの管理画面を接続すれば識別子も同じになると考えず、実際に取得している計測を整理します。

決済からの参照とつながりの欠落を分けて扱う

決済ドメインが参照元になると、それ以前のキャンペーンが見えにくくなることがあります。解析サービスに不要な参照の設定があれば、決済サービスから戻った訪問を適切に分類できる場合があります。しかし、その設定は失われた顧客の関連付けを作らず、削除されたパラメータを戻さず、すべての取引の発生元を後から証明するものでもありません。

支払い後の戻り方を丁寧に調べます。自動で戻るのか、確認ボタンを押すのか、支払い後にブラウザを閉じるのか。サンクスページへの到着だけで購入を計測していると、支払いが完了していてもブラウザのイベントが発生しない場合があります。逆に、イベントを重複排除していなければ、確認ページへの再訪で二重計上されることもあります。

入金の有無は、決済または注文システムの確定ステータスで判断します。記録を照合するときは、権限のあるシステム内で安定した取引IDを比べてください。そのIDを公開キャンペーンタグに露出させないことも重要です。支払い成功と計測できるブラウザの帰還は関連しますが、どちらかをもう一方の代わりにしてはいけません。

必要な分岐ごとに条件をそろえてテストする

同じ状態の残ったブラウザで何度も購入するのではなく、小さなテスト計画を作ります。通常のパソコン用ブラウザ、スマートフォンのブラウザ、利用者が多ければアプリ内ブラウザを含めます。実装が対応する同意状態も加えます。利用できるならテスト環境や明示されたテスト取引を使い、実際の顧客注文を実験に混ぜないでください。

毎回、開始したキャンペーン、時刻、端末の種類、同意の選択、購入手続きへの遷移、確定結果を記録します。イベントを照合できる情報は残しつつ、パスワード、決済認証情報、個人情報を解析ラベルに入れないでください。スクリーンショットに顧客の住所やトークンがあれば、報告を共有する前に隠します。

変更は一つずつ行います。ドメイン設定、リダイレクト規則、購入イベントを同時に変更すると、結果が改善しても何が効いたか分かりません。変更のたびに同じ分岐を再テストします。管理者としてログインした自分のセッションだけで成功しても、公開された購入手続きが正しい証拠にはなりません。

残る不確実性をそのまま伝える

証拠に応じて、購入数、計測されたキャンペーンのコンバージョン、流入元不明の取引を別々に示します。合計を比べる前に対象期間とタイムゾーンをそろえます。各システムの定義に従って、処理の遅れ、返金、再試行を考慮してください。きれいな割合よりも、どの段階を直接観測できたかが分かる方が役立ちます。

入口リンクについては Lumeraya Linksのヘルプを、決済の証拠には購入手続きの提供元がサポートするツールを使います。調査の成果は、検証済みの引き継ぎ図、未解決の境界ごとの担当、計測上の制約を記した説明です。根拠のない流入元の物語にすべての注文を押し込むより、キャンペーン担当者が判断しやすくなります。