最新機能をフル活用してセキュアで爆速、SEOも最高のサイトを（ほぼ無料で）実現する考え方と方針についてはGatsbyとNetlifyを使って爆速サイトを２時間で構築をどうぞ。早くCMS画面でコンテンツを修正できるようにしたいので、今回はNetlify CMSを設定し、コンテンツの編集に着手します。

Day 4：Netlify CMSでコンテンツ編集を可能に

まず方針を固める

GatsbyはWebブラウザで動作するフロントエンドのアプリで、CMSの「ヘッド」部分にあたります。コンテンツの編集や管理、保管の機能はなく、ContentfulやPrismicのようなヘッドレスCMSや、プラグインでヘッドレス化したWordPressからAPI経由でコンテンツを取得する設計になっています。今回のサイトは小規模なので、GitHubのリポジトリにマークダウン形式でコンテンツを格納することにしました。

エンジニアなら、GitHubだけでもマークダウン形式のテキストファイルの編集やレビュー・承認ワークフローを運用できると思いますが、コンテンツのライターや編集者には、もっと使いやすい編集画面が必要です。

そこで、今回はNetlifyの無料オマケ機能「Netlify CMS」を使います。これはGatsbyと同様にReactのアプリで、GitHubのリポジトリ上の.mdファイルを読み書きする編集画面や簡易ワークフロー機能が使えるようになります。

1. CMS管理画面を使ってみる

Netlify CMSは今回ベースにしたGatsby + Netlify CMS Starterに最初から含まれているので、Netlifyの開発サーバーを起動するとNetlify CMSも起動します。

以下のように、起動時にコンソールに表示されるメッセージにNetlify CMSのURLが表示されるので、アクセスしてみます。

CMS画面は至ってシンプル。コンテンツ（ページ）とメディア（画像）を管理します。コンテンツはさらにブログエントリと固定ページに分けて管理するようStarterのCMSは設定されています（変更可能）。

Pages＞Landing Pageがトップページ。開いて編集し、Publishすると、変更されたマークダウンのファイルがGitHubにコミットされ、その結果Netlifyがデプロイを開始。本番ページに反映されます。

商用CMSほど作り込まれていないので、入力欄の順番が実際の画面と一致しなかったり、レイアウトがズレたりし、完全なプレビューにならない点はガマン。

2. ワークフロー機能を有効化する

「Publish」をクリックするとすぐにGitHubにファイルがコミットされて本番デプロイが開始するのは困るので、ワークフロー機能を有効化します。

Netlify CMSのファイルは全て/static/admin/ の中に格納されています。この中の「config.yml」を編集し、以下の行を追加します。

publish_mode: editorial_workflow
site_url: https://YOUR-SITE.com
display_url: https://YOUR-SITE.com

ついでにサイトのURLを設定すると、ヘッダにサイトへのリンクが追加され、ドラフト保存したページをプレビューできるようになります。

3. 変更したパスを反映させる

前回にディレクトリ構成を変更したので、それらのページがCMS画面に表示されなくなりました。設定ファイル「config.yml」中のパスを更新して直します（上の図を参照）。

これでようやく、コンテンツを編集できるようになりました。

この Starterのテンプレ を このサイト に近づけようとしています。今のところ こんなサイト になってます。

次回は、ページの構造やお問い合わせ機能をチューニングします。

最新の思想・機能・ツールをフル活用してセキュアで爆速、SEOも最高のサイトを（ほぼ無料で）実現する連載その１ではGatsbyとNetlifyを使って爆速サイトを２時間で構築しました。まだデフォルトのダミーサイトのままなので、今回はGatsbyを設定してサイト名や構成を修正します。

Day 3：CMSでサイトの形を整える

まず方針を固める

３日目の今回は、最低限の設定を行い、今回使ったテンプレート (Gatsby + Netlify Starter)に含まれているNetlify CMSというコンテンツ編集の画面が使えるようにします。サイト名やメニュー構成、URLの変更までで、デザインやコンテンツは今回は変更しません。

画像の管理と配信はCloudinaryを使います。デバイスやブラウザに応じて最適な解像度で最適なサイズの画像をサーバー側で生成してくれるので、画像の質を落とさずにサイトの速度を向上できます。今回のテンプレート（Gatsby + Netlify Starter）はUploadcareにも対応していますが、Uploadcareは有料プランのみの提供に方針を変えたようです。継続的な無償利用はできなくなりました。

1. PCでGatsbyの開発環境を作る

GitHubのリポジトリ中でコンテンツ（.mdファイル）の追加や更新を行う（コミットする）と、Netlifyが自動でデプロイを開始し、HTMLやJSが生成され、ホスティングのサーバーに転送される、というのが日々の運用の流れです（今回の構成の場合。GitHubではなくヘッドレスCMSやWordPressと連携させることも可能）。

一方、サイトやCMSのカスタマイズをするためには、手元のPC（やMac）でもGatsbyサーバを走らせて開発環境を作る必要があります。

まず、Gatsbyが動作するフレームワークの「Node」と、作業で使うコマンドラインのツールをインストールします。

• Node
• Gatsby CLI
• Netlify CLI

次に、GitHubのリポジトリをローカルにダウンロード。

git clone https://github.com/[GITHUB_USERNAME]/[REPO_NAME].git

続いて、必要なモジュールのインストール。

cd [REPO_NAME]
yarn

ここまでは、初回のみの作業です。

開発サーバーを起動するために（プロジェクトのディレクトリで）以下を実行します。

netlify dev

しばらくしてから

You can now view gatsby-starter-netlify-cms in the browser.
http://localhost:8000/

と表示されれば、開発サーバーの起動に成功。そのURLをブラウザで開き、作業を続けます。

2. サイト名を変更

Gatsby全体の設定は、ルート直下の「gatsby-config.js」に書かれています。
まず、冒頭のサイト名とサイト説明を編集。

全ページのtitleタグとmetaタグにすぐ反映されました。開発サーバーの場合、ファイルを変更しても再起動やブラウザのリロードは不要です。

なお、次回に使うCMS画面では、各ページごとに異なるタイトルとdescriptionを設定できます。このconfigファイルの設定は、個別設定をしなかった場合のデフォルト値になります。

3. ディレクトリ構成を変える

デフォルトのサイト構成を以下のように変えたいので、/src/pages/のディレクトリ名とファイル名を変更します。

• /about/　→ そのまま
• /products/　→ /seminar/に名称変更
• /blog/　→ /note/に名称変更
  • 記事　→ 後で個別に変更
• /contact/　→ そのまま
  • examples　→ 不要なので削除
  • file-upload　→ 不要なので削除

/contact/の中の不要な２つのファイルを削除し、/blog/ と /products/ のディレクトリ名を変更しました。変更直後はブラウザがエラー画面になりますが、気にしないで/products/（変更後はseminar）の中のindex.mdを開いて、冒頭の

path: /products

を

path: /seminar

に変更し、開発サーバーを再起動（Control＋Cで停止してもう一度netlify devを実行）します。
どのファイルのどこを変更するのかは、Gatsbyサイトの作り方次第です。

4. メニューとフッタのリンクを直す

URLが変わったので、各種メニューのリンクが切れてしまいました。リンクはURLのパスを直書きする作りになっているので、以下のファイルを修正します。

• /src/components/Navbar.js
• /src/components/Footer.js

ついでに使わないSNSアイコンも削除。ロゴ画像のAltとサイズが直書きされているので修正。

5. ロゴとfaviconを変更

/src/img/logo.svg　にロゴ画像
/static/img/　に各種favicon

のファイルが格納されているので、同じファイル名で画像を上書きすると楽です。

今日は約４時間

テンプレのサイトがどう構築されているかを理解するのに時間がかかりました。所要時間は、Node環境の有無や、サイトの構成・デザインをテンプレからどれくらい変更するかによって変わると思います。

構築中のサイトはこちら。次回はコンテンツを編集するCMS管理画面を設定し、コンテンツの更新を開始します。

最新の思想・機能・ツールをフル活用してセキュアで爆速、SEOも最高のサイトを（ほぼ無料で）実現するのがこの連載の目的です。前回はGatsbyとNetlifyを使って爆速サイトを２時間で構築しました。今回は、新しいサーバーサイドGTMを導入してセキュアかつ負荷を下げる形で2種類のGAを導入し、さらにプライバシー保護とITP対応のためCookie管理を改善する方法と結果を紹介します。

サーバーサイドGTMは「爆速セキュアサイトを構築したい」という前提がないと意味がないので、未読の方はその1も読んでみてください。

Day 2：サーバーサイドGTMでITPに対応

まず方針を固める

ITPは抜け道を探すのではなく、お客さまの意思を尊重してパーソナルデータをしっかりセキュアに管理するのが一番。タグマネージャーはそのために最も重要なパートを担うので、サイトの制作・開発・構築を進める前にデータやタグの活用と管理方法についてしっかり設計しておきたいところ。

今回の前提は

• Webの行動データをイベント単位で細かく取得し、一人ひとりの行動や心理の変化に合わせてパーソナライズすることを「良い顧客体験（CX）」とする。その実現がビジネス成功のために必須
• ただし、属性や心理データ、購買データを含む分析やターゲティングをする場合、個人情報は当然としてパーソナルデータの保護もかつてないほど重大な課題
• ブラウザの商業主義から人権保護へのシフトはアップルを先導に業界全体へ広がっていく
• そのため、タグを貼るだけで管理を丸投げするツール導入方式は駆逐されていく

そこで、以下のような方針を立てました。

• 行動データは個人情報と同様に扱い、社外サーバーへの送信を極力減らす
• ブラウザや訪問者を識別するIDは自社で発行・管理し、ツール横断で活用する
• 各種ツールへの行動・属性データ送信はサーバー間通信を基本とし、タグを極力減らす
• JavaScriptのタグ管理システムはなるべく使わない

具体的な作業メモ：サーバーサイドGTM導入

構築中のサイトにタグマネとGAを導入し、サイトの制作とアナリティクスのカスタマイズをアジャイルに同時進行していきます。

1. GTM用のサーバーを構築する

• GTMでサーバー用のコンテナを新規作成
  • 東京のサーバーを使いたいのでプロビジョニングは「手動」
• クラウド (GCP)でGTMサーバーを立ち上げる
  • Google App Engine (GAE)を起動
  • そのマシンにGTMサーバーソフトウェア（GAEのApp）をインストール
  • さらに対象サイトのサブドメインを割り当てる
• サーバー用GTMコンテナの設定を変更
  • 「タグ設定サーバー」欄にサブドメインを設定

今回はITP対策したいので、サブドメインの割り当ては必須です。

2. ウェブ用GTMに新しいGA4のタグを追加

ブラウザの負荷をなるべく減らしたいので、GA（Universal Analytics）ではなく新しいGA4（App + Web）のみをGTMではなくgtag.jsで導入します。

普通にGA4のタグを入れて動作検証を終えたら、GAデータの送信先をGoogleのサーバーではなく、1で構築したサブドメイン上のGTMサーバーに変更するため、「トランスポートURL」を指定します。

1
2
3
4
5
6
7
8
9
10
11

<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-EXAMPLE"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-EXAMPLE', {
    transport_url: 'https://analytics.example.com',
  });
</script>

参考：ウェブ用のGTMでGA4を導入する場合は、以下のようにフィールドを追加します。

これで、GAのデータの送付先がGAのサーバーではなく今回立ち上げたGTMサーバーに変わります。

3. サーバー用GTMコンテナでクライアントを設定

サーバー用GTMの「クライアント」はGAのビーコン（計測用データ）を受け取るレシーバーです。サーバーサイドGTMの設定に基づいてデータを処理し、GAなどのサーバーへデータを送信します。

サーバーサイドGTMのコンテナではデフォルトで２種類の「クライアント」が作成されますが、設計思想的に、この両方のクライアントを同時に使うことはあまり無いはず。せっかくサーバーサイドのGTMを導入するので、ブラウザから飛ばすビーコンはGA4に一本化し、GAのデータはGTMサーバーから送信するのが良いので、「Universal Analytics」のクライアントは削除しました。

サーバーサイドでデータの加工を行う場合、クライアントのテンプレートを自作することになりますが、今回はデフォルトの「GA4」をそのまま使います。よりセキュアにするため、１箇所だけ設定を変更します。

詳細設定＞SameSite

詳細設定では、「_ga」Cookieとは別の、訪問者（ブラウザ）を識別するIDを格納するためにGTMサーバーから送信される「FPID」Cookieの設定ができます。SameSiteは「Lax」に変更しました。現時点ではITPとは関係ないですが、なるべくセキュアにしておきたいので。

4. サーバー用GTMコンテナでトリガーを作成

サーバーサイドGTMのタグの発火条件とするトリガーを、サーバーサイドGTMのコンテナ内で作ります。トリガーの種類は「カスタム」です。GTMコンテナにデフォルトで作られているクライアントがデータを受信した時に反応します。

今後対象サイトやビーコンの種類が増えた場合、トリガーが全てのデータに反応してしまうとゴミデータが増えるので、ビーコンの種類と計測IDで制限をかけます。

「Client Name」は組み込み変数で、有効化が必要です。受信データに反応したGTMクライアントの名前がセットされます。
「Query String」も組み込み変数です。ビーコンのURL中の「?」以降の文字列（パラメータの組み合わせ）が格納されます。

5. サーバー用GTMコンテナでタグを作成

最後に、4で作成したトリガーを条件としたGAタグを作ります。

今回は爆速セキュアなサイトを作るのが趣旨なので、サイトにはGA4のみをgtag.jsでミニマム実装し、GTMサーバー側で受信するデータを分解・複製してサーバー間通信でGA v1とGA4の計測を行います。

GA4のタグは、受信したデータをそのまま送信する場合は、設定は不要です。サーバー側でデータの分解や加工、マッピングなどの処理をしたいので、後日必要に応じてカスタマイズの設定を行います。

GA (Universal Analytics)のタグでは「UA-xxxxxxxxx-x」というGAのプロパティIDを上書き指定します。GTMサーバーが受信するのはGA4用ビーコンなので、GAのプロパティIDは含まれていません。

これで最低限の設定は終わり。検証して公開します。

6. サーバーサイドGTMでGAをカスタマイズ

今回は爆速セキュアなサイトを作るのが趣旨なので、カスタムディメンションへ値をセットするなどのカスタマイズは極力サーバーサイドで行います。

無料のGA（Universal Analytics）はBigQueryで生データを抽出できないので、カスタムディメンションに追加のデータをセットしておくと何かと便利。今回はGTMサーバー側でそのカスタマイズを行ってみます。

カスタムディメンションに入れるデータ

• クライアントID (client_id)
• セッションID (ga_session_id)

この2つのデータはgtag.jsからのストリームを受け取ったGTMサーバー上のクライアントが分解して「イベントデータ」として利用可能になっているので、それを取り出して格納するGTM変数を２つ作成します。

この２つをカスタムディメンションにセットするため、GAのタグにフィールドを追加します。サーバーサイドコンテナのGAタグには、カスタムディメンション用の入力欄がないので、ビーコンのパラメータと同じ「cd＋数字」と言う書式でフィールドを追加します。

GA側でもカスタムディメンションを定義し、サーバーサイドGTMのコンテナを検証・公開して終わり。GAで２種類のカスタムデータを計測開始しました。

よりセキュアになったCookie

Safari 13.1.2でサイトにアクセスすると、従来の「_ga」に加えて「FPID」Cookieが発行されました。

_ga：ITPにより期限が２年から１週間に短縮された
FPID：期限は２年間、Secure、HttpOnly、Lax

どちらかを削除しても、リロードすると同じ値で復活します。FPIDの値に_gaの一部が含まれているので、お互いリンクしているようです。

ブラウザからのビーコンでは今まで通りcidパラメータに_gaの値がセットされますが、GTMサーバーはFPIDを優先し、それをGAサーバーに送信してくれます。

実際に使ってみて分かったこと

爆速セキュアなサイト構築という目的意識を持って実際にサーバーサイドGTMを導入した結果、いろいろわかりました。

• サーバーサイドGTMは手動でプロビジョニングしないとGCPのリージョンを東京にできない
• ITP対策としてサブドメインは必須
• デフォルトでもHttpOnlyでSecureな「FPID」Cookieがセットされるので、他のツールでもIDとして使える
  • 従来の「_ga」と新「FPID」Cookieのどちらかが残っていれば同じ値が引き継がれる
  • SameSite=Laxの指定もできる
• サイトに直接導入するのはGA v1 (Universal Analytics)ではなくGA4が良い
  • 直接導入するGAは、あまりカスタマイズしなくなるので、GTMも不要、gtag.jsが良い
  • サーバーサイドGTMでGA4のビーコンを分割してGA v1のビーコンを生成できる
  • サーバーサイドGTMでGAのカスタムディメンションもセットできる
• サーバーサイドGTMのトリガーにはクライアント名や計測の条件を追加すると良い
  • 複数サイトのサブドメインを一つのサーバーサイドGTMに割り当てても動作する

最初から正解がわかっていれば、２時間で終わる作業です。

リアルに構築中のサイトはこちら。記事が進行しながらサイトも変わっていきます。

次回はGatsbyをカスタマイズし、サイト名やURL構成、ナビゲーションリンクを更新します。その後はコンテンツ投入、デザイン変更と進めていきます。

CXやDX（デジタルトランスフォーメーション）が流行ってきましたが、ツールのタグを入れすぎてサイトが重い、iTPなどセキュリティ・プライバシー対策が弱いので精度が落ちた、なんて状況は避けたいですよね。
「分かりやすいデザイン」「使いやすいUI」は誰でも追求できますが、楽してWordPressを使っているようではパフォーマンスのチューニングに限界があります。ここ数年、数週間でWebの技術は驚くほど格段に進化しました。

そこで、将来のWebの進化を見据えて最先端のツールやアプローチを使って、でも（ほぼ）無料でセキュアで爆速なサイトを最短で構築することに挑戦します。

ヘッドレスとサーバーサイドでいこう

CMSとタグ管理の発想を根本的に変えることで、爆速セキュアなサイトを実現することにします。

1.CMSはヘッドレスとSPA

まず、CMSはヘッドレスとSPAを組み合わせます。ヘッドレスCMSは2017年あたりから進化が加速し、WordPressのような動的CMSは言うまでもなく、静的サイトよりもさらに速くて快適なウェブサイトを実現できるフロントエンド技術「SPA」の流れと合流。ツールや情報も増えたので、だいぶ実用的になりました。

2.タグ管理はサーバーサイド

タグマネジメントは、GDPRの施行やiTPの進化で迷走、イタチごっこが続きましたが、Google Tag Manager（GTM）のサーバーサイド化という新機能がベータ公開され、サーバーから生成するセキュアなCookieの実現が簡単になりました。

3.アナリティクスはイベントベースで一本化

アナリティクスは、クリックやスクロールのようなイベントを計測サーバーに送信し、ヒット単位の生データを別のBI（DataポータルやTableau、PowerBI）で集計・可視化するのが最近のトレンド。訪問者一人ひとりの行動や心理の変化を追うカスタマーアナリティクス的なアプローチも増えてきました。

Adobe Analyticsは、軽量・汎用化した計測用JavaScriptライブラリの新バージョンをリリース。生データの取り出しは少し不便です。

GoogleもFirebaseをベースとしたGoogle Analyticsの新しいバージョン（Web + App）をイベント型に切り替えて生ログ保存にも対応し、開発に力を入れています。ログインして利用するレポート画面はおまけのプレビュー機能でしかなく、今後はあまり進化しないでしょう。その代わりにプラットフォームとしての進化が半端ないです。広告連携しないなら360も不要?!

実際に既存サイトを再構築してみる

理屈だけの机上の空論にならないよう、実在するWordPressのサイトを再構築することで

• 実現はどれくらい難しい？
• 工数（作業時間）はどれくらいかかる？
• どこまで速くなる？
• 意外なデメリットは？
• 運用は犠牲にならない?

という懸念を具体的にクリアしていきます。

Day 1：GatsbyとNetlifyでテンプレサイトを立ち上げる

まず方針を固める

デザインは後で変更すれば良いので、まず先にテンプレートを使って開発用サイトを立ち上げることにします。従来の「WordPressをインストールして適当なテーマを適用する」作業に近いイメージです。

CMSのヘッド側は、GatsbyJSを採用。最近はGatsbyかNuxtの二択でしょう。機能に大差はないので、お好みで。私はReactの方に将来性を感じました。

ホスティングは、レガシーなレンタルサーバーをやめて最先端でホットなNetlifyに移行。使っていくうちに進化していくので、Webの将来が垣間見えて「その手があった！」と感動することもしばしば。運用管理も劇的に楽です。

コンテンツの格納という意味でのCMSは、GitHubを選びました。チームでの同時作業やバージョン管理ができます。

コンテンツ編集はNetlify CMSを使い、マークダウン形式で記述することで構造化されたクリーンなHTMLを実現します。無制限で自由すぎるHTML形式はパフォーマンス低下の原因になるので禁止。

画像管理は、リサイズや最適化、Retina対応ができるデジタルアセット管理（DAM）を導入します。DAMは高価なソリューションが多い状況が10年以上続きましたが、今風のモダンで安価なサービスがここ数年で増えてきました。今回は、長年のノウハウに基づく豊富で実用的な機能を持ち、小規模なら無料で使えるCloudinaryを採用します（本サイトで利用中）

具体的な作業メモ：まずヘッドレスCMSで雛形サイトを構築

早速作業スタートです。

Netlify+Gatsby+Cloudinaryの組み合わせの場合、Netlifyが提供するテンプレを使うと、１クリックでインストールできます。

「Deploy to netlify」ボタンをクリックし、GitHubのリポジトリ名を変更して「Save and deploy」ボタンをクリック。

リポジトリ作成とNetlify接続設定、デプロイまでが一気に完了し、仮ドメインでサイトが立ち上がります。

CMSに自分を追加

いくつかのメールがNetlifyで登録したメールアドレスに届きますが、そのうち「You’ve been invited to join xxx.netlify.app」という件名のメールだけ、対応が必要です。

と言っても本文中の「Accept the invite」をクリックし、Netlifyのアカウントでログインするだけ。CMS用のパスワードを指定すると登録が完了し、CMS管理画面が開きます。

テンプレを使ったので、ダミーの珈琲屋サイトのコンテンツがいくつか投稿済みになっています。

Netlifyでサイト名とドメインを変更

次に、Netlify管理画面のSettingsで設定を変更します。デザインやコンテンツはその後で。

General＞Site detailsでサイト名を変更
これはサイトに表示されない管理上のサイト名なので、半角英数字で指定します。変更すると仮ドメインも合わせて変更されます。今回は「concept-diagram」にしました。

Domain managementでカスタムドメインを指定
本番サイトはそのままで作業を進めてから切り替えたいので、仮のドメイン「netlify.concept-diagram.com」を指定しました。いずれ必要になるので、ついでにIPv6も有効化。
NetlifyのDNSサーバーを使う場合は、Let’s Encryptの無料SSL証明書も自動でインストールされます。

Build & Deploy＞Snippet injectionでGA v2のタグを挿入

サイトをなるべく軽くしたいのと、タグマネはサーバーサイドGTMのみで頑張りたいので、GA v2はgtag.jsを直書きで導入します。

Netlifyの場合デプロイ（本番リリース）時に全ページへ自動でタグを入れてくれるので、HTMLにタグを入れる必要はありません。
場所はbodyではなくheadを選び、gtag.jsのタグを入れます。

ここまでで約２時間

慣れると１時間で終わります。
NetlifyやGitHubが初めてで、ドメインも新規に取得する場合は、半日くらいでしょうか。

次回はサーバーサイドのGTMとGoogle Analyticsを最新方式でスマートに導入します。

LPのような長いページの場合、表示回数（PV）よりも「どこまでスクロールしてじっくりコンテンツを読み込んだか」が重要です。GTMを使うと、画面の何パーセントまでスクロールされたか、を簡単に計測できますが、ページによってパーセントの解釈が異なり、分析が難しいので、ページをセクション（パーツ）に分割し、その単位で画面にN秒間以上表示された、という計測方法がオススメです。

ただし、ページの作り方に合わせてGTMの設定を追加したり削除するのは運用が大変なので、ページ制作時に決められた属性を追加するだけで、GTMの設定を変更することなく計測すると良いでしょう。

このページ自体に実装してあるので、ゆっくりスクロールしながら以下のセクション2以降をブラウザの画面に表示させた状態で2秒などの指定時間が過ぎると、GAでイベントが計測され、画面右上に通知が表示されます。

DEMO

1

data-track-name="Section 2"

1
2

data-track-trigger="view"
data-track-duration="2000"

1
2
3

data-track-name="Section 2"
data-track-trigger="view"
data-track-duration="2000"

1
2
3

data-track-name="Section 3"
data-track-trigger="view"
data-track-duration="1000"

1
2
3

data-track-name="Section 4"
data-track-trigger="view"
data-track-duration="4000"

GTMの設定は以上でおしまい。今後は、どのページでも、divなどのタグに属性を追加するだけで、要素の表示をGoogle Analyticsで計測できるようになりました。もうGTMを毎回編集する必要はありません。運用が劇的に楽になりました。楽というより、運用フリー、不要になりました！

企業で採用されることが多いBrightcove動画。動画ごとの再生回数や完了はBrightcoveの管理画面でも調べられますが、Google AnalyticsやAdobe Analyticsなどのサイト内の行動データと統合すると、顧客体験を点ではなく線で理解できるようになります。

• どの広告からの訪問者がコンテンツや動画の消費につながるのか？
• 動画の閲覧体験はサイトへの定着に寄与するのか？
• ニーズや意識を広げる系の動画によって、興味関心や検討対象の商品ジャンルは広がるのか？
• 手厚いサポート系の動画はNPSに影響を与えるのか？

そのためには、まず動画視聴行動（再生開始と再生完了）をアナリティクスで計測する実装が必要です。YouTubeと違ってBrightcoveの情報は少なく、公式サイトも散らかっていて日本語が変（ネイティブのレビューをしていない機械翻訳？）なので、メモを残しておきます。

前提となるBrightcoveの実装方法

Brightcoveの動画は、以下のような形式でページに埋め込まれていて、そのページにはすでにGTMとGAが導入されていると想定します。

1
2
3
4
5
6
7
8

<video
 data-video-id="xxxxxxxx"
 data-account="yyyyyyyyy"
 data-player="zzzzzzzz"
 data-embed="default"
 data-application-id controls class="video-js"></video>

<script src="//players.brightcove.net/yyyyyyyyy/zzzzzzzz_default/index.min.js"></script>

GTMで計測を実装する

Google Tag Managerの標準機能であるYouTube計測機能を流用することで、最低限の手間とコードで実装するという方針で進めます。

GTMのタグを作る

まず、埋め込まれた一つまたは複数の動画にイベント処理を仕込むため、
以下のコードをGTMのHTMLタグとして作成します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<script>
var track = function(a, b){
  dataLayer.push({
    'event': 'gtm.video',
    'gtm.videoTitle': a,
    'gtm.videoStatus': b
  });
}
for (var i in videojs.getPlayers()){
    videojs(i).ready(function(){
    this.one('play', function(){
      track(this.mediainfo.name, 'start');
    });
    this.one('ended', function(){
      track(this.mediainfo.name, 'complete');
    });
  });
}
</script>

• 同じページ内に複数の動画がある場合でも対応可能
• 再生開始と再生完了のみ計測
• 動画IDは内容を把握しにくいので動画タイトルを取得
• ページのHTMLが完成してから実行したいので、トリガーはDOM Ready以降で

GTMの変数を有効化する

このタグが送信するdataLayerを受け取るための組み込み変数「Video Status」と「Video Title」を有効にします。

GTMのトリガーを作る

dataLayerへpushされるeventを受け取るためのトリガーを作成します。

• YouTubeの動画計測機能を流用するので、トリガータイプは「YouTube動画」

GTMのタグを作る

続いて、上記のトリガーで発火するGA計測用のタグを作ります。

• イベントカテゴリ、アクション、ラベルに何を入れるかはお好みで
• Video StatusとVideo Titleは、先ほど有効化した組み込み変数

これで、動画の再生開始と再生完了時にイベント計測できるようになります。

Google Analyticsで目標を設定する

GAのイベント計測だけだと「どの動画が何回再生開始や完了されたのか」という点の分析になってしまいがちなので、動画の再生完了（や再生開始）をGAの目標として設定します。

この設定によって再生完了を指標として使えるようになるので、冒頭のような顧客の長期的な変化を把握できるカスタマーアナリティクス流のレポートを作れるようになります。

• ランディングページや流入チャネルなど、ページを超えて持続するディメンションをディメンションに入れる
• 「◯◯な人」「◯◯したことがある人」など、セッションではなくユーザーレベルのセグメントを作成し、それらのセグメントをディメンションに入れると長期の顧客の変化を比較できる
• カレンダーの期間は長めに（動画の視聴によって訪問者の心理や行動の変化はどれくらいの期間で持続するのか次第）

今回のポイント

• BrightcoveのAPIを使って動画タイトルや再生開始、再生完了のタイミングを取得する
• 分析しやすいように最低限のデータのみ取得する
• タグマネージャーの標準機能を使ってなるべく楽をする
• レポートはカスタマー視点で作る

要件に応じて応用してみてください！

「直帰率が高いキャンペーン用LPがあり、時間をかけてスクロールしながら読まれているのか知りたい」というご質問をいただいたので、ここで回答します。
GTMとGAで実装しやすいように、ページのスクロール（10％間隔）の最大量と滞在時間（3秒間隔）をGTMの機能を使って計測し、ページを移動や離脱する時に最終的な値をイベント計測するというアプローチをおすすめします。実際にこのページに実装し、計測データとレポートも共有しておきました。

DEMO

このページを開くとタイマーがスタートします（毎秒だと細かすぎるので3秒毎）

別のページへ移動したりタブやウィンドウを閉じる時にタイマーが停止して最終的な滞在時間が確定し、GAへデータが送信されます。

こんなデータが取れるようになります。

Google Sheetsのレポートに自動反映される

結果はこのGoogle Sheetsに1時間に1回、自動反映されます。

この方式の特徴や注意点

• GTMの標準機能をなるべく使っているので、実装が比較的楽
• GTMのタイマーはブラウザがバックグランドになっていたりタブが非アクティブになっていても止まらない
• 間隔を短くしすぎるとブラウザに負荷がかかるのでご注意
• ％形式のスクロールは解釈が難しいので、LPの主要エリアが「N秒以上表示された」という精読の計測も併用すると良い

真似してみよう

GTMで

1. カスタムHTMLのタグ「JS - 離脱前にdataLayerへevent送信」を作る

   1 2 3 4 5 6 7

   <script> window.addEventListener('beforeunload', function() { window.dataLayer.push({ event: 'beforeunload' }); }); </script>

2. そのタグが送信するカスタムイベント「beforeunload」を受け取るトリガー「beforeunload」を作る
3. スクロール距離のトリガー「Scroll Depth」を作る
4. 組み込み変数「Scroll Depth Threshold」を有効にする
5. タイマーのトリガー「Timer 3sec」を作る
6. データレイヤー変数「DL - timerEventNumber」を作る（データレイヤーの変数名は「gtm.timerEventNumber」）
7. データレイヤー変数「DL - timerInterval」を作る（データレイヤーの変数名は「gtm.timerInterval」）
8. カスタムJS変数「Time on Page」を作る

   1 2 3 4 5 6

   function() { var elapsed = {{DL - timerEventNumber}} * {{DL - timerInterval}} / 1000; var min = Math.floor(elapsed / 60); var sec = elapsed % 60; return ('0'+min).slice(-2) + ':' + ('0'+sec).slice(-2); }

9. GA計測用のタグ「GA - ページ離脱」を作る

• ページ離脱後でもバックグラウンドでビーコンが送信されるようtransportをbeaconにしておくと良い
• イベント、カテゴリ、アクションのどこに何を入れるかはお好みで（計測中の他のデータと形式を合わせる）

2019年4月23日：データレイヤー変数自体の名前と設定画面中の「データレイヤー変数の名前」は別物です。後者で指定すべき文字列について追記しました。

参考

• #GTMTips: Fire Trigger When User Is About To Leave The Page - Simo Ahava’s blog
• How to Use Timer triggers in Google Tag Manager V2

Google ColaboratoryでR言語を使うためには、追加インストールやセッション強制終了などが必要で、毎回数分間かかるという状況でしたが、2月頃にRのカーネルがこっそりと追加されたようで、面倒なハックは不要になりました。その方法についてのメモ。

カーネルを確認

まず、Google Colaboratoryにデフォルトでインストールされているカーネルを確認するため、以下を実行します。

!jupyter-kernelspec list

kernels/irが表示されれば、Rのカーネルが入っているということ。

2019年4月3日時点で、Swiftも入っているようです。

Rのカーネルに切り替える

カーネルは入っているのにGoogle Colaboratoryのランタイム変更画面に「R」がまだ表示されず、選択できないので、Notebook（.ipynb）ファイルをダウンロードし、テキストエディタで開いて以下の部分を編集します。

1
2
3
4

"kernelspec": {
  "name": "ir",
  "display_name": "R"
}

終わったらこのNotebookをアップロードして開くだけ。
ランタイムのタイプを確認すると「R」に切り替わっていることがわかります。

あとは普通にRが使えます。

簡単！

元ネタ：

• jupyter notebook - How to use R with Google Colaboratory? - Stack Overflow (2/8)
• YanaiさんのTweet (3/29)

Jupyter Notebookの利便性はそのままで、操作性とデータビジュアライズ機能が改善されたnteractを最近よく使っています。日本ではあまり知られていないようなので、デモ動画を作ってみました。

nteractがJupyter Notebookよりもスゴイ点

データの確認や探索が簡単

操作性やデザインも大事ですが、データ分析の場合はこちらの方が重要ですね。
nteractには、データをインタラクティブに確認や探索できるData Explorerの機能が内蔵されています。

テーブル形式の場合はカラムの幅を変更したり、ヘッダをクリックして並び替えしたり、一度に表示される行数を変更してページ分割できます。ヘッダは固定表示されるので、大量データを確認しやすくなっています。

さらに、インタラクティブなグラフ表示も簡単。Pythonモジュールをimportしたり設定用のコードを書くことなく、クリックだけで表示方法を切り替えられます。

キーボードショートカットに依存しない直感的なGUI

Jupyter Notebookはキーボードショートカットを使う前提のUIになっているのか、とっつきにくく、慣れるまで時間がかかります。

nteractの場合、セルをドラッグ＆ドロップで移動したり、ゴミ箱アイコンをクリックして削除したりと直感的に利用できるので、エンジニアではないマーケターやビジュアル派のアナリストにフレンドリー。

インストールと起動方法

Jupyter Notebookに慣れた人なら、より機能的なWeb版がオススメ。

コマンドラインを使いたくない、エンジニアではないのでGUIで使いたい！という人は、シンプルなデスクトップ版が使いやすいでしょう。

Web版のインストールと起動

pip install nteract_on_jupyter

（やcondaなど）でインストールし、

jupyter nteract

で起動できます。Jupyter Notebookと同じ要領です。

デスクトップ版のインストールと起動

公式サイトからダウンロードしたインストーラを実行した後に（前でも可）

pip install ipykernelpython -m ipykernel install --user

を実行し、裏で動くカーネルを設定しておく必要があります。

まとめ

nteractはNetflixの社員ブログで知りました。

Pythonの各種ライブラリを活用するとデータ分析が一気にレベルUPするので、GoogleアナリティクスやAdobe Analytics、エクセルのようなツールの限界を感じているアナリストは、これを機会にぜひ挑戦してみてください。

更新しにくいので放置しがちだったこのサイトを4月にようやくリニューアル（再構築）しました。SSL化とレスポンシブ対応は当然として、画像はDAMでデバイスに合わせて解像度とフォーマットを最適し、CDNで配信。Static Generatorなので応答が速く、セキュリティも強固。ひと昔前のエンタープライズ向けCMSを無料で実現！

コンテンツ更新が滞っていた理由

• 自前のDAMライブラリが壊れて画像やコードが表示されなくなった
• CMSの管理画面が重く、古いコンテンツの把握や確認がしにくくなった
• ヨーロッパ産のCMSで日本語の漢字変換ができなくなった
• 古いコンテンツを把握できなくなった

このままではマズイ、と一年前からリニューアルの準備を進めていました。
きっかけは、USで参加したSDLのイベント。コンテンツ管理に関する最新のソリューションについて知り、いろいろ刺激を受けました。特に、Headless CMSというコンテンツの保管と表現を分離する考え方を実践したいと思うようになりました。

定めたWebリニューアルの要件

• コンテンツ（テキスト）をバージョン管理したい
• 手元で複数のコンテンツを開いて一括編集したい
• リポジトリ（コンテンツ保管）とフロントエンド（HTML表現）を分離したい
• 画像をCDNで高速化したい
• 画像はデバイスに応じて解像度と容量を最適化したい
• レイアウトをデスクトップとモバイルでレスポンシブ対応したい
• AMP対応でスマホからのアクセスを高速化したい
• 全ページSSL化したい
• 内容と合わなくなったのでドメインを変えたい
• 既存コンテンツのURLを維持したい

と積もり積もった希望を満たすために試行錯誤。

まずWordPressで構築

まずは各種プラグインを探してWordPressを拡張しました。

** Markdown対応 **
HTMLを生成するWYSIWYGエディタは余計なHTMLを挿入するのが嫌いなので、もっとシンプルでかつ普及していて長期的にサポートされそうなマークダウン形式でコンテンツを記述するためにプラグイン「JP Markdown」を導入。Jetpackの設定でもMarkdown形式を有効化できますが、多機能すぎてWordPressが重くなるのが難点。

** GitHub同期 **
WordPressのテキストコンテンツが自動的にGitHubのリポジトリに同期されるプラグイン「WordPress GitHub Sync」を導入。テキストエディタで一括編集し、コミットするだけでサイトが更新されるようにしました。コンテンツの保存時に毎回Gitにコミットするので、これもWordPressの管理画面が重くなるのが難点。

結果として、バージョン管理、ローカル一括編集、リポジトリとフロントエンドの分離はできるようになったけども、WordPressのサイトも管理画面も、あまりに遅くて更新する気が失せるほどになったので、断念。

Headless CMSは発展途上？

新興のツールやソリューションをいくつか検討しましたが、対応する無料のフロントエンドが見つからず、自前で構築する必要があったので断念。このジャンルはまだ発展途上なのかも？

静的ジェネレーター「Hexo」を採用

最近は静的HTMLを生成するジェネレーターが増えていると知り、検討を開始。
そのうちメジャーなJekyllは、方法やテンプレートが充実しているので有力候補でしたが、Rubyを今から覚える気になれず、ボツ。Node.jsベースのHexoを採用しました。

ホスティングは「Netlify」

ジェネレータの実行とホスティング環境としては、Netlifyを採用。Githubへコミットすると自動でジェネレーターの実行と配信が行われるだけでなく、CSSやJSのファイル結合・圧縮、CDN対応、タグ追加や認証、A/Bテストなどの機能があるので、GitHub Pagesよりも圧倒的に便利です。

DAMは「Cloudinary」

画像をWeb用の解像度とフォーマットに変換してからサーバーにアップロードすることは避けたいので、動的に解像度やフォーマットを変換してくれるDAM (Digital Asset Manager)と、その配信を高速化できるCDNをいろいろ検討しました。

Netlifyにも画像のCDN配信機能がついていますが、さらにデバイス毎に最適化したかったので、Cloudinaryを採用。容量や転送量によっては、なんと無料で使えるDAMです。

Cloudinaryへ画像をアップロードし、その画像のURLを細工すると、サーバー側で動的にリサイズ、フォーマット変換、トリミング、フィルタ適用などができ、その結果はCDNで配信されます。

特に気に入ったのは、デバイスの解像度（DPR）に応じて必要なピクセルサイズを算出し、過不足ない解像度の画像を自動で配信してくれる機能。高解像度のスマートフォンで見ると画像がボケボケになる状況を避けられるようになりました。

↓iPhoneのretinaなど高解像度に自動対応、フォーマットもWebPなどに最適化する画像の例

URLはres.cloudinary.com/mak00s/f_auto,w_auto:200:800/Eclipse

↓URLにパラメータを含めるだけでDPR 1.0で幅200pixelにリサイズした例

URLはres.cloudinary.com/mak00s/w_200/dpr_1.0/Eclipse

HTMLのタグで縮小しているわけではなく、環境に応じて無駄のない大きさの画像がサーバーから配信されます。

オリジナルの最大解像度の写真をそのまま入れておけるので、元画像を別で管理する必要もありません。5年くらい経って通信速度や画面の解像度がさらに改善されたとしても、一番大きな元画像を保管してサーバー側で変換しているので、画像URLのパラメータを変えるだけで対応できます。

無料でも軽量で楽なサイト運用を実現できる！

以上、試行錯誤しながら今風の構成を個人サイトで実現してみました。昔（2005年頃）は勤務先に同じようなシステムを入れるのに数千万円かけていたのに、同じような構成を今はここまで無料で実現できるのか、と興奮の連続。CMSやDAM、タグマネージャーを自作していた時期もありましたが、世界のトレンドやブラウザのバージョンアップに合わせて進化させずに放置してしまいがち。似たようなニーズを持つ人や組織は世界にたくさんいるので、車輪の再発明をするのではなく、みんなの知恵やツールを上手に活用するのが一番ですね。

ユーザー単位で分析するカスタマーアナリティクスの場合、Google AnalyticsやAdobe Analyticsの画面で表示できるレポート機能が物足りないので、Data Warehouseなどで生データ（に近い集計データ）を抽出してTableauで集計することが多いですが、データが巨大だとBIツールで読み込めません。そんな時にPythonで巨大ファイルを並列処理し、不要なカラムやレコードを削除してからBIで読み込む方法についてです。

以下のように、Adobe AnalyticsのデータをData WarehouseでFTP配信したCSVファイルをPythonで前処理してみます。

元ファイルは18.5GBもあり、ExcelでもテキストエディタでもTableauでも開けません。少しでもデータ量を減らすためにセグメントを適用してありますが、Data Warehouseのセグメント機能には制約があり、どうしても不要なデータが混ざってしまいます。

データベースやGCPで処理するのが確実ですが、手元のパソコンでサクっと分析したいので、Pythonの並列・分散処理ライブラリ「Dask」を使いました。

使ったPythonコードはこちら。
pipでdaskをインストールしておく必要があります（Anacondaには標準で含まれているようです）。

to_csvで普通にCSV保存すると、読み込みの時に分割されたパーティションの単位で分割された複数のCSVファイルが生成されます。時間はかかりますが、pandasで普通に処理した時のようにフリーズしたり待った挙句にエラーになったりしません。

メモリに読み込める程度までデータ量が減った場合は、一つにまとめて単一のCSVファイルとして保存することもできます。

上のコードを実行して生成されたのは3.6GBのCSV。Macbook上のTableauでも読み込めるようになりました。

注意点など

• CSV読み込み時に最小限のデータ型を指定するとメモリを節約できる
• 並び替えなど、全データをメモリに読み込むような処理は避ける必要がある
• NumPyとpandasのAPIを完全サポートしているわけではない

pandasだけでもchunksizeを指定してループ処理できますが、DASKだと小さな単一ファイルと同じように処理しても自動で分割や並列処理してくれるのが便利！

GTM (Google Tag Manager) でGAのClient IDを取得する最新で確実な方法について。

今までの問題点

Cookieから取得する、Callbackで取得するなど、いろいろな方法がありましたが、新規訪問の最初の1ページ目で取得できない、無駄なイベントトラッキングが増える、GAのタグをそのままカスタムJavaScriptタグとして貼り付けるので タグマネUIの便利機能を使えない、などの 不便な点があり、イマイチな状況が続いていました。

1. GA管理画面でカスタムディメンションを作る

Client IDを格納するカスタムディメンションをGAの管理画面で作成しておきます。範囲はユーザーで。

2. GTMのカスタムJavaScript変数を作る

カスタムJavaScript変数を作って以下のコードを入力します。

1
2
3
4
5

function() {
  return function(model) {
    model.set('dimension1', model.get('clientId'));
  }
}

3. customTaskを追加する

GAのタグ（または使っている場合はGA設定の変数）で、「customTask」という名前のフィールドを作成し、値で前述の変数を指定します。

はい、これだけ。簡単ですねー。

とはいえ、公開前のテストをお忘れなく。

元ネタ：#GTMTips: Use customTask To Access Tracker Values In Google Tag Manager - Simo Ahava’s blog

2018年7月追記：GTMを使わない場合はGAタグのsend previewよりも上に以下のコードを追加します。

1
2
3

ga('set', 'customTask', function(model) {
  model.set('dimension9', model.get('clientId'));
};

効果測定はアナリティクス活用方法の１つでしかなく、顧客理解やセグメント発見も重要です。例えばコンテンツマーケティングにおける単純なページ閲覧数や訪問者数は企業努力の効果を測定する指標でしかなく、顧客の理解には役立ちません。一人ひとりのサイト体験をデータを活用して理解できれば、コミュニケーション施策の立案や改善が可能になります。

そこで、訪問者がどんなトピックのコンテンツをじっくり読んでいるかをデータで把握できるデモを作ってみました。実データのレポートもリアルタイム公開！

DEMO

本サイトに全体的に導入しています。例えばこのページを下の方までスクロールしてタグや関連リンクのエリアを１秒以上表示させると、ポコっと音が鳴って画面右上に通知が表示され、そのページに設定されたトピック（タグ）である「Demo」と「Google Analytics」にそれぞれ１点が加算されます。

ポイント

• 単なるページ表示ではなく、スクロール後の表示時間で精読を判定
• 長いランディングページでも複数のエリア毎に精読を判定できる
• 訪問者の関心をタグでざっくり把握できる

Google Sheetsのレポートに自動反映される

タグごとの精読状況がわかるGoogle Sheetsを公開しておきます。

• データは1時間に1回、自動反映されます。
• スプレッドシートをコピー（複製して保存）すると自由に編集できるようになります

真似してみよう

1. どの要素がどこまで何秒間表示されたら精読とみなすかを決める
2. それを条件とするGTMの「要素の表示」トリガーを作る
3. そのトリガーでGTMのGAタグを作り、イベントを計測
4. Google Sheetを作成し、Googleアナリティクスのアドオンを使ってイベントデータを抽出する（上記のシートを参考に）

↑↑↑↑↑（コンテンツはここまで）↑↑↑↑↑

アナリティクスのDEMOページが地味なので、Google Analyticsへデータを送信するたびに音を鳴らしたり通知トーストを表示する仕組みをGTMで実装してみました。とっても実用的で流行しそうですが（笑）、実はいろんな用途で応用できます。

DEMO

このページにアクセスしてみてください。ページ読み込み時に通常のページビューが計測され、右上に通知が表示されて「ポコっ」と音が鳴ります。

さらに、商品画像を切り替えたり、「お気に入りに追加」をクリックするたびにイベントが計測されて、今度はコインGET音とともに違うデザインの通知が表示されます。

真似してみよう

2017年にanalytics.jsに追加された新機能「Task」の「customTask」を使って、GAへデータが送信される直前の処理を追加します。

1. 通知用ライブラリを組み込む

まず、GTMで組み込み変数「Container ID」と「HTML ID」を有効化しておきます。

次に、通知用のJavaScriptライブラリ「Toastr」を読み込むためのGTMタグを作成します。

単に外部のCSSとJavaScriptファイルをロードするだけですが、この外部JavaScriptファイルがロードされた後にGoogle Analyticsタグを発火させたいので、少し複雑になっています。

そのため、トリガーの指定は不要です。「トリガーがないよ」とアラートが出ますが、気にしないで保存してください。

続いて、（すでに作ってあるはずの）GA基本タグの詳細設定を開き、「タグの順序付け」の「…が発効する前にタグを配信」に上のタグを設定します。

2. データ送信時に処理されるcustomTaskを設定する

customTaskとして以下のようなカスタムJavaScript変数を作成します(既にある場合は追記)。

• MP3ファイルのURLは適宜変えてください
• サウンド再生の実装はシンプル化したので、タイミングや環境によって鳴らないことがあります（WebAudio APIで実装する方が確実）
• Toastrの読み込みや実行に失敗してもGA計測が継続されるように、try-catchで囲んでいます

これをGA設定の「フィールド」に「customTask」として追加します。その方法については「GTMでGoogleアナリティクスのClient IDを取得する一番確実で楽な方法」を参照してください。

いろいろ応用できる

以上、customTaskの活用方法について紹介しました。

今回のGA計測の通知は誰も真似しなさそうですが（笑）、以下のような応用が可能です。

応用例

• GDPRのオプトインFlagに応じて計測を停止したりパーソナルデータのみ匿名化する
• HTMLでベタ書きされたイベント計測の修正に時間がかかるのでGTMで送信前にインターセプトしてデータを改変する
• GTMのUIでは指定できないGAの詳細設定を行う
• ClientIDやTimestampなどをカスタムディメンションで計測する
• 外部APIと連携する
• GAの計測データをクラウド（GCPなど）に送信して別途記録する

効果測定はアナリティクス活用方法の１つでしかなく、顧客理解やセグメント発見も重要です。例えば、NPS算出のためにアンケートで取得する推奨度をGoogle Analyticsで計測すると、推奨度の違いによる訪問や閲覧パターンがわかるので、サイト改善やリマーケティングなどの施策につなげることができます。

NPS用アンケートに回答すると

本ページにKARTEを使ってアンケートを実装しました（一時停止中）。デモなので気軽に回答を送信してみてください。

• ページが読み込まれてから３秒後に表示されます
• ２回閉じると、もう表示されなくなります（テストしやすいよう無効化しました。毎回表示されます）
• ０〜１０の項目をクリックすると、KARTEとGoogle Analyticsでデータが記録されます
  • 「閉じる」をクリックしないと記録されません（テンプレートの仕様なのでカスタマイズ可能）

Google Sheetsのレポートに自動反映される

Google Analyticsで計測されたイベントのデータを１時間に一度自動更新するGoogle Sheetを作りました。公開しておくので自由にみてみてください。

• 数字とグラフの部分は全て自動で更新されます
• スプレッドシートをコピー（複製して保存）すると自由に編集できるようになります

回答データは通常はKARTEの管理画面からCSVでダウンロードします。GAで計測するのは、以下がメリットです。

• Google Sheetsと組み合わせると柔軟なレポートを自動化しやすい
• GAでセグメントを作成できる
  • 回答者の前後の動きを追える
  • セグメントをリマーケティングの対象にできる

真似する方法

KARTE自体のレポート機能よりも多くのディメンションや指標を使って長期の間接効果も把握したいので、アンケートが表示されたタイミング（KARTEの接客時）と、送信時の回答をGoogle Analyticsで計測します。

アンケート回答を計測するためのKARTE接客サービスを作る

表示されたKARTE接客に反応して回答を送信した時に、その回答内容を計測するため、KARTEの接客サービスを一つ作成します。

• Webhookのテンプレートを使ってMeasurement ProtocolでGAにデータを送信する
• 対象イベントは「アンケート回答が存在する」を指定する
• 自力でできない場合はプレイド社から有償のテンプレートを入手するとサポートを受けられる

表示を計測するためのKARTE接客サービスを作る

さらにアンケート表示も計測するには、KARTEのGA連携機能が便利です。テンプレート「GA cid取得_接客イベント送信（tracker名指定）」をプレイド社から入手し（有償）、接客サービスを作成します。通常のタグ導入の場合は通常版を、GTMやカスタマイズによってトラッカー名が変更されている場合はtracker名指定版を追加します。

これは汎用的な計測用の「接客サービス」です。一つ作ると全ての接客を計測できるようになります。

KARTE接客の表示をもれなく全員分GAで計測するため、「未実施時」は使いません。名前がランダムで設定されている上のアクションに名前をつけて、表示率を100%にしてから、その編集画面に移動します。

• GTMでGAを導入している場合はトラッカー名を変更
• KARTEのVisitor IDをセットするカスタムディメンション番号を指定
• KARTEに会員IDを送信している場合は「user_id送信設定」でGAのカスタムディメンション番号を指定
• 「cid送信設定」では、GAのClient IDをセットするカスタムディメンション番号を指定
• 「ga_event送信設定」では、KARTEのどの接客のどのアクションが表示されたかを計測するためにGAのイベントカテゴリ、イベントアクション、イベントラベルを指定

続いて、「接客サービスが表示されたら」という条件の配信トリガーを設定します。

保存して公開すれば設定完了。KARTEの接客が表示された時点でGAのイベントを計測できるようになりました。

効果測定はアナリティクス活用方法の１つでしかなく、顧客理解やセグメント発見も重要です。例えばECにおける売上データは事業パフォーマンスの把握に役立ちますが、顧客の理解には不十分です。
そこで、見込み顧客がどの商品をどれくらい真剣に検討しているかを数値化するデモを作ってみました。サンプルECサイトと実データのレポートも大公開！

DEMO

サンプルサイトのこの商品詳細ページを開いて、以下のいずれかの検討アクションを行うと、それぞれ点数が加算されていきます。

• 写真の切り替え
• サイズの選択
• お気に入り追加
• メーカーサイトへのリンクのクリック
• レビューの全体表示

Google Sheetsのレポートに自動反映される

結果はこのGoogle Sheetsに1時間に1回、自動反映されます。

• スプレッドシートをコピー（複製して保存）すると自由に編集できるようになります

真似してみよう

1. 商品詳細ページ上の検討系アクションをGAでイベント計測する
2. Google Sheetを作成し、Googleアナリティクスのアドオンを使ってデータを抽出する（上記のシートを参考に）

効果測定はアナリティクス活用方法の１つでしかなく、顧客理解やセグメント発見も重要です。例えば、資料請求のリード一覧にGAの閲覧履歴を合わせると、見込み顧客の関心エリアや本気度がわかるので、営業アプローチする際の参考になります。有料ツール（MA）を使わずに無料GAで実装してみました。

以下のフォームに記入して送信すると、その内容とGAの閲覧履歴データがClient ID単位で結合されてGoogle Sheetsに自動反映されます。

• 入力内容はこの公開Spreadsheetに反映されるので個人情報は入力しないでください
• GAのデータは毎日更新されます（2024年現在は一時停止しています）
• スプレッドシートをコピー（複製して保存）すると自由に編集できるようになります

真似してみよう

1. Google Formsでフォームを作る
2. 本ページを参考にしてフォームのHTMLページを作る
3. フォームを含むサイト全体にGAを導入しclient IDをカスタムディメンションへ入れる
4. Google Formsによって回答が自動記入されるGoogle SheetsにGAのアドオンを入れてGAデータを抽出し、定期実行をONにする
5. サンプルをコピーして参考にしつつ、ビジュアライズ

GDPR準拠の要件を満たすため、Adobe Analyticsにも保持期間の設定とそれを超えたデータの自動削除機能が実装されました。Googleアナリティクスの場合は一部の集計データのみ残るという仕様ですが、Adobe Analyticsの場合はざくっと月単位で全部消えます。一方、個人から受け付けるGDPR要求の対応に関しては、返すべきデータと消すべきデータを細かく設定できます。

保持期間は契約次第

Adobe Analyticsのデータ保持期間は、Adobeとの契約書で25ヶ月などと定められています。2018年5月23日よりも前に契約した場合、1年間のオマケがついるはずです。

まず、保持期間がどう設定されているかの現状を確認してみましょう。Analyticsにログインし、「管理者」メニューの中にある「データガバナンス」をクリックします。

• この例では37ヶ月になっています
• 保持期間の変更はAdobeに依頼する必要があります
• 短縮は無償、延長には追加の費用がかかります

月単位で全部消える

削除は月単位で行われます。毎月一度、期限を過ぎた月のデータが消えていきます。
例えば2018年6月2日現在、以下のように2015年3月31日までのデータが削除されてレポートに表示されなくなっていることを確認できました。

参考：データ保持に関する公式FAQ

GDPR要求の対象データを特定するラベル付け

個人（データ主体）からのデータのアクセスや削除要求への対応については、細かい設定が可能です。「可能」というより、設定は必須です。全てのデータ（ディメンションと指標）に、方針を表すラベルを設定しておく必要があります。

データガバナンスの画面でレポートスイートをクリックすると、その設定を確認・変更できます。

標準的なディメンションと指標のみ、便宜的にデフォルトでいくつかの設定がされた状態になっていますが、Adobeが法的な責任を持つ訳ではないので、導入企業が判断して追加や変更する必要があります。特にカスタムディメンション（eVar, Prop）や指標（event）は、全て無設定の状態になっているはずです。

ラベルで分類すべきデータ

• IDデータ：個人を直接・間接的に特定できるデータ
• 機密データ：地理情報などプライバシーに関わるデータ（センシティブなデータの誤訳）
• データガバナンス：GDPR要求を受けた際に対象とするデータ
  • 個人データのアクセス・削除を要求した個人を特定するためのキーとするデータ
  • アクセス（開示・送付）要求を受けた場合に返送すべきデータ
  • 削除要求を受けた場合に削除すべきデータ

すべてのディメンションと指標を、これらの3カテゴリごとに分類します。GDPR対応に直接的に必要なのは3つ目の「データガバナンス」ですが、その設定のために「IDデータ」と「機密データ」も設定しておく必要があります。

参考：GDPRラベル関する公式ヘルプ

1. IとID - どのディメンションで個人を特定するか？

まず、個人を特定できるデータにI1またはI2ラベルをつけます。

• I1（個人を直接的に特定可能）：名前やEmailアドレス、住所など、それだけで個人を特定できるデータ
• I2（個人を間接的に特定可能）：会員IDやオンライン識別子（訪問者ID、ECID、MCID）など、社外のデータを含む他のデータと組み合わせることで個人を特定できるデータ

アナリティクスの場合、I1のデータを収集することは基本的に無く、オンライン識別子はデフォルトでI2が設定されているので、実際には会員IDなどをeVarに入れている場合のみ追加でI2を付与することになると思います。

次に、アクセスや削除の要求をした本人（データ主体）を特定するためのID（キー）を選定します。本人確認をしないと、他人のセンシティブなデータを送付してしまい、データ漏えいにつながるリスクがあるためです。本人確認をどの程度どのようにして行うかの運用フローは、慎重な検討が必要です。例えば、IPアドレスは個人を間接的に特定できるI2に該当しますが、同じIPが別のデバイスで流用・共有されることがあるので、単体では本人確認できません。
Cookieに保存されるオンライン識別子も同様で、ブラウザまでしか特定できません。同じデバイスの同じブラウザを別の人が使うこともあるからです。
ログイン後に取得する会員IDなら個人レベルまで特定できますが、ログインしないサイトでは使えません。

このように、個人レベルで本人を認証できたのか、それともブラウザやデバイスまでしか特定できていないのか、によって、返信や削除するデータの種類を変える必要があります。以下のラベルによって、このレベルを区別した上で本人特定に使えるディメンションを指定します。

• ID-PERSON：認証済みユーザー（特定のユーザー）の識別に使用するID
• ID-DEVICE：デバイス（ブラウザ）の識別に使用するID

I1やI2のラベルをつけたディメンションの中から慎重に選んだ1〜2個のディメンションのみに、データガバナンスの以下のラベルを付与することになります。

参考：GDPRラベル設定のIDに関する公式ヘルプ

2. ACC - どのデータを返送すべきか？

GDPRでは、自分の個人データにアクセスする（送付してもらう）権利が保障されています。このデータのアクセス要求を個人から受け付けた場合に、どのデータを抽出して返送するのかを決めて、それぞれにデータガバナンスのACCラベルを付与します。

• ACC-ALL：ECIDなどID-DEVICEが付与されたディメンションでゆるくデータを特定できた場合に返送するデータ
• ACC-PERSON：会員IDなどID-PERSONが付与されたディメンションで本人を認証できた場合のみ返送するデータ

この設定もまた、他人のセンシティブなデータを送付してしまわないよう、慎重な検討が必要です。そのため、デフォルト設定では、最低限の標準ディメンションにのみACC-ALLが設定されています。それだけでは足りないので、残りの標準・カスタムディメンションにもACC-ALLまたはACC-PERSONを設定する必要があります。

オンライン識別子だけでアクセス要求を受け付けた場合にどこまでデータを開示すべきかは判断が必要です。Adobeの公式ヘルプでは以下のように説明されているのみで、どのデータにACC-ALLを付与すべきかの方針については書かれていません。

アクセスラベルが多くの変数に適用されることが期待されます。ただし、自社の法務チームと相談し、収集したデータのうちどれをデータ主体と共有するかを決めるのは、お客様次第です。

日本語がわかりにくいですが、「ほぼ全てのデータにACC-ALLまたはACC-PERSONのどちらかを付与するのが良いと思うけど自己判断でよろしく」という意味だと私は解釈しています。社内で議論し、例えば「全てのデータを隠さず返送するのが基本、ただし重複や類似データは省略、地域や検索キーワードや閲覧商品などセンシティブなデータは確実に本人認証できた場合のみ返送する」というようなポリシーを決める必要があります。どこまでをセンシティブとみなすのかがポイントですね。サイトによっては、閲覧したページもセンシティブな情報になり得ます。リファラや広告用パラメータなども、普段のオンライン行動癖が漏洩するので、微妙なところです。

3. DEL - データの削除はIDとの紐付け解除が目的

データの削除（匿名化）はデータと個人（ブラウザ）を紐付けできなくするのが目的なので、削除対象はディメンションのみ、その数はACCよりも圧倒的に少なくなるはずです。該当ディメンションの値はランダムな値で置き換えられ、同じヒットで送信されるその他のデータはそのまま残ります。元の値とランダム値は１：１の関係になるので、ユニーク性や連続性は維持されます。

どのデータを匿名化すればヒットと個人やブラウザが紐付かなくなるのかを調査・検討し、データガバナンスのDELラベルを付与します。

• DEL-DEVICE：ECIDなどID-DEVICEが付与されたディメンションでゆるく特定できた場合に匿名化すべきディメンション（I1, I2, S1のいずれかも必要）
• DEL-PERSON：会員IDなどID-PERSONが付与されたディメンションで本人を認証できた場合にのみ匿名化すべきディメンション（I1, I2, S1のいずれかも必要）

参照：ラベルを付与してアクセスや削除を実行するとどんなデータがどう変わるのかの具体例 - Adobe公式ヘルプ

まとめ

以上、Adobe AnalyticsのGDPR対策としての新機能について紹介しました。取得・保管する全てのデータを吟味し、２段階でプライバシー性（センシティブ性）を定義した上で、アクセスや削除要求に1ヶ月以内に対応できる運用プロセスを構築する必要があります。準備や社内調整に時間がかかるので、実際のリクエストが来る前に決めておくと良いでしょう。

なお、Googleアナリティクスの場合は、期限を過ぎたデータは個人やブラウザとの紐付けができなくなるようなデータの匿名化を行い、削除依頼があった場合はそのデータを完全削除するようです。期限を過ぎたら全部消し、削除依頼があったデータは個人やブラウザとの紐付けができなくなるようなデータの匿名化を行う、という逆のアプローチですね。GDPR施工の直前になって、それぞれが前例のない中で仕様を決めたためでしょう。GDPRの解釈はまだ曖昧なので、追加情報や前例が増えるにつれて仕様も変わっていくと思われます。

GDPRの対策としてWebアナリストがすべきことの記事の中で、個人データの取得には同意が必要、と書きました。その具体的な方法と注意点について紹介します。

同意を得るだけでは足りない

プライバシー保護のために個人データの取得に関して本人（データ主体）から明示的な同意を得るためには、以下の対応が必要です。

• 初めてサイトを訪問した時に通知を表示する
  • データ取得の概要を説明する
  • 詳細はプライバシーポリシーやCookieポリシーへ誘導する
• 個人データ取得の拒否（オプトアウト）を可能にする
  • 対象Cookieを消去する
  • GoogleやAdobe Analyticsへのデータ送信やCookie発行を止める
• 必要に応じて個人データ取得の明示的なオプトインを可能にする
  • オプトインがあるまではGoogleやAdobe Analyticsへのデータ送信やCookie発行を止める
• オプトインやオプトアウトの選択を一定期間保存しておき、次回からは通知を表示しない
  • ログインが必要な会員制サイトの場合は、サーバー側の会員情報にも反映させ、別のブラウザでログインした時も選択内容が反映されるようにする

このように書き出してみると、色々な仕組みが必要なことがわかります。

「簡単だからJavaScriptで自作できそう」と思いがちですが、既存のツールを活用した方が楽なだけでなく、ツールの機能や説明ドキュメント、アップデート内容から一般的なEU企業が抱えるニーズや解決アプローチが垣間見えて参考になるというメリットもあります。

オプトインの方式

同意の明確性によって以下のようなパターンがあります。どの方式にするかを指定できるツールもあります。

1. 通知のみ（詳細へのリンクを含む）
2. 通知＋Opt-outボタン（デフォルトはオプトイン）
3. 通知＋Opt-inボタン（閉じる、スクロール、他ページへの遷移などサイトの利用を継続する場合は同意とみなす）
4. 通知＋Opt-inボタン（デフォルトはオプトアウト）

下に行くほど厳格な運用になります。訪問者のIPアドレスからEU（EEA）からのアクセスを判定し、対応レベルを切り替えられるツールもあります。

無料で使える同意・Cookie管理ツール

Cookie管理ツールから包括的なプライバシー管理ソリューションまで色々あります。iapp.orgのPrivacy Tech Vendor Reportでは、Consent Manager（同意管理）のカテゴリだけで36ものツールが紹介されています。

今回は、無料で使えるものを5つ紹介します。

InsitesのCookie Consent

初回訪問時の通知表示と同意取得に特化したオープンソースの無料ツール。見た目や文言を細かくカスタマイズできます。デモのページで各種カスタマイズ結果を確認できます。Cookieの削除やオプトアウト機能はありません。

Cookiebot

通知表示と同意取得に加えて、サイトをスキャンしてCookie表を自動生成したり、EUからのアクセス時のみ機能をONにする機能もあります。デンマークのCybot社によるサービスを日本企業のクラスメソッド社が日本語化を行い、日本円による請求書対応を行なっています。

無料版は、100ページ以内のみに対応（超えたら有料プランへ自動移行）。多言語対応やカスタマイズができず、基本機能のみ。本番利用は現実的ではないので、事実上お試しプランという位置づけですね。

OneTrust

機能的にはCookiebotに似ていて、通知表示と同意取得に加えて、サイトをスキャンしてCookie表を自動生成したり、EUからのアクセス時のみ機能をONにする機能もあります。本サイトはこれを採用しました。

無料版でも多言語対応やカスタマイズ、サイトをスキャンしたCookie表の自動生成、入力フォーム自動検出が可能。ただしオンライン登録したすぐ使えるようにはならず、何日か経って審査を通った場合に登録の通知メールと営業担当からの個別フォローメール（英語）が届きます。

まずサイト全体を自動スキャンし、Cookieや入力フォーム、LocalStorageを検知することから始めます。

検知したCookieは、設定内容だけでなく、データベースと照合して何のCookieなのか説明文も表示してくれます。

この情報をもとにサイト上のCookie Notice（利用するCookieの説明表）ページを自動生成できます。

同意の通知は、表示場所や色、項目をカスタマイズできます。

Cookieのオプトイン・オプトアウト用UIもあります。

COOKIE INFO SCRIPT

通知表示のみに特化した無料JavaScriptライブラリ。詳細リンクを含む通知を表示するだけで、同意の管理機能はありません。デザインや文言をカスタマイズできます。

CIVICのCookie Control

同意取得というよりもCookieのオプトイン・オプトアウト管理ツール。カテゴリやツール毎に細かくCookieのON・OFFを切り替えられます。デフォルトがオプトアウト状態になっていて、ONにして明示的にオプトインする必要がある、ONからOFFに切り替えると該当Cookieが即削除される、というストリクトなポリシーが前提。イギリスの公的機関ICOが採用しています。

無料版は、初回訪問時にお知らせを表示することができない、見た目のカスタマイズが限定される、ツールのAboutページへのリンクが入る、などの機能制限があります。

本サイトでは、GDPRに関連したページにのみ、CIVIC Cookie Control V8を実験導入しています（デモ用なのでオプトアウトしてもCookieは消えません）。インストールと設定方法が難しく、日本語の情報も無いので、以下にメモを残しておきます。

まず設定情報を入力してダウンロード（タグ取得）

Cookie ControlのサイトからDownloadページへ進み、Editionを選択します。V8の場合、Community Editionは無料です。

さらに、名前やEmailアドレス、サイトのドメインなどを記入していきます。

Cookieをカテゴリやツール単位で分類し、その単位でオプトイン・アウトできるのがCIVIC Cookie Controlの一番の特徴です。そのカテゴリを編集や削除、追加します（後でJavaScriptで変更することも可能）。

サイト下部に表示される（C）アイコンの位置（左／右）、テーマ（ダーク／ライト）を指定します。

これ以外のカスタマイズ、文字色やサイズ、背景色、アイコン、Aboutリンク削除などは有償のPRO版のみで可能です。

PRO版には、さらにEUとUKからのアクセス時のみ同意を必要とするジオロケーション機能やマルチドメイン対応、多言語対応が含まれます。

最後に規約に同意してボタンをクリックすると、APIキーが発行され、実装用タグが表示されます。

Google Tag Managerでタグを入れる

発行されるタグは、HTMLソースにベタ張りするためのものです。

私はGoogle Tag Managerで管理するために、以下のように修正しました。

文言も全て日本語に変更しています。設定の詳細は公式ドキュメントをどうぞ。

オプトアウト時にGoogleアナリティクスを無効化

Googleが提供するブラウザのアドオンを紹介してインストールしてもらうのは昔の方式です。手間がかかるだけでなく、サイトに関わらずGoogleアナリティクスへのデータ送信が全て止まってしまうので、特定のサイトのみGoogleアナリティクスを無効化する新方式が望ましいです。

Googleアナリティクスのプロパティ単位でオプトアウトするには、

1

window['ga-disable-UA-XXXXX-Y'] = true;

を、GAへのデータ送信よりも前のタイミングでセットします。

参照：GA公式ヘルプ

タイミングの制御が難しいので、Cookie Controlのオプトイン時に実行されるfunctionの中にGAのタグを、オプトアウト時に実行されるfunctionの中に上記のGA無効化のJavaScript文を入れるのが確実で楽です。

onAcceptのfunctionは、オプトインした時と、次回の訪問時を含む以降のページ閲覧時に毎回実行されます。

タグマネージャーを使っている場合は、onAcceptのfunctionの中でDataLayerのイベントを発生させ、それをタグマネージャーのトリガーとしてGAの計測をすると良いでしょう。

要件を決めてから選定と導入を

以上、CIVICのCookie Control V8について詳しく紹介しました。これは明示的にオプトインしないとCookieをセットしない、というかなりストリクトなポリシーを前提としているので、日本ではInsitesのCookie Consentの方が要件に合うかもしれません。

通知のみで良いのか、オプトアウトの方法を伝えるだけで良いのか、明示的なオプトインを必要とするのか。また、サイト全体でざっくりとオプトイン・アウトすれば良いのか、それともカテゴリごとに細かい制御をするのが望ましいのか。通知はどの程度目立たせるべきか？ビジネスと顧客の双方の視点で要件を決めてから、どのツールがベストなのかを選択すると良いでしょう。

GDPRの対策としてWebアナリストがすべきことの記事の中で取り上げた、不要な個人データを匿名化する方法の一つとしてGAやAAでIPアドレスを匿名化する方法と注意点について。GAの場合、訪問者のIPアドレスをレポート画面で表示することはできませんが、システム内部に保存されています。GDPRでは、個人データを取得し保存しているだけで、ツールベンダーや代理店ではなく事業会社のデータ管理責任が問われるので要注意。

Googleアナリティクスの場合

GA公式ヘルプを見ながら設定しましょう。

GAのタグをHTMLソースにベタ張りしている場合は、pageviewを送信するよりも前（上）に以下のようなコードを追加します。

gtag.jsの場合

1

gtag('config', 'UA-********-*', { 'anonymize_ip': true });

ga.jsの場合

1
2

ga('set', 'anonymizeIp', true);
ga('send', 'pageview');

analytics.jsの場合

1
2

_gaq.push(['_gat._anonymizeIp']);
_gaq.push(['_trackPageview']);

Google Tag ManagerでGAを実装している場合は、GAタグの詳細設定で「anonymizeIp」というフィールドを追加します。

検証方法

GAのビーコンに &aip= が付与されていれば成功です。

サーバー側でデータが処理・保存されるよりも前の段階で、IPアドレスの一部が「0」で置き換えられるようになります。

IPフィルタは更新が必要

自分や社内からのアクセスを除外するためにIPを使ってフィルタしている場合は、最後の桁（オクテット）が0で置き換わるので、IPの指定方法を「前方が一致」方式に変えるなどの対応が必要です。

地域レポートの精度が落ちる

IPアドレスで判定している地域（都道府県・市区町村）のレポートは、元データの粒度が荒くなるので、精度が下がります。

GAのIPアドレスを他のシステムと連携させていないか確かめるなど、影響範囲を把握してから設定を変更すると良いでしょう。

Adobe Analyticsの場合

管理画面（レポートスイートマネージャー）の「一般的なアカウント設定」だけで対応可能です。

IPアドレスの最後のオクテットを0に置き換える

GAと同じ方式です。IP除外よりも先に置き換えられるので、GAと同様にフィルタ設定を見直す必要があります。

IPアドレスを不明化

IPアドレスをハッシュ化された文字列で置き換えます。IP除外や地域特定の処理が行われた後に不明化されるので、IP除外の設定変更は不要です。

IPアドレスを削除

IPアドレスを一律の固定文字列（x.x.x.x）で置き換えます。EMEA向けのレポートスイートでは、これがデフォルトで有効になります。IP除外や地域特定の処理が行われた後に削除されるので、IP除外の設定変更は不要です。