Facebookがクリックインジェクションによる不正広告で2人のデベロッパーを訴訟

Facebookは2人のアプリデベロッパーを、同社の広告プラットホームを利用して不正な収益を得たとして告訴した。同社はその法的アクションを、米国時間8月6日のブログ記事で発表した

同社の社則執行および法務担当ディレクターであるJessica Romero(ジェシカ・ロメロ)氏は「そのデベロッパーはアプリをGoogle Playストア上で一般公開し、ユーザーのスマートフォンをマルウェアに感染させた。そのマルウェアはユーザーのスマートフォン上に現れるFacebookの広告で偽のユーザークリックを作り出し、ユーザーがその広告をクリックしたような効果を生じさせた」。

この手口はクリックインジェクションと呼ばれ、ユーザーに知られることなくアプリが不正な広告クリックを作り出すことによって、広告収入を増やす。それは、セキュリティの研究者たちには以前から知られている問題で、デベロッパーは簡単に作れるジャンクアプリを作り、それが何百万回もダウンロードされるとき、ユーザーに知られることなく見えない広告のクリックが作り出される

Facebookによると、今回のケースでは二人のデベロッパー、香港のLionMobiとシンガポールのJediMobiが、同社の広告システムから不正な支払いを受けた。彼らのアプリは、概算で2億700万回以上インストールされたと思われる。そのアプリはGoogleのアプリストアにまだあるが、Googleはそれに関してまだ何もコメントしていない。

Facebookは「被害者の広告主には広告料金相当を返金した」ことを表明したが、Facebookのスポークスパーソンはコメントの要求に応じなかった。

関連記事:File-storage app 4shared caught serving invisible ads and making purchases without consent(ファイル保存アプリ4sharedが不可視の広告で同意なき購入を偽造、未訳)

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

App Storeはアプリの墓場

app-store-graveyard1

【編集部注:本稿の執筆者、Alex AustinはBranchのファウンダー。

最近のApple App Storeや、Google Playプラットフォームに対して、誰もが同じワクワク感を抱いているわけではない。モバイルアプリのエコシステムを取り巻く絶望の空気は明白であり士気を失わせる。

私が両プラットフォームで初めてアプリを公開した時(運転中の燃費を自動的に監視するアプリ)、最初の一週間は夢中でダウンロード数をチェックし、壮大な夢を描いていた。その夢が実ることは、もちろんなかった。誰にも見つけてもらえないのに、なぜ時間を費して公開するのだろうか。

昨年私は、アプリの発見されにくさ、デベロッパーにとっての害、およびその改善方法に関する記事で、この感情を露わにした。しかし、注目されたのはアプリの成功率がいかに低いかだけで、モバイルエコシステムにおけるアプリ発見性の欠陥には、明確な影響を与えられなかった。

エコシステムの現状を明示すために、私はMighty SignalMixRankの友人らから提供されたApple App Storeのデータを分析して、いくつかのグラフにまとめた。

まず、各年に公開されたアプリの月間平均数を見てみよう。App Store開設後最初の丸一年は2009年で、毎月約3000本の新しいアプリが公開された。早送りして2016年、ここまで毎月5万本の新アプリが公開されており、今なお加速している。

Apps-Released-by-Year-Branch毎月出てくるアプリ数が増え続けているにもかかわらず、新しいアプリが目に触れられるための対策はとられていない。これは、デベロッパーが自分のアプリを見つけてもらうのが難しくなっていくことを意味しており、それがダウンロード数減少に直接結びついている。アプリ毎のレーティング(評価)の数の平均を年毎にプロットすればわかる。歴史的に、レーティング数はダウンロード数を示す優れた指標である。

Avg-Rating-Numbers-Branch
2009年には、アプリ1本当たりの平均レーティング数は〈10倍〉だった ― これは、2009年に公開されたアプリは、今より10倍ダウンロードされていたことを意味している。痛っ。

デベロッパーに与える影響は何か? 以前と比べてアプリを作ることは簡単になっていない。同じような努力で得られる報酬はもはや存在しない。これが、放棄アプリの劇的増加を呼んでいる。

Time-Invested-in-Apps-Branch

あるアプリが過去6ヵ月間アップデートされていなければ、現在アクティブに作業がなされていない可能性が高いとして、私は放棄アプリに分類する。各放棄アプリについて、公開日から最終アップデートまでの期間から、アプリがどれだけアクティブに手を加えられていたかを調べ、アプリ寿命グラフを作った。

上のグラフでわかるように、2009年にアプリをリリースしたデベロッパーは、放棄するまで2年以上アクティブに作業していた。一方、2014年と2015年にリリースされたアプリは、わずか3ヵ月で放棄されている。デベロッパーはかつてない早さでApp Storeから離脱し、放棄アプリを残していく。

この放棄率を新アプリの公開本数に掛け合わせれば、どれほど早く墓地が埋まっていくかは容易に見てとれる。

Number-of-Abandoned-Apps-Branch

この計算でいくと、App Storeには2015年末時点で150万本の放棄アプリが蓄積されている。2~3ヵ月というデベロッパーの早い離脱と、アプリ公開数の増加があいまって、App Storeは夢と希望の墓場と化している。

Appleがこの問題を認識し、あらゆる手を尽くしてデベロッパーを雑音の上に引き上げようとしていることを私は知っている。App Store検索の改善と、噂されているApp Storeスポンサー付検索結果に望みを託そうではないか。

[原文へ]

(翻訳:Nob Takahashi / facebook

モバイルアプリの応答性が速いのはカナダと日本, よくクラッシュするのはゲームアプリ–Crittercismの調査より

アプリケーションが成功するためには、ユーザの心をとらえるデザイン、マーケティング、そして強力なユーザ開拓戦略が必要だ。しかしアプリの信頼性は、デベロッパがコントロールできない要素に依存している場合が多い、とCrittercism最新レポートは告げている。

Crittercismはアプリのパフォーマンス管理やエラー監視システムを作っている企業だが、アプリのパフォーマンスやクラッシュレートは、そのアプリが使用しているクラウドサービスや、各地のネットワークキャリアののクォリティに大きく左右されることを見出した。

アプリが十分な競争力を持つためには、ユーザのリクエストに1秒以内で応答することと、クラッシュレートが全稼動時間の1%未満でなければならない。しかしCrittercismのレポートMobile Experience Benchmarkによると、アプリの47%がクラッシュレート1%を超えており、32%は2%を超えている。

このレポートのベースとなっているCrittercismの標本数は、リアルタイムで調べたリクエストが毎秒3万、モバイルユーザ数はのべ10億である。そして得られた結果を、クラウドサービス別、オペレーティングシステム別、地域別に分類している。ただしCrittercismのの顧客はおおむね、自分が使うアプリのパフォーマンスの最適化に熱心に取り組むタイプだ。

CrittercismのCTO Rob Kwokは次のように語る: “モバイルアプリのパフォーマンスに影響を与える要因は、あまりにも多すぎる。ウェアラブルのような新しいモバイルが普及すると、ユーザに高品質な体験を安定的に提供することがますます困難になり、アプリのパフォーマンス管理のためには、個々の阻害要因に応じたカスタムメイドのソリューションが必要になる”。

下図に見るように、クラッシュレートがいちばん高いカテゴリはゲームで、4.4%にもなる。次に高いのがメディア関連の1,8%(写真、ビデオなど)だ。この二つのカテゴリは、グラフィクスの多いことが共通している。一方、クラッシュレートがいちばん低いのはeコマースで、0.4%だ。

地域別国別のアプリパフォーマンス

アプリのパフォーマンスは、国による、あるいは地域による違いが大きい。下図のように、合衆国を1とした場合の相対値では、カナダと日本のレスポンスタイムが最速だ。中国、オーストラリア、そしてヨーロッパもまあまあである。〔値が少ないほど速い。〕

中東、東南アジア、アフリカなどの新興市場は平均レスポンスタイムが遅いが、とりわけインドは合衆国の倍を超えている。

“キャリアの伝送クォリティにも地域差がある”、とレポートは述べている。“アプリのオーナーは、CDNの利用やデータセンターの分散化など、アプリとアーキテクチャの最適化を図り、レスポンスタイムの地域差に対応すべきである”、ということだ。

クラウドサービスの不安定性

Crittercismによると、今では一つのアプリが平均で6つのクラウドサービスに依存している。たとえばログインはFacebookに、ストレージはAmazon Web Servicesに、アクセス分析はFlurryに、といった具合だ。

これらのクラウドサービスが、アプリのパフォーマンスを大きく左右する。レスポンスタイムが長かったり、エラーレート(つながるまで何度呼び出すか)が高いと、それによってアプリそのもののパフォーマンスが落ちる。Crittercismのデータでレスポンスタイムがとくに長いのは、Flurry(750ミリ秒)、Facebook(669ミリ秒)、Twitter(574ミリ秒)の三つだ。これらに対して、Google Analytics(237ミリ秒)やCloudfront(328ミリ秒)、Admob(389ミリ秒)はレスポンスタイムが短い。

[クリックすると大きい図へ]

AndroidとiOSのレスポンスタイム

Androidの各バージョンの中で、クラッシュレートはGingerbreadがもっとも高くて1.7%だ。Gingerbreadは今、三番目に多く使われているバージョンだが、そのクラッシュレートは最新バージョンのKitKatや、その前のIce Cream SandwichとJelly Beanの倍以上だ(下図)。

  1. Android 1.0
  2. Android 1.1
  3. Android 1.5 Cupcake
  4. Android 1.6 Donut
  5. Android 2.0/2.1 Eclair
  6. Android 2.2 Froyo
  7. Android 2.3 Gingerbread
  8. Android 3.x Honeycomb
  9. Android 4.0 Ice Cream Sandwich
  10. Android 4.1/4.2/4.3 Jelly Bean
  11. Android 4.4 KitKat

一方メーカー別機種別では、いちばんクラッシュしにくいAndroidスマホはSamsung Galaxy S4である。S3も、それに次ぐ。

iOSのバージョンでは、iOS 7.1がもっとも安定していて、クラッシュレートは1.6%だ。対してiOS 7.0は2.1%、iOS 6は2.5%である。機種別ではiPhone 5のクラッシュレートが最低で、iPhone 5sよりも15%少ない。

またiOSもAndroidも、スマートフォンの方がタブレットよりも安定性が良いと言える。

[クリックすると大きい図へ]

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))