Google Tag ManagerでAMPを測るならAMP用containerを新しく作る

Google Tag ManagerでAMP pageを測るなら、AMP site用のcontainerを新しく作ります。通常pageで使うcontainerへtagを足すことと、AMP pageで使えるtagを設定することは別です。AMPのページで何を計測するかを決め、通常pageの計測結果とどう比べるかを決めてから、snippetを置きます。

AMP containersでは、Google Analyticsのほか、AdWordsやDoubleClickを含むtagを使えます。scrollの深さやpage titleのような値には、AMP Analyticsのbuilt-in variablesも使えます。ただし、通常pageで使うtag、variable、triggerが同じ条件で使えるとは限りません。同じ名前のeventを送っても、送る条件が違えば同じ数字として比べられません。

AMP用containerを分ける理由は、通常page用の設定を捨てるためではありません。AMP pageで動かせるものと、通常pageでだけ使うものを分けて管理するためです。通常pageのcontainerには、クリックやform送信など、ブラウザー上の動作に応じたtagが入っていることがあります。AMP pageに同じ名前のtagがあっても、発火の条件や送れる値が違えば、同じ設定を複製したとは言えません。containerごとに、何を測るためのものかを短く残します。

tagを作る前に、数字を見て何を判断するのかを一文にします。「AMP pageの閲覧があるかを知る」のか、「記事を最後まで読む人がいるかを知る」のかで、必要なtagと確認する値が変わります。pageviewを送るだけなら、読まれた深さや問い合わせにつながったかまでは分かりません。反対に、細かなeventを増やしても、誰も見返さなければ運用の負担だけが残ります。計測する行動は、次に決めることへつながるものから選びます。

container、tag、計測の問いを別に決める

説明用の仮例として、記事pageを最後まで読まれたかを見たい場合を考えます。通常pageではscroll計測を使い、AMP pageでも同じようなeventを送りたいとします。このとき最初に決めるのは、どちらのpageでも同じ深さを測れるか、同じ記事を読んだ人をどう区別するかです。containerを二つ作っただけでは、比較条件はそろいません。

pageviewの確認も同じです。AMP pageのpageviewを知りたいのか、通常pageとAMP pageを合わせた記事閲覧を知りたいのかで、見る数字が変わります。二つのcontainerから同じpropertyへ送る場合は、AMPか通常pageかを後から分けられる条件を決めます。別propertyへ送る場合は、単純に足し合わせてよいかを先に考えます。

説明用の仮例で、同じ記事に通常pageとAMP pageがある場合を考えます。一人が検索結果からAMP pageを読み、あとで通常pageを開くことがあります。この二つを同じ記事の閲覧として扱うのか、別のpageviewとして扱うのかで、集計の意味が変わります。containerを別にしただけでは、この判断は決まりません。集計する人が、AMPと通常pageの数字をどの目的で見るのかを決め、区別に使う値とreportの見方をそろえます。

広告のconversionを測る場合も、通常pageで動いているtagをAMPへ増やせば終わりではありません。広告から来た人がAMP pageを開いたあと、どのpageで問い合わせを完了するかを確認します。AMP pageではなく通常pageのformで完了するなら、AMP containerのtagだけでは相談の完了を数えられないことがあります。入口のpageviewと、事業にとって意味のある問い合わせを別に測ることが必要です。

最初は一page、一tagでpreviewする

Googleの案内では、AMP用containerを作り、AMP pageへsnippetを置き、最初のtagを作ってpreviewしてからpublishします。この順番は、設定を増やすためではなく、どこで問題が起きたかを分けるためです。

1. AMP pageで知りたい行動を一つ選ぶ。
2. AMP用containerを作り、その行動のためのtagを一つ作る。
3. AMP pageへsnippetを置き、代表URLでpreviewする。
4. tagが動くことと、送る値が意図どおりかを確認する。
5. 通常pageと比べる必要があるなら、同じ問いへ答えられる条件かを確認してからpublishする。

最初からpageview、scroll、広告、外部サービスのtagをまとめて入れると、問題が出たときに原因を分けにくくなります。tagを増やす前に、一つのtagがどのページで、どの条件で、何を送るかを確認します。

previewでは、tagが表示されたかだけを見ません。代表URLを開き、意図した行動を一度行い、どのtagが動いたかを確認します。scrollを測るなら、pageを少し開いただけで何度も送られないか、決めた深さまで読んだときに送られるかを見ます。page titleのような値を送るなら、別の記事を開いたときに同じ値のままになっていないかを確認します。動作したという表示と、送った内容が正しいことを分けます。

問題が出たときは、tagを増やして様子を見ません。まずAMP pageのHTMLへcontainer snippetが出ているか、次にpreviewでcontainerを読み込めているか、そのあとtagの条件と値を確認します。template、container、tagの順に切り分ければ、原因と無関係な設定を替えずに済みます。通常page用のcontainerが同時に出ているなら、二重計測の可能性も確認します。

外部の制作担当へ設定を依頼する場合は、AMP containerの所有者、AMP pageのtemplate、追加したtag、previewを確認した人を残します。Tag Managerを直せる権限と、siteのtemplateを直せる権限が別なら、どちらを確認するかも決めます。

containerの所有は、設定画面へ入れる人だけの問題ではありません。制作会社が作ったcontainerを使い続け、事業側に編集できる人がいなければ、tagの追加や不要なtagの整理を自分で判断できません。依頼が終わる前に、container名、編集できる人、公開できる人、AMP templateを直せる場所を確認します。作業を任せることと、設定の所在を失うことは別です。

AMP pageを増やすときは、最初に有効だった一pageをそのまま証拠にしません。画像がない記事、長い本文、外部linkを含む記事など、条件が違うpageを代表として開きます。同じtemplateでも入力内容によって出力が変わるためです。一tagで確認した条件を残しておけば、次のtagや次のpageを追加するときに、何を比較すればよいかが分かります。

最初の一手は、AMP pageで測りたい行動を一つだけ選ぶことです。その行動のためのtagをAMP containerへ作り、一pageでpreviewしてから広げます。