2014年8月28日木曜日

運用型広告の現場におけるレポーティング/分析環境の変化

僕が所属するアタラの主力ビジネスは実は運用型広告のExcelレポート作成を自動化するglu(グルー)というシステムだったりします。非常に地味に展開してきたこともあり、知らない方も多いと思います。もう4年目になり、導入先企業もかなり増えてきています。

gluは運用型広告の現場の基幹システムとしての地位を確立すべく、運用型広告プラットフォーム各社の進化に合わせて、自身も進化を続けています。

gluをどう運用型広告の現場で進化させていくかをお客さまと話し合うことが僕の仕事の大部分と言っても過言ではないように思います。そんな中、お客さまの現場で昨年あたりから、ある変化が見られます。

まず、Google、Yahoo!、Facebook、DSPなど各プラットフォーム側のデータ種類の増大によって、分析すべきデータが格段に増えている点が挙げられます。これは昨今のDMPの流れからもわかると思いますが、さまざまなデータが集約され、精緻なターゲティングなどができるようになっていいますが、それに伴い、効果測定もより一層細かく行う必要が出てきています。Googleなどもここ1-2年でレポート種類はかなり増えました。

それに加え、分析スピードが加速している点も挙げられます。あ、これはちょっと言い方が違うかな。今までと同じ時間の中で、より多くのデータを分析しないといけないので、結果的にスピードが求められていると言ったほうがいいですね。代理店やコンサルティング会社も大変だし、クライアント側も、色々な角度から戦略や予算の判断をしないといけないので、これまた大変です。

gluは特に毎月・毎週・毎日、何らかの形で定型のExcelレポートを出力するのを非常に得意としています。これはこれで今後もニーズはあるのですが、上記の変化の中、「定型レポートはもちろんやっていくが、それとは別にアドホックな分析がしたい」、「定型レポートに含めるデータが何かを見極めるために分析をもっと柔軟に、スピーディにしたい」という声を昨年からいただくようになりました。これだけで見ても、昨今のBIツールの流れはとても納得がいくものです。gluもそういうことがよりやり易くなるよう、進化をしつつあります。

データ種類が爆発的に増えれば増えるほど、分析に値するデータの見極め力がより一層求められているなぁ、と思うのです。そして通り一遍のレポートは不要になり、カスタマイズしやすいレポーティング環境がより求められているなぁ、とも感じ、まだまだこの分野は深堀りのしがいがあると思うのです。今後も運用型広告のデータは増える傾向にあるでしょうね。Marketers, brace for impact!

2014年6月13日金曜日

SMX Advanced Seattle 2014に参加してます(初日)2

初日のセッションですが、僕はPaid Searchのトラックを中心に参加しました。

特筆すべきセッションの内容だけ抜粋します。

【The Mad Scientists Of Paid Search】
Speakers:
Lars Hirsch, Group Program Manager, Microsoft (@larshirsch)
Bryan Minor, Chief Scientist, Acquisio (@BryanMinorPhD)
Jared Schroder, VP Data Intelligence & Marketing Technology, Location3 Media

毎年同じタイトルでやっている人気セッションです。各社の「Paid Search分野の狂ったサイエンティスト」たちがその成果を披露します。個人的にも好きなセッションです。




さすが人気セッション。満席でした。











<Microsoft>
要約:業種別、時間帯別、デバイス別でパフォーマンスは異なる。このあたりを分析した上での予算配分と入札設定を実施。クロスチャネルアトリビューションは必須。アトリビューション関連データを提供すべく試験中。ゴールベースの最適化機能は提供予定。

  • Bing/AdCenter上での各種データを提示。
    • 一日の終わり、月の終わりにさしかかるにつれ競合が脱落するのでCPC、CPAは落ちる。よって予算を一日の終わり、月の終わりにシフトする。まあ、これはold school SEMですね
    • リテール業種
      • PCのCTRは昼にスパイク。タブレットは夜間
      • 朝のタブレット経由のクリックは過小評価されている
    • 金融業種
      • 一日を通じて質の高いタブレット経由のクリック
    • 旅行業種
      • 昼と夜に質の高いモバイル経由のクリック
    • 業種別で一日の各時間帯で、一番ROIがよいデバイスタイプの話。興味深い(P12)
  • クロス・デバイス・アトリビューションを実施しないとキャンペーンを過小評価している可能性がある
  • 試験的に取り組んでいるアトリビューションモデル:Keyword Assist
    • クリックだけでなく、クエリーを見るモデル
  • 手法
    • コンバートしたキーワードからクエリーを特定
    • コンバージョンパスに現れる相対的確率を計算
    • 関連性を計算
    • ユーザーダイバーシティを計算
    • コンバートしたキーワードと直前クエリーの組み合わせパターンを頻出度を計算
  • 「アトリビューション・モデルを制するものは予算を制す」。名言かな。
  • Pathfinderという、ゴールベースの最適化機能を18ヶ月内にAdCenterに実装予定の模様です。膨大な並列クラスター処理で、考えうるキャンペーンの変化をシミュレートするようです。広告主にはゴール達成のための最適なアクションを提示してくれるようです。



感想:Bing/AdCenterだけの世界の話ではないので参考になりました。弊社もレポーティングシステムをやっているのでわかりますが、時間帯別はもっとやらないとですね(ただ、データフィールドが爆発的に増えたので容量管理と処理スピードが課題・・)。

<Acquisio>
このプレゼンが一番すごいと思いました。総合ツールベンダーのAcquisioの方による入札戦略に関する話でした。

要約:なるべく細かくfine-tuneすることで固定予算をきちんと使い切り、最大の効果を得ることは可能

  • キャンペーン予算が固定化されているケースは多いと思うが、1日・1ヶ月の予算が枯渇させず最大の効果を得るには?
  • Googleはアルゴリズムを一日に2度変更するペースで、動く標的を追うようなもの
  • インプットに対する小さな変更がアウトプットに対する大きな変化を生む
  • 5年間研究した結果、継続的な入札調整(毎30分間(1時間2回))をすることで優れた結果を生むことがわかった
  • 軍の巡航ミサイルをなぞらえたcruise missile approachと呼んでいる。動く標的を細かい微調整しながら追尾するのに似ているから。
  • より多くのクリック(コンバージョン)をより少ないCPCで実現


感想:考慮しないといけない変数が多い中、変化に応じて細かく追尾していくのは確かに理にかなっている思いました。紹介された事例でも精度は高い様子でしたし、サーチ以外(GDN、DSP、他)でも基本的には使える手法であるため、Acquisioとしては最適化の中心に据えるんだろうなと思いました。

<Location3 Media>
要約:クエリーデータをマイニングし、精度の高いキーワード戦略を実現

  • Googleのクエリーの70%はどの広告キャンペーンともマッチングしないと言われている
  • 完全一致は部分一致、フレーズ一致の3.12倍もコンバートする率が高い


  • クエリーデータから頻出ワードをマイニングし、写真のようにタグクラウド化。クエリーテーマ分析(Query theme analysis)
  • タグクラウドの文字サイズはコストの大きさ、カラーは費用対効果
  • 重要クエリー、損失の大きいクエリー、品質スコアキラーをこの中からマイニング
  • キーワードのカニバリゼーションを起こさないよう注意
  • リスティング広告とオーガニックでの重複もマイニングできることになるが、両社は共存すべきで、相応に扱われるべき、というスタンス

【PLA To Pay: Maximizing Profits With Product Listing Ads】
Speakers:
Elizabeth Marsten, Vice President of Search Marketing, Portent, Inc.
Jay Stampfl, Client Services Manager, 3Q Digital
Frank Kochenash, VP Client Services, Mercent

<Portent>
  • Bing Ads PLAがロンチ
  • 構造は概ねGoogleと同じ
  • 彼らの事例では、Bing Ads PLAはGoogle PLAの獲得数の 3-4%だが、獲得コスト面ではまだ高騰していないのでオススメ
  • 良い点の一つはGoogleと違って管理画面の中にある点
  • 審査に時間がかかる、審査がまだこなれていない
  • エディターと互換性問題が残る
  • Tipsとしては開始したばかりまだ複雑な構造にしないこと
  • Bing UTMトラッキングがようやく実装予定
  • SuperMetricsというGoogle Analytics plug-inを使うとトラッキングできる


<Mercent>
要約:米国の(PLA実施)広告主予算の平均35%はGoogle PLAに費やされているらしい。それだけ重要性が増しているGoogleの近未来の姿を予想

このセッションが一番ためになった気がします。もちろんMercentのKochenash氏の個人的な予想ではあります。ちなみにMercentは米国のデータフィードサービス提供会社。エンタープライズ級クライアントがほとんどのようですが、何年も前からデータフィードを手がけていることもあり、その視点は興味深かったです。
  1. PLAに反映されるデータは増える〜Structured Dataの準備をしておくことが有利に。差別化要因は入札ではなくフィードにある。フィードを最適化
  2. 購入可能なバリエーションが重要に。バリエーションのデータをより多くフィードに送信する。最近アップデートされたContent APIを活用する
  3. ユーザが価格比較をしやすい新しい機能が実装される。価格競合性の測定を。価格を意識した入札戦略をテストし始めておく
  4. Googleによるフルフィルメントサービスの充実化。別の言い方をするとGoogleのフルフィルメントサービスを活かすためのデータ認定の実装。常にフルフィルメントやカスタマーサービスを充実させる
  5. AdWords内で価格競合性に関する指標の実装
  6. PLA内での検索広告用リマーケティングリスト(RLSA)の実装
  7. ブランド企業のための新しい広告商品の実装。共同マーケティングやMDF(市場開発基金)的なプログラムを活かすようなもの
  8. モバイルでのショッピング体験はより充実したものに。ローカル店舗の在庫・価格情報を提供できるようにしておくこと
サマリーとしては:
  • Google PLAはより「eコマース風」になっていくと予想
    • データの準備を怠らない
    • 組織についてもそういった変化に対応できるよう準備していく
    • サプライチェーンパートナーシップを強化しておく


感想:PLAはすでに最重要施策の一つであり、そのプレゼンスはさらに高まる見込みです。どの程度予測が当たるかはもちろんわからないですが、データも組織も柔軟性を持たせておくことがやはりとても大事だと思いました。Amazonとかなり競合する感じですね。日本ではフルフィルメントサービスはどうするんでしょうね。

<3Q Digital>
要約:PLA内でのアカウント構成、除外キーワードの考え方、ショッピングキャンペーンへの対応について。

  • PLAは2013年に競合が増え、オークションも活性化。結果、スケールも増し、CPCも増加
  • 特にホリデーシーズンの売上増は特筆すべき点
  • キーワードのマッピングは課題。除外キーワードはそもそもサーチとは違うビヘイビア。マッチタイプの制御は困難
  • ユニークなクエリーが減るにつれ、コンバージョン率が高まる
  • コンバージョン率を見てトッププロダクトを選定。ただし、入札によるので注意
  • ショッピングキャンペーンについて
    • キャンペーン優先度を付けることができるようになり、クエリーマッピングがよりしやすくなる
    • インプレッションシェアと競合性指標の導入。インプレションシェアの増加が高いCTRにつながる
    • ダブルサービングが実質できてしまう件。根本的に違う性質のオークション
    • 詳しくは下記のAdmarketech.の記事で解説されていますので参照願います

AdWordsのショッピングキャンペーンを考える
http://www.admarketech.com/2014/02/adwords-shopping-campaigns.html




以下、SEO関連。ただ、私自身はSEOの専門ではないので、解説などは控え、要約記事へのリンク掲載と個人的な感想に徹することにします

【Super Session: Enhancing Search Results With Structured Data & Markup】
Speakers:
Jay Myers, Emerging Digital Platforms Product Manager – Product Recomendations, BestBuy.com
Jeff Preston, Senior Manager, SEO, Disney Interactive
Marshall Simmonds, Founder and CEO, Define Media Group, Inc.

SEOセッションで毎年楽しみなのがこれ。3年前から定番になっていてschema.org、Structured Dataの参考になります。

Up Close @ SMX: Enhancing Results With Structured Data & Markup
http://searchengineland.com/super-session-enhancing-search-results-structured-data-markup-193869

Bruce Clay社のブログから。
SMX Liveblog: Enhancing Search Results with Structured Data & Markup
http://www.bruceclay.com/blog/smx-liveblog-enhancing-search-results-with-structured-data-markup/

詳細の解説は今回のSMXでご一緒させていただいた鈴木謙一さん(ご一緒できて楽しかったです!)にお願いしますw 無茶ぶりすみません。

感想としては、やはり2008から地道にStructured Dataの導入に取り組んで結果を出しているBest Buy、組織的にかなり細かいテストや導入をして実績を積んでいるDisney Interactiveの話は非常に面白かったですし、Structured Dataの重要性とその可能性を信じてきてよかったと思える内容でした。

実装しても当然リッチスニペットの表示が保証されるわけではないし、ビジネスへの直接的な貢献度は測りづらい面があります。組織としてどう予算化したり、取り組むかは今後も課題かもしれません。Best Buy、Disneyの方々は両者とも"leap of faith"(結果を考えずにやってみるしかない)と言ってました。それが許容される組織とそうでない組織はあると思います。ただ、よい結果がついてくることを信じて取り組む熱意が一番のドライバーなのかと思いました。

毎回SMXでは全体としての大きなテーマを自分なりにキャッチするようにしています。ここ数年は大きなテーマ(2007あたりからはアトリビューション、ソーシャル、DSPと続きましたが)が見当たりませんでした。ただ、今年は個人的にはStructured Dataだと思いました。理由は、3年前と比較してもStructured Data導入の重要性はかなり浸透してきたこと、そして、OrganicだけでなくPLAなどPaidの取り組みでもStructured Dataに対応できるデータ環境を整備することがますます重要になっていること、そしてGoogle、Microsoftが力を入れて取り組んでいる音声検索の分野でも、Structured Dataが重要であること(Microsoftの人は少なくともそう明言してました)が挙げられます。

Structured Dataは手段でしかないと思います。結局、本質的には消費者にどんな情報をコミュニケートしたいのかに行き着く話であり、それを構成するデータの器となる商品データベースやCRMのデータ設計、データ出力、データ/システム連携の柔軟性を保っておくことが、変化、進化が多いビジネス環境の中で、企業のマーケティング活動にとって今後ますます大事なのだと思います。そのあたりは日本でももっと語られてもいい分野なのだと思います。

【You and A with Matt Cutts】
もはや業界イベントの名物となったSMX/SearchEngineLand創設者Danny SullivanとGoogleのMatt Cuttsのセッション。
相変わらず軽妙な掛け合い。Dannyが絶妙なレベルで突っ込み、Mattが絶妙なテクニックで笑顔で交わすという(笑)
これを執筆している現時点で、ロンチ予告のあったPayday Loanアルゴリズムはロンチしてますね。

Matt Cutts: New Payday Loan Algorithm Update Coming, More News From SMX Advanced 2014 Keynote
http://searchengineland.com/matt-cutts-smx-advanced-2014-193814

2014年6月12日木曜日

SMX Advanced Seattle 2014に参加してます(初日)1

今年も参加してます。正確には数えてませんが、通算で6-7回目になりますかね。



会場は変わらずシアトルのPuget Sound(ピュージェット湾)沿いにあるBell Harbor International Conference Centerで開催されました。






6月のシアトルの気候は毎年いいです。つい先週あたりまでは雨がひどかったようですが。一年中、降雨量が多いことで有名です。雨が嫌いな人は住めない町ですね。








毎年写真を撮るエントランスです。毎年よく来るよなぁ、と我ながら思います。ほとんど意地ですよねw










今年も満員御礼だったようで、人気セッションは満席が目立ちます。米国のみならず、僕のように海外からの参加者も多いですね。Advanced = 上級者向けの内容とあって、検索エンジン業界周りではベストカンファレンスの一つとされています。





まずは展示スペースから。展示社の数は例年通り。今年はGoogleはプレミアスポンサーですが、スポンサードセッションにフォーカスしているのかブースはありませんでした。








Yahoo!は健在でした。












今年でしたか、発表してたモバイルサーチとネイティブ広告の統合アドプラットフォームであるYahoo Geminiを展示してました。管理ツールであるYahoo Ad Managerは緩くBing AdCenterとは連携していますが、大方の見方としてはMicrosoftとのSearch Allianceから離脱しようとしていると見られていますね。ブースのYahoo!社員にAdCenterとの連携について聞いてみましたが、きちんと理解できてなかったので、どうも動きとしては別々に見えました。






デモ要員の方が、ネイティブ広告として出る部分と、モバイルサーチで出る部分をデモしてくれました。彼ら曰く、ですが、大口の広告主から導入が進んでいるとのことでした。

















一方のBingは目新しい発表は少ない印象でした。











Bingチョコレート(さすがオーガニックチョコレートで有名なシアトル近郊にある会社)とペンはちゃっかりいただきました。








MOZも毎年元気ですね。SEO Mozからリブランドしてからより一層勢いがある気がします。










MOZ AnalyticsでロンチしたばかりのLanding Pagesをデモしてもらいました。うちもMOZは試験的に使い始めているので帰国したら吟味してみましょう。








MOZ Barはサイレントロンチしたそうなので、知らない人も多いかもしれません。Chrome Extension(FireFoxもある)で提供されていて、開いたページの診断をしてくれます。Attribution.jpのトップページの診断をしてもらいました。結果は内緒でw




MOZ Barを入れておくとSERPにこういう感じで出てきます。便利。




















おなじみのブルース・クレイ氏もブースで直々にSEO指南をしてました。氏もそうですが、各方面の有名なプレーヤーがブースにいたりセッションパネリストを努めています。








競合分析ツールでは老舗のAdGooRoo。PLA関連の新しいツールをリリースしてました。










Kenshooも展示してました。












Marinも今年も展示してました。









本セッションに関しては別途書きます。僕はほとんどPaid Searchのセッションのみに参加しています。

2014年5月8日木曜日

Google AdWordsのMCCレベルでGoogle Apps Script(MCC Scripts)が使えるようになりました

以前からGoogle AdWordsでもGoogle Apps Scriptが使えるようにはなっています。AdWordsの視点からネーミングしているのかAdWords Scriptsという言い方をしていますがSpreadsheetなどGoogleプロダクト間の連携はGoogle Apps Scriptと同サービスと同じですし、コードの書き方も同じです。

MCCレベルでのスクリプトサービスMCC Scriptsは今年3月あたりからベータ提供されていましたが、正式にロールアウトされたようです。

http://searchengineland.com/google-adwords-scripts-mcc-accounts-ready-use-190774

レポーティング、入札、予算管理、ON/OFF管理、各種アラートなどができます。サンプルコードも豊富ですし、コーディングしない人のための完成コードまで準備されています。至れり尽くせりです。

MCC Scripts
https://developers.google.com/adwords/scripts/docs/features/mcc

いくつか制限もあるので注意です:


  1. MCC Scriptsは30分間しか実行できないので、どうしてもやることに制限ができてしまいます。ただし、executeInParallelで並行処理を行えば追加の30分、合計60分間は実行できます。最大のアカウント数は50までに制限されています。
  2. MCC Scriptsをそのままで使おうとすると、すべてのアカウントに同じ処理をするようになっていますが、現実的にはアカウント毎に違う設定があったり、異なる処理をすることになるかと思います。前述のexecuteInParallelも便利ですが、コールする際に変数をパスすることはできないので、Google Spreadsheetに別で設定情報を保有し、アカウント毎の処理に使う、というのがベストプラクティスのようです。
  3. OAuth2認証を使いますが、アカウント毎に250個のスクリプトが上限になります。そこまで使うことは少ないようにも思いますが、一応制限はあるということです。
  4. AdWords ExpressやAdWords for Videoのキャンペーンは対象外です。キャンペーン情報をコールする際、自動的にフィルターされるのでご注意ください。
若干の制限はありますが、ここまでできるようになったのはスゴいことだと思います。AdWords APIを使った本格的なシステムと、日々の運用支援を行うAdWords/MCC Scriptsベースのスクリプトをバランスよく使い分けるとよいかと思います。今後Googleからも、ユーザーからも、数多くのサンプルコードが出回ることと期待しています。

来る6月11-12日に毎年恒例のSMX Advanced Seattleに参加してきます。今年はこのAdWords/MCC Scriptsを取り上げたセッションもあることでしょう。少なくとも海外のPaid Search従事者がどの程度使いこなしているのかを調べてこようと考えています。

2014年4月14日月曜日

【Google Apps Script】8. Yahoo!ニューストピックスAPIで最新の動向をキャッチする

多くの人がヤフーのトップページのニューストピックスから最新情報を得ていることと思います。私もそうです。できれば効率よく、このニュースを見れればと思うので、Google Apps ScriptからトピックスAPIを使って最新トピックスを引っぱり、好きな時間やタイミングで自動的にメールに届けるようにしたいと思います。



Yahoo! JAPANトップページのトピックス部分。日々の情報収集に欠かせませんね。一日に何度か見ていると思います。






まず、APIを使うためのアプリケーションIDを取得する必要がありますので、Yahoo!デベロッパーネットワークのページの「アプリケーションの管理」メニューから申請をしてください。










リクエストURLはこのようになります。
http://news.yahooapis.jp/NewsWebService/V2/topics?appid=<アプリケーションID>&pickupcategory=top

アプリケーションIDはご自身で取得したものをappid=の後に入れてください。最後のpickupcategory=topは、Yahoo! JAPANトップページのトピックスを表示するパラメータになります。これを「エンターテインメント」などカテゴリを指定したり、「地震」など特定の検索キーワードを指定することも可能です。

【サンプルコード】

サンプルコードです。前述のようにアプリケーションIDを挿入したURLをフェッチすることをお忘れなく。

実行するとこんな感じで8本の最新ニュースが更新されます。




使っているレスポンスフィールドは5つ。

  1. 【Category】〜トピックが所属するカテゴリ(国内、海外、経済、エンターテインメント、スポーツ、コンピュータ、サイエンス、地域のいずれか)です。
  2. 【Title】〜トピックの見出しです。ない場合は表示されません。
  3. 【Overview】〜話題の単位であるトピックについての数十文字の簡単な説明です。
  4. 【HeadlineId】〜トピックの見出し(Title)に対応するIDです。
  5. 【SmartphoneUrl】〜スマートフォン最適化ページのURLです。
トピックス毎のURLがなぜかどのフィールドも完全ではなかったので、SmartphoneUrlの後にHeadlineIdをアペンドすることで対応しました。

メール送信のスクリプトはいつもの通りです。Googleスプレッドシート内でトリガーを設定します。その際に必ず更新用のスクリプト(parseXml関数)とメール送信用スクリプト(sendemail関数)の両方のトリガーを設定することを忘れないでください。






2014年4月9日水曜日

【Google Apps Script】7. アマゾンの書籍ベストセラーランキングを取得する(JSON形式)

前々回、前回はXML形式のデータを取得する練習をしましたが、今回はJSON形式のデータを取得する練習をしようと思います。

アマゾンでお買い物をする人は多いと思いますが、アマゾンのショッピングカテゴリの売れ筋ランキングはすべてRSSで提供されていて、最も下の階層まで絞ることも可能です。


例えば【書籍】カテゴリを例にとります。

Amazonランキング - 本のベストセラー
http://www.amazon.co.jp/gp/bestsellers/books/ref=sv_b_3

こちらから好きな階層を選ぶことができます。私のビジネスに関係がある【本 > ビジネス・経済 > マーケティング・セールス】のランキングを毎日更新してメール送信するようなスクリプトを作ろうと思います。

今回ですが、Google Feed APIを使ってRSSをJSON形式で受け取って処理する方法を取ります。実際にやってみると、XMLのままで処理するよりも比較的楽に組むことができたと思います。

前回同様、関数は3つです。
onOpen(e)で独自メニューを追加します。
UrlFetchAppでJSONデータを取得後、今回初めて取り上げるjsonParseでパースし、スプレッドシートにデータを展開します。
sendemail()で、展開したデータを、指定したメールアドレスに送信します。

 【サンプルコード】 サンプルコードはこちらです。シート名は「Amazon」に変更してください。

そもそもGoogle Feed APIは、パブリックなatomやRSSフィードをJavaScriptを使って取得しようとした場合、Same-Origin Policyの制限によってドメインが違うサイトのデータは取得できないという問題を解決し、クライアント側で処理できるようにするための便利な仕組みです。結果の出力をXMLでもJSONでも選択できるので、JSON形式に変換するツール的に使えます。URLはこのようになります。
https://ajax.googleapis.com/ajax/services/feed/load?v=1.0&q=http://www.amazon.co.jp/gp/rss/bestsellers/books/492064/ref=zg_bs_492064_rsslink&num=10
上記リンクをクリックしてもらうとJSON形式になっているのがわかると思います。印象としてはXMLよりもJSONのほうがデータが軽いし、コードを組む際に属性の階層が深いデータを指定するのはJSONのほうがシンプルでずっとやりやすかったです。

最後の&num=10はオプションで、10件表示するという指定です。

実行すると、スプレッドシートでこのようにデータが展開されます。シンプルに、ランキング付きの書籍タイトルとURLだけの構成になっています。

AmazonアソシエイトのIDを持っていて、用途によってURLに反映させたい場合(データをアフィリエイト利用したいなど)はサンプルのようにsetvalueをする際に&tag='AmazonアソシエイトID'という形で引数を付与するようにします(今回はサンプルなので付けてみました)。

Googleのスプレッドシートのトリガー機能で実行時間を設定してメールを自動送信するようにします。アマゾンのフィードは1日の中でも何度も更新しています。私の場合は朝一でメールを受信するように設定しています。

変化が激しい昨今の広告・マーケティング業界なので、読むべき書籍のアンテナを張るのには便利なツールになっています。よかったら使ってみてください。

2014年4月7日月曜日

【Google Apps Script】6. ヤフーの検索ランキングを取得する(XML形式)

前回は英語ブログのRSSフィードを取得する練習をしました。今回はもう少しマーケティング活動に近いデータを取り扱ってみようと思います。

ヤフーが検索行動に関するデータをいくつか公開していますが、その中の「総数ランキング 総合(デイリー)」を取り上げたいと思います。これはヤフーで検索されるすべてのキーワードの日々のトップ20をランキングにしたものです。

Yahoo!検索データ 総数ランキング
http://searchranking.yahoo.co.jp/total_ranking/general/

取得方法は前回の英語ブログの取得の際に使ったスクリプトとほぼ同じなのでコピペ・編集で概ねいけますが、今回は一部のXMLデータ取得の際に名前空間を指定する必要があるので、少々難易度が上がっています。それ以外は同じです。

前回同様、関数は3つです。
onOpen(e)で独自メニューを追加します。
parseXml()で、XMLデータを取得、パースし、スプレッドシートにデータを展開します。
sendemail()で、展開したデータを、指定したメールアドレスに送信します。

【サンプルコード】
サンプルコードはこちらです。前述の通り、一部のXMLデータでrankingという名前空間を指定しているので、それを処理しないといけません。
var ranking = XmlService.getNamespace('ranking', 'http://searchranking.yahoo.co.jp/ns/ranking');
というコードを加えました。getChildメソッドで指定した属性データを取得する際に、オプションで名前空間名を指定すれば取得できるようになります。

このフィードでは親切に、前回順位と変動(トレンド)もデータで提供してくれているので、前回と最新の比較処理などが必要ありません。そのまま使うことにします。ただ、トレンドに関してはデータ上は"stay","new","down","up",と英語なので、一旦E列に展開し、スプレッドシート上のsubstitute関数を使ってD列に、"変化なし","新登場","下降","上昇"として変換して展開する処理を加えています。コードでこのあたりもやったほうがキレイだという意見もあるでしょうが、ここはスプレッドシートを併用するメリットを解説するためにもこうしました。

また、これもスプレッドシート上の機能を使って、条件付き書式で、"新登場"の場合はグリーン、"下降"の場合はレッド、"上昇"の場合はブルーにテキストカラーを変化させるようにしました。

メール送信機能は今回も加えました。私はこのデータは毎朝8:00に受信するようにトリガーを設定しています。上位5位までのキーワードはさほど変動はないですが、それ以下は新しいキーワードが入ってきやすいので、トレンドが把握できます。

また、今回もスプレッドシートのメニューに関数を加えているので必要な時にスプレッドシートの結果を更新したり、メールすることもできるようになっています。
ちなみにヤフーからRSSで提供されている検索データはいくつか種類があるので、好きなものを取り込んでみるのもいいと思います。
http://searchranking.yahoo.co.jp/rss/

以上です。RSSの取得については、もう何度かやっていきます。

2014年4月5日土曜日

【Google Apps Script】5. ブログのデータを取得する(XML形式)

今、シリコンバレーにきてまして、Google本社、Facebook本社に訪問しています。かなり刺激を受けてきたので、こちらのプロジェクトの意欲も高まっています。ということで、気分を高める意味も含め、今回はFacebook本社近くのカフェでこのブログを書いています。

そろそろ実践に入ろうと思います。ひとまずこのシリーズはマーケティングに役立つダッシュボードを作るのが目的なので、さまざまなデータを取得してGoogleスプレッドシートに展開することをこなしていこうと思います。

atom形式のブログRSSの最新データを取得し、GoogleスプレッドシートにタイトルとURLを展開します。そして、定期的に指定したメールに送信するというスクリプトを作りました。まずは英語の勉強に使うブログ(http://www.eigowithluke.com/)で練習です。

関数は3つです。
onOpen(e)は、Googleスプレッドシートのメニューに作成した関数を実行できる独自メニューを追加します。これは今後作成するスクリプトでも活用していきますので、いつでもコピペ利用ができるようにしておきます。

parseXml()は、RSSからXMLデータを取得、パースし、指定した属性の値を取り出し、スプレッドシートに展開します。

sendemail()は、スプレッドシートに展開したデータをコピーして、指定したメールアドレスに送信します。

サンプルコードはこちらです。特に編集しないと使えない箇所は1点だけ(宛先メールアドレスだけ指定してください)。そこだけを編集すれば、ご自身のGoogleスプレッドシートのエディターにコピペしてもらえれば使えるはずです。 細かくコメントアウトで解説をつけたので、なるべく解読しやすくしたつもりです。パースできる形式はXMLのみならずJSONでもありますが、JSONは別のサンプルで取り組みたいと思います。

すべてのコードを保存した後(実行する際に一度認証が入ります)は、スプレッドシートを開くたびに、onOpen(e)で指定した独自メニューが表示されます。


メニューのRetrieve Dataを選ぶとデータ取得が行われます(エディターから関数を実行することももちろん可能です)。
UrlFetchAppクラスを使うことで外部データの取得はかなり楽にできます。XmlServiceもアップグレードはかなりできることも増えたのでパースもより便利にできるようになりました。


Send Dataを選ぶとスプレッドシートに展開された部分をコピーして指定したメールアドレスにメッセージとして送信されます。






さて、Google Apps Scriptの便利なことの一つにトリガーを設定することができることです。エディターにあるメニューの「現在のプロジェクトのトリガー」を選ぶと、時間やアクションなどの条件に合致した際に関数を実行させることができます。僕の場合は「データ取得を毎月14日と28日の6-7時の間に実行し、その後7-8時の間に最新のデータをメールに送信する」と指定しています。

普通にRSSリーダー的に使うこともできますが、XMLで公開されている有益な外部データは多いので(API経由で取得するデータもXMLであることが多いです)、Google Apps Scriptでさらに自動化をすることで、マーケティング活動に役立つデータを収集することが可能です。これは今後取り上げていきます。今日の練習はここまで。

2014年3月27日木曜日

【Google Apps Script】4. 参考となる講座や書籍、ウェブサイト

Google Apps Scriptの習得のために参考となる講座や書籍は今はあまり多くありません。JavaScriptから入ればたくさんの講座や参考書籍、ウェブサイトがありますので、まずはそれがいいかもしれません。実際私はJavaScriptとGoogle Apps Scriptを同時に習得しようとしていますが、2つ同時よりもJavaScript優先をオススメします。




まず、講座はドットインストールがオンライン動画講座を設けています。細かく内容が分かれてて、ストレスなく受講できますし、実践的な内容です。


ドットインストール(オンライン動画講座)
Google Apps Script入門 (全16回)
http://dotinstall.com/lessons/basic_google_apps_script

参考書籍ですが、


Google クラウドスクリプティング Google Apps ScriptによるGoogleパワーアップ活用ガイド
http://goo.gl/w7JF92
レファレンスガイド的な内容です。






Google Apps Scriptクイックリファレンス
http://goo.gl/xv92Jw
もっとも網羅したレファレンスガイドです。逆引きガイドの決定版。







Google Appsでつくる仕事便利ツール ~Google Apps Scriptで実践構築~
http://goo.gl/29Pk9Z
こちらはいくつかの仕事で仕えそうなサンプルコードを中心に解説しています。









ウェブサイトですが、こちらもまだGoogle Apps Scriptを取り上げているところは少ないです。

初心者のためのGoogle Apps Scriptプログラミング入門
http://libro.tuyano.com/index3?id=623009
こちらは一番参考にさせてもらっています。

Google Apps Script Examples
https://sites.google.com/site/scriptsexamples/
こちらは海外では書籍「Google Apps Script: Web Application Development Essentials」の著者が運営しているサイトが参考になります。


海外では比較的多くGoogle Apps Scriptのサイトやサンプルコードがあるので、検索してみてください。

2014年3月26日水曜日

【Google Apps Script】3. デバッグ環境

Google Apps Scriptは取り組んでいけばいくほど奥深くて面白いのですが、コードを書いて、一発で完成という域にはなかなか達するものではないかと思います。といいますか、人間ですので・・必ずミスは発生すると思ったほうが無難です。

そのために、Google Apps Scriptのエディタにはデバッグするための機能がいくつか標準でついています。

例えば、Googleカレンダーの今日の予定数を教えてくれるプログラムを書いたとします。




サンプルコード(// の行はコメントなので実行されません)
-----------------------------
function myEventstoday() {
    var today = new Date();
                 // 現在日時を取得します
    var events = CalendarApp.getDefaultCalendar().getEventsForDay(today);
                 // カレンダーに登録されている今日のイベントを取得します
 Logger.log('本日のイベントの数: ' + events.length);
                 // イベントの数をログに出力します
}
-----------------------------

こちらをコピペしてもらい、実行すれば恐らく問題なく動作します。あ、その前にログって何ということがあると思います。開発者の方には当たり前のものなのですが、意外とそのへんの説明が何を調べてもなにかと不親切でw・・。

Google Apps Scriptのドキュメントを見ると、クラスloggerの概要説明は"This class allows the developer to write out text to the debugging logs."とありますので、「この(logger)クラスを使うことで、開発者はテキストをデバッグ用ログにテキストを出力することができます」ということになるかと思います。

そもそもログの目的はいろいろありますが、Google Apps Scriptの中での主な目的は、
  • プログラム内部の動きを調べる
  • プログラムなどの処理や動作の過程を記録する
  • スプレッドシート画面などを使って伝えることができないメッセージを伝達する
あたりかなぁと思います。


で、スクリプトを実行した後で、メニューの「表示」→「ログ」を選んでいただくと





こんな感じでログに出力されたかがわかります。これはGoogleスプレッドシートを起点にしていますが、そもそもスクリプトだけが独立して存在するということもありえます。



Google Appsの新規作成メニューの中にスクリプトってありますよね。こういう場合は特に、途中の動作を確認する上でもログ機能は必要になりますね。











同じような機能で実行トランスクリプトがあります。メニューの「表示」→「実行トランスクリプト」を選んでください。ログは最終的なテキストの出力結果のみですが、実行トランスクリプトは、スクリプト実行時の各メソッドの 実現の様子を記録したものになります。

仮にスクリプトにバグがあった場合、まずは画面上部に赤色で表示が出ますが、「ReferenceError: 「s」が定義されていません。(行 5、ファイル「コード」)」のように、コードのどこに問題があるのかを指定してくれます。エディタに戻って該当する行を直せばOKです。
あとは実行トランスクリプトの中でも同様に問題箇所を提示してくれます。

最後にデバッグ機能があります。虫マークのボタンをクリックするとデバッグモードで実行され、問題箇所がハイライトされます。あと、下の部分に各定義や取り込んだデータの構造(例えばXMLデータなどの)がわかるようになっているので、デバッグだけではなく、コード作成中にも重宝する機能です。ただ、コードに問題がない場合はデバッグ画面は起動しないので、どうしても見たい際はわかりやすい余計な文字などを挿入してデバッグ画面が出るようにしています。

ということでブラウザだけでこういう環境が準備されているので、取りかかりやすいなと思う次第です。