読者です 読者をやめる 読者になる 読者になる

まちいろエンジニアブログ

南池袋のWebサービス開発会社、株式会社まちいろのエンジニアブログです。

AWS Lambda で EC2 インスタンスを自動起動・停止してみる (セットアップ編)

AWS Lambda Node.js

こんにちは、まちいろの工藤です。

先日の AWS Summit レポートでも

今回の AWS Summit では「サーバーレス」という単語がよく聞こえてきました。

Lambda をうまく利用することで、開発・運用コストの最小化でき、 かつアプリケーションからビジネスロジック以外のコードを切り出すことができる、というのはかなりキャッチーですね。

事例で紹介されていた、EC2 インスタンスを日中だけ起動しておくよう Lambda で制御する、というのは面白いなと思いました。

と触れましたが、今回は事例として紹介されていた「EC2 インスタンス自動起動・停止」に挑戦してみたいと思います。

まずはコンソール画面から触ってみる

Lambda がどんなものか、まずはコンソールから Lambda Function を登録してみたいと思います。
ヘッダメニューのサービスから、[コンピューティング]-[Lambda] にアクセスします。

f:id:mkudo-machiiro:20160615113649p:plain:w400

Lambda Function を追加する

「Step 1: Select blueprint」は【Skip】ボタンを押してスキップします。
次に、「Step 2: Configure function」にて以下の設定を行います。

項目 設定
Name lambda-test
Runtime Node.js 4.3
Code entry type Edit code inline
Handler index.handler
Role Create new role - * Basic execution role

ソースコードには、サンプルとして以下のコードを貼り付けます。
他にも ZIP ファイルをアップロードしたり、S3 に配置した ZIP ファイルを読ませる方法があるようです。

exports.handler = (event, context) => {
  console.log('lambda test');
};

Role のプルダウンを変更すると、IAM ロールの登録画面が別ウィンドウで表示され、Lambda を実行するために必要なポリシーが予め設定された状態となります。
このロールは後ほど使用したいので、名称に EC2_OPERATING_SCHEDULE_MANAGER と付けて保存しておきます。
登録が完了すると、Lambda Function の設定画面側で追加した IAM ロールが選択された状態となります。

以上の設定で Lambda Function を追加します。

動作確認

Lamda Function の詳細画面の【Test】ボタンからテストを実行します。
ここで Function に渡すパラメータを定義可能ですが、今回はサンプル Hello World そのままで実行します。

f:id:mkudo-machiiro:20160615120755p:plain:w400

実行すると、画面下部に実行結果が表示されます。
先ほど貼り付けたコードに記述した console.log の実行結果がログに出力されていれば成功です。

f:id:mkudo-machiiro:20160615121028p:plain:w400

ローカル開発環境の構築

コンソールを触ってみた印象としては、コードの修正・デプロイの流れが面倒そうに感じました。
そこで、ローカルのソースコードを ZIP 化 -> デプロイまでの流れを作ってみたいと思います。

今回はこの要件にぴったりな npm モジュール node-aws-lambda を使用したいと思います。

github.com

gulp セットアップ

まずは node-aws-lambda を使ったデプロイに必要な各種モジュールをインストールします。

$ npm install gulp gulp-install gulp-zip del node-aws-lambda require-dir run-sequence --save-dev

次に gulpfile.js を作成します。
require-dir モジュールを使って、タスクファイルの分割を行っています。

var dir = require('require-dir');
dir('./gulp/tasks', {recurse: true});

node-aws-lambda の README を参考に、デプロイ用のタスクファイル gulp/tasks/deploy.js を作成します。

const gulp = require('gulp');
const zip = require('gulp-zip');
const del = require('del');
const install = require('gulp-install');
const runSequence = require('run-sequence');
const awsLambda = require("node-aws-lambda");

gulp.task('clean', function() {
  return del(['./dist', './dist.zip']);
});

gulp.task('js', function() {
  return gulp.src(['index.js'])
    .pipe(gulp.dest('dist/'));
});

gulp.task('node-mods', function() {
  return gulp.src('./package.json')
    .pipe(gulp.dest('dist/'))
    .pipe(install({production: true}));
});

gulp.task('zip', function() {
  return gulp.src(['dist/**/*', '!dist/package.json'])
    .pipe(zip('dist.zip'))
    .pipe(gulp.dest('./'));
});

gulp.task('upload', function(callback) {
  awsLambda.deploy('./dist.zip', require("./lambda-config.js"), callback);
});

gulp.task('deploy', function(callback) {
  return runSequence(
    ['clean'],
    ['js', 'node-mods'],
    ['zip'],
    ['upload'],
    callback
  );
});

node-aws-lambda 用の設定ファイル gulp/tasks/lambda-config.js を作成します。
role には先ほど作成した IAM ロール EC2_OPERATING_SCHEDULE_MANAGER の arn を指定します。
注意点として、指定した profile に Lambda Function の登録・更新権限を付与しておく必要があります。

module.exports = {
  profile: 'machiiro',
  region: 'ap-northeast-1',
  handler: 'index.handler',
  role: 'arn:aws:iam::xxxxxxxx:role/EC2_OPERATING_SCHEDULE_MANAGER',
  functionName: 'lambda-test',
  timeout: 5,
  memorySize: 128,
  publish: false,
  runtime: 'nodejs4.3'
}

最後に、package.jsonscript に gulp 実行用の設定を追加しておきます。

  "scripts": {
    "gulp": "gulp"
  },

デプロイ

コンソール画面で貼り付けたソースコードindex.js として作成します。
正常にデプロイされたことがわかるよう、ログに出力するメッセージをちょっといじっておきます。

exports.handler = (event, context) => {
  console.log('lambda test2');
};

最終的なファイル構成は以下のようになります。

gulp/
    tasks/
        deploy.js
        lambda-config.js
node_modules/
gulpfile.js
index.js
package.json

デプロイを実行してみます。

$ npm run gulp deploy
> gulp "deploy"

[12:47:12] Using gulpfile path-to-path/gulpfile.js
[12:47:12] Starting 'deploy'...
[12:47:12] Starting 'clean'...
[12:47:12] Finished 'clean' after 8.02 ms
[12:47:12] Starting 'js'...
[12:47:12] Starting 'node-mods'...
[12:47:12] Finished 'js' after 19 ms
npm WARN package.json lambda-test@1.0.0 No description
npm WARN package.json lambda-test@1.0.0 No README data
[12:47:13] Finished 'node-mods' after 716 ms
[12:47:13] Starting 'zip'...
[12:47:13] Finished 'zip' after 28 ms
[12:47:13] Starting 'upload'...
[12:47:14] Finished 'upload' after 597 ms
[12:47:14] Finished 'deploy' after 1.36 s

Lambda の画面から再度テストを実行してみましょう。
ログに出力されるメッセージが変更したものになっていれば、デプロイは正常に動作しています。

まとめ

今回は Lambda を一から触りつつ、gulp をつかってソースコードをデプロイする流れを構築してみました。
次回は、実際に EC2 インスタンスの起動・停止させる部分を実装していきたいと思います。

Gemfileのバージョンとオプション指定についてまとめてみた

こんにちは、柏谷です。

弊社ではrubyをアプリケーション開発に採用する事が増えてきて、必然的にbundleやgemの知識が必要となってまいりました。

今回は備忘録もかねて、rubyで開発をする際の入り口ともいえるGemfileの記述方法を記事にしました。

Gemfileを作成

普通にファイルを作成してもいいのですが、bundle initすると自動で生成してくれます。

提供元を指定する

Gemfileの最初には提供元を記載します。

source 'https://rubygems.org'
# 認証が必要な場合
source 'https://user@password:rubygems.org'
# プライベートなリポジトリを指定
source 'https://rubygem.machiiro.jp'

その他の提供元(使った事ない)

rubyのバージョンを指定する

続いて、rubyのバージョンを指定します。

ruby '1.9.1'
# パッチレベルを指定する
ruby '1.9.1', :patchlevel => "376"

RubyのバージョンはMAJOR.MINOR.TEENY+PATCHとなっています。 MINORバージョンは1年に1度クリスマスにあがるとのこと。おもしろい文化ですね。

2.1.0以降のバージョンは、Semantic Versioning 2.0.0に乗っ取って更新されています。

必要なGemを指定する

いよいよ、アプリケーションに必要なgemを羅列していきます。

バージョンの指定

# 常に最新のもの
gem 'activerecord'
# バージョン指定
gem "activerecord", "3.0.0",
# バージョン指定・以上以下
gem "activerecord", ">= 3.0.0", "< 3.1.0"
# バージョン指定・メジャーバージョンは変えない
gem "activerecord", "~>= 3.0.0"

必要とするファイルの指定

# 必要とするファイルを指定
gem 'activerecord', '>= 3.1.0', require: 'active_record'
# 必要とするファイルを指定・複数
gem 'activerecord', '>= 3.1.0', require: ['active_record', 'active_record2']

requirefalseに指定すると、アプリケーションでライブラリを使用する際に、明示的にrequire: gem_nameとしなければなりません。

development用に入れているツールには、production用で不要な自動ロードをさせないため指定する事が多いです。

また、gemの名称とrequireするライブラリの名称が異なる際などにもよく利用されます。

http://stackoverflow.com/questions/4800721/bundler-what-does-require-false-in-a-gemfile-mean

環境の指定(group,groups)

個別に指定する場合

# 環境を一つ指定する
gem 'rspec', group: 'test'
# 環境を複数指定する
gem 'rspec', group: [:test, :development]

グループ毎に指定する場合

# デフォルトでアプリケーションに必要
gem activerecord
# 開発に必要
group :development do 
     gem 'rspec'
group :test do 
# テスト環境に必要
group :test do 
     gem 'rspec'
group :test do 
# 本番環境に必要
group :production do 
     gem 'rspec'
group :test do 

bundle installするときに--withoutオプションをつけると、不要なインストールを避ける事が出来ます。

# 全部インストール
bundle install
# 開発用に必要なモノは除いてインストール
bundle install --without development

gemファイルのパスを指定

ローカルに自前のgemなどがある場合に、pathを指定して読み込む事が出来ます。

gem "rails", :path => "vendor/rails"

プラットフォームを指定

gourpとプロジェクトに必要なgemが、rubyのバージョンやwindows環境などプラットフォームによって変わってくる場合は、プラットフォームを指定してインストールするgemを記載する事が出来ます。

bundle installする際の処理系により判断されます。

gem "weakling",   :platforms => :jruby

gitリポジトリを利用する

gemが公な提供元に属していない場合や、提供元で公開されていない最新のバージョンを利用したい場合、gitオプションでgemを指定することで利用する事が可能となります。

githubとbitbucketに関しては、専用のオプションが準備されています。

# git リポジトリを利用する
# HTTP(S)でダウンロードする場合
gem "rails", :git => "https://github.com/rails/rails.git"
# SSHでダウンロードする場合
gem "rails", :git => "git@github.com:rails/rails.git"

# github のリポジトリを利用する
gem "rails", :github => "rails/rails"

# bitbucketのリポジトリを利用する
gem "rails", :bitbucket => "rails/rails"

皆さんもぜひGemfileを使いこなして、快適なrubyライフを送ってください!

Slack のスタンプ機能でコミュニケーションを円滑に

Slack

こんにちは!まちいろの森です。

昨年から導入したslackにてコミュニケーションが円滑に進みつつあるまちいろ社内でありますが、 さらに円滑に進めるいいslackの機能を発見しました。

それがこれ…

f:id:e_mori:20160614113224p:plain

そう!自作スタンプです。

好きな写真や好きな画像、おもしろ画像をスタンプにしてslackで送ることでちょっとした仕事の合間にリフレッシュできたり

社内での話のネタとなり、コミュニケーションさらに円滑に進めることが出来ています。

ちなみに私のお気に入りTOP3は以下です。NO.3は一体何でしょうか…笑

f:id:e_mori:20160614114523p:plain

そんなコミュニケーションを円滑に進めるためのスタンプ作成方法をここではご紹介していきます!

まずは…

スタンプにしたい画像選びです。ここが一番重要です!!!!

自作画像の場合は、線ははっきり作成しましょう。

好きな画像はある程度大きく映っているものを使いましょう。

大きいものだと何のスタンプかがはっきりわかります。

こんな感じで選んで、次は早速スタンプ作成の前準備をして行きましょう。

スタンプ作成の前準備

画像選びが完了すると次は画像をスタンプ登録可能サイズにトリミングを行います。

今回はこの画像を利用します。(鬼ジェンキンス)

f:id:e_mori:20160614175243p:plain

トリミングはどんなツールを利用しても良いですが、今回はペイントを使ってやってみます。

まず画像をペイントで開きます。

f:id:e_mori:20160614175538p:plain

その後、サイズ変更でピクセルを縦、横両方128ピクセル以内に設定し、保存します。

f:id:e_mori:20160614175806p:plain

ここまでで前準備は完了です!それではこの後で実際にスタンプを作成してみましょう。

スタンプ作成

slackの絵文字マークをクリックします

f:id:e_mori:20160614180227p:plain

クリックすると以下が表示されるので、「add custome emoji here」を押下します

f:id:e_mori:20160614180414p:plain

押下後、以下画面が表示されるので、名前と先ほど前準備でサイズ変更した画像を選択し、「save New emoji」ボタン押下します。

f:id:e_mori:20160614180727p:plain

作成が完了すると絵文字に追加され、利用が可能となります。

実際に使ってみた

実際に使ってみるとこうなりました。

f:id:e_mori:20160614180950p:plain

結構まちいろ社内では評判が良いです笑

怒った時に使いましょう笑

最後に…

こんなに簡単にスタンプが作成できます!皆さんもコミュニケーションを図るうえで利用してみてはいかがでしょうか。

社内のCSSの管理にルールを持たせよう SMACSS編

CSS

こんにちは、まちいろの門田です。

入社して早一年、主にフロント側で様々なコードを書いてきた次第ですが
最初は個人で書いていた時の癖でひたすらルール無用で好き勝手ガリガリ書いており、なんとも汚いコードが出来上がっておりました。

「まあ、とりあえずデザイン通りの見た目なら・・・」という気持ちが先行してのことなのですが・・・
結果、後々の機能改善や保守の際にどこを直せば、どれを消せばと一つ一つ調べるハメになり
非効率かつ面倒でしかも自分しか理解できなさそうなコード群となっておりました。その上見た目も気持ち悪いですし。

f:id:s_kadota:20160615165219p:plain

ということもありましたし、元々社内で「コレ」といったcssのルールがあったわけでも無いですので
今後のプロジェクトをより効率よく進めていくためにちゃんとしたルールを取り決めようという方針となりました。
チームでプロジェクトを進めていく上でやはりあらかじめルールを決めておくことは、大切です。とても。


まずは主に一般的に普及しているcss設計の手法を、かいつまんでご紹介します。

OOCSS

オブジェクト指向を取り入れた手法。

  • 構造部分と見た目部分を別で作成しそれぞれのクラスなどで呼び出す。
  • 要素ごとを独立して定義する。

など、一度定義したものを他でも使いまわしたりすることを前提にしているものです。
全体の記述量も減りますし、修正時も一括で行えたりと便利です。

SMACSS

サイトを作成するにあたって存在する様々な要素をカテゴリで分けて管理するものです。
基盤となるcssはココ、ページごとのデザインはココ、汎用的なボタンやアイコンはココ・・・など
しっかりとディレクトリ毎に管理し、どこに何が書かれているかをメンバー間で共有できます。
基本的に五つのカテゴリ、

名称 内容
Base サイトの基本スタイル。リセットやフォントサイズ、行間など。
Layout ヘッダーやフッターなどの各所のレイアウトを管理。
Module ボタンやフォームなどサイト内で多数使用されると思われるパーツの管理。
State 要素の状態を管理する。JavaScriotでの切り替えなどに使用する。
Theme サイト全体のテーマの管理。背景色や文字色など。

で分けて考えられますがこれらの分類も社内で独自に定義するのが良いと思います。

BEM

BEMもSMACSS同様カテゴリに分けられます。

名称 内容
Block Webページを構成する大元の要素。ヘッダーやセクションなど。
Element Block内の要素。ヘッダー内のナビゲーションなど。
Modifier Block、Elementの見た目を変える要素。

そしてさらに、厳格な命名規則で管理される手法です。
クラス名を付与する際には「Block__Element--Modifier」など、どこのBlockのどこのElementに対して
使用しているcssなのかがクラス名の時点ではっきりと分かる様に定義するものです。
管理が徹底されていますが、作業スピードが少し他に比べて遅れ気味になるデメリットも含んでおります。

FLOCSS

上記の手法の様々な要素を取り入れた手法です。
レイヤー構成の考え方なども取り入れられておりルールもしっかりと定められ、まとまっております。
ただし元となったOOCSSやSMACSSを知っておくことが望ましいので、css設計に足を踏み入れたばかりの方が
いきなりこの手法を取り入れるのはあまりお勧めしません。
しかし発案者が日本の方ということもあり、ドキュメントなどは日本人向けに揃えられており分かりやすいです。


他にも様々な手法が存在します。興味のある方は是非調べてみてください。

さて、上記の手法の中でもまちいろではどの手法を基に社内CSS設計を組み立てていくか、ですが...
「SMACSS」を参考にしたCSS設計を社内で用いていく方針となっております。

カテゴリに分類し管理していくのはCSSに限らず用いるケースも多いですし、
入り易さもあり、拡張性も大きいとのことで取り入れようと考えました。

SMACSS

それではSMACSSに焦点を当てて基本的にどのような手法が定義されているかを記述していきたいと思います。
カテゴリに分けて管理する...と上ではご説明しましたがそのカテゴリごとの役割や推奨ルールなどをもうすこし
踏み込んでご説明していきます。

Base

Baseカテゴリ、運用する上ではBaseフォルダ等と呼ぶかと思いますがこちらはサイトの基本的な情報をまとめていく場所になります。
例えばまず一番最初にブラウザ間であらかじめ用意されているデフォルトCSSをリセットするreset.cssを適用させるかと思いますが それはこちらの管理下に置くことになります。
プロジェクトのスタート時にまず最初に行うアレコレ、それらがここに置かれるものだと思っていただければ。

他にはサイト全体のフォントや、リンクカラーなどを定義しておくなどでしょうか。

body.css



body{
  font-size:12px;
  font-family:'Meiryo';
  line-height:1.3
  color:#111111;
}

a{
  color:#eeab33;
  text-decoration:none;
}

a:hover{
  opacity:0.5;
  text-decoration:underline;
}

f:id:s_kadota:20160616173456p:plain

Layout

Layoutはその名の通りサイト内の様々なレイアウトを管理する場所です。
ヘッダー、フッター、サイドバー、コンテンツ、ナビゲーション......などなど。
それらをレイアウト別にcssで管理し、どの箇所がどのcssを参照しているかをわかりやすくします。

また、レイアウトに関するクラス名を付与するさには頭に「 l- 」や「 layout- 」などをつけることが推奨されています。
要するにこれはレイアウトのクラスですとすぐに分かるクラス名をつけましょうということですので、ここの名称も
社内で独自に定義して広めていきましょう。

header.css



l-header{
  width:960px;
  height:100px;
  padding:20px 0px;
}

l-header-inner{
  width:100%;
  margin:0 auto;
}
sidebar.css



l-sidebar{
  width:200px;
  float:right;
  padding:10px;
}

f:id:s_kadota:20160616181015p:plain

Module

Moduleはサイト内で使用する様々なパーツ、ボタンや入力フォームなどを管理するカテゴリです。
OOCSSの様に一度作成したものを他所でも使える様にという考え方がこのカテゴリにも表れています。
使いまわせるということは無駄を省き効率が上がるのと同時にサイト内のテイストに統一感を持たせることができます。
都度都度ボタンなどのスタイルを作っていては微妙な差異が生まれてしまうことも少なくありません。
可能な限り、サイト内で多く使用されるものはどこでも使える様に定義いたしましょう。

また、Module内にも構造と見た目を分けた呼び方があり構造側を「Base Module」、
見た目側を「Sub Module」と呼んだりします。

button.css



/*大きいサイズのボタンの構造(base)*/
large-btn{
  width:150px;
  padding:15px 0px;
  text-align:center;
  border:none;
  border-radius:5px;
}

/*小さいサイズのボタンの構造(base)*/
small-btn{
  width:80px;
  padding:10px 0px;
  text-align:center;
  border:none;
  border-radius:3px;
}

/*完了ボタン用の見た目(sub)*/
comp-btn{
  background-color:#333;
  color:#fff;
}

/*キャンセル用の見た目(sub)*/
can-btn{
  background-color:#fff;
  color:#333;
}

大きいサイズのキャンセルボタンを作る場合は、buttonタグのクラスに
「large-btn can-btn」を入れる感じになると思います。

f:id:s_kadota:20160616183128p:plain

State

Stateは状態を管理するカテゴリとなります。displayの表示非表示、成功時の表示、エラー時の表示等など。
何かしらのアクションが行われた際に適用されるケースが多いと思われますので、基本的にはjavaScript
addClassされるものが定義される箇所になるでしょう。 またpositionのfixや、hoverやactive、そしてCSS3ではアニメーションなどcssのみで完結できる状態の管理などもこちらに書かれたりする事もあるでしょう。

さらにこのカテゴリ下のスタイルが呼び出される際、そのスタイルが最優先で適用される事が想定されていますので Stateに関しては他では推奨されていない「!important」を使っても良いとされています。

error.css



errro-text{
  color:#f00;
  font-size:bold;
}

error-box{
  background-color:#ffdc87;
  text-align:center;
}

display.css



disp-hide{
   display:none !important;
}

disp-show{
   display:block !important;
}

f:id:s_kadota:20160616184838p:plain

Theme

Themeはサイト全体の背景色や文字色などをテーマ毎に管理するカテゴリです。
例えば地域毎に同じテイストのサイトを設けた場合、構造は全く同じでも差分化するために
背景色や背景画像、文字色を変えたりする事があると思います。そういった際に読み込むcssの管理場所となります。
また、サイトの訪問者によっては言語を変えたい場合もあるでしょうし、
製作者の遊び心でボタン一つでサイトの雰囲気をガラリと変えたりなどするケースなどもあるのではないでしょうか。

area.css



/*東京用サイトはモノクロをベースにする*/
theme-tokyo{
  background-color:#aaa;
  color:#333;
}


/*神奈川用サイトは青をベースにする*/
theme-kanagawa{
  background-color:#3377EE;
  color:#fff;
}

f:id:s_kadota:20160616185813p:plain

社内独自の設計

上記で述べた事以外でもSMACSSのより細かなルールや設計について詳細に記されたサイトがいくつも出てくるかと思います。
しかし完全にSMACSSを模倣するのではなく、カテゴライズするという考え方や命名規則などを参考に
チームメンバーで最も共有しやすい形を探し社内独自の設計をするのが最も効率的な形になると思います。

プロジェクトの規模によってはカテゴリの数は4つ、あるいは3つにしても良いでしょうし、
各カテゴリ名もより馴染みのある単語に置き換え何が属するかるなど決めていきましょう。

私自身もまだ社内のCSS設計を確立していないため日々勉強しより良いものに形作ることを心がける毎日です。


さて、カテゴリや用途ごとにCSSのファイルを分類して作成してきましたが
これらを単純にhtmlに読み込む場合head内に膨大な量の記述が必要になってしまいます。

<head>
    <link rel="stylesheet" href="css/base/reset.css">
    <link rel="stylesheet" href="css/base/body.css">
    <link rel="stylesheet" href="css/layout/header.css">
    <link rel="stylesheet" href="css/layout/footer.css">
    <link rel="stylesheet" href="css/layout/sidebar.css">
    <link rel="stylesheet" href="css/layout/contents.css">
    ・
    ・
    ・
    ・
    ・
    <link rel="stylesheet" href="css/theme/area.css">
</head>

見栄えも悪い上に管理しづらいですし、CSSが増えるごとに都度都度で追記が必要に......となってしまいます。
単純にCSSのみを使って行う場合はこれも仕方のないことですが、CSSメタ言語の一つである「SASS」を活用すれば
管理もコードの記述もグッと速く、楽になります。

次回のCSS設計の続きは、SASSに関して触れてみようかと思います。

GoogleAnalyticsでクロスドメイン設定をやってみた

Google Analytics

こんにちは! まちいろの日高です。

お客様のサイトで「別サイトを立てたんだけど、Analytics集計はいっしょにしたい」という要望がありました。

例えばECサイトだと決済を別URLにしていたり、問い合わせだけ別システムを使っていたり…

いろいろと使うタイミングはありそうです。

複数のサイトを一緒に集計できるクロスドメイン設定の方法を書いてみます。

まず初めに…

ここでは、AというサイトとBというサイト2つがあると仮定します。

サイトAではすでにGoogle Analyticsタグを埋め込んでいて計測を行っています。

サイトBの集計をサイトAにまとめるとします。

Aはaaa.machiiro.jpというドメインで、Bはbbb.machiiro.jpというドメインで運用しているとしましょう。

サイトAのGoogle Analyticsタグを変更する

サイトAは既にGoogle Analyticsタグを埋め込んでいます。 タグは初期設定だと以下のようになっているかと思います。

ga('create', 'UA-XXXXXXX-1', 'auto');
ga('send', 'pageview');

サイトBとクロスドメイン設定をするために下記のように書き換えます。

ga('create', 'UA-XXXXXXX-1','auto',{'allowLinker':true});
ga('require', 'linker');
ga('linker:autoLink', ['bbb.machiiro.jp']);
ga('send', 'pageview');

ga('linker:autoLink', ['リンクさせたいサイトのドメイン']); を記載するのがポイントです。

サイトBにGoogle Analyticsタグを挿入する

サイトBにもGoogle Analyticsタグを挿入する必要があります。

サイトAに挿入したタグのlinker:autoLink部分にサイトAのドメインを記載します。

ga('create', 'UA-XXXXXXX-1','auto',{'allowLinker':true});
ga('require', 'linker');
ga('linker:autoLink', ['aaa.machiiro.jp']);
ga('send', 'pageview');

Google Analyticsフィルタ設定を変更する

両サイトにタグを埋め込むことで計測自体は可能になります。

ただし、このままでは、aaa.machiiro.jp/index.html も bbb.machiiro.jp/index.html も /index.html としてカウントされてしまいます。

どちらのサイトが計測されてのか?が分からなくなります。

これを解消するため、GoogleAnalyticsの設定を変更します。

Google Analyticsを開いて、「アナリティクス設定」から「ビュー」→「フィルタ」を選択し、新規フィルタ追加を行います。

f:id:shidaka:20160531100247p:plain

フィルタの種類は「カスタム」を選んで、さらに「詳細」を選択します。 以後、以下の通りに設定を行います。

フィールド A -> 引用 Aホスト名(.*)
フィールド B -> 引用 BリクエストURI(.*)
出力先 -> 構成リクエストURI$A1$B1

この設定を行うことで、ドメイン/ページで以降のカウントが可能になります。

Google Analytics参照元除外リストを変更する

例えば Yahoo → サイトA → サイトB と着地した時、参照元はYahooとサイトAがカウントされます。

サイトAはカウントされないよう参照元除外リストに追加します。

Google Analyticsを開いて、「アナリティクス設定」から「プロパティ」→「トラッキング情報」→「参照元除外リスト」を選択して、参照の除外を追加します。

サイトAのドメイン、サイトBのドメイン両方を追加します。

まとめ