支援実績

計測が「予約確定ボタンのクリック」になっていて入力エラーでも数えていました。完了画面にだけ出る要素が表示されたときに数えるよう直しました。

キーイベントの条件にしていた完了ページのURLが実際のURLと違っていました。条件を直して正しく数えられるようにしました。

LINE側は「そのURLから来た人」を数え、Google広告は広告をクリックした人だけを数えます。日時で1件ずつ突き合わせてずれの条件を特定しました。

「決済手続きの開始」で売上を計上していて購入完了が目標に入っていませんでした。売上を持たせるのは購入完了だけにしました。

予約フォームが別ドメインのiframeの中にありました。iframe側にもGTMを入れ、それでも取れない場合は完了時にdataLayerで送ってもらう形にしました。

完了ページは計測できても、どこから来た人がCVしたかが分からなくなります。クロスドメインの設定を先に入れておく必要があります。

リンクや画像ごとに重ならないclass名を付けてもらい、GTMでボタンごとに計測しました。

押した瞬間なら次のページを見ずに離脱した人も数えられます。導線がボタンだけなら遷移先の表示で十分で、設定も簡単です。

同じ時期のサイトの変更とデバイス別の直帰率を見ます。この案件ではトップページを変えた後にスマホだけ直帰率が急に上がっていました。

流入チャネル別に「セッション」「売上」「購入率」に分けます。購入率が変わっていなければ課題はサイトの中ではなく流入の方です。

サーチコンソールのクエリ×LPを前年と比べ「順位も表示も下がった」「需要が減った」「順位だけ下がった」に分けると直すページが決まります。

ページタイトル系は回遊を含む数え方なので入口は分かりません。「ランディングページ」のディメンションで見ます。

GA4の「AI Assistant」のチャネルで見られます。アプリ経由などは判定されないことが多いので、実際はもっと多いと考えてください。

機械が読みやすい構造、FAQ、出典を明記した信頼性などが共通して効きます。出てほしい質問を20〜30個決めて定期的にAIに投げ、紹介された割合で効果を測ります。

前月の納品版を見本に渡し、推測は「仮説」と明記させるなどのルールを決めると使えます。最後は人が表と照らし合わせます。

APIの制限やしきい値、サンプリングを避けられ、SQLでセグメントや過去のCVを再現できます。SQLを書く人が必要なことと従量課金がかかることは先にお伝えします。

Eコマースの設定とBigQuery連携が前提です。会員ごとに見るならログインIDをハッシュ化してユーザーIDとして送り、SQLで整形してからダッシュボードにつなぎます。

期間内に初めて来てもう一度来た人は両方に数えられるためです。GA4はディメンションと指標で「新規」の定義も違うので、どちらで見るかを先に決めます。