JSON-LDで定義されたメタデータをGTMから読み取る方法

Googleタグマネージャー

実装

記事公開日: 2018年05月22日

多くの人が、HTML上からGoogleタグマネージャにデータを連携するのに、「dataLayer」と呼ばれるデータレイヤー変数を使う手法を利用しています。

しかしながら、私はこの「HTML上からGoogleタグマネージャにデータを連携する」なら「データレイヤー変数を使う」という風潮をあまり好ましいとは思っていません。当然、データレイヤー変数を使うべき内容のものもあると思います。でも、それ以外の選択肢も知った上で、どういった方法でGoogleタグマネージャにデータを連携するべきかを考えるべき時期にきています。

なぜ、データレイヤー変数が万能ではないのか、とその解決案

今のWebにおけるメタデータの定義方法

今、Webページを作成しようとすると、たくさんのメタデータを定義することが推奨されています。有名なものを挙げると、

HTMLのタイトルタグ情報
HTMLのメタタグ情報(特にmeta-description)
FacebookのOpen Graphデータ
TwitterのOpen Graphデータ
JSON-LDやMicrodataなどのデータ
ファビコン情報
Web Clip(iOSのアイコンなど)のデータ
各マーケティングツールがページごとに必要とする情報

などがあります。これだけでなく、Webサイトには様々なマーケティングタグがあり、そのマーケティングタグで送信したい情報を受け渡すために、メタデータが追加されていきます。

そしてこれらのメタデータの内容は、驚くべきことに多くが重複した情報になっています。OGPのタイトル情報とJSON-LDのタイトル情報に<title>タグと同じ情報を入れたり、ページURLの情報をcanonicalとOGPとJSON-LDに入れたりと、複雑化していきます。そして、　さらにWebマーケティングの多様なデータも追加されるので、カオスな状態に陥ってしまいます。

Webのデベロッパーの方がWebマーケティングのツールの仕組みについて把握できていれば、Webマーケティングのツールで必要な情報の取得方法を最適化することもできるのですが、今のWebマーケティングのツール事情を把握できているエンジニアはごく僅かです。

今のメタデータ管理の問題点

前述したようにHTMLの様々な箇所で同じメタデータを扱っていると発生しうる状況が、「メタデータの一部の更新漏れ」です。例えば、

過去に作成したHTMLをコピーして新しいページを実装したが、一部のメタデータの変更が漏れていた

という状況です。例えば、OGPの情報を更新し忘れると、

せっかく誰かがFacebook(や、Twitterなど)でページをシェアしてくれても、そのときに表示されるタイトルやOGP画像、説明文、リンク先などが過去のページ情報となってしまう

ということが起こりえます。OGPの場合は制作会社も正しく動作しているかテストしそうですが、これがWebマーケティングのタグだと、制作会社のテストから漏れてしまうことも多々あります。

他にも、マーケティング・チームが新しいマーケティングツールを導入しようとすると、そのツールに合わせてHTML側を改修してもらいタグを実装する必要が出てきます。高度なマーケティングツールを導入しようと思えば思うほど、このHTMLとツールタグ間での情報のやり取りのために新たなメタデータが必要になり、ツール導入を妨げます。

どう解決するべきか

我々の力でブラウザや<title>タグやメタタグ、OGPの仕様を変えることができるのであれば、schema.org(JSON-LDやMicrodataなど)を通じて、メタデータを全て書き出しておき、<title>タグなどの情報は、これらのメタデータをどのように割り当てるかのみを記載していけば情報の重複が解決します。

しかしながら、ブラウザや<title>タグ、メタタグ、OGPの仕様を変えることは我々にはできません。我々ができるのは、マーケティングツールが増えるときに、マーケティングツールごとにHTMLの実装を行わなくても良いようにすることです。

今まで多くのサイトでは、Googleタグマネージャを使って、dataLayer変数を通じてHTMLから情報を受け取っていました。ここで提唱する解決策は、dataLayer変数を使うのではなく、HTML上に既に埋め込まれているschema.orgのメタデータをタグマネージャから取得し、その値を各種マーケティングタグで利用する方法です。

「schema.orgはリッチスニペット表示のために設置するもの」と思い込んでいる人も多いと思います。しかし、それは正しくありません。正確には、「schema.orgは、構造化マークアップのためのものであり、それによりサイトに記載されている情報をプログラムが適切に理解しやすくするためのもの」です。プログラムがサイトに記載されている情報を適切に理解できることで、現時点ではリッチスニペットという仕組みが実現できているのです。しかし、schema.orgの活用例はリッチスニペットに限る必要はありません。もともとの目的が「プログラムがコンテンツを適切に理解しやすくするためのもの」である以上、各種マーケティングタグはschema.orgの情報をもっと活用するべきです。

実際、既にGoogle Adwordsの中のショッピング広告の分野では、商品アイテムの自動更新という形で、構造化データの利用が行われています。

GTMからJSON-LDで定義された値を読み取る方法

ここでは、記事タイトルにあるように、GTMからJSON-LDで定義された値を読み取る方法を紹介します。

元となるJSON-LDの例

ここでは、下記のJSON-LDを想定してGTMの変数を作成していきます。これは、ブログ記事の詳細ページを想定したJSON-LDの実装になっています。

<script type="application/ld+json">
  {
    "@context": "http://schema.org",
    "@type": "Article",
    "mainEntityOfPage":{
      "@type":"WebPage",
      "@id":"https://sem-technology.info"
    },
    "url": "https://sem-technology.info/ja/google-tag-manager/ga-scroll-tracking",
    "identifier": "84",
    "headline": "Googleアナリティクスによる現代版のスクロール計測の方法",
    "image": "https://sem-technology.info/assets/social-facebook.png",
    "datePublished": "2018-02-14T14:15:13JST",
    "dateModified": "2018-02-14T14:15:13JST",
    "author": {
      "@type": "Organization",
      "name": "SEM Technology",
      "logo": {
        "@type": "ImageObject",
        "url": "https://freelance.sem-technology.info/img/www/logo.png",
        "height": 672,
        "width": 1666
      }
    },
    "description": "Googleアナリティクスのイベントトラッキングを使ってスクロール状況をトラッキングしたい。そういったニーズは数年前から出続けており、それに対する解決策として、「画面の何%スクロールされたか？をイベントトラッキングする」実装をしている人がほとんどだと思います。この記事では、この実装法の問題点とともに、どう実装するのが現代的であるかを解説したいと思います。"
  }
</script>

GTMで作成する変数の例

では、Googleタグマネージャで変数を作成します。現時点では、JSON-LDを読み取る組み込みの変数タイプは存在しないので、カスタムJavaScript変数を作成します。下記のサンプルでは、前述した形式のJSON-LDを対象として、記事タイトル(headline)と、記事の著者(authorのname)を取得する方法を記載します。

それぞれ、スクリプトの前半は同じコードを利用しており、JSON-LDの中からルートのタイプが"Article"であるものを探しています。その後最後のところで、取得する対象が「記事タイトル」なのか「記事の著者」なのかを指定しています。

スクリプトは少し複雑なので、JavaScriptに詳しくない方は、Webマーケターのためのテクノロジー入門で勉強を行うといいと思います。

記事タイトルを取得する。

function () {
  return [].slice.call(
    document.querySelectorAll('script[type="application/ld+json"]')
  ).map(function(script) {
    return JSON.parse(script.text);
  }).filter(function(json) {
    return json["@type"] == "Article";
  })[0].headline;
}

記事の著者を取得する

function () {
  return [].slice.call(
    document.querySelectorAll('script[type="application/ld+json"]')
  ).map(function(script) {
    return JSON.parse(script.text);
  }).filter(function(json) {
    return json["@type"] == "Article";
  })[0].author.name;
}

未来のタグはどうなっているべきか

Googleアナリティクスの拡張eコマースを例に、私が考える「未来のタグがどうなっているべきか」を紹介します。それは、

「拡張eコマース機能を有効にする」設定を行ったら、GAタグの標準ライブラリ側が、schema.orgのメタデータを読み取り、必要な情報を全て送信する。当然、商品のインプレッションや詳細ページの閲覧、購入情報、ユーザー情報なども全てキレイにデータが送信されている状態

だと思います。schema.orgのメタデータを網羅的にHTML内に書いているのであれば、拡張eコマースで必要な情報はほとんど揃っていると思います(Orderを表すスキーマもあるので、注文データもschema.orgで表現可能であり、ログインユーザーに関する情報もschema.orgで表現することが可能です)。あとは、標準のGAトラッキングコードがそのメタデータを読み取り、拡張eコマース用のデータに変換してくれれば済む話です。

もし、そのような状況になったとしたら、拡張eコマースの実装のために、JSON-LDやMicrodataなどのメタデータをHTML内に含めるサイトが増えてきます。すると、HTML内のメタデータが充実するので、Googleを始めとするクローラー(ボット)がコンテンツを解釈しやすくなります。Googleアナリティクスがそういった実装をしてくれれば、他のツールベンダーも追従していき、タグ実装が格段に簡単になると思います。ショッピング広告で必要になる商品フィードも、広告プラットフォーム側がサイトをクロールすればすべて情報が埋まるので、フィードを作成する必要性もなくなってくると思います。

こんな状況になったとしたら、テクノロジー・マーケティングが一気に加速すると思いませんか？

まとめ

今回は、JSON-LDに従って書かれたHTMLコードからメタデータを読み取る方法を紹介しました。JSON-LDは、ログインユーザーの情報や、購入商品の情報など多くの情報をプログラムが読み取りやすいフォーマットで記述することが可能です。

JSON-LDの仕様に乗っかることで、より汎用的なトラッキングコードの実装が可能になります。