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

ku-sukeのブログ

Just another hatena blog

スマートフォンアプリマーケティング 現場の教科書を執筆しました

 いよいよ来週6月1日発売となります。すでにお友達や会社の皆さんから予約したよ!といっていただきありがたい限りです。表紙はアイロンビーズクリエイターのヌン氏に作成いただきました。かわいい!

スマートフォンアプリマーケティング 現場の教科書

スマートフォンアプリマーケティング 現場の教科書

 

 法人の方、複数冊購入の方はAmazonが一時的な売り切れ多いので紀伊国屋などもご利用ください。

スマートフォンアプリマーケティング 現場の教科書 / 丸山弘詩 - 紀伊國屋書店ウェブストア

これはどんな本?

アプリ開発者やディレクター、プロデューサーおよび、マーケティング担当者向けの、アプリの制作運用マーケティングがまるっと分かる本です。また、アプリをこれから作ってみたい学生さんやアプリのハッカソンを運営する方にもぜひ読んでいただきたい内容となっております!

目次:

Chapter 1 アプリを取り巻く市場環境
Chapter 2 アプリ制作・運用の基礎知識
Chapter 3 企画の立案
Chapter 4 マネタイズ
Chapter 5 アプリの設計
Chapter 6 プロトタイピング・モック検証
Chapter 7 開発ディレクション
Chapter 8 開発・デザインツール
Chapter 9 ストアへの提出
Chapter 10 公開時のプロモーション
Chapter 11 運用データの取得
Chapter 12 運用データの活用
Chapter 13 メンテナンスとサポート

調査して、企画書いて、ビジネスモデル決めて、設計して、UX調査して、プロトタイピングして、開発して、提出して、プロモーションして、運用して・・

 

ひとつひとつの情報やテクニックはWebで探せば出てくるかもしれませんし、上級者にはアプリマーケティング研究所さんとかのディープなネタのほうが参考になるかもしれません。

それでも、現場に出ると全体像を把握している人っていうのは意外と少なくて、書籍というパッケージング化されたメディアで「体系的に」やるべきことや気をつけるポイントを解説する価値はあると考えました。まさに現場の教科書として新しくスマホアプリ事業に携わる方や今さら聞けない基礎知識を身に着けたい方に手にとっていただきたいです。

実は第三弾です。

f:id:ku-suke:20160516010249p:plain

 

2011年と2013年にiPhoneに特化したマーケティング本をリリースしていました。黎明期の2011年、市場が成熟し始めた2013年と変化の激しいスマホ業界に対応しながら書いてまいりました。

今回はAndroidにも対応しました。共著者は前回に引き続き丸山氏と、第二弾も制作協力いただいたフェンリル株式会社の荻野氏のお二人です。前作への評価もなかなか良いようです^^。

 

f:id:ku-suke:20160516010526p:plain

 

どんなことを書いたの?

 基本的にはできるだけ広範囲をカバーしようと書いたのですが、例えば(学生含む)エンジニアの方におすすめしたいのは企画〜UXのあたりです。

広く書くというのは悩ましいもので、たとえばUXひとつとっても、カスタマージャーニーマップの作り方だけで本が1冊かけてしまうようなジャンルなので、できるだけ例を入れて「見よう見まねで」始められることを意識しました。

 

個人の方であればまずやってみることで「うーん、これは思いつかない、、実はユーザーは求めていないのでは、、」と気づきを得られますし、 大きなチームに加わる方であればカスタマージャーニーマップはすでにあるでしょうから、その活用方法がわかります。

 

ほかにも、リーン開発(こちらも壮大なテーマですが・・)に触れたり、SketchやZeplin、Prottなど人気ツールの紹介もしてあります。このあたりもすでに現場で活用されている方からすると読み飛ばしても良いポイントですが、新しく加わる方に「ここ読んどけ」と渡して基礎知識習得の時間短縮に使っていただければと思います。

 

というわけで、2016年6月1日ごろ発売予定です!

ご予約は今すぐAmazonにて!早い方には31日に届くかも 

スマートフォンアプリマーケティング 現場の教科書

スマートフォンアプリマーケティング 現場の教科書

 

 謝辞

書面の都合上書ききれなかった方や、川畑に個人的に協力いただいた皆様にもこの場で改めて御礼を申し上げます。スマホアプリの環境のうつりかわりが激しく掲載を見送ったり、また広く体系立てて内容を扱うために泣く泣く削った企画もありました。それでも、皆さんがいなければこの本はできませんでした。エッセンスや考え方としてできるかぎり取り込んだつもりです。

最後に、川畑の遅筆(という表現が憚られるほどの。)にお付き合いいただきました関係者の皆様、ラストスパートで家の予定そっちのけで作業をする僕を支えてくれた妻と息子に感謝いたします。本当にありがとうございました。

 

リクルートマーケティングパートナーズに入社しました。

というわけで、1/18より京橋駅グランシャトーがない方)付近におります。

お仕事内容ですが、受験サプリをはじめとするラーニングプラットフォーム推進室というところで、(受験サプリではなく)新規をやります。

職種はUXデザイングループというところでプロダクトオーナーになります。しばらくは開発ディレクションも手伝います。

ご指導ご鞭撻のほどよろしくお願いします。

 

 

落ち着いたら飯行きましょう!な方、こちらで予定を個人的に管理しますので、各種メッセにてお誘いいただけるとありがたいです。R社員の皆様もお誘いお願いします。

chouseisan.com

振り返りとご挨拶-2015年12月-

2015年12月を最終出勤とし、現在の会社を退職いたします。在職中はたくさんのご支援を頂きまして、誠にありがとうございました。

在職中は公私を通じてたくさんの才能と出会い、刺激的な4年間を過ごしました。人間としてどこか欠落していた自分も人間らしさを少し身につけられた気もします。終わってみると、とても寂しくて、感傷的になってまだ冷静に振り返ることができません。

(エントリタイトルをつけるときはがっつり振り返る気まんまんでした・・)

 

アプリエンジニアとして入社し、企画、ディレクションとサービス作りを一通りさせていただき、大阪拠点をたちあげて、小さな組織でしたがマネジメントも経験させていただきました。

後半は広告代理店部門に異動し、デジタルマーケティングの仕事に携わる中でやりがいと成果が両立し、この仕事ならおっさんでも若いもんに負けず頑張れるわ!と自分へのキャリアにとって自信を深めることができました。また何年後か、いつかはマーケの世界に戻ってきたいと思っています。

 

次はまた事業にチャレンジ*1すべく東京にゆきます。また練馬区に住みますです。

 

年齢が上がるということと、家族を持ち子を育てるということは、人生の掛け金が上がってきているなと感じます。そう簡単に飛び込めない度合いがあがってるなと。

今回の東京行きに関しても、住み慣れた土地や友人たちと離れることはとてもさみしいし、特に小学生の息子はせっかく出来た友達とお別れし寂しい思いをさせてしまいました。

支えてくれる家族のためにも、また、一緒にやってきた仲間に恥ずかしくない成果を挙げれるよう、2016年は「やるしかない」の精神で進んでいく所存です。

 

割と頻繁に心折れる可能性もあるので、みなさんぜひご飯に誘ってくださいw

で、誰?という暖かなブコメもお待ちしております。

*1:独立しないの?と今回も聞かれましたが、もう少しサラリーマンのメリットを享受したいと思います。次の会社も一定のルール内で副業できるので、講演や顧問などは引き続きお受けできます。

ペコッターで12月金曜の夜のお店予約が超絶楽ペコ

便利すぎてキャラ崩壊しましたこんばんわ。

みなさん、飲んでますか。幹事の皆さん、がんばってますか。あと今年も10営業日くらいしかないですよーーーー

金曜の店選び&予約がペコッターで超絶楽だった

金曜の飲み会のお店を決めるのをついつい放置してて、いやーそろそろ決めないと・・と思ってる時に、ペコッターが面白いみたいなので使ってみましょうよという流れになり代表して僕が使ってみました。

f:id:ku-suke:20151210230515p:plain

こんな感じで、最初のレスは2分後くらい、2件目も5分以内にレスが有りました。スペインバル、イタリアン×お野菜てきなところだったので、日本酒か焼酎にあうところも〜とこのUIに精一杯しゃべり方を合わせてコメントすると、追加で豆腐のお店もおススメいただきました。

 

ペコッターすごいね~この中でどれにする?ということで、最初にレコメンドされたスペインバル行こーぜとなりまして、予約を依頼しました。

どこのコンシェルジュだよ!レベルのチャット予約

結論からいうと、スペインバルは12月の金曜夜ということで、満席でした。でもそこからのリカバリがすごかったw

f:id:ku-suke:20151210232642p:plain

すかさず他におすすめされた2件も電話してくれた。そして満席だったぺこり。でもそこからのリカバリがすごい!

f:id:ku-suke:20151210233939p:plain

すごい、お隣にあるとかなんなんだその情報w

Androidアプリがないのが残念なぐらい12月の金曜日に最高のサービスでした。上司から「いい感じの店探しといて」と言われた皆さん、ペコッターにまるなげしましょう。投稿・質問はiOSアプリからのみっぽいです。

pecotter.jp

 

※なおステマではありません

f:id:ku-suke:20151210234729p:plain

 

Web屋がWordpressで消耗しないCMSを考えてみた

 最近ちらほら、Wordpressキツイよねという話がWeb屋さんの知り合いからよく耳にする機会があるように感じます。というか、僕自身コーポレートサイト製作の案件とか相談された時に、Wordpressはちょっとないなと思っちゃいます。(まぁ予算があったり規模がデカければ普通に商用CMS使いますが。)

そんななか滋賀の渚さんが虚構新聞のサイトとアプリをまるっとリニューアルして、すんごく薄いCMS?的なものを作られていたので影響されて考えをまとめてみました。 

Wordpressが嫌になるシチュエーション

だいたい、昔の静的サイト制作のノリのままCMS化が進んでWordpress使いやすいよね~で流れてしまった挙句、バージョンアップや脆弱性対応でつらい目にあってWordpressやめたくなってるんだと思います。

そもそもの前提として

  • コーポレートサイトとか、基本静的ページでもギリ行ける内容。
  • でも、お知らせ更新とか問い合わせフォームとかちょこっと動的。
  • スマホでアクセスしたらスマホ版でみせたい。
  • 保守は請け負っていない、顧客も予算とってない。
  • 3−5年くらいは使用されることが予想される。
  • サーバは安い共用

というかんじだと思うんですよ。

じゃあどういうのがあればいいか

裏返すと、以下の様なCMSがあれば良いなーと個人的に思うわけです。

  • めっちゃシンプル。PHP10ファイルくらいで出来てる。
  • テンプレートは制作会社で作るので10個くらい主要なタグ(現在のURL取得とかogタグ各種組み立てられるくらい)が使えればいい。
  • なんだったらデータベースなくても動いてくれていいかも。
  • クライアントが新着情報を更新するくらいのWysiwyg管理画面はほしい。画像やPDFの添付くらいは必要。
  • ユーザエージェントでスマホ版には切り替えてほしい。
  • 勝手にバージョンアップしないで欲しい。
  • バージョンアップしなくても脆弱性とかないようにしといてほしい。(すくなくとも外部からアクセス可能な記事表示部分は。制作会社に責任が発生するという意味で。)
  • プラグインとかで拡張しなくていいのでシンプルを保ってほしい。拡張したければ制作会社がカスタマイズ費とって改造するし。
  • ロリポップ/minibird等のレンサバでFTPアップで動くこと。黒い画面禁止。
  • スマホアプリも今度作るかもなのでJSON APIも吐き出してほしい。

いかがでしょうか。PHP製の軽量CMSを幾つかあさってるのですが、まだこれといったものに出会えていません。SoyCMSとかbaserCMSもいいのですが、もっともっと薄いものを探しています。

 

例)Monstra

monstra.org

例)kirby

getkirby.com

 

ほかにもPico,getSimpleなどあるのですが、これらは結構似通っていて、Markdownベースだったりします。クライアントにMarkdown書いてっていうのもなぁ(Aceエディタとかあるけども)と思って、あまり深入りしていません。これくらいのシンプルな薄いCMSで、gitとmarkdownがなくても使えるものがあったらぜひ教えて下さい。

 

虚構新聞/虚構新聞社公式アプリ

虚構新聞/虚構新聞社公式アプリ

  • NagisaWorks, K.K.
  • ニュース
  • 無料

 

爆速モバイルWeb、AMPの仕組み抄訳

鈴木さんの記事を読みましてAMPの仕組みについて読んでみました。以下抜粋して日本語メモを。

モバイルウェブが爆速に! GoogleがAMP (Accelerated Mobile Pages) を立ち上げ | 海外SEO情報ブログ

 

追記:ざっくり言うと、主にニュースとか静的コンテンツを想定し、HTML+CSSでJSは原則禁止、広告とかで使いたい場合iframeを用意するのでその中だけ。iframeや画像は事前にサイズを固定し変更不可にすることでlazyloadしてもレンダリング時にガタガタしないよね。というAMP HTMLフレームワークを策定したお話です。

 

原文:https://www.ampproject.org/how-it-works/

モバイルのための仕組み

(※見出しは筆者による)

Web performance is not unexplored territory for the tech community: books have been written about it, many talks have been given – there is even an entire conference series dedicated to the topic. However, users still frequently see poor web performance in the wild, particularly on mobile devices. 

Consumption of news articles, and similar relatively static content, is often painfully slow, with pages taking a long time to load. Even after text becomes visible, pages continue to build up over many seconds, as ads and images come into display. The result is an often jarring experience of janky scrolling and users needlessly losing their reading position.

中略

To make the web fast at scale, we want to make it easier to create documents that are fast-by-default.

 ウェブパフォーマンスは、技術コミュニティにとって未知の領域ではなくなったものの、ことモバイルウェブにおいてはまだまだ荒削りの状態です。ニュース記事を読むにしても、テキストが表示されてなお画像や広告を読み込むためにページの構築は何秒間も続きます。その結果ユーザは読むために不毛なスクロールと耳障りな経験をします。

そこで我々はWebを高速にスケールさせるために、デフォルトで高速なドキュメントを作りやすくしたいと考えました。

対象は静的コンテンツのみ

The web today is many things: an application platform, an e-commerce platform, a content platform, a gaming platform, and so much more. We decided to focus entirely on static content 

いまウェブはEC、プラットフォーム、ゲームなど様々なものでできているので、その中で容易に適用できる静的コンテンツに集中することに決めました。

 

We began to experiment with an idea: could we develop a restricted subset of the things we’d use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance? That experiment has culminated in a promising proof of concept we call Accelerated Mobile Pages (AMP). AMP HTML is built on existing web technologies, and the documents written in it render in all modern web browsers and web views. 

我々はHTMLのサブセットを開発し高速で表現力豊かな、そして信頼できるパフォーマンスを実現できるか検証し、AMPと呼ばれるコンセプトを実証しました。

AMP HTMLは既存のWeb技術で作られているため、すべてのモダンブラウザやWebViewで適切にレンダリングされます。(※翻訳元のページ自体がAMP HTMLで記述されています)

We think AMP HTML is promising, but we know it's not complete. We are sharing our proof-of-concept on GitHub to start a conversation about how to make static content on the web fast.

AMP HTMLは有望だと思いますが完全ではありません。ぜひgithubページをみて静的コンテンツを(モバイル)ウェブ上で高速にする方法について議論しましょう。

JavaScriptについて

One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.

私達が早くから認識していたパフォーマンス問題の一つに、ページ内に埋め込まれる多数のJavaScript(ライブラリやツール等)があります。

JavaScript=パフォーマンス低下というわけではありません。しかし任意のJavascriptを実行させるとパフォーマンスの保証を行うことが非常に難しいため、難しい決断でしたがAMP HTMLは一切のJavaScript(自信が書いたものもサードパーティ製のものも)を含めないことにしました。

JavaScript is the core building block for advanced web apps, but for static content it may not always be required

中略

But the web platform has a great solution: custom elements and web components. AMP components may have JavaScript under the hood, but it is coordinated with other AMP components, so its composition into the page doesn’t cause performance degradation.

JavaScriptは先進的なWebアプリにとって中心をなすものですが、必ずしも静的コンテンツに必要ではありません。(投票などの機能を用いている記事はあるものの)ウェブプラットフォームにはカスタム要素とweb componentがあります。AMPコンポーネントの中にJavaScriptを用意しています、他のAMPコンポーネントと協調して動作するためパフォーマンスの低下を引き起こしません。

So, AMP HTML comes with strong limitations on JS. What about CSS? AMP HTML loves CSS! We do add some best practice enforcement, but we do want AMP HTML documents to look like their authors intended them to, and so allowing extensive styling is core to the platform.

AMP HTMLがJSに強い制限を加える一方、CSSはどうでしょうか。AMP HTMLはCSSが大好きです!いくつかのベストプラクティスを用意しましたが、AMPページで制作者の表現をぜひして欲しいので、スタイルの許可をプラットフォームのコアとして据えています。

広告とアクセス解析は?

Ads and analytics – while critical for publishers – are a big part of the performance problem and so they must be a big part of the solution.

中略

AMP HTML does not allow this. We realize that both ads and analytics are an important element of monetization on the web, and so we need to support them: our goal is to realign monetization with great user experience.

パブリッシャーにとって、広告と解析がとても重要であることは理解しています。(広告や解析は様々なタイミングでJSを実行しますが)AMP HTMLではそれらを許可しません。解析や広告がウェブでの重要なマネタイズ手段だと認識しているので、我々はそれをサポートする必要があります。私達のゴールは素晴らしいユーザ体験とともにマネタイズを再編成することです。

AMP HTML is taking the following approach to analytics: so-called “tracking pixels” can be embedded into AMP documents as long as they don’t use JavaScript. They typically come with a noscript version that makes this easy. More advanced analytics are currently not supported. Our vision is to deploy a single, unified, auditable, high performance, open source analytics library with AMP HTML that can report to various existing analytics provider backends, so it is possible to use the existing ecosystem without overloading a page with analytics software. 

 AMP HTMLでは、従来noscriptタグとともに用いられていたような解析ピクセルを使用して下さい。それ以上の高度な解析は現在サポートしていませんが、AMP HTMLが従来と同様の解析を出来るようなオープンソースライブラリを提供したいと構想しています。

instead they live in sandboxed iframes with no access to the primary document. 中略

We also prioritize ads lower during loading than other content and optimize load timing to avoid jank. Ads in AMP files can still be heavyweight, so there is still a lot of work to do for us. 

 (AMP HTMLはJSが利用できませんが)代わりにサンドボックスiframeに広告を表示できます。iframeは優先度低くロードされることでページロードを阻害しません。iframe内の広告自体に関しては、まだまだ高速ではないため私たちは多くのことをする必要があります。

速度について

So, how fast is AMP HTML? Pretty fast. In a sample of pages our early partners created we are seeing performance improvements measured through Speed Index between 15% and 85%. This was measured with a simulated 3G connection and a simulated Nexus 5 device.

それで、どれくらい速いのでしょう?めっちゃ速いで。SpeedIndexを使用してNexus 5の3G回線で計測したら、15%~85%位早くなりました。

But how do we get from good to, let’s say, instant? We’ll cheat :) AMP documents are from the ground up designed to be efficiently pre-renderable. Browsers have long supported pre-rendering through the <link rel=prerender> tag, but they need to be conservative about this mechanism because prerendering can be expensive. With AMP HTML we added the ability to tell a document: render yourself, but only as far as what is visible above the fold and only elements which are not CPU intensive to minimize the cost of pre-rendering. With this mechanism in place, referrers of AMP document can initiate rendering of docs before the user acts much more aggressively, so that in many cases the document will be done rendering by the time the user clicks.

でも、どのように実現しているのでしょうか。私たちはズルをしました。AMPは事前にレンダリングしやすいようにデザインされています。各ブラウザは<link rel=prerender>タグを実装していましたが、処理が重くあまり利用されてきませんでした。AMP HTMLは、ブラウザ自身がレンダリングするもののファーストビューができるだけ早く、かつCPU負荷の高くないものという条件でプレレンダリングするようブラウザに伝えます。このため、多くの場合でユーザがクリックする前にドキュメントのレンダリングが完了しているのです。

With all of these techniques in place, AMP HTML documents can be loaded with a small set of HTTP requests: the document itself, custom fonts (if used) and what we call the AMP JavaScript library that implements the AMP custom elements and resource loading. 

これらのテクニックを適切にするため、AMP HTMLは少数のHTTPリクエストでロードできます。ドキュメント自体、カスタムフォント(使う場合)そしてカスタム要素やリソースをロードするためのAMPライブラリと呼んでいるものです。 

Our goal with AMP HTML is reliable performance, so we designed it to be easily cacheable by content delivery networks (CDNs). Google is offering a service that delivers AMP HTML documents given their URL through its CDN. Others can use this service or make their own or serve AMP HTML pages from a plain-old-web-server.

信頼できるパフォーマンスを達成するため、CDN経由でキャッシュ可能な配信できるようにしました。AMP HTMLはGoogleが提供するCDN経由で配信することができます。もちろん自身のサーバからでも、普通の古いサーバからでも配信することが可能です。

レイアウトを事前に定義

This brings us to the final topic that makes AMP HTML unique: all resource loading is controlled by the AMP library and, more importantly, resources must declare their sizing up-front. 

This doesn’t mean that resources can’t be responsive – they can be, but their aspect ratio or dimensions needs to be inferable from the HTML alone. This means that after initial layout, an AMP document does not change until user action.

中略

This gets us lazy loading with zero visual jank.

 

 最後に、AMP HTMLを特徴づけている点について。すべてのリソースは、事前に自分のサイズを定義しておかなければなりません。

これは、レスポンシブデザインに対応していないという意味ではありませんが、縦横比やサイズを初期ロードのタイミングでHTMLから読み取れるようにしておく必要があります。AMPページは初期レイアウトされてから、ユーザがアクションするまでレイアウトが変化しません。(広告であっても固定の枠からサイズ変更を許可しないので)非同期でリソースを読み込んでもページがガタガタとレンダリングされることがありません。

To summarize: AMP HTML is a specialized subset of HTML with custom elements that provides reliable performance and instant loading of static content. Nothing about the project is set in stone.  

中略

See you over on GitHub!

 まとめ:AMP HTMLはHTMLのサブセットとカスタム要素で出来ていますが、まだなにも確定はしていません。See you over on GitHub!

=================

ということで、HTML+CSSでシンプルなページを用意し、JSを禁止し、画像や広告の表示サイズを事前に固定することで、高速ロード、高速レンダリングかつ読みやすくなるよね!ということのようでした。Googleが参加するということでWeb界隈の人は抑えておいたほうが良いと思います。

iOS 9の各種ブロック率をGAで解析する方法

先のエントリで、検出テストをやってみたのですが、だいたい仕組みとかがわかってきたのでfuckadblockに頼らないお手軽対策をやってみたいと思います。

 

一応傾向値だけは知っときたいなと思って、設定してみました。これでほぼGAのブロック率は計測できるんじゃないかなと思います。

<script type="text/javascript" src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
<script type="text/javascript">$(window).load(function(){
if(typeof window.ga.loaded == "undefined"){$("#header").append("<img src='http://example.com/analytics.php' />");}
}
);</script> 

 本来windowのロードが完了した時点では、gaのロードが概ね終わってるはずなので、そのタイミングに引っ掛けてwindow.ga.loadedプロパティの有無を調べるという方法です。

これで検出できた場合に、自分のドメインに設置したGAにサーバサイドでページビューを送信するスクリプトを読ませるようにします。Universal Analyticsをガラケーサイトに対応させるためのスクリプトみたいな感じです。

gist954e13443c2dc1982f3b

いちおうCookieでユニークユーザを計測できるようにしつつ、IPとUserAgentだけ送信しておきます(仕組み上GhosteryみたいなPC用のブロッカーも反応するので。)

ちゃんとやる場合はページパスも渡すようにしてもいいのですが、今回は傾向値を掴みたいだけなので固定パスでpageviewを送ります。ここは好みに合わせて、埋め込み元からパスやタイトル情報を渡したり、eventで送信してもいいですね。詳しくはMeasurement Protocolを読みましょう。

 

この方法で、GAのBlock率を計測することができます。なお、24時間での実験結果ではこんだけBlockerの記事書いててもGAブロック率7%程度でした。

 

広告屋さん向けに書いておくと、GTM/YTMなどのブロック率検知も同様に行えます。

GTMなら、window.google_tag_managerとか、YTMはちょっとわかりやすいパラメータが見当たらなかったのですが、window.BrightTag.V2_RESPONSEとかですかね。

PCでテストする場合は、Ghosteryの拡張でオン・オフしながらChromeのコンソールでconsole.dir(window)として、ブロック時と非ブロック時で違いが検出できそうかつwindow.loadイベントのタイミングで拾えそうなものを選びます。

 

ちなみに、解析用スクリプトはadとかanalyticsっていう単語を入れると引っかかる可能性があるので、自ドメインで無関係そうなファイル名にするのが無難だと思います。