クラウド型のログストレージサービス「Xdata collect」をサービス開始

こんにちは。MOBYLOG事務局です。

 

相当久しぶりの投稿となりますが、本日は新サービスのPRとなります。

 

2013年5月7日、株式会社セラン(東京都千代田区、代表取締役 佐々木 孝司、以下『セラン』)は、ビッグデータ分析のためのクラウド型ログストレージサービス『Xdata collect(クロスデータ・コレクト)』の提供を開始しましたので発表致します。

 

簡単に説明すると、アクセス解析のタグで通知したログを生ログの状態で保存するサービスです。

サービスの詳細はXdata collectのサイトを見て頂くとして、ここではMOBYLOGをご契約のお客様へお知らせさせて頂きます。

 

 

Xdata collectは、既に導入頂いているMOBYLOG ENGINEHandloaD TAGでビーコン送信された多種多様で高精度なログを、自動的に整理整頓した状態で保存します。
保存したログは、必要な時に管理画面やAPIから期間を絞って抽出することができるため、アクセス解析以外の分析ツール(例えばBIツールやCRMツール、自社データベース)を利用する際に、各種ツールへのデータ提供をシンプルにすることができます。

 

 

無料・有料 2つのプラン

プランは無料と有料の2つを用意しており、月間のログ保存件数が50万件以内であれば、無償でご利用頂くことができます。

 

 

MOBYLOGからcollcetアカウントの発行について

collectは、MOBYLOGとは全く別のサービスとなりますが、MOBYLOGをご契約中のお客様の場合、MOBYLOGのアカウントからcollectアカウントを発行すると、MOBYLOGで受け付けたログをcollectに保存することができる、特別なプログラムを用意しました

これにより、これまでMOBYLOGでは機能として提供していなかった、生ログの取得が可能となります。

是非collectにアカウントを作成し、新しいサービスの機能をご活用ください。

 

 

[ MOBYLOGご契約中のお客様への特典 ]

MOBYLOGをご契約中のお客様は、MOBYLOGを契約する限り有料プラン(100GBの標準ストレージ付き)を無償でご利用頂けます。

 

 

[ collectアカウント発行の手続き ]

MOBYLOGをご利用中のお客様がcollectにアカウントを作成する場合はアカウント発行申請書を当社に送付して頂く必要があります。

詳しくはアカウント発行についてをご覧ください。

collectにアカウントを発行すると、MOBYLOGと同一のサイトID、メールアドレス、パスワードでログインができるようになります。

 

注意事項

  • MOBYLOGの利用料は発生します。
  • ストレージをアップグレードした場合は、@5,250円(税込)/100GB/月が発生致します。
  • 100GBの標準ストレージで、月間1,000万PVのサイトのログを約4年間保存することができます。
  • collectにアカウントを発行した後、MOBYLOGもしくはcollectの管理画面でメールアドレスやパスワードの変更をしても互いに同期されません。

 

 

契約に関しまして

 

1.利用規約

collectにアカウントを発行する場合は、collectの利用規約に同意して頂く必要がございます。

 

2.ご利用料金

 

月額費用に関して

MOBYLOGをご契約のお客様は、MOBYLOGの契約が続く限り、ログ件数に応じたcollectの課金は発生しませんが、MOBYLOGのご利用料金は、MOBYLOGの契約の通り発生致します。

 

 

オプション費用に関して

collectにアカウントを発行後、オプション(例えばログストレージのアップグレードなど)を行った場合、オプション料金はご請求させて頂きます。

[契約プランとご利用料金]
 
MOBYLOGを解約した場合に関して

collectにアカウントを発行した後にMOBYLOGを解約した場合、collectの契約は継続され、MOBYLOGの解約後からcollectの正規料金が発生します。
collectの解約は解約申請が必要です。

[有料プランアカウントの解約]

 

※collectは最短で半年契約ですが、MOBYLOGからcollectにアカウント発行を行った場合は最短契約期間は免除されます。

 

 

 


(第3回)直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

こんにちは。MOBYLOG事務局です。

 

前回までは

 

  • 第1回)直帰率の高いページにイベント関数を仕込むことにより、直帰した場合は計測できない「滞在時間」を計測する方法。
  • 第2回)ページ内で完結して画面遷移しない他イベントを計測する方法。

 

を説明し、イベント機能を利用し、直帰率などページ遷移に紐付く計測情報だけでは把握できない訪問者の行動をトラッキングすることで、これまで見えなかった情報を明確にして次の施策に繋げるヒントを得ることができることをお伝えしました。

 

今回(第3回)では、外部サイトへ遷移するリンクの計測について説明します。

 

 

 

外部サイトへのリンク計測方法

 

外部サイトへのリンクを設けているサイトは多いと思いますが、そのリンクのクリック数を計測するには一工夫が必要です。

 

通常、外部サイトへのリンクを計測する場合は直接外部サイトに遷移させずに、計測中のサイトに1ページリダイレクトページを設けて、そのページを計測することにより外部サイトへのリンクがクリックされたと見なす手法が一般的です。

 

 

上図のリダイレクトページは、Locationヘッダーを使ってHTTPステータス 302 でリダイレクトする方法と、metaタグのRefreshでリダイレクトする方法の2つがあります。

 

携帯サイトの場合だとmetaタグのRefreshが使えない端末があるため、Locationヘッダでリダイレクトさせて、そのページを計測するしか方法がありません。

 

PCサイトやスマホサイトの場合は、metaタグのRefreshを利用することができますが、リフレッシュ時間を0秒とか1秒に設定しておくと、JavaScriptのタグがビーコン通知を実行する前にリダイレクトしてしまい計測ができない可能性があり、それ以上の秒数に設定しておくと空ページが長い間隔で表示される(感覚に陥る)ので、ユーザビリティを損ねる可能性があります。

よって、MOBYLOGではmetaタグのRefreshは利用せずに、リダイレクトページを設けて、そのページを計測するようにお勧めしています。

 

Locationヘッダでリダイレクトする場合、JavaScriptのタグや計測用のimgタグが利用できません。

そのためMOBYLOGでは、MOBYLOG ENGINE(自動タグ型)、HandloaD TAG(手動タグ型)の双方の計測タグで、リダイレクトページではSocket通信を実行してMOBYLOGログ受付サーバに直接ログを書き込みする機能を備えています。

 

 

特にMOBYLOG ENGINEでは、設定ファイルにリダイレクトページを計測する設定を追加しておくだけで自動的に計測を実行するため、複数のページに外部サイトへのリンクがある場合も手間無く簡単に外部サイトのリンククリック数が計測できます。

 

 

PC・スマホサイトでは別の方法で計測できる

 

携帯サイトでは前述の通りリダイレクトページを設けて、そのポイントを計測するという方法しか選択肢がありませんが、PCサイトやスマホサイトの場合、JavaScriptを使って別の方法で計測することができます。

 

 

1.イベント関数を使う

 

第1回、第2回でも説明したイベント関数を使って、外部リンククリックをイベントとして計測する方法が1つです。

 

<a href=”http://外部サイトのURL/” onClick=”__push_event(‘外部サイトへのリンク’, ‘外部リンク’);” target=”_blank”>外部サイトへのリンク</a>

※JavaScript版HandloaD TAGを使った例

 

上記の例では、イベント関数を使って「外部サイトへのリンク」というイベント名、「外部リンク」というカテゴリ名でログ通知しています。

 

ここでの注目点は「target=”_blank”」としているところです。

外部サイトを同一のWindowで開くと、onCkickよりもhref属性が先に有効になってしまい、イベント関数が実行される前に外部サイトに遷移してイベント通知がされないケースがあります。

これを回避するために「target=”_blank”」として、別Windowを開くようにしています。

 

しかし、この方法だと、例えば外部リンクが沢山あるような紹介サイトの場合、外部サイトに遷移すると都度別Windowが開き、ブラウザの戻るボタンで戻れず、いちいちWindowを閉じなければならないため、ユーザビリティを著しく損なう可能性があります。

 

こういうケースに備えて、イベント関数は第3引数に遷移先URLを指定することができるようになっています。

 

<a href=”#” onClick=”__push_event(‘外部サイトへのリンク’, ‘外部リンク’,’http://外部サイトのURL‘);”>外部サイトへのリンク</a>

※JavaScript版HandloaD TAGを使った例

※MOBYLOG ENGINEでは「__becon.event()」関数

 

上記のように、第3引数に遷移先URLを指定すると、イベント関数はイベント通知を実行した後に指定のURLに遷移する処理を行うため、別Windowで開く必要がなくなります。

 

 

 

2.PV関数を利用する 

 

イベント関数を利用して通知したログは、ページとして計測されることはなく、あくまでもイベントとして計測されます。

MOBYLOGの仕様上、コンバージョン計測はページ単位での計測となっています。

このため、例えば外部サイトへの送り出しが成果となっているサイトの場合はイベント関数を使ったログ通知ではコンバージョン計測ができなくなってしまいます。

 

外部サイトへの送り出しをコンバージョンとするサイトに対応するために、MOBYLOGではPV関数を用意しています。

 

__push_beacon(‘第一引数’, ‘第二引数’);   JavaScript版HandloaD TAG__beacon.pv(‘第一引数’, ‘第二引数’);            MOBYLOG ENGINE

 

第一引数にはページとして計測するURL、第二引数には遷移先URLを指定することができます。

 

<a href=”#” onClick=”__push_beacon(‘外部サイト’, ‘http://外部サイトのURL/’)”>外部サイトへのリンク</a>

※JavaScript版HandloaD TAGを使った例

 

上記の場合、第一引数に設定した「外部サイト」という文字列がページとしてログ通知され、その後に第二引数に指定したURLに遷移します。

 

 

 

ログ通知関数を利用した場合の直帰率との相関関係

 

上記の説明で、イベント関数とPV関数の2つの通知方法により、外部サイトへのリンククリックを計測することができる、ということをご理解頂けたかと思います。

 

では、この2つの関数で通知したログは、直帰率(もしくは離脱率)にどのように影響するのでしょうか?

 

直帰というのは、そのページを見て自社サイト内の別ページに遷移することなくどこかのサイトに行ったり、ブラウザを閉じたり、もしくはセッションが切れるまでそのまま放置することを言います。

 

 

イベント関数は直帰(離脱)率には影響しない。

 

例えば直帰率100%のページAがあるとします。

下図のように、外部サイトへのリンクをイベント関数で計測していた場合、外部サイトに遷移したというイベントログは通知されますが、ページアクセスのログは通知されません。

よって、MOBYLOGの計測上ではページ遷移していないと見なされるので、直帰率は100%のままとなります。

 

 

このようにイベント関数を使った計測の場合、外部サイトへのリンククリックの計測は行えますが直帰(離脱)率には影響しません。

 

 

PV関数は直帰(離脱)率に影響する。

 

外部サイトへのリンクをPV関数で計測していた場合、外部サイトに遷移したというページログが通知されます。

よって、MOBYLOGの計測上では、ページAの後に「外部サイト」ページへ遷移したと見なされるので、ページAの直帰(離脱)率は下がります。

 

 

 

 

サイトの特性により使い分けが重要

 

イベント関数もPV関数も、外部サイトへのリンククリックを計測することはできますが、どちらを使うかはサイトの特性によりますので、KPIにより使い分けをしましょう。

 

例えば、外部サイトへの送り出しが成果ポイントとなる場合は、PV関数を使うべきです。

何故なら、ページログとして計測しないとコンバージョン計測ができない=流入元別の成果も計測できないためです。

 

逆に、自社の別サイトを紹介する程度の外部リンクであれば、イベント関数で計測しても良いでしょう。

 

因みに、イベント関数により通知されたログ件数は、いくら件数があっても課金対象とならないため、使い方を工夫するとより低価格で計測が可能となります。

 

 

関連記事

(第1回)直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

(第2回) 直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。


iPhone 5 には2種類のモデルがある

こんにちは。MOBYLOG事務局です。

 

セランが提供するiPhoneアプリ「ヘア・コンシェルジュ」のアクセス解析レポートを見ると、iPhone 5 発売以降に利用者が少しづつ増えてきています。

※発売後、約1週間でまだ全体の1.21%しかいませんが。

 

MOBYLOG SDKで計測した場合、MOBYLOG SDK独自のUser-Agentを残すようにしています。

 

MOBYLOG SDKで通知するUser-Agent情報

“[アプリ名]/[アプリバージョン] ([端末]; U; CPU iPhone OS [OSバージョン] like Mac OS X; ja-jp) [端末名称]/MOBYLOG SDK for iOS/[MOBYLOG SDKバージョン]“

 

User-Agentにある「端末名称」は、その名の通り端末名が入るのですが、これはiPhone 4とかiPhone 4Sという端末名ではなく、モデル番号(?)が入ります。

例えば、iPhone 3GS であれば「iPhone2,1」、iPhone 4 であれば「iPhone3,1」、iPhone 4S であれば「iPhone4,1」となります。

 

ログに残っているiPhone 5 のUser-Agentを見ると、「iPhone5,2」となっていました。

通常「iPhonex,1」となっているのにiPhone 5だけは「iPhone5,1」ではないんですね。

 

気になって調べてみたところ、こちらの記事を見つけました。

 

AppleからDownloadできるiPhone 5 iOS 6.0のIPSWファイルですが、2種類あります。

この違いは何かというと、N41AP/iPhone 5,1とN42AP/iPhone 5,2というモデルになります。

モデルA1428(GSMモデル)が前者でAT&TやRogersなどのモデルになります。

後者は、モデルA1429(CDMA,GSMモデル)で日本のauやSoftBankがこれに当たります。

 

「iPhone5.2」はSoftBankとauから発売されているモデルのようです。

 

 


(第2回)直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

こんにちは。MOBYLOGでは事務局です。

 

 

前回の投稿では、直帰率の高いページにイベント関数を仕込むことにより、直帰した場合は計測できない「滞在時間」を計測する方法をご紹介しました。

 

今回は、そのページ内で外部リンクなど、ページ内で完結して画面遷移しない他イベントを計測した結果をお伝えします。

 

実験対象としたサイトは第1回と同じく、セランで実験運用しているiPhoneアプリの紹介用スマホサイトです。

このサイトは、AppStoreで用意されているAPIから評価やレーティングなどのアプリ情報をリアルタイムに取得してアプリ紹介をするという単純な作りのサイトです。

機能としては、アプリ紹介の他に訪問者が気になったアプリをクリップして後からクリップリストを参照し、そこからAppStoreの該当アプリへ遷移できるという機能がついています。

 

このクリッピング機能は、JavaScriptでWeb Stroageに書き込みするので画面遷移が無く通常の計測タグだけではどの程度クリッピングされているか分かりません。

 

そこで、第1回にも紹介したイベント関数を用います。

今回対象としたのは、9月17日あたりからアクセスが急上昇している「MP3ミュージックダウンローダー無料版」というアプリ紹介ページです。

 

 

 

ページ遷移をしないイベントを計測

 

このアプリ紹介ページの上部にある「◎このアプリをクリッピングする◎」というボタン、ここにイベント関数を仕込んでいます(下記、赤文字部分)。

 

 <a href=”javascript:clip(’470101678′,’MP3ミュージックダウンローダー無料版’,'http://a3.mzstatic.com/us/r1000/062/Purple/v4/bd/dd/e7/bddde7ad-5f4f-be14-8fe5-32ba5c40005c/Icon.png’,’0′)”  onClick=”__push_event(‘MP3ミュージックダウンローダー無料版’, ‘無料_AddClip’, ”);” >◎ このアプリをクリッピングする ◎</a>

 

イベント名を「MP3ミュージックダウンローダー無料版」、イベントカテゴリ名を「無料_AddClip」として通知しています。

尚、全てのアプリ紹介ページのクリップイベントで、イベントカテゴリ名を「無料_AddClip」で通知しているので、どのアプリのクリップ機能が多く使われるかイベントメニューで確認することができます。

 

イベントメニューから「イベントカテゴリ→無料_AddClip」で絞り込み検索

 

 

イベント関数を利用すると、ページ遷移しないページ内でのイベントを計測することができます。

スマホ端末は表現力が豊になっており、タップするとメニューを表示したり、検索リストをさらに追加表示したりと、コンテンツ内容を変更することができます。

このようにページ遷移の無いイベントがある場合に、イベント関数が役立ちます。

 

 

次回は、外部サイトへのリンクをイベント関数を用いて計測する方法です。

 

 

 

 

余談

残念ながら今回検証しているアプリではクリップされておらず、しかもNo.1のアプリ以外、ほとんど使われていないことが分かりました。

「MP3ミュージックダウンローダー無料版」アプリの紹介ページへのアクセス数は上図No.1のアプリと同じ程度なのに、クリップ機能の利用数にこれほどの違いがあるのは、きっと何か理由があるはずです。

この理由については今後検証していきたいと思います。

 

 

関連記事(2012/10/02)

(第1回)直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

(第3回)直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

 


Googleの検索表示回数はページの更新間隔に依存しているのか?

こんにちは。MOBYLOG事務局です。

 

忙しさにかまけてブログ更新をサボっており、約3週間ぶりの投稿です。

 

本日、久々にGoogleのウェブマスターツールを見たところ、表示回数やクリック数が激減していました。

 

 

表示回数の折れ線がで凹んでいるのは土日祝祭日で、これは以前からの特徴(ビジネス系サイトで多い傾向)ですが、ここ2週間程度、平日の表示回数が半減しています。

これはブログの更新をサボっていたからでしょうか?

 

表示回数の多いキーワードを見てみたところ、こちらの投稿で記事にしたアプリ名での表示回数が大きく減っていることが分かりました。

 

 

 

全体の表示回数とこのキーワードの表示回数が減っているタイミングが同じなので、このキーワードに引っ張られて表示回数が減っていたようです。

 

このキーワードでの平均掲載順位を見ると7.5なので、検索順位が落ちて表示回数が減った訳ではなく、このキーワードで検索する人の数が少なくなったと見ることができます。

特定のキーワードにより流入が増えた場合、そのキーワードの正味期限が切れると途端に流入が少なくなるということが分かりました。

 

このキーワードはMOBYLOGのサービスとは全く関係の無いキーワードで、この流入がコンバージョン(資料請求やトライアル申込など)に貢献することは皆無のため、表示回数が減っても実害はありませんが、これがサービスに直結するキーワードだった場合、その影響ははかり知れません。

 

このことから、訪問者にメリットのある内容のページを拡充していき、それらページが検索エンジンにINDEXされ、より多くのキーワードで検索結果に表示されるように、地道な努力が必要であることを再認識しました。

 

 

 


AppStoreのランキングは同じ日にこんなにも変動している。

こんにちは。MOBYLOG事務局です。

 

 

以前に投稿した AppStoreのランキングについて考察してみた で

 

ランキングは24時間常に上下しており、バッチでの集計タイミングにより違いが出てくる

 

と書きましたが、実際に1日にどの程度上下しているか調査してみました。

 

調査の対象としたのは、セランで提供しているヘア・コンシェルジュという美容師さん向けの顧客管理・電子カルテアプリで、ビジネスカテゴリで配信しています。

 

調査方法は、AppStoreで提供されているAPIを使い、1時間に1回ビジネスカテゴリのランキング一覧を取得し、ヘア・コンシェルジュのランキングを保存しました。

 

ちなみに、ヘア・コンシェルジュの時間別ランキングは8月初旬からデータを取得していますが、今回は日単位ランキングの変動が大きかった8月27日〜8月29日までの3日間のデータを使います。

 

まず、日単位のランキングは以下のようになっています。

 

ヘア・コンシェルジュのビジネスカテゴリ内 日別ランキング

日付 順位 DL数
8/27 166位 9
8/28 248位 4
8/29 316位 5

 

日別ランキングはは7:00 AMに取得しているので、上記ランキングは大凡7:00 AMのランキングです。

 

 

時間別ランキングはこんなにも変動している

 

下のグラフは、時間帯別ランキングの推移です。

 

 

 

●印は日次ランキングの集計タイミング(AM 7:00)です。

 

このグラフを見ると、ランキングが時間によってかなり変動していることが分かります。

最も差があったのは、8月29日17時と18時の1時間で、374位から215位まで159位もランクアップしていました。

 

日別のアプリダウンロード数を見るとたった一桁台、つまり1時間に1本もダウンロードされていない時間帯があるにも関わらず、この変動は何故でしょうか?

 

恐らく、このランキング近辺だと、自社アプリよりも下にランクしているアプリが1本でもダウンロードされると、それに引きずられてランクがダウンしているかと思います。

ということは、グラフの山(ランキングがアップしている時間帯)では、自社のアプリがダウンロードされている時間と考えられます。

特に急上昇している箇所では、数本ダウンロードされたと見なしてよいでしょう。

 

 

数ダウンロード/日しかないアプリだとこのような感じですが、ダウンロード数の多いアプリで統計を取ると面白いデータになるかも知れません。

 

例えば、統計的にダウンロード数が落ちる時間帯があれば、その時間帯を狙ってプロモーションするとか、ライバルアプリとのランキング比較で、ライバルアプリのランキングが上がった時に広告を出すとかなどなど。

 

ただこの場合、単位は1時間ではなくて分とか秒とかになりそうですね。

 

次は分単位で検証してみたいと思います。

 

 


(第1回)直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

こんにちは。MOBYLOG事務局です。

 

アクセス解析ツールでよく目にする指標の一つとして直帰率というものがあります。

直帰率とは、広告や検索エンジンなどの外部サイト、メルマガ、ブックマークなど、外部からウェブサイトにランディングした後にページ遷移をせず、1ページだけ見てそのまま帰ってしまった訪問者の割合のことをいいます。

 

 

直帰の概念図

 

 

例えば、100人(通常、直帰率はセッション単位で計算しますが、ここでは分かりやすいように「人」で説明します)がウェブサイトに訪問して、そのうち90人が訪問後にページ遷移せずにブラウザを閉じたり、30分間なにもアクションをせずにセッション切れになったり、(外部サイトから来た人であれば)ブラウザの戻るで戻ったりした場合、直帰率は

 

90人 ÷ 100人  × 100 = 90%

 

となります。

 

 

一般的に、直帰率が高いページ=改善が必要なページと解説されるケースが多いです。

 

直帰率が高いページは、

 

ウェブサイト内に用意した様々な情報を見てもらうことなく、ウェブサイト内に掲載したサービスの魅力を十分にアピールできずに多くの訪問者を帰してしまっているページである。

特にランディング数が多いページで直帰率が高い場合は、多くの訪問があるにも関わらず、訪問者が知りたい情報を十分に提供できていなかったり、他のページに遷移しようとしても何らかの問題があって、途中で諦めさせてしまっている可能性が髙いので、このようなページを改善して直帰率を低減させれば、商品やサービスの説明機会を得ることに繋がる。

その結果、最終的にコンバージョン率を高め、ウェブサイトからの収益も高めることができる。

 

と考えられているからです。

 

確かに、100人の訪問者のうち9割が1ページだけ見て帰ってしまっていたら「 改善が必要なページ」なので早急に施策するべきでしょう。

 

ただし、直帰率が高いというレポート内容だけでは、どこをどのように改善すれば良いのか皆目検討が付かない、という方が多いのではないでしょうか?

 

 

そういう場合は、もう一歩踏み込んだ検証をしてみてください。

 

手っ取り早いのは、ヒートマップアクセス解析をすることです。

こちらの投稿にもあるように、ヒートマップを使えば、訪問者の画面タッチやスクロールをトラッキングできるので、直帰が多くても、実はページ内の文章が熟読されているとか、ページ内に設置した動画や外部サイトへのリンクなどのイベントアクションを行っているといった、ページの利用状況を簡単に確認することができます。

 

ただし、MOBYLOGではヒートマップメニューはスマートフォンサイトのみ対応しているので、PCサイトでは確認する術がありません。

携帯サイトでは、これから説明する検証方法は使えません。

 

 

PCサイトもスマホサイトも検証したい場合はどうすれば良いか?本日から2回に分けて、下記検証方法をお伝えしていきます。

 

 

  1. 直帰率の高いページの滞在時間を計測する。
    • 内容を熟読しているのか、パッと見で帰ってしまっているのか確認する。
  2. ページ内のイベントを計測する。
    • ページ内のイベント(例えば動画閲覧や外部サイトリンクなど)がある場合は、そのアクションを確認する。

 

 

 

1.滞在時間を計測してみる

 

通常、アクセス解析の平均滞在時間の計算方法は以下の図のようになります。

 

 

同じセッションで、ページ1にアクセスした時刻と、ページ1から別ページにアクセスした時刻の差を計算して、ページ1の滞在時間として計算します。

 

セッション毎にページ1から別ページに遷移するタイミングは違いますから、その差を総和して、別ページに遷移したセッション数で割ることで平均滞在時間としています。

 

 

 

上記に挙げたように、平均滞在時間はアクセスしたページから別ページに遷移することではじめて計算できる指標です。

つまり、直帰した訪問者の場合は滞在時間を取得することができません。

 

これだと、直帰したにしても、ページ内のコンテンツを熟読したのか、パッと見で帰ってしまったのか確認することができません。

 

訪問者が直帰したとしても、どの程度ページに滞在しているか確認することで、施策を打つための一つの情報を得ることができます。

 

では、直帰が多いページの滞在時間を計測するにはどうすれば良いでしょうか?

 

 

イベント関数を応用しよう

 

MOBYLOGでは、バージョン5から「イベント」メニューを提供しています。

これはMOBYLOGのタグが用意するイベント関数を用いることで、ページ内で発生する各種イベントをトラッキングすることができる機能です。

 

通常、イベント関数は動画の再生ボタンやリンクやボタンのクリック時に発生するonClickイベントを取得してイベント通知する使い方が一般的です。

例えば、リンクをクリックした場合にイベント通知をしたい場合は以下のように記述します。

<a href=”#” onClick=”__push_event(param1,param2);”>リンク</a>

「__push_event(param1,param2)」はJavaScript版HandloaD TAG、MOBYLOG ENGINEで用意されているイベント通知関数は「__push.event(param1, param2)」です。

それぞれ、param1はイベント名、param2にイベントカテゴリ名を代入します。

 

 

滞在時間を計測する場合はこのイベント関数を応用します。

以下のコードは、15秒間隔でイベント関数を実行して、滞在時間をイベント通知するJavaScriptのサンプルコードです。

ページを開いている状態で放置されて永遠にイベント通知されても意味がないので、5分以上経過したらイベント通知をしないようにしています。

 

 

滞在時間を計測するためのイベント関数応用例

 

イベント名に秒数(15秒間隔)、イベントカテゴリ名に「滞在時間」を設定して、レポート画面のイベントメニューで簡単に検索できるようにしています。

 

 

実サイトで検証してみた

 

下図は、セランでテスト運用しているスマートフォンサイトのコンテンツ – ページで見た計測結果です。

 

「コンテンツ – ページ」レポート

 

No.1のページはとあるアプリのレビューページですが、レビュー情報だけでなく、ここからAppStoreに遷移したり、このアプリをクリッピングできる機能を持っています。

計測値を見ると訪問者(ランディング数=590セッション)は他のページに比べて多いのですが直帰率も高い状況です。

 

このページには上記のイベント関数を応用したスクリプトを実装して滞在時間を計測していますので、滞在時間を見てみましょう。

 

 

「コンテンツ – イベント」レポート

 

滞在時間が15秒のイベントが最も多く274セッションあり、 滞在時間が増えるに従いセッション数が少なくなっていることが分かります。

 

 

このレポートから分かること

 

このページにアクセスした訪問者は、15秒後に必ず滞在時間取得イベントが通知されるので、590セッションのうち274セッション(46%)は15秒以上ページに滞在していることになります。

直帰率は91.86%ですが、滞在時間のイベント計測を見る限り、訪問者の46%はパッと見で帰っていない、つまりページ内の情報を読んだり別のアクションをしている可能性があることが分かりました。

 

 

第2回では、ページ内の別のアクションをイベント計測してその結果を報告したいと思います。

 

 

関連記事(2012/10/02)

(第2回) 直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

(第3回)直帰率だけで判断してはいけない。もう一歩踏み込んだ検証方法。

 


コンバージョン数が増加。その理由はSNSでの記事拡散。

こんにちは。MOBYLOG事務局です。

 

 

このブログ、こちらの目的ではじめたのですが、約1ヶ月強続けていてSEO的に多少の効果があり、検索エンジン経由の訪問数増加を達成したものの、コンバージョンが増えるまでには至っていませんでした。

もともとコンバージョンを増加させるためにはじめた訳ではないので良いのですが。

 

 

ところが、先週末くらいからMOBYLOGサイトのコンバージョン数が増加していて、この理由を調べていたら面白いことが分かりました。

 

現状、MOBYLOGサイトで成果ポイントとしているのは以下の4つです。

 

  1. 問い合わせの完了ページ
  2. 資料請求の完了ページ
  3. トライアル申込の完了ページ
  4. パートナー資料請求の完了ページ

 

このうち、1と2が通常の3倍程度になりました。

 

コンバージョンの流入経路を見たところ、ランディングページが↓このページ。

 

iPhoneアプリの効果測定。初回起動時ブラウザ立ち上げはリジェクトされる。

 

この記事は2012年7月30日に投稿したものですが、掲載から3週間以上も経過しています。

このページのレポートを見たところ、以下のようになっていました。

 

コンテンツ – ページ (2012年7月30日〜8月24日)

 

投稿した7月30日から8月24日までの推移情報です。

棒グラフのPV数に、緑色のUU数を示す折れ線グラフを重ねてます。

それまで数PV/日だった記事に8月23日、24日と1,000UU近いアクセスがあり、23日の9時10分頃からアクセスが急増しています。

 

これはMOBYLOG’s BLOG始まって以来の記録的アクセス数な訳ですが、それはさておき、この原因を探ってみたところ、Facebookからのアクセスが大半を占めていることが判明。

 

 

このほか「t.co」という短縮URLドメインからのリファラーも確認できるので、Twitterでも流れているのかと思い、検索してみたところ思ったよりも多くのツイートがされていました。

 

 

この記事の「いいね!」ボタンや「ツイート」ボタンを見ても明らかですね。

 

 

解析情報を見ると、8月23日の9時頃に検索エンジン経由でこの記事を読んだ方が、Facebookに投稿したか、Twitterでツイート(もしくは両方)して拡散。記事タイトルで興味を持った人がアクセスし、記事を読んで内容に興味を持った方が「問い合わせ」「資料請求」をしたことにより、コンバージョン数が増加したと結論付けました。

 

 

記事タイトルの付け方にも一工夫が必要?

 

今回の件で記事タイトルの付け方にもテクニックが必要そうだと感じました。

通常、FacebookやTwitterに投稿する場合、記事のタイトルを入れるかと思いますが、例えば、この記事のタイトルが「アプリの効果測定は難しい」だったらどうでしょうか?

記事タイトルからはどんな内容か判断できないのと、興味喚起されるキーワードが含まれていないために、多くの人がスルーしたかと思います。

 

実例として、8月15日に投稿した残暑見舞い申し上げますという記事。

この記事には、オリジナルのショックアブソーバースマホケースMOBYLOGストラッププレゼントのキャンペーン内容が記載されているのですが、ほとんど応募がありません。もちろんアクセス数もほとんどありません。

このタイトルでは「あぁ、単に残暑見舞いのブログか」 と思われるからなのだと思います。

もしかしたら全く欲しくないのかも知れませんが。。。

 

9月末まで受付しておりますので、ご興味のある方は是非ご応募ください。

 

 

ウェブサイトのコンバージョン数だけでは成果は見えない

 

さて、コンバージョン数が増加したからといって喜んでばかりもいられません。

その場で課金できるECサイトであれば、ウェブサイトのコンバージョン数はそのまま売上に直結しますが、資料請求や申込を成果としているサイトの場合は、ウェブサイトのコンバージョンがすぐさま売上に直結しません。

MOBYLOGのサイトは後者で、サイト上のコンバージョン数は増えましたが、実際に売上に結びつくまではトライアルを経て本契約して頂かなくてはなりません。

「トライアル申込」でのコンバージョンであればCVRは比較的髙いのですが、資料請求や問い合わせだと情報収集が目的のケースもあるので、CVRはガクッと下がります。

 

 


「ヒートマップアクセス解析の使い処」のその後

こんにちは。MOBYLOG事務局です。

 

こちらの投稿で、ヒートマップアクセス解析の使い処をご紹介しました。

 

弊社でテスト運用しているスマホサイトにヒートマップタグを仕込んでレポートを見たところ、サイト運営側で想定していなかったアクションをユーザーがとっていることが判明(「評価/レビュー」というリンクを貼っていない文字が多くタップされていた)。

そこで得た結果から

 

ユーザーはこのアプリのレビューをもっと読みたがっている。

 

という仮説を立ててサイトに以下のカスタマイズを施しました。

 

  1. 評価/レビュー一覧の下に「さらに評価をみる」というリンクを設けた。
  2. リンク先はレビューを改ページで見ることのできるレビュー専用ページとした。

 

 

図1は、前回の投稿で掲載した想定外のアクションが分かったヒートマップレポートですが、この画像を見る限り「評価」ではなく「レビュー」という文字が多くタップされています。

 

図1)カスタマイズ前のヒートマップ

 

今回のカスタマイズでは、コピーによってアクションが代わるのかを検証するために「レビュー」という文字は使わずに敢えて「さらに評価をみる」としました。

 

 

さて、今回のカスタマイズで対応したのが図2の「さらに評価をみる」リンクです。

 

図2)カスタマイズ箇所

 

「さらに評価をみる」リンクをタップするとレビュー専用ページに遷移するだけの簡単なカスタマイズですが、果たしてその効果はあったのでしょうか?

 

図3)カスタマイズ後のヒートマップ-1

 

図3はカスタマイズ後のヒートマップアクセス解析結果です。

カスタマイズ以前には多くタップされていた「評価/レビュー」の「レビュー」文字が、ほとんどタップされることがなくなったことが分かります。

 

ここまでは仮説通りになっています。

 

次に、今回のカスタマイズで設けた「さらに評価を見る」リンクがどの程度タップされているか確認します。

 

図4)カスタマイズ後のヒートマップ-2

 

どうでしょうか?

図4の「さらに評価をみる」のリンクあたりが他エリアに比べるとヒートアップしているのが分かるかと思います。

 

これを見ると仮説した通りに

 

設けたリンクがタップされている

 

ようです。

 

 

 

しかし。。。

 

当初に思ったよりも新たに設けたリンクがヒートアップしていません。

このリンクはもう少し赤くヒートアップするかと思っていました。

 

また、「さらに評価をみる」リンクの箇所の上下に若干ヒートアップしている箇所が見受けられます(図5の赤枠)。

 

図5)リンクの箇所の上下に若干ヒートアップしている箇所

 

タップしても何も発生しないと想定される箇所が、ヒートアップしているのは釈然としません。

 

 

縦位置が変動する場合のヒートマップ計測

 

この投稿を書いている最中にもう一度見たヒートマップが下の図5です。

 

図6)カスタマイズ後のヒートマップ-3

 

図6は図4)カスタマイズ後のヒートマップ-2をキャプチャした1時間後に見た時のキャプチャですが、ヒートアップしている箇所が違っています。

 

これは何故でしょうか?

 

図4と図6のレビューを見比べてみて原因が分かりました。

No.10のレビューの投稿者と内容が違っています。

このサイトはリアルタイムにApp StoreのAPIから情報を抽出しているのですが、抽出した時間によってレビューの内容が変更します。

つまり、アクセスした日時によって「さらに評価をみる」リンクが上下するのです。

 

図7)縦位置が上下した場合のヒートマップ

 

ヒートマップアクセス解析は、タップした箇所を画面の縦横の位置で判断して解析するので、図7のように期間によって操作位置が変わる場合、正確な位置をトラッキングすることは出来ません。

これが原因で、図4と図6の差が出ています。

 

これを回避するには、位置を固定化するという選択肢があります。

例えば、ここでサンプルに使っているページであれば、1レビューの縦枠のサイズを固定サイズにし、続きが読みたい場合はフリックで別ページに飛ばしたりPOPで表示するなどです。

 

ただし、これはお勧めできる手法ではありません。

なぜなら、ヒートマップアクセス解析はあくまでツールであって、それ自体が目的になってはならないからです。

 

ここで縦サイズを固定化することにより、レビューがパッと一覧で見れなくなったらどうでしょうか?

もともとレビューがもっと読みたいというニーズに応えるためにカスタマイズをしたのに、ユーザビリティを損ねてしまい意味が無くなってしまいますね。

 

ページの特性により表示する日時や内容によって上下するということを事前に理解していれば、多少ヒートアップの位置がずれていても、ヒートマップアクセス解析結果から意味を汲むことは可能かと思います。

また、リンクにイベント関数を仕込んでイベント計測をしたり、レビュー専用ページのアクセス解析をすれば、その解析結果からリンクタップの効果を判断することができます。

 

 

まとめ

 

リンク位置が変動することで、ヒートマップが指すヒートアップの箇所がずれるという未知の課題にもぶつかりましたが、前回立てた仮説を実行に移してチェックした限り、一応正しかったことが証明されたと思います。

 

ただ、これで終わりではありません。

次は

 

  1. 「もっと評価をみる」から「もっとレビューをみる」に変えてみる
  2. 固定位置にも「もっとレビューをみる」リンクを設けて、その動向を検証する

 

ということを行ってみたいと思います。

 

 


髙いコストメリット〜専有サーバプランのススメ

こんにちは。MOBYLOG事務局です。

 

残暑厳しい日々が続きますが、皆様健やかにお過ごしでしょうか?

約1週間ぶりの投稿となりますが、今回はMOBYLOGのセールスなので、ご興味の無い方は読み飛ばしてください。

 

現状、MOBYLOGは4つの料金プランを用意しています。

 

  1. アクセス解析・効果測定プラン(ASP)
  2. 効果想定プラン(ASP)
  3. 専有サーバプラン(ASP)
  4. パッケージプラン(ライセンス販売)

 

1.アクセス解析・効果測定プランは文字そのままで、アクセス解析しながら効果測定をしたい場合にご利用頂くASP(今だとクラウドサービス?)で、これをご利用のお客様はMOBYLOG契約社数の80%を占めている人気のプランです。

このプランは月間数千PVから500万PVまでを上限にしていますが、もちろんそれ以上のPVがある場合でも問題なく計測できます。

ただ、その場合は月額コストが高くなるため、専有サーバプランをオススメしております。

 

 

2.効果測定プランは、計測対象のページをLP(ランディングページ)とCVP(成果ページ)だけに絞り、MOBYLOGに通知するPVを少なくすることで月額費用を抑えて効果測定だけをしましょうというプランです。

「効果測定」という領域は競合するツールが多いため、あまり導入数は多くはありませんが、こと「ガラケーサイト」に絞った場合、MOBYLOG ENGINEという特殊技術の優位性があるため、近頃のガラケー新規案件では、このプランでの導入が多くなっています。

 

 

3.専有サーバプランは、お客様専用のデータベースサーバを1台用意し、そのサーバを使い倒して頂く定額のプランです。

このプランの詳細はのちほど。

 

4.パッケージプランは、ライセンス販売で、お客様にH/Wを用意して頂き、そこにMOBYLOGのシステム一式をインストールしてご利用頂くプランです。

ログを外に出したくない場合や、自社でシステム運用できるテクニカル部門を持つお客様に最適のプランです。

このプランは、MOBYLOGのシステム運用はもとより、障害対応やバージョンアップなどのメンテナンス作業はお客様で行って頂くため、弊社ではあまり推進していないプランですが、クラウド時代とはいえ「ログを外出ししたくない」というニーズはまだ多いようで、案件のお話は多く頂いています。

 

また、通常、パッケージ販売のツールだと、年間のPV数やインストールするサーバ台数で課金するケースが多いようですが、MOBYLOGの場合は計測するサイト単位での課金でPV数やサーバ台数には依存しないのと、オプションという考えがなく1ライセンスで全ての機能が使える+バージョンアップも保守内容に含むという販売体系もコストメリットが髙いと認識される要因になっているようです。

 

 

本当にコストメリットが高いのは専有サーバプラン

 

MOBYLOGで販売に力を入れているのが専有サーバプランです。

専有サーバプランは前述した通り、お客様専用にデータベースサーバを1台用意して、そのサーバスペックが許す限り使い倒して頂くことができるプランです。

よく勘違いされるのですが、専有サーバ=専用のデータベースサーバとなります。

ログ受付サーバやアプリケーションサーバはMOBYLOGシステム共有の冗長化されたサーバ群を使います。

 

基本的に一番負荷が掛かるのがデータベースサーバで、共有サーバだと、どこか一つのサイトのログ集計に負荷が掛かると、それに引っ張られる形で重くなります。

レンタルサーバの共有サーバと一緒と考えて頂くと分かりやすいかと思います。

 

 

専有サーバの場合はお客様専用のサーバですので、共有サーバよりもサクサクとしたレポート生成が可能となります。

もちろん専有サーバでも大規模なサイトであると共有サーバと同じような現象が発生することがあります。

 

専有サーバの魅力は何と言ってもコストです。

月額52.5万円(税込)なので、非常に高く感じる方もいらっしゃるかと思いますが、この金額で効果測定オプションも利用可能。しかもサーバは実績値で月間1億強のPV処理をします。

計測対象のページ数にも依存しますが、それほど計測するページ数が多くなければ1.5億/月程度は処理可能かと思います。

 

つまり月間1億PVのサイトであれば1サイト、月間5,000万PVのサイトであれば2サイト、月間500万PVのサイトであれば20サイト、月間100万PVのサイトであれば100サイトを1専有サーバで計測することが可能ということになります。

例えば運営サイトを多く持っているお客様であれば、専有サーバで100サイト計測した場合、1サイトあたりの月額コストは5,250円

しかもASPなので、サーバメンテは要らずサポートも受けることができます。

 

また、WebサイトログをBIツールに連携するための生ログ抽出サービスなど各種サービスもご用意しております。

 

大規模サイトを運営している方、多くのサイトを運営している方で、アクセス解析にコストが掛かっている場合は是非こちらまでお問い合わせください。