最新機能をフル活用してセキュアで爆速、SEOも最高のサイトを(ほぼ無料で)実現する考え方と方針についてはGatsbyとNetlifyを使って爆速サイトを2時間で構築をどうぞ。早くCMS画面でコンテンツを修正できるようにしたいので、今回はNetlify CMSを設定し、コンテンツの編集に着手します。
GatsbyはWebブラウザで動作するフロントエンドのアプリで、CMSの「ヘッド」部分にあたります。コンテンツの編集や管理、保管の機能はなく、ContentfulやPrismicのようなヘッドレスCMSや、プラグインでヘッドレス化したWordPressからAPI経由でコンテンツを取得する設計になっています。今回のサイトは小規模なので、GitHubのリポジトリにマークダウン形式でコンテンツを格納することにしました。
エンジニアなら、GitHubだけでもマークダウン形式のテキストファイルの編集やレビュー・承認ワークフローを運用できると思いますが、コンテンツのライターや編集者には、もっと使いやすい編集画面が必要です。
そこで、今回はNetlifyの無料オマケ機能「Netlify CMS」を使います。これはGatsbyと同様にReactのアプリで、GitHubのリポジトリ上の.mdファイルを読み書きする編集画面や簡易ワークフロー機能が使えるようになります。
Netlify CMSは今回ベースにしたGatsby + Netlify CMS Starterに最初から含まれているので、Netlifyの開発サーバーを起動するとNetlify CMSも起動します。
以下のように、起動時にコンソールに表示されるメッセージにNetlify CMSのURLが表示されるので、アクセスしてみます。
CMS画面は至ってシンプル。コンテンツ(ページ)とメディア(画像)を管理します。コンテンツはさらにブログエントリと固定ページに分けて管理するようStarterのCMSは設定されています(変更可能)。
Pages>Landing Pageがトップページ。開いて編集し、Publishすると、変更されたマークダウンのファイルがGitHubにコミットされ、その結果Netlifyがデプロイを開始。本番ページに反映されます。
商用CMSほど作り込まれていないので、入力欄の順番が実際の画面と一致しなかったり、レイアウトがズレたりし、完全なプレビューにならない点はガマン。
「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を設定すると、ヘッダにサイトへのリンクが追加され、ドラフト保存したページをプレビューできるようになります。
前回にディレクトリ構成を変更したので、それらのページがCMS画面に表示されなくなりました。設定ファイル「config.yml」中のパスを更新して直します(上の図を参照)。
これでようやく、コンテンツを編集できるようになりました。
この Starterのテンプレ を このサイト に近づけようとしています。今のところ こんなサイト になってます。
次回は、ページの構造やお問い合わせ機能をチューニングします。
]]>最新の思想・機能・ツールをフル活用してセキュアで爆速、SEOも最高のサイトを(ほぼ無料で)実現する連載その1ではGatsbyとNetlifyを使って爆速サイトを2時間で構築しました。まだデフォルトのダミーサイトのままなので、今回はGatsbyを設定してサイト名や構成を修正します。
3日目の今回は、最低限の設定を行い、今回使ったテンプレート (Gatsby + Netlify Starter)に含まれているNetlify CMSというコンテンツ編集の画面が使えるようにします。サイト名やメニュー構成、URLの変更までで、デザインやコンテンツは今回は変更しません。
画像の管理と配信はCloudinaryを使います。デバイスやブラウザに応じて最適な解像度で最適なサイズの画像をサーバー側で生成してくれるので、画像の質を落とさずにサイトの速度を向上できます。今回のテンプレート(Gatsby + Netlify Starter)はUploadcareにも対応していますが、Uploadcareは有料プランのみの提供に方針を変えたようです。継続的な無償利用はできなくなりました。
GitHubのリポジトリ中でコンテンツ(.mdファイル)の追加や更新を行う(コミットする)と、Netlifyが自動でデプロイを開始し、HTMLやJSが生成され、ホスティングのサーバーに転送される、というのが日々の運用の流れです(今回の構成の場合。GitHubではなくヘッドレスCMSやWordPressと連携させることも可能)。
一方、サイトやCMSのカスタマイズをするためには、手元のPC(やMac)でもGatsbyサーバを走らせて開発環境を作る必要があります。
まず、Gatsbyが動作するフレームワークの「Node」と、作業で使うコマンドラインのツールをインストールします。
次に、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をブラウザで開き、作業を続けます。
Gatsby全体の設定は、ルート直下の「gatsby-config.js」に書かれています。
まず、冒頭のサイト名とサイト説明を編集。
全ページのtitleタグとmetaタグにすぐ反映されました。開発サーバーの場合、ファイルを変更しても再起動やブラウザのリロードは不要です。
なお、次回に使うCMS画面では、各ページごとに異なるタイトルとdescriptionを設定できます。このconfigファイルの設定は、個別設定をしなかった場合のデフォルト値になります。
デフォルトのサイト構成を以下のように変えたいので、/src/pages/のディレクトリ名とファイル名を変更します。
/contact/の中の不要な2つのファイルを削除し、/blog/ と /products/ のディレクトリ名を変更しました。変更直後はブラウザがエラー画面になりますが、気にしないで/products/(変更後はseminar)の中のindex.mdを開いて、冒頭の
path: /products
を
path: /seminar
に変更し、開発サーバーを再起動(Control+Cで停止してもう一度netlify devを実行)します。
どのファイルのどこを変更するのかは、Gatsbyサイトの作り方次第です。
URLが変わったので、各種メニューのリンクが切れてしまいました。リンクはURLのパスを直書きする作りになっているので、以下のファイルを修正します。
ついでに使わないSNSアイコンも削除。ロゴ画像のAltとサイズが直書きされているので修正。
/src/img/logo.svg にロゴ画像
/static/img/ に各種favicon
のファイルが格納されているので、同じファイル名で画像を上書きすると楽です。
テンプレのサイトがどう構築されているかを理解するのに時間がかかりました。所要時間は、Node環境の有無や、サイトの構成・デザインをテンプレからどれくらい変更するかによって変わると思います。
構築中のサイトはこちら。次回はコンテンツを編集するCMS管理画面を設定し、コンテンツの更新を開始します。
]]>最新の思想・機能・ツールをフル活用してセキュアで爆速、SEOも最高のサイトを(ほぼ無料で)実現するのがこの連載の目的です。前回はGatsbyとNetlifyを使って爆速サイトを2時間で構築しました。今回は、新しいサーバーサイドGTMを導入してセキュアかつ負荷を下げる形で2種類のGAを導入し、さらにプライバシー保護とITP対応のためCookie管理を改善する方法と結果を紹介します。
サーバーサイドGTMは「爆速セキュアサイトを構築したい」という前提がないと意味がないので、未読の方はその1も読んでみてください。
ITPは抜け道を探すのではなく、お客さまの意思を尊重してパーソナルデータをしっかりセキュアに管理するのが一番。タグマネージャーはそのために最も重要なパートを担うので、サイトの制作・開発・構築を進める前にデータやタグの活用と管理方法についてしっかり設計しておきたいところ。
今回の前提は
そこで、以下のような方針を立てました。
構築中のサイトにタグマネとGAを導入し、サイトの制作とアナリティクスのカスタマイズをアジャイルに同時進行していきます。
今回はITP対策したいので、サブドメインの割り当ては必須です。
ブラウザの負荷をなるべく減らしたいので、GA(Universal Analytics)ではなく新しいGA4(App + Web)のみをGTMではなくgtag.jsで導入します。
サーバーサイドGTMでブラウザの負荷を減らし、送信データを極力減らしたい場合、従来のGA (Universal Analytics)ではなく、新しいGoogle Analytics 4 (旧Web + App)のみをクリーンに導入するのが実はベストです。GA4はイベント中心の考え方なので、デフォルト導入だけでもスクロールや離脱クリック、ダウンロード、動画再生などのイベントを計測でき、サーバーサイドGTMの思想にマッチします。GAのJavaScriptライブラリも新しいGA4の方が開発の力が入っていて、より改善や進化を期待できます。
普通にGA4のタグを入れて動作検証を終えたら、GAデータの送信先をGoogleのサーバーではなく、1で構築したサブドメイン上のGTMサーバーに変更するため、「トランスポートURL」を指定します。
1 | <!-- Global site tag (gtag.js) - Google Analytics --> |
参考:ウェブ用のGTMでGA4を導入する場合は、以下のようにフィールドを追加します。
これで、GAのデータの送付先がGAのサーバーではなく今回立ち上げたGTMサーバーに変わります。
サーバー用GTMの「クライアント」はGAのビーコン(計測用データ)を受け取るレシーバーです。サーバーサイドGTMの設定に基づいてデータを処理し、GAなどのサーバーへデータを送信します。
サーバーサイドGTMのコンテナではデフォルトで2種類の「クライアント」が作成されますが、設計思想的に、この両方のクライアントを同時に使うことはあまり無いはず。せっかくサーバーサイドのGTMを導入するので、ブラウザから飛ばすビーコンはGA4に一本化し、GAのデータはGTMサーバーから送信するのが良いので、「Universal Analytics」のクライアントは削除しました。
サーバーサイドでデータの加工を行う場合、クライアントのテンプレートを自作することになりますが、今回はデフォルトの「GA4」をそのまま使います。よりセキュアにするため、1箇所だけ設定を変更します。
詳細設定>SameSite
詳細設定では、「_ga」Cookieとは別の、訪問者(ブラウザ)を識別するIDを格納するためにGTMサーバーから送信される「FPID」Cookieの設定ができます。SameSiteは「Lax」に変更しました。現時点ではITPとは関係ないですが、なるべくセキュアにしておきたいので。
サーバーサイドGTMのタグの発火条件とするトリガーを、サーバーサイドGTMのコンテナ内で作ります。トリガーの種類は「カスタム」です。GTMコンテナにデフォルトで作られているクライアントがデータを受信した時に反応します。
今後対象サイトやビーコンの種類が増えた場合、トリガーが全てのデータに反応してしまうとゴミデータが増えるので、ビーコンの種類と計測IDで制限をかけます。
「Client Name」は組み込み変数で、有効化が必要です。受信データに反応したGTMクライアントの名前がセットされます。
「Query String」も組み込み変数です。ビーコンのURL中の「?」以降の文字列(パラメータの組み合わせ)が格納されます。
最後に、4で作成したトリガーを条件としたGAタグを作ります。
今回は爆速セキュアなサイトを作るのが趣旨なので、サイトにはGA4のみをgtag.jsでミニマム実装し、GTMサーバー側で受信するデータを分解・複製してサーバー間通信でGA v1とGA4の計測を行います。
GA4のタグは、受信したデータをそのまま送信する場合は、設定は不要です。サーバー側でデータの分解や加工、マッピングなどの処理をしたいので、後日必要に応じてカスタマイズの設定を行います。
GA (Universal Analytics)のタグでは「UA-xxxxxxxxx-x」というGAのプロパティIDを上書き指定します。GTMサーバーが受信するのはGA4用ビーコンなので、GAのプロパティIDは含まれていません。
これで最低限の設定は終わり。検証して公開します。
今回は爆速セキュアなサイトを作るのが趣旨なので、カスタムディメンションへ値をセットするなどのカスタマイズは極力サーバーサイドで行います。
無料のGA(Universal Analytics)はBigQueryで生データを抽出できないので、カスタムディメンションに追加のデータをセットしておくと何かと便利。今回はGTMサーバー側でそのカスタマイズを行ってみます。
カスタムディメンションに入れるデータ
この2つのデータはgtag.jsからのストリームを受け取ったGTMサーバー上のクライアントが分解して「イベントデータ」として利用可能になっているので、それを取り出して格納するGTM変数を2つ作成します。
この2つをカスタムディメンションにセットするため、GAのタグにフィールドを追加します。サーバーサイドコンテナのGAタグには、カスタムディメンション用の入力欄がないので、ビーコンのパラメータと同じ「cd+数字」と言う書式でフィールドを追加します。
GA側でもカスタムディメンションを定義し、サーバーサイドGTMのコンテナを検証・公開して終わり。GAで2種類のカスタムデータを計測開始しました。
Safari 13.1.2でサイトにアクセスすると、従来の「_ga」に加えて「FPID」Cookieが発行されました。
_ga:ITPにより期限が2年から1週間に短縮された
FPID:期限は2年間、Secure、HttpOnly、Lax
どちらかを削除しても、リロードすると同じ値で復活します。FPIDの値に_gaの一部が含まれているので、お互いリンクしているようです。
ブラウザからのビーコンでは今まで通りcidパラメータに_gaの値がセットされますが、GTMサーバーはFPIDを優先し、それをGAサーバーに送信してくれます。
爆速セキュアなサイト構築という目的意識を持って実際にサーバーサイドGTMを導入した結果、いろいろわかりました。
最初から正解がわかっていれば、2時間で終わる作業です。
リアルに構築中のサイトはこちら。記事が進行しながらサイトも変わっていきます。
次回はGatsbyをカスタマイズし、サイト名やURL構成、ナビゲーションリンクを更新します。その後はコンテンツ投入、デザイン変更と進めていきます。
]]>CXやDX(デジタルトランスフォーメーション)が流行ってきましたが、ツールのタグを入れすぎてサイトが重い、iTPなどセキュリティ・プライバシー対策が弱いので精度が落ちた、なんて状況は避けたいですよね。
「分かりやすいデザイン」「使いやすいUI」は誰でも追求できますが、楽してWordPressを使っているようではパフォーマンスのチューニングに限界があります。ここ数年、数週間でWebの技術は驚くほど格段に進化しました。
そこで、将来のWebの進化を見据えて最先端のツールやアプローチを使って、でも(ほぼ)無料でセキュアで爆速なサイトを最短で構築することに挑戦します。
CMSとタグ管理の発想を根本的に変えることで、爆速セキュアなサイトを実現することにします。
まず、CMSはヘッドレスとSPAを組み合わせます。ヘッドレスCMSは2017年あたりから進化が加速し、WordPressのような動的CMSは言うまでもなく、静的サイトよりもさらに速くて快適なウェブサイトを実現できるフロントエンド技術「SPA」の流れと合流。ツールや情報も増えたので、だいぶ実用的になりました。
タグマネジメントは、GDPRの施行やiTPの進化で迷走、イタチごっこが続きましたが、Google Tag Manager(GTM)のサーバーサイド化という新機能がベータ公開され、サーバーから生成するセキュアなCookieの実現が簡単になりました。
アナリティクスは、クリックやスクロールのようなイベントを計測サーバーに送信し、ヒット単位の生データを別のBI(DataポータルやTableau、PowerBI)で集計・可視化するのが最近のトレンド。訪問者一人ひとりの行動や心理の変化を追うカスタマーアナリティクス的なアプローチも増えてきました。
Adobe Analyticsは、軽量・汎用化した計測用JavaScriptライブラリの新バージョンをリリース。生データの取り出しは少し不便です。
GoogleもFirebaseをベースとしたGoogle Analyticsの新しいバージョン(Web + App)をイベント型に切り替えて生ログ保存にも対応し、開発に力を入れています。ログインして利用するレポート画面はおまけのプレビュー機能でしかなく、今後はあまり進化しないでしょう。その代わりにプラットフォームとしての進化が半端ないです。広告連携しないなら360も不要?!
理屈だけの机上の空論にならないよう、実在するWordPressのサイトを再構築することで
という懸念を具体的にクリアしていきます。
本サイトは2018年にWordPressからヘッドレスCMSのhexoに移行し、CDNベースのホスティング「Netlify」と画像管理のGAM「Cloudinary」を採用したので割と高速ですが、SPAではない単なる静的HTMLなので、今回の最新アプローチとツールを組み合わせると、もっと速くなるはず。
今回はWordPressと比較したいので、「コンセプトダイアグラム公式サイト」を移行対象にします。そのサイトはチューニングしてないので重いです。WooCommerceのショッピングカートもあるので、さらにShopifyでヘッドレスコマースに挑戦するかも?
デザインは後で変更すれば良いので、まず先にテンプレートを使って開発用サイトを立ち上げることにします。従来の「WordPressをインストールして適当なテーマを適用する」作業に近いイメージです。
CMSのヘッド側は、GatsbyJSを採用。最近はGatsbyかNuxtの二択でしょう。機能に大差はないので、お好みで。私はReactの方に将来性を感じました。
ホスティングは、レガシーなレンタルサーバーをやめて最先端でホットなNetlifyに移行。使っていくうちに進化していくので、Webの将来が垣間見えて「その手があった!」と感動することもしばしば。運用管理も劇的に楽です。
コンテンツの格納という意味でのCMSは、GitHubを選びました。チームでの同時作業やバージョン管理ができます。
コンテンツ編集はNetlify CMSを使い、マークダウン形式で記述することで構造化されたクリーンなHTMLを実現します。無制限で自由すぎるHTML形式はパフォーマンス低下の原因になるので禁止。
画像管理は、リサイズや最適化、Retina対応ができるデジタルアセット管理(DAM)を導入します。DAMは高価なソリューションが多い状況が10年以上続きましたが、今風のモダンで安価なサービスがここ数年で増えてきました。今回は、長年のノウハウに基づく豊富で実用的な機能を持ち、小規模なら無料で使えるCloudinaryを採用します(本サイトで利用中)
早速作業スタートです。
Netlify+Gatsby+Cloudinaryの組み合わせの場合、Netlifyが提供するテンプレを使うと、1クリックでインストールできます。
「Deploy to netlify」ボタンをクリックし、GitHubのリポジトリ名を変更して「Save and deploy」ボタンをクリック。
リポジトリ作成とNetlify接続設定、デプロイまでが一気に完了し、仮ドメインでサイトが立ち上がります。
デフォルト状態の架空サイトを開いて、いろいろクリックしてみてください。
SPAなので、最初のページを開いた時点で他のページのコンテンツも読み込んだり、リロードせずにコンテンツを書き換えたりでき、劇的に速いです。ページごとにURLがちゃんと切り替わります。SEOもスマホ最適化も完璧。
いくつかのメールがNetlifyで登録したメールアドレスに届きますが、そのうち「You’ve been invited to join xxx.netlify.app」という件名のメールだけ、対応が必要です。
と言っても本文中の「Accept the invite」をクリックし、Netlifyのアカウントでログインするだけ。CMS用のパスワードを指定すると登録が完了し、CMS管理画面が開きます。
テンプレを使ったので、ダミーの珈琲屋サイトのコンテンツがいくつか投稿済みになっています。
次に、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のタグを入れます。
慣れると1時間で終わります。
NetlifyやGitHubが初めてで、ドメインも新規に取得する場合は、半日くらいでしょうか。
LPのような長いページの場合、表示回数(PV)よりも「どこまでスクロールしてじっくりコンテンツを読み込んだか」が重要です。GTMを使うと、画面の何パーセントまでスクロールされたか、を簡単に計測できますが、ページによってパーセントの解釈が異なり、分析が難しいので、ページをセクション(パーツ)に分割し、その単位で画面にN秒間以上表示された、という計測方法がオススメです。
ただし、ページの作り方に合わせてGTMの設定を追加したり削除するのは運用が大変なので、ページ制作時に決められた属性を追加するだけで、GTMの設定を変更することなく計測すると良いでしょう。
このページ自体に実装してあるので、ゆっくりスクロールしながら以下のセクション2以降をブラウザの画面に表示させた状態で2秒などの指定時間が過ぎると、GAでイベントが計測され、画面右上に通知が表示されます。
という問題があります。
そこで、対象セクションを囲むdivタグに以下のような計測目的に特化した属性を付与し、GTMがその値を読み取って自動的に計測するようにすれば、GTMの運用が不要になります。
まず、セクション名など、アナリティクスのレポート上で表示される文字列を指定します。
1 | data-track-name="Section 2" |
1 | data-track-trigger="view" |
応用例として、「click」や「hover」なども条件として考えられますね。
実際に以下の「セクション2」に設定してあるので、セクション2の高さのうち20%以上を2秒間表示させると、Google Analyticsのイベント計測が発火します。
1 | data-track-name="Section 2" |
という3種類の値を読み取ってGoogle Analyticsで計測するために、Google Tag Manager(GTM)の設定を行います。
まず、HTMLタグの属性として設定された各種設定内容を取得するために、「データレイヤーの変数」の変数を2つ作成します。
エリアの名前
変数名には以下を入力します。
gtm.element.dataset.trackName
表示時間(ミリセカンド)
変数名には以下を入力します。
gtm.element.dataset.trackDuration
変数名の中の「gtm.element」はGTM標準のデータレイヤー変数で、計測対象の要素(タグ)が格納されます。属性の名前「data-track-name」のうち、「data-」の部分は自動で削除され、ハイフン「-」も削除され、続く単語の頭が大文字に変換されるので、「dataset.trackName」という少し異なる表記になります。
参考:データ属性の使用 - MDN Web Docs
1 | data-track-name="Section 3" |
次に、「要素の表示」タイプのトリガーを作ります。
選択方法は「CSSセレクタ」、要素セレクタには以下のように入力します。
[data-track-trigger=”view”]
「トリガーを起動するタイミング」は「1要素につき1度」に変更します。一つのページにセクションが複数ある場合、それぞれのセクション単位で一回ずつ計測するためです。
「画面上での最小表示時間を設定」には、先ほど作成したGTM変数を指定します。
GTMの設定は以上でおしまい。今後は、どのページでも、divなどのタグに属性を追加するだけで、要素の表示をGoogle Analyticsで計測できるようになりました。もうGTMを毎回編集する必要はありません。運用が劇的に楽になりました。楽というより、運用フリー、不要になりました!
今回は説明のために実装をシンプルにしましたが、「20%」という表示条件も変数にしたり、+3点、+5点、といったスコアリングの加点を指定したり、GAのカスタム指標の番号を指定するなど、いろいろな応用が可能です。クリックやオンマウスの計測も同じ方式で実現できます。
企業で採用されることが多いBrightcove動画。動画ごとの再生回数や完了はBrightcoveの管理画面でも調べられますが、Google AnalyticsやAdobe Analyticsなどのサイト内の行動データと統合すると、顧客体験を点ではなく線で理解できるようになります。
そのためには、まず動画視聴行動(再生開始と再生完了)をアナリティクスで計測する実装が必要です。YouTubeと違ってBrightcoveの情報は少なく、公式サイトも散らかっていて日本語が変(ネイティブのレビューをしていない機械翻訳?)なので、メモを残しておきます。
Brightcoveの動画は、以下のような形式でページに埋め込まれていて、そのページにはすでにGTMとGAが導入されていると想定します。
1 | <video |
Google Tag Managerの標準機能であるYouTube計測機能を流用することで、最低限の手間とコードで実装するという方針で進めます。
以下で紹介するのはBrightcoveのGAプラグインを使わない方法です。Brightcoveのアカウントがなくても計測開始できます。
まず、埋め込まれた一つまたは複数の動画にイベント処理を仕込むため、
以下のコードをGTMのHTMLタグとして作成します。
1 | <script> |
BrightcoveのJavaScriptライブラリ(videojs)がロードされていないとエラーになるので、このタグはBrightcoveの動画が存在するページでのみ発火させます(タイミングにも注意)
このタグが送信するdataLayerを受け取るための組み込み変数「Video Status」と「Video Title」を有効にします。
dataLayerへpushされるeventを受け取るためのトリガーを作成します。
続いて、上記のトリガーで発火するGA計測用のタグを作ります。
これで、動画の再生開始と再生完了時にイベント計測できるようになります。
GAのイベント計測だけだと「どの動画が何回再生開始や完了されたのか」という点の分析になってしまいがちなので、動画の再生完了(や再生開始)をGAの目標として設定します。
この設定によって再生完了を指標として使えるようになるので、冒頭のような顧客の長期的な変化を把握できるカスタマーアナリティクス流のレポートを作れるようになります。
要件に応じて応用してみてください!
]]>「直帰率が高いキャンペーン用LPがあり、時間をかけてスクロールしながら読まれているのか知りたい」というご質問をいただいたので、ここで回答します。
GTMとGAで実装しやすいように、ページのスクロール(10%間隔)の最大量と滞在時間(3秒間隔)をGTMの機能を使って計測し、ページを移動や離脱する時に最終的な値をイベント計測するというアプローチをおすすめします。実際にこのページに実装し、計測データとレポートも共有しておきました。
このページを開くとタイマーがスタートします(毎秒だと細かすぎるので3秒毎)
別のページへ移動したりタブやウィンドウを閉じる時にタイマーが停止して最終的な滞在時間が確定し、GAへデータが送信されます。
こんなデータが取れるようになります。
結果はこのGoogle Sheetsに1時間に1回、自動反映されます。
GTMで
1 | <script> |
1 | function() { |
2019年4月23日:データレイヤー変数自体の名前と設定画面中の「データレイヤー変数の名前」は別物です。後者で指定すべき文字列について追記しました。
Google ColaboratoryでR言語を使うためには、追加インストールやセッション強制終了などが必要で、毎回数分間かかるという状況でしたが、2月頃にRのカーネルがこっそりと追加されたようで、面倒なハックは不要になりました。その方法についてのメモ。
まず、Google Colaboratoryにデフォルトでインストールされているカーネルを確認するため、以下を実行します。
!jupyter-kernelspec list
kernels/irが表示されれば、Rのカーネルが入っているということ。
2019年4月3日時点で、Swiftも入っているようです。
カーネルは入っているのにGoogle Colaboratoryのランタイム変更画面に「R」がまだ表示されず、選択できないので、Notebook(.ipynb)ファイルをダウンロードし、テキストエディタで開いて以下の部分を編集します。
1 | "kernelspec": { |
終わったらこのNotebookをアップロードして開くだけ。
ランタイムのタイプを確認すると「R」に切り替わっていることがわかります。
あとは普通にRが使えます。
簡単!
元ネタ:
]]>Jupyter Notebookの利便性はそのままで、操作性とデータビジュアライズ機能が改善されたnteractを最近よく使っています。日本ではあまり知られていないようなので、デモ動画を作ってみました。
操作性やデザインも大事ですが、データ分析の場合はこちらの方が重要ですね。
nteractには、データをインタラクティブに確認や探索できるData Explorerの機能が内蔵されています。
テーブル形式の場合はカラムの幅を変更したり、ヘッダをクリックして並び替えしたり、一度に表示される行数を変更してページ分割できます。ヘッダは固定表示されるので、大量データを確認しやすくなっています。
さらに、インタラクティブなグラフ表示も簡単。Pythonモジュールをimportしたり設定用のコードを書くことなく、クリックだけで表示方法を切り替えられます。
詳細は開発者のブログ記事をどうぞ:Designing the nteract Data Explorer(英語)
Jupyter Notebookはキーボードショートカットを使う前提のUIになっているのか、とっつきにくく、慣れるまで時間がかかります。
nteractの場合、セルをドラッグ&ドロップで移動したり、ゴミ箱アイコンをクリックして削除したりと直感的に利用できるので、エンジニアではないマーケターやビジュアル派のアナリストにフレンドリー。
Jupyter Notebookに慣れた人なら、より機能的なWeb版がオススメ。
コマンドラインを使いたくない、エンジニアではないのでGUIで使いたい!という人は、シンプルなデスクトップ版が使いやすいでしょう。
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を無料で実現!
このままではマズイ、と一年前からリニューアルの準備を進めていました。
きっかけは、USで参加したSDLのイベント。コンテンツ管理に関する最新のソリューションについて知り、いろいろ刺激を受けました。特に、Headless CMSというコンテンツの保管と表現を分離する考え方を実践したいと思うようになりました。
と積もり積もった希望を満たすために試行錯誤。
まずは各種プラグインを探してWordPressを拡張しました。
** Markdown対応 **
HTMLを生成するWYSIWYGエディタは余計なHTMLを挿入するのが嫌いなので、もっとシンプルでかつ普及していて長期的にサポートされそうなマークダウン形式でコンテンツを記述するためにプラグイン「JP Markdown」を導入。Jetpackの設定でもMarkdown形式を有効化できますが、多機能すぎてWordPressが重くなるのが難点。
** GitHub同期 **
WordPressのテキストコンテンツが自動的にGitHubのリポジトリに同期されるプラグイン「WordPress GitHub Sync」を導入。テキストエディタで一括編集し、コミットするだけでサイトが更新されるようにしました。コンテンツの保存時に毎回Gitにコミットするので、これもWordPressの管理画面が重くなるのが難点。
結果として、バージョン管理、ローカル一括編集、リポジトリとフロントエンドの分離はできるようになったけども、WordPressのサイトも管理画面も、あまりに遅くて更新する気が失せるほどになったので、断念。
新興のツールやソリューションをいくつか検討しましたが、対応する無料のフロントエンドが見つからず、自前で構築する必要があったので断念。このジャンルはまだ発展途上なのかも?
最近は静的HTMLを生成するジェネレーターが増えていると知り、検討を開始。
そのうちメジャーなJekyllは、方法やテンプレートが充実しているので有力候補でしたが、Rubyを今から覚える気になれず、ボツ。Node.jsベースのHexoを採用しました。
ジェネレータの実行とホスティング環境としては、Netlifyを採用。Githubへコミットすると自動でジェネレーターの実行と配信が行われるだけでなく、CSSやJSのファイル結合・圧縮、CDN対応、タグ追加や認証、A/Bテストなどの機能があるので、GitHub Pagesよりも圧倒的に便利です。
画像を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でも読み込めるようになりました。
注意点など
pandasだけでもchunksizeを指定してループ処理できますが、DASKだと小さな単一ファイルと同じように処理しても自動で分割や並列処理してくれるのが便利!
]]>GTM (Google Tag Manager) でGAのClient IDを取得する最新で確実な方法について。
Cookieから取得する、Callbackで取得するなど、いろいろな方法がありましたが、新規訪問の最初の1ページ目で取得できない、無駄なイベントトラッキングが増える、GAのタグをそのままカスタムJavaScriptタグとして貼り付けるので タグマネUIの便利機能を使えない、などの 不便な点があり、イマイチな状況が続いていました。
2018年10月現在は、2017年にGA (analytics.js)に追加されたCustomTaskという機能を使うのが一番楽で確実です。
Client IDを格納するカスタムディメンションをGAの管理画面で作成しておきます。範囲はユーザーで。
カスタムJavaScript変数を作って以下のコードを入力します。
1 | function() { |
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 | ga('set', 'customTask', function(model) { |
さらに、アクセス時間(年月日+時分秒)も別のカスタムディメンションへ入れるのがオススメです。一人ひとりの行動データをAPIやGoogle Sheetsで抽出する際に役立ちます。
詳しくはこちら:GTMでGoogleアナリティクスのアクセス時間を計測しよう
効果測定はアナリティクス活用方法の1つでしかなく、顧客理解やセグメント発見も重要です。例えばコンテンツマーケティングにおける単純なページ閲覧数や訪問者数は企業努力の効果を測定する指標でしかなく、顧客の理解には役立ちません。一人ひとりのサイト体験をデータを活用して理解できれば、コミュニケーション施策の立案や改善が可能になります。
そこで、訪問者がどんなトピックのコンテンツをじっくり読んでいるかをデータで把握できるデモを作ってみました。実データのレポートもリアルタイム公開!
本サイトに全体的に導入しています。例えばこのページを下の方までスクロールしてタグや関連リンクのエリアを1秒以上表示させると、ポコっと音が鳴って画面右上に通知が表示され、そのページに設定されたトピック(タグ)である「Demo」と「Google Analytics」にそれぞれ1点が加算されます。
GAサーバーへデータが送信されると、画面右上に通知が表示されます
タグごとの精読状況がわかるGoogle Sheetsを公開しておきます。
↑↑↑↑↑(コンテンツはここまで)↑↑↑↑↑
]]>アナリティクスのDEMOページが地味なので、Google Analyticsへデータを送信するたびに音を鳴らしたり通知トーストを表示する仕組みをGTMで実装してみました。とっても実用的で流行しそうですが(笑)、実はいろんな用途で応用できます。
このページにアクセスしてみてください。ページ読み込み時に通常のページビューが計測され、右上に通知が表示されて「ポコっ」と音が鳴ります。
さらに、商品画像を切り替えたり、「お気に入りに追加」をクリックするたびにイベントが計測されて、今度はコインGET音とともに違うデザインの通知が表示されます。
2017年にanalytics.jsに追加された新機能「Task」の「customTask」を使って、GAへデータが送信される直前の処理を追加します。
まず、GTMで組み込み変数「Container ID」と「HTML ID」を有効化しておきます。
次に、通知用のJavaScriptライブラリ「Toastr」を読み込むためのGTMタグを作成します。
単に外部のCSSとJavaScriptファイルをロードするだけですが、この外部JavaScriptファイルがロードされた後にGoogle Analyticsタグを発火させたいので、少し複雑になっています。
そのため、トリガーの指定は不要です。「トリガーがないよ」とアラートが出ますが、気にしないで保存してください。
続いて、(すでに作ってあるはずの)GA基本タグの詳細設定を開き、「タグの順序付け」の「…が発効する前にタグを配信」に上のタグを設定します。
customTaskとして以下のようなカスタムJavaScript変数を作成します(既にある場合は追記)。
これをGA設定の「フィールド」に「customTask」として追加します。その方法については「GTMでGoogleアナリティクスのClient IDを取得する一番確実で楽な方法」を参照してください。
以上、customTaskの活用方法について紹介しました。
今回のGA計測の通知は誰も真似しなさそうですが(笑)、以下のような応用が可能です。
効果測定はアナリティクス活用方法の1つでしかなく、顧客理解やセグメント発見も重要です。例えば、NPS算出のためにアンケートで取得する推奨度をGoogle Analyticsで計測すると、推奨度の違いによる訪問や閲覧パターンがわかるので、サイト改善やリマーケティングなどの施策につなげることができます。
本ページにKARTEを使ってアンケートを実装しました(一時停止中)。デモなので気軽に回答を送信してみてください。
Google Analyticsで計測されたイベントのデータを1時間に一度自動更新するGoogle Sheetを作りました。公開しておくので自由にみてみてください。
回答データは通常はKARTEの管理画面からCSVでダウンロードします。GAで計測するのは、以下がメリットです。
KARTE自体のレポート機能よりも多くのディメンションや指標を使って長期の間接効果も把握したいので、アンケートが表示されたタイミング(KARTEの接客時)と、送信時の回答をGoogle Analyticsで計測します。
表示されたKARTE接客に反応して回答を送信した時に、その回答内容を計測するため、KARTEの接客サービスを一つ作成します。
さらにアンケート表示も計測するには、KARTEのGA連携機能が便利です。テンプレート「GA cid取得_接客イベント送信(tracker名指定)」をプレイド社から入手し(有償)、接客サービスを作成します。通常のタグ導入の場合は通常版を、GTMやカスタマイズによってトラッカー名が変更されている場合はtracker名指定版を追加します。
これは汎用的な計測用の「接客サービス」です。一つ作ると全ての接客を計測できるようになります。
KARTE接客の表示をもれなく全員分GAで計測するため、「未実施時」は使いません。名前がランダムで設定されている上のアクションに名前をつけて、表示率を100%にしてから、その編集画面に移動します。
続いて、「接客サービスが表示されたら」という条件の配信トリガーを設定します。
保存して公開すれば設定完了。KARTEの接客が表示された時点でGAのイベントを計測できるようになりました。
]]>効果測定はアナリティクス活用方法の1つでしかなく、顧客理解やセグメント発見も重要です。例えばECにおける売上データは事業パフォーマンスの把握に役立ちますが、顧客の理解には不十分です。
そこで、見込み顧客がどの商品をどれくらい真剣に検討しているかを数値化するデモを作ってみました。サンプルECサイトと実データのレポートも大公開!
サンプルサイトのこの商品詳細ページを開いて、以下のいずれかの検討アクションを行うと、それぞれ点数が加算されていきます。
GAサーバーへデータが送信されてスコアが加算されると、マリオのコインGET音が鳴ります
結果はこのGoogle Sheetsに1時間に1回、自動反映されます。
効果測定はアナリティクス活用方法の1つでしかなく、顧客理解やセグメント発見も重要です。例えば、資料請求のリード一覧にGAの閲覧履歴を合わせると、見込み顧客の関心エリアや本気度がわかるので、営業アプローチする際の参考になります。有料ツール(MA)を使わずに無料GAで実装してみました。
以下のフォームに記入して送信すると、その内容とGAの閲覧履歴データがClient ID単位で結合されてGoogle Sheetsに自動反映されます。
GDPR準拠の要件を満たすため、Adobe Analyticsにも保持期間の設定とそれを超えたデータの自動削除機能が実装されました。Googleアナリティクスの場合は一部の集計データのみ残るという仕様ですが、Adobe Analyticsの場合はざくっと月単位で全部消えます。一方、個人から受け付けるGDPR要求の対応に関しては、返すべきデータと消すべきデータを細かく設定できます。
Adobe Analyticsのデータ保持期間は、Adobeとの契約書で25ヶ月などと定められています。2018年5月23日よりも前に契約した場合、1年間のオマケがついるはずです。
まず、保持期間がどう設定されているかの現状を確認してみましょう。Analyticsにログインし、「管理者」メニューの中にある「データガバナンス」をクリックします。
削除は月単位で行われます。毎月一度、期限を過ぎた月のデータが消えていきます。
例えば2018年6月2日現在、以下のように2015年3月31日までのデータが削除されてレポートに表示されなくなっていることを確認できました。
個人(データ主体)からのデータのアクセスや削除要求への対応については、細かい設定が可能です。「可能」というより、設定は必須です。全てのデータ(ディメンションと指標)に、方針を表すラベルを設定しておく必要があります。
データガバナンスの画面でレポートスイートをクリックすると、その設定を確認・変更できます。
標準的なディメンションと指標のみ、便宜的にデフォルトでいくつかの設定がされた状態になっていますが、Adobeが法的な責任を持つ訳ではないので、導入企業が判断して追加や変更する必要があります。特にカスタムディメンション(eVar, Prop)や指標(event)は、全て無設定の状態になっているはずです。
すべてのディメンションと指標を、これらの3カテゴリごとに分類します。GDPR対応に直接的に必要なのは3つ目の「データガバナンス」ですが、その設定のために「IDデータ」と「機密データ」も設定しておく必要があります。
まず、個人を特定できるデータにI1またはI2ラベルをつけます。
アナリティクスの場合、I1のデータを収集することは基本的に無く、オンライン識別子はデフォルトでI2が設定されているので、実際には会員IDなどをeVarに入れている場合のみ追加でI2を付与することになると思います。
次に、アクセスや削除の要求をした本人(データ主体)を特定するためのID(キー)を選定します。本人確認をしないと、他人のセンシティブなデータを送付してしまい、データ漏えいにつながるリスクがあるためです。本人確認をどの程度どのようにして行うかの運用フローは、慎重な検討が必要です。例えば、IPアドレスは個人を間接的に特定できるI2に該当しますが、同じIPが別のデバイスで流用・共有されることがあるので、単体では本人確認できません。
Cookieに保存されるオンライン識別子も同様で、ブラウザまでしか特定できません。同じデバイスの同じブラウザを別の人が使うこともあるからです。
ログイン後に取得する会員IDなら個人レベルまで特定できますが、ログインしないサイトでは使えません。
このように、個人レベルで本人を認証できたのか、それともブラウザやデバイスまでしか特定できていないのか、によって、返信や削除するデータの種類を変える必要があります。以下のラベルによって、このレベルを区別した上で本人特定に使えるディメンションを指定します。
I1やI2のラベルをつけたディメンションの中から慎重に選んだ1〜2個のディメンションのみに、データガバナンスの以下のラベルを付与することになります。
GDPRでは、自分の個人データにアクセスする(送付してもらう)権利が保障されています。このデータのアクセス要求を個人から受け付けた場合に、どのデータを抽出して返送するのかを決めて、それぞれにデータガバナンスのACCラベルを付与します。
この設定もまた、他人のセンシティブなデータを送付してしまわないよう、慎重な検討が必要です。そのため、デフォルト設定では、最低限の標準ディメンションにのみACC-ALLが設定されています。それだけでは足りないので、残りの標準・カスタムディメンションにもACC-ALLまたはACC-PERSONを設定する必要があります。
オンライン識別子だけでアクセス要求を受け付けた場合にどこまでデータを開示すべきかは判断が必要です。Adobeの公式ヘルプでは以下のように説明されているのみで、どのデータにACC-ALLを付与すべきかの方針については書かれていません。
アクセスラベルが多くの変数に適用されることが期待されます。ただし、自社の法務チームと相談し、収集したデータのうちどれをデータ主体と共有するかを決めるのは、お客様次第です。
日本語がわかりにくいですが、「ほぼ全てのデータにACC-ALLまたはACC-PERSONのどちらかを付与するのが良いと思うけど自己判断でよろしく」という意味だと私は解釈しています。社内で議論し、例えば「全てのデータを隠さず返送するのが基本、ただし重複や類似データは省略、地域や検索キーワードや閲覧商品などセンシティブなデータは確実に本人認証できた場合のみ返送する」というようなポリシーを決める必要があります。どこまでをセンシティブとみなすのかがポイントですね。サイトによっては、閲覧したページもセンシティブな情報になり得ます。リファラや広告用パラメータなども、普段のオンライン行動癖が漏洩するので、微妙なところです。
データの削除(匿名化)はデータと個人(ブラウザ)を紐付けできなくするのが目的なので、削除対象はディメンションのみ、その数はACCよりも圧倒的に少なくなるはずです。該当ディメンションの値はランダムな値で置き換えられ、同じヒットで送信されるその他のデータはそのまま残ります。元の値とランダム値は1:1の関係になるので、ユニーク性や連続性は維持されます。
どのデータを匿名化すればヒットと個人やブラウザが紐付かなくなるのかを調査・検討し、データガバナンスのDELラベルを付与します。
参照:ラベルを付与してアクセスや削除を実行するとどんなデータがどう変わるのかの具体例 - Adobe公式ヘルプ
以上、Adobe AnalyticsのGDPR対策としての新機能について紹介しました。取得・保管する全てのデータを吟味し、2段階でプライバシー性(センシティブ性)を定義した上で、アクセスや削除要求に1ヶ月以内に対応できる運用プロセスを構築する必要があります。準備や社内調整に時間がかかるので、実際のリクエストが来る前に決めておくと良いでしょう。
なお、Googleアナリティクスの場合は、期限を過ぎたデータは個人やブラウザとの紐付けができなくなるようなデータの匿名化を行い、削除依頼があった場合はそのデータを完全削除するようです。期限を過ぎたら全部消し、削除依頼があったデータは個人やブラウザとの紐付けができなくなるようなデータの匿名化を行う、という逆のアプローチですね。GDPR施工の直前になって、それぞれが前例のない中で仕様を決めたためでしょう。GDPRの解釈はまだ曖昧なので、追加情報や前例が増えるにつれて仕様も変わっていくと思われます。
]]>GDPRの対策としてWebアナリストがすべきことの記事の中で、個人データの取得には同意が必要、と書きました。その具体的な方法と注意点について紹介します。
以下は技術情報です。対応の必要性については法務担当や専門家に相談してください。
プライバシー保護のために個人データの取得に関して本人(データ主体)から明示的な同意を得るためには、以下の対応が必要です。
このように書き出してみると、色々な仕組みが必要なことがわかります。
「簡単だからJavaScriptで自作できそう」と思いがちですが、既存のツールを活用した方が楽なだけでなく、ツールの機能や説明ドキュメント、アップデート内容から一般的なEU企業が抱えるニーズや解決アプローチが垣間見えて参考になるというメリットもあります。
同意の明確性によって以下のようなパターンがあります。どの方式にするかを指定できるツールもあります。
下に行くほど厳格な運用になります。訪問者のIPアドレスからEU(EEA)からのアクセスを判定し、対応レベルを切り替えられるツールもあります。
Cookie管理ツールから包括的なプライバシー管理ソリューションまで色々あります。iapp.orgのPrivacy Tech Vendor Reportでは、Consent Manager(同意管理)のカテゴリだけで36ものツールが紹介されています。
今回は、無料で使えるものを5つ紹介します。
初回訪問時の通知表示と同意取得に特化したオープンソースの無料ツール。見た目や文言を細かくカスタマイズできます。デモのページで各種カスタマイズ結果を確認できます。Cookieの削除やオプトアウト機能はありません。
通知表示と同意取得に加えて、サイトをスキャンしてCookie表を自動生成したり、EUからのアクセス時のみ機能をONにする機能もあります。デンマークのCybot社によるサービスを日本企業のクラスメソッド社が日本語化を行い、日本円による請求書対応を行なっています。
無料版は、100ページ以内のみに対応(超えたら有料プランへ自動移行)。多言語対応やカスタマイズができず、基本機能のみ。本番利用は現実的ではないので、事実上お試しプランという位置づけですね。
機能的にはCookiebotに似ていて、通知表示と同意取得に加えて、サイトをスキャンしてCookie表を自動生成したり、EUからのアクセス時のみ機能をONにする機能もあります。本サイトはこれを採用しました。
無料版でも多言語対応やカスタマイズ、サイトをスキャンしたCookie表の自動生成、入力フォーム自動検出が可能。ただしオンライン登録したすぐ使えるようにはならず、何日か経って審査を通った場合に登録の通知メールと営業担当からの個別フォローメール(英語)が届きます。
まずサイト全体を自動スキャンし、Cookieや入力フォーム、LocalStorageを検知することから始めます。
検知したCookieは、設定内容だけでなく、データベースと照合して何のCookieなのか説明文も表示してくれます。
この情報をもとにサイト上のCookie Notice(利用するCookieの説明表)ページを自動生成できます。
同意の通知は、表示場所や色、項目をカスタマイズできます。
Cookieのオプトイン・オプトアウト用UIもあります。
通知表示のみに特化した無料JavaScriptライブラリ。詳細リンクを含む通知を表示するだけで、同意の管理機能はありません。デザインや文言をカスタマイズできます。
同意取得というよりも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キーが発行され、実装用タグが表示されます。
発行されるタグは、HTMLソースにベタ張りするためのものです。
私はGoogle Tag Managerで管理するために、以下のように修正しました。
文言も全て日本語に変更しています。設定の詳細は公式ドキュメントをどうぞ。
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では、個人データを取得し保存しているだけで、ツールベンダーや代理店ではなく事業会社のデータ管理責任が問われるので要注意。
日本向けの日本語のみサイトでここまで対応すべきか、は法務と相談してください。
GA公式ヘルプを見ながら設定しましょう。
GAのタグをHTMLソースにベタ張りしている場合は、pageviewを送信するよりも前(上)に以下のようなコードを追加します。
gtag.jsの場合
1 | gtag('config', 'UA-********-*', { 'anonymize_ip': true }); |
ga.jsの場合
1 | ga('set', 'anonymizeIp', true); |
analytics.jsの場合
1 | _gaq.push(['_gat._anonymizeIp']); |
実装方法によっては他の書き方もあります
Google Tag ManagerでGAを実装している場合は、GAタグの詳細設定で「anonymizeIp」というフィールドを追加します。
プライバシー保護を強化するため、ついでにforceSSLも設定しておくと良いでしょう。
GAのビーコンに &aip= が付与されていれば成功です。
サーバー側でデータが処理・保存されるよりも前の段階で、IPアドレスの一部が「0」で置き換えられるようになります。
自分や社内からのアクセスを除外するためにIPを使ってフィルタしている場合は、最後の桁(オクテット)が0で置き換わるので、IPの指定方法を「前方が一致」方式に変えるなどの対応が必要です。
0〜255の範囲でざっくりとフィルタされるのが困る場合は、GAのフィルターではなくタグマネージャーやブラウザプラグインなどの別の除外方法を検討しましょう。
IPアドレスで判定している地域(都道府県・市区町村)のレポートは、元データの粒度が荒くなるので、精度が下がります。
GAのIPアドレスを他のシステムと連携させていないか確かめるなど、影響範囲を把握してから設定を変更すると良いでしょう。
管理画面(レポートスイートマネージャー)の「一般的なアカウント設定」だけで対応可能です。
GAと同じ方式です。IP除外よりも先に置き換えられるので、GAと同様にフィルタ設定を見直す必要があります。
IPアドレスをハッシュ化された文字列で置き換えます。IP除外や地域特定の処理が行われた後に不明化されるので、IP除外の設定変更は不要です。
IPアドレスを一律の固定文字列(x.x.x.x)で置き換えます。EMEA向けのレポートスイートでは、これがデフォルトで有効になります。IP除外や地域特定の処理が行われた後に削除されるので、IP除外の設定変更は不要です。
]]>