Agile Cat — in the cloud

どれくらいの時間を、モバイルとテレビに消費しますか? アメリカでの調査結果を1枚のチャートで!

Posted in .Chronicle, Advertising, Mobile, Research by agilecat.cloud on September 13, 2015
US consumers are now spending more time on apps than watching TV
Laurie Beaver – Sep 11, 2015
http://www.businessinsider.com/us-is-spending-more-time-on-apps-than-tv-2015-9
 
_ Business Insider
 
US consumers are now spending more time on their phones using apps than watching TV, according to recent data from Flurry.
 
最新の Flurry マーケット調査から、アメリカでは TV に費やす時間よりも、モバイル・アプリを使用している時間の方が長いという、結果が得られている。
 
TV-vs-Moble-Chart
BI Intelligence
  • The average US consumer spends nearly 198 minutes using mobile apps compared to 168 minutes watching TV each day. This excludes time spent inside mobile web browsers.
  • The inclusion of web browsing on mobile devices bumps the daily average up to 220 minutes.
  • That isn’t to say that TV viewing is decreasing, either. Over the last three years, TV viewing has stagnated. On the other hand time spent in apps has increased from 126 minutes per day on average in Q2 2013 to 198 minutes in Q2 2015.
 
  • アメリカ国民の1日あたりの平均値として、モバイル・アプリに 198分が費やされているが、TV の場合は 168分に過ぎない。さらに言うなら、このデータからは、モバイル Web ブラウザでの消費時間が除外されている。
  • そして、このデータに、モバイル・デバイス上での Web ブラウジング時間を取り込むと、その値は 220分までジャンプする。
  • しかし、TV 視聴が、減少しているわけではない。とは言え、この 3年間(2013 Q2〜2015 Q2)で、TV の成長が止まっていることは否定できない。その一方で、モバイル・アプリの方は、126分から 198分へと、急成長しているのだ。
 
The data shows that users are spending more time on mobile devices, and that apps are now the top channel for viewing media in the United States. What this suggests is that consumers are more likely to expect video content to be presented in an app format, highlighting why pay-TV companies are increasingly offering their own mobile services to subscribers.
 
このデータが示すのは、モバイル・ユーザーたちの、デバイス利用時間が伸びているという状況であり、また、アメリカ国内において、モバイル・アプリがトップ・メディアになったという現実である。そして、モバイル・アプリのフォーマットで提供されるビデオ・コンテントを、消費者たちが好むという状況も示唆される。いくつかの、Pay-TV 企業が、そのサブスクライバーたちに対して、モバイル・サービスを充実させている点を強調しておきたい。
 
Don’t miss another day of breaking developments. Stay ahead of the curve and gain insight into the latest news & trends. Join thousands of other professionals who start the day with Mobile INSIDER.Try any of our INSIDER newsletters for two weeks »
 
ーーーーー
FB-Auto-Playresearch_55この1年で、いったい何が起こったのでしょう? 文中にもあるように、モバイルで観るビデオ・コンテントという状況が、一挙に増えていったとしか思えない伸びですよね。 Agile_Cat 的には、Facebook での自動動画再生も、この成長を支える要因になっていると感じています。アレ、ついつい観てしまいますものね。 そして、この Bisiness Insider のようなメディアを常用する、Agile_Cat の Timeline には、その種のスポンサーが付いた動画コンテントが、じゃんじゃんと流れ込んでくるのです。 つまり、ばっちりとターゲティグされているのです。 そう考えると、コンテントだけの話ではなく、アド・テクも絡んだ大きなトレンドなのかと思えてきます。ーーー それはそうと、Facebook 動画の自動再生を止めることも可能です。 それで、仕事の効率が上がるのか、、、という論点はさておき、少なくともバッテリーのもちが、良くなるような気がします 🙂 _AC Stamp
ーーーーー
<関連>
どれくらいの頻度で メール・チェックしますか? アメリカでの調査結果を1枚のチャートで!
アメリカの若者たちは依然として SMS を好んでいる:それを示す1枚のチャート!
Black Monday 2015 : 大手クラウド・プロバイダーたちの株価は、どれほど下落したのか? 
オンライン出版とトラフィック誘導: Facebook と Google Search が逆転したようだ!
Facebook 2015-Q2 決算:欧米だけに依存しない、グローバル戦略が実を結んできた!
 
 

Comments Off on どれくらいの時間を、モバイルとテレビに消費しますか? アメリカでの調査結果を1枚のチャートで!

ハイブリッド・クラウドへの移行: APAC の 3200 社に、目標と課題について聞いてみた!

Posted in .Selected, Asia, Hybrid, Research by agilecat.cloud on September 4, 2015
APAC firms want to move apps to cloud, but lack data to determine opportune time
Eileen Yu – Aug 20, 2015
http://www.zdnet.com/article/apac-firms-want-to-move-apps-to-cloud-but-lack-data-to-determine-opportune-time/
 
_ zdnet normal
 
Some 41 percent of Asia-Pacific businesses expect up to 24 percent of their applications to be on the cloud in 2016, but 35 percent do not have the analytics to determine whether it’s cost-effective to do so.
 
Asia-Pacific における 41% の企業が、自身のアプリケーションの 24%(最大で)を、2016年までにクラウドに移行したいと望んでいる。しかし、35% の企業は、クラウド移行を判断するための、費用対効果に関する分析を行なっていないと述べている。
 
ーーーーー
 
Some 35 percent of Asia-Pacific organizations do not have the necessary data to determine when it is more cost-effective to deploy their application in the cloud or within their own datacentres.
 
Asia-Pacific における 35% の組織は、クラウドあるいは独自のデータセンターへ向けて、自身のアプリケーションをディプロイする時期について、最も費用対効果の高いタイミングを判断するための、データを有していないという。
 
APAC firms and cloudsClick to Large
 
According to survey findings released Thursday by F5 Networks, 45 percent of businesses in the region operated up to 200 applications, while 8 percent deployed more than 3,000 applications. The study polled 3,200 IT decision makers across Asia-Pacific to analyse their existing and future use of application services.
 
8月20日(木)に F5 Networks がリリースした調査結果によると、この地域における 45% の企業は、200種類以内のアプリケーションを運用しているが、8% の企業に関しては、3,000 種類以上のアプリケーションを展開している状況も分かった。この調査は、現在と未来におけるアプリケーション・サービスの利用について分析するために、Asia-Pacific の 3,200人の IT 意思決定者を対象としている。
 
It found that 41 percent of respondents were keen to move up to 24 percent of their applications to the cloud within the next year, while 24 percent would do likewise for 25 to 50 percent of their applications.
 
また、回答者の 41% は来年中に、自身のアプリケーションの 24%(最大で)を、クラウドへ移行したいと強く望んでいることが分かった。同様に、24% の回答者も、自分のアプリケーションの 25%〜50% を、クラウド移行したいと望んでいるようだ。
 
F5 Networks’ Asia-Pacific senior vice president, Emmanuel Bonnassie, said: “As applications continue to be a critical part of the business strategy, organisations are seeking the same confidence level in cloud deployments that they’ve seen in the datacentre. Companies in every industry rely on applications to drive customer engagement, employee productivity and revenue today.”
 
F5 Networks の Asia-Pacific Senior VP である Emmanuel Bonnassie は、「ビジネス戦略における重要なパートに、アプリケーションが位置づけられるのと平行して、データセンター内に展開されるクラウドに対して、同じようなレベルの信頼が求められてきている。あらゆる産業における企業が、顧客のエンゲージメントおよび、従業員の生産性、日々の収益を促進するために、アプリケーションに依存しているのだ」と述べている。
 
He added that more respondents deemed mobile apps and big data analytics to be important trends for their organisation, compared to the Internet of Things (IoT) or software-defined networks. This indicated a growing hybrid environment across the region, with a mix of on- and off-premise services increasingly adopted by organisations, Bonnassie noted.
 
そして、それらの回答者にとっては、モバイル・アプリとビッグ・データ分析が、IoT や SDN よりも重要なトレンドになっていると、彼は付け加えている。さらに言うなら、それらの組織により採用され、また、増大している、この地域に展開されたオン・プレミス/オフ・プレミスのサービスを、組み合わせていくためのハイブリッド環境が成長していると、彼は指摘している。
 
However, 35 percent pointed to the lack of analytics as a challenge in adopting hybrid clouds, where they struggled to understand when it would make more sense to deploy applications in cloud datacentres and when it would be more cost-effective to do so within their own datacentres. Another 29 percent said the failure to establish comprehensive identity and access management policies as a barrier to the hybrid cloud adoption.
 
しかし、35% の企業は、ハイブリッド・クラウドを採用する際の、課題に対する分析が欠落していると指摘している。つまり、アプリケーションをディプロイする先として、クラウド・データセンターを選ぶ方が理にかなうと思われるときや、独自データセンターを選ぶほうが費用対効果が高いと思われるときがあるが、その判断に苦労しているのだ。その他の 29% は、ハイブリッド・クラウドを採用する際の障壁として、包括的な ID および、アクセス・マネージメント・ポリシーの確立に問題があるの述べている。
 
Some 23 percent highlighted the inability to ensure consistent application performance as a challenge in hybrid cloud deployment, while 21 percent pointed to the lack of cloud providers that could meet their organisation’s data security requirements.
 
また、23% の企業は、ハイブリッド・クラウドを採用する際の課題として、アプリケーション性能に関する一貫性が確保できないことを強調している。そして 21% は、自社のセキュリティ要件に合致する、クラウド・プロバイダーが見つからないと指摘している。
 
With security a key concern, 42 percent of respondents believed applications services should not be implemented without security, compared to 30 percent who pointed to availability as a priority.
 
セキュリティが重要だとする 42% の回答者は、セキュリティを伴わずに実装されるアプリケーション・サービスが、存在するはずだと確信している。その比率は、可用性を優先する 30% と比べて、大きな値になっている。
 
ーーーーー
Asia Pacificモバイル・アプリ対応が、最大の課題というのは分かりますが、ビッグ・データ分析が IoT と SDN よりも重要なトレンドだというのは、ちょっと意外でした。 以前に、「Hybrid の調査: 企業データを分析すると、20-60-20 の 仕分けシナリオが見えてくる」という抄訳をポストしましたが、どのようにデータを切り分けて、オンプレミスとクラウドに配置すべきかという点が、依然として大きな課題になっているようですね。それにしても、とても興味深い調査結果ですね!  _AC Stamp
ーーーーー
<関連>
Alibaba クラウドも Equinix プライベート・リンクに接続:香港が中国と世界をつなげる?
APAC のモバイル・エンタープライズは、2015年で US$22B の規模にいたる:VMware
NTT が 専用線 クラウド接続を提供:ハイブリッド化は 促進されるのか?
Huawei が ジョホールバールに、独自の Cloud Exchange をオープンする!
欧州クラウドのリーダー Interoute が、ついにシンガポールに進出だ!
 

Comments Off on ハイブリッド・クラウドへの移行: APAC の 3200 社に、目標と課題について聞いてみた!

Enterprise Mobile App の調査:情シスのキャパに対して、モバイル開発は5倍のスピードで突っ走る!

Posted in DevOps, Enterprise Social, Mobile, On Monday by agilecat.cloud on August 10, 2015
Enterprise Mobile App Development: Growing 5x Faster Than IT Can Respond
By Dick Weisinger – August 6th, 2015
http://formtek.com/blog/enterprise-mobile-app-development-growing-5x-faster-than-it-can-respond/
_ formtek
Demand for enterprise mobile applications is expected to grow five times faster than the ability of IT organizations to respond between now and the end of 2017, according to Gartner.  The growth is being fueled by the rapid increase in number of mobile phone devices which is expected to reach 2.1 billion units by 2019.
 
エンタープライズ・モバイル・アプリに関する需要だが、これから 2017年末までの間において、IT 組織の許容力と比べて、5倍というスピードで成長していくと、Gartner は予測している。この成長は、2019年まで 21億台に達すると予想される、モバイル・フォンの急激な増加により加速していく。
 
Dali_5Today employees typically use three different devices on a daily basis, but trends like Internet of Things (IoT) and wearable devices are expected to increase the number of devices used daily to five or six devices.
 
今日において、一般的な企業などに属する従業員たちは、日常的に 3種類のデバイスを使用している。しかし、IoT および Wearable デバイスといったトレンドにより、前述のデバイス数は5種類〜6種類ほどに増加すると予想される。
 
Adrian Leow, principal research analyst at Gartner, said that “organisations increasingly find it difficult to be proactive against competitive pressures, which is resulting in their mobile apps becoming tactical, rather than strategic.  We’re seeing demand for mobile apps outstrip available development capacity, making quick creation of apps even more challenging. Mobile strategists must use tools and techniques that match the increase in mobile app needs within their organizations.”
 
Gartner の Principal Research Analyst である Adrian Leow は、「 競合のプレッシャーに対して、先回りして戦っていくことの困難さに、直面する企業が増加していくだろう。言い換えれば、モバイル・アプリに求めるものが、戦略的というより、戦術的なものになってきているのだ。つまり、モバイル・アプリに対する需要が、調達できる開発能力を上回るという現実に、私たちは直面しているのだ。その結果として、短時間でアプリを開発することが、ますます困難になってきている。モバイル戦略家たちは、組織内で必要とされるモバイル・アプリの増加に適合するように、ツールやテクニックを活用していかなければならない」と述べている
 
In order to be able to keep up with mobile app demand within organizations, Gartner recommends:
 
組織内で増大していくモバイル・アプリの需要に対応していくために、以下の能力を獲得すべきと、Gartner は推奨している:
 
  • Make Application Development a high priority for the business
  • Adopt a bimodal approach
  • Use rapid development app development tools
  • Supplement in-house development skills with outsourcing
 
  • モバイル・アプリ開発の優先順位を、ユーザー企業内で高めていく
  • 多様性のあるアプローチを適用する
  • 迅速なアプリ作成を可能にする、適切な開発ツールを採用する
  • 社内開発のスキルを高めながら、アウトソースも活用する
 
ーーーーー
On Mondayサービス/プロダクトの供給という側から見て、この5年の間に、最も大きく変化してきたのがモバイル開発なら、最も保守的に進んできたのが情シスなのかもしれません。 それぞれの社会における役割が異なるため、このような比較自体に意味はありませんが、モバイルを取り込まざるを得ないという現実が、エンタープライズに対して大きな変化を要求しています。 そうなると、情シスにとっても、モバイル対策が欠かせなくなってきます。 どのようにしたら、両者を隔てる深い溝が埋まるのでしょうか? 考えるべきことが、たくさん有りそうですね。_AC Stamp
ーーーーー
<関連>
IT as a Service の調査:クラウドと情シスの、新しいコンペのスタイルになるのか?
Hardware の調査:IoT によるイノベーションは、新たなハードウェアが具現化していく
Future Growth の調査: 大半の CEO たちが、テクノロジーを最重要視している
IoT の調査: 各種デバイスが生成するデータの、90% 以上が廃棄されているという現実
Data Warehousing の調査: Snowflake が、Azure と AWS にガチンコ勝負を挑む
 
 

Comments Off on Enterprise Mobile App の調査:情シスのキャパに対して、モバイル開発は5倍のスピードで突っ走る!

Facebook エンジニア と Android ローエンド:積極的に使ってアジアを知る!

Posted in Asia, Facebook, Mobile by agilecat.cloud on January 23, 2015
Why Facebook Forces A Bunch Of Its Engineers To Use Terrible, Low-End Phones
http://wp.me/pwo1E-8e2 
Jillian D’Onfro – Dec. 7, 2014
http://www.businessinsider.com/facebook-low-end-phones-bad-network-conditions-2014-12
 
_ Business Insider
 
You might not expect to find many flip phones in the high-tech and free-food laden Facebook offices, but your expectations would be wrong.
 
ハイテクとフリー・ランチが自慢の Facebook オフィスで、数多くのフリップ・フォン(折りたたみ)を見かけるなんて想像もしないだろうが、それは間違った思い込みだ。
 
Facebook is creating a special lab filled with low-end Android smartphones,”crappy old flip phones,” and weak networking to help the company study the computing conditions in parts of the world like rural India that either have limited internet or none at all.
 
Facebook が立ち上げた特別なラボは、ローエンドの Android スマホと、安くて古いフリップ・フォン、そして、脆弱なネットワーキングで構成されているのだ。それにより、たとえばインドの農村のような、インターネットが供給されるにしても、きわめて制約が多いという世界における、コンピューティングの条件を調査することが可能になる。
 
Facebook with old Android
Not actually
Facebook employees
 
Developers have to try to use Facebook’s apps on super-old versions of Android so they can understand what it’s like for people in areas without good network connection.
 
ここでの開発者たちは、きわめて古いバージョンの Android で、Facebook アプリを使用しなければならない。したがって、条件の整ったネットワークに接続できない地域の人々のために、何をすれば良いのかを理解できるようになる。
 
“It’s easy to not have empathy for what the experience is for the majority of people in the world,” Facebook CEO Mark Zuckerberg told Time’s Lev Grossman of Facebook’s employees.
 
「 この世界の大多数の人々のために、どのようなエクスペリエンスを持つべきかと言っても、それに対して容易には共感してもらえない」と、Facebook の CEO である Mark Zuckerberg が、一人の従業員である Lev Grossman に語った。
 
So, the team manufactures empathy.
 
そして、このチームは、その共感を作り出すことになった。
 
“I force a lot of the guys to use low-end phones now,” Javier Olivan, Facebook’s head of growth, says. “You need to feel the pain.”
 
Facebook の Head of Growth である Javier Olivan は、「 私の役割は、より多くの従業員にローエンド・スマホを持たせることだ。 そうすれば、痛みを共有できる」と発言している。
 
And Facebook employees aren’t the only ones getting the terrible-phone treatment.
 
そして、いまでは、そんな旧式フォンの面倒を見るのが、Facebook の従業員だけではなくなってきている。
 
“We brought in some phones, like very low-end Android, and we invited guys from the Valley here—the eBay guys, the Apple guys,” Olivan says. “It’s like, ‘Hey, come and test your applications in these conditions! Nothing worked.”
 
Olivan は、「 私たちは、このラボに、きわめてローエンドの Android などの、いくつかのフォンを持ち込んでいる。 そして、eBay や Apple の、つまりシリコンバレーの仲間たちを招待している。ここに来れば、そこらじゃ有り得ない、特殊な条件でアプリをテストできるという感じで誘っている 」と述べている。
 
That pain is of one of the things motivating Zuckerberg’s work on Internet.org, an initiative which aims to bring internet access to everyone in the world. Facebook recently released apps in Zambia and Tanzania with content like Wikipedia, Google Search, and AccuWeather that local people can get and use for free.
 
ここで言う痛みとは、Zuckerberg が Internet.org を立ち上げた、動機の1つでもあるのだ。 この組織は、世界のすべての人にインターネット・アクセスを提供することを目標としている。 最近のことだが、Facebook は Zambia と Tanzania の人々に、Wikipedia/Google Search/AccuWeather などを使用できるアプリをリリースしている。 そして、それらの地域の人々は、それらを無償で利用できるのだ。
 
Read the rest of Time’s profile of Zuckerberg and Internet.org here.
ーーーーー
facebookタイトルには「アジア」キーワードを使ってしまいましたが、それ以外にも、南米やアフリカのマーケットもあります。 低品質のネットワーク環境で、Facebook を使う貧しい人々のことを考えると、Menlo Park のキャンパスで、こうした取り組みが進められていることが、とても嬉しく思えてきます。 そして、以前にポストした「Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!」や、「Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!」といった抄訳を読み返すと、心から拍手を送りたくなってしまうのです。_AC Stamp
ーーーーー
<関連>
Facebook と Mark の途上国戦略:Coca-Cola スタイルの長期スパンで考えていく
Zuck が Cook に 一発かました:もっと Apple は、自分の顧客を大切にすべきだ!
iOS から Android へ : Facebook は優先順位を切り替えるのか?
2012年:ネイティブの Facebook App for Android が、最終テストの段階らしい!
2012年:Droid フードって Cat フードよりも 不味いの? Facebook さん・・・
2014 Agile Cat:大人になった Facebook の マトメ

Comments Off on Facebook エンジニア と Android ローエンド:積極的に使ってアジアを知る!

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC by Agile Cat on December 11, 2014

Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model
http://wp.me/pwo1E-85F
Monday, October 20, 2014
http://highscalability.com/blog/2014/10/20/facebook-mobile-drops-pull-for-push-based-snapshot-delta-mod.html

We’ve learned mobile is different. In If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong we learned programming for a mobile platform is its own specialty. In How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks we learned bandwidth on mobile networks is a precious resource.

私たちは、モバイルが別の世界のものであることを学んできた。If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong では、モバイル・プラットフォームのためのプログラミングが、独特のものであることを知った。そして、How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks では、モバイル・ネットワークの帯域幅が、きわめて貴重なリソースであることを学習した。

Given all that, how do you design a protocol to sync state (think messages, comments, etc.) between mobile nodes and the global state holding servers located in a datacenter?

それら、すべてのことを考慮して、ステート(メッセージやコメントなど)をシンクさせるためのプロトコルを、どのようにデザインすべきなのだろうか? ここでは、複数のモバイル・ノードと、データセンターのサーバーに置かれたグローバル・ステートの、同期について考えていく。

Facebook recently wrote about their new solution to this problem in Building Mobile-First Infrastructure for Messenger. They were able to reduce bandwidth usage by 40% and reduced by 20% the terror of hitting send on a phone.

最近のことだが、Facebook の Building Mobile-First Infrastructure for Messenger というポストにおいて、この問題に関する彼らの新しいソリューションが紹介されている。それによると、帯域幅の使用率が 40% まで、そして、スマホでの送受信を阻害する要因が 20% まで、削減できたという。

That’s a big win…that came from a protocol change.

それは、素晴らしい成功体験であり、また、プロトコルの変更にもたらされたものである。

<関連> Facebook が語るモバイル・チューニングの極意

Facebook Messanger went from a traditional notification triggered full state pull:

The original protocol for getting data down to Messenger apps was pull-based. When receiving a message, the app first received a lightweight push notification indicating new data was available. This triggered the app to send the server a complicated HTTPS query and receive a very large JSON response with the updated conversation view.

Messenger がデータをダウンロードする際の、オリジナルのプロトコルは Pull ベースのものであった。 このアプリはメッセージを受信するとき、新しいデータがあることを示す、ライトウェイトなプッシュ通知を最初に受信する。それは、アプリに対するトリガーであり、その結果として、サーバーへ向けて複雑な HTTPS クエリーを送信し、また、アップデートされた会話を取り込んだ、きわめて大規模な JSON レスポンスを受信することになる。

To a more sophisticated push-based snapshot + delta model:

Instead of this model, we decided to move to a push-based snapshot + delta model. In this model, the client retrieves an initial snapshot of their messages (typically the only HTTPS pull ever made) and then subscribes to delta updates, which are immediately pushed to the app through MQTT (a low-power, low-bandwidth protocol) as messages are received. When the client is pushed an update, it simply applies them to its local copy of the snapshot. As a result, without ever making an HTTPS request, the app can quickly display an up-to-date view.

私たちは、前述のモデルに代えて、Push ベースの SnapShot + Delta モデルに移行することを決めた。 この新しいモデルでは、クライアントは自身のメッセージに関する、イニシャルの SnapShot を取得する(一般的には、これまでの HTTPS Pull のみとなる)。 続いて、Delta アップデートが読み込まれるが、それはメッセージを受信した直後に、MQTT(リソースと帯域において負荷の少ないプロトコル)を介してアプリに Push されるものである。また、クライアントからアップデートが Push されるときには、ローカルに保持される SnapShot に、その内容がコピーされる。その結果として、これまでのような HTTPS リクエストを必要とすることなく、アプリはアップデートされたビューを表示できるようになる。

We further optimized this flow by moving away from JSON encoding for the messages and delta updates. JSON is great if you need a flexible, human-readable format for transferring data without a lot of developer overhead. However, JSON is not very efficient on the wire. Compression helps some, but it doesn’t entirely compensate for the inherent inefficiencies of JSON’s wire format. We evaluated several possibilities for replacing JSON and ultimately decided to use Thrift. Switching to Thrift from JSON allowed us to reduce our payload size on the wire by roughly 50%.

さらに、私たちは、メッセージと Delta アップデートから、JSON エンコーディングを切り離すことで、このフローを最適化した。もし、開発者のオーバーヘッドを最低限に抑えたかたちで、ヒューマン・リーダブルで柔軟なデータ転送を実現するなら、JSON は素晴らしいソリューションとなる。しかし、JSON における送受信の形式は、きわめて効率が悪い。 圧縮により、いくつかの問題は解決するが、JSON の固有の非効率性を、完全に補完することは不可能だ。私たちは、JSON を置き換えるための、いくつかの可能性について評価し、最終的には Thrift を使用することにした。JSON から Thrift へ移行することで、転送における実質的なサイズを、およそ 50% に低減できた。

On the server side Facebook also innovated:

Iris is a totally ordered queue of messaging updates (new messages, state change for messages read, etc.) with separate pointers into the queue indicating the last update sent to your Messenger app and the traditional storage tier. When successfully sending a message to disk or to your phone, the corresponding pointer is advanced. When your phone is offline, or there is a disk outage, the pointer stays in place while new messages can still be enqueued and other pointers advanced. As a result, long disk write latencies don’t hinder Messenger’s real-time communication, and we can keep Messenger and the traditional storage tier in sync at independent rates. Effectively, this queue allows a tiered storage model based on recency.

Iris は、メッセージングのアップデート(新しいメッセージやメッセージ・リードによるステートの変化など)で用いる順列キューのことであり、Massenger アプリに送信された最新のアップデートと、伝統的なストレージ階層において、別々のポインタを持つことが可能になっている。ディスクおよびスマホへのメッセージ送信が成功すると、それに対応するポインタが前進する。もし、スマホがオフラインであったり、ディスクに障害が発生した場合には、対象となるポインタを所定の位置に留めながら、新しいメッセージをキューに保持し、他のポインタを前進させることができる。その結果として、ディスクへの書き込みなどの、大きなレイテンシが発生しても、Messenger のリアルタイム通信を妨げることはない。 そして、Messenger のレベルと伝統的なストレージ階層を、それぞれの頻度で同期させることも可能だ。このキューの効率性により、新しい階層型ストレージ·モデルが実現する。

Delta based syncing strategies are very common in Network Management systems where devices keep a north bound management system in sync by sending deltas. The problem with a delta based approach is it’s easy for clients to get out of sync. What if changes happen at a rate faster than than deltas can be moved through the system? Or queues get full? Or the network drops updates? The client will get out of sync and it won’t even know it. Sequence numbers can be used to trigger a full sync pull if there’s an out of sync situation.

Delta ベースの同期ストラテジーは、ネットワーク・マネージメント・システムにおいて、きわめて一般的なものである。 そこでは、デバイスが Delta を送信することで、上位階層のマネージメント・システムとの同期を維持する。 Delta ベースのアプローチにおける問題点は、その同期のメカニズムから、クライアントが容易に逸脱してしまうことである。 何らかの変更が Delta よりも速く、対象となるシステムを介して移動することが、実際に起こり得るだろうか? また、キューが溢れると、どうなるだろうか? さらに言えば、ネットワーク上でアップデートが失われたら、何が起こるだろうか? いずれにせよ、クライアントは同期から逸脱し、起こっていることを知ることもできない。そのような場合には、シーケンス・ナンバーを用いる。 それにより、完全な同期を引き起こし、同期から逸脱している状況を解消できる。

It’s also good to see Facebook got rid of JSON. The amount of energy and bandwidth wasted on moving and parsing fat JSON packets is almost criminal.

Facebook が JSON から離れることは、別の観点でも歓迎すべきことだ。このような巨大なシステムが、重たい JSON パケットを解析して転送するために、膨大なエネルギーと帯域幅を消費することは、きわめて罪作りなことでもあるのだ。

ーーーーー

先日にポストした「Facebook が語るモバイル・チューニングの極意」に続いて、今回も Todd Hoff さんの記事を紹介することができました。途上国におけるモバイル通信の状況を前提とした、ストレスを最小限に抑えた環境を提供したいという、Facebook の一貫したストラテジーが見えてきますね。 ただ、これは、途上国だけの問題ではなく、たとえば日本においても、モバイル・トラフィックの大幅な削減という、大きなメリットをもたらすはずです。 そして、私たちが使用している大半のサービスは、① モバイル・デバイス、② モバイル・インターネット環境、③ バックエンド・テクノロジー、④ データセンター・インフラのバランスの上に成り立っているわけですが、とりわけ途上国においては、① と ② のケアが不可欠なのでしょう。

ーーーーー

<関連>

iOS から Android へ : Facebook は優先順位を切り替えるのか?
Facebook が キャリアの協会に参加 : 狙いは Internet.org だ!
Mark Zuckerberg と Internet.org : コネクティビティが社会経済をバランスさせる
Facebook とモバイルの巨人たちが、Internet.org を立ち上げた!
Facebook に続け : 10億に挑む Android と iOS

Comments Off on Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC, Strategy by Agile Cat on December 2, 2014

How Facebook Makes Mobile Work at Scale for All Phones, on All Screens, on All Networks
http://wp.me/pwo1E-84k
September 22, 2014 – ImageTodd Hoff
http://highscalability.com/blog/2014/9/22/how-facebook-makes-mobile-work-at-scale-for-all-phones-on-al.html

When you find your mobile application that ran fine in the US is slow in other countries, how do you fix it? That’s a problem Facebook talks about in a couple of enlightening videos from the @scale conference. Since mobile is eating the world, this is the sort of thing you need to consider with your own apps.

アメリカ国内では快適に走るモバイル・アプリが、その他の国では遅くなると分かったとき、どのように修正すればよいのだろう?それは、@scale conference における何本かのビデオで、Facebook が指摘している問題である。そして、この世界をモバイルが呑み込んで以来、あらゆるアプリにおいて考察すべき、ある種の問題でもある。

<関連> Facebook アプリ:Push + Delta + Thrift でモバイル帯域を 40% も削減!

In the US we may complain about our mobile networks, but that’s more #firstworldproblems talk than reality. Mobile networks in other countries can be much slower and cost a lot more. This is the conclusion from Chris Marra, Project Manager at Facebook, in a really interesting talk titled Developing Android Apps for Emerging Market.

アメリカにおいても、私たちはモバイル・ネットワークに文句を言うだろうが、Twitter の #firstworldproblems で語られていることが真実だ。その他の国々におけるモバイル・ネットワークは、はるかに遅いものであり、また、より多くの費用がかかる。以下に示すのは、Developing Android Apps for Emerging Market という興味深いタイトルの講演の中で、Facebook の Project Manager である Chris Marra が結論づけたものである。

Facebook found in the US there’s 70.6% 3G penetration with 280ms average latency. In India there’s 6.9% 3G penetration with 500ms latency. In Brazil there’s 38.6% 3G penetration with more than 850ms average latency.

Facebook が調べた結果によると、アメリカにおける 3G の浸透率は 70.6% であり、レイテンシは 280ms である。それがインドとなると、3G の普及率は 6.9% であり、レイテンシ は 500ms になる。そしてブラジルの場合は、38.6% と 850ms だ。

Chris also talked about Facebook’s comprehensive research on who uses Facebook and what kind of phones they use. In summary they found not everyone is on a fast phone, not everyone has a large screen, and not everyone is on a fast network.

さらに Chris は、Facebook のユーザーである人々および、そこで用いられるスマホに関して、同社が実施している包括的な調査についても話してくれた。要約すると、誰もが高性能のスマホを使い、大きなスクリーンを持ち、高速のネットワークを使用できると思ったら、それは大きな間違いということだ。

It turns out the typical phone used by Facebook users is from circa 2011, dual core, with less than 1GB of RAM. By designing for a high end phone Facebook found all their low end users, which is the typical user, had poor user experiences.

その結果として、Facebook ユーザーが使用する典型的なスマホは、2011年頃のモデルから始まり、Dual-Core の CPIU を搭載し、RAM は 1GB 以下ということが分かってきた。 ハイエンド・スマホに合わせてデザインしてきた Facebook は、ローエンドのデバイスを持つユーザーが大半であり、そのすべてがプアなユーザー・エクスペリエンスを持つことを理解した。

For the slow phone problem Facebook created a separate application that used lighter weight animations and other strategies to work on lower end phones. For the small screen problem Facebook designers made sure applications were functional at different screen sizes.

Facebook は性能の低いスマホのために、軽いアニメーションなどの戦略を適用するために、使別のアプリを作成した。また、同社のデザイナーたちは、小さなスクリーンという問題に対処するために、異なる画面サイズであっても、機能的にアプリが振る舞えるようにしていった。

Facebook has moved to a product organization. A single vertical group is responsible for producing a particular product rather than having, for example, an Android team try to create all Android products. There’s also a horizontally focussed Android team trying to figure out best practices for Android, delving deep into the details of what makes a platform tick.

つまり、Facebook 自身が、プロダクトを構築するための組織に転身しているのだ。例を挙げるなら、すべての Android プロダクツを、そのためのチームが開発するのではなく、特定のプロダクトを構築するために、垂直方向へと問題を掘り下げていくグループに責任が振り分けられている。ただし、プラットフォームに適合するものを詳細まで踏み込み、Android のためにベスト・プラクティスを把握していく、水平方向に焦点を当てた Androidチームも存在する。

Each team is responsible for the end-to-end performance and reliability for their product. There are also core teams looking at and analyzing general performance problems and helping where needed to improve performance.

そして、個々のチームが自身のプロダクトに関して、その性能と信頼性を隅から隅まで担当することになる。さらに、コアとなるチームが、全体的なパフォーマンスの問題を分析し、それを向上させるために必要な支援を行う。

Both core teams and product teams are needed. The core team is really good at instrumentation and identifying problems and working with product teams to fix them. For mobile it’s important that each team owns their full product end-to-end. Owning core engagement metrics, core reliability, and core performance metrics including daily usage, cold start times, and reliability, while also knowing how to fix problems.

コアとプロダクトの、双方のチームが必要とされている。コア・チームは、適切に測定を行い、問題を特定し、それらを修正するために、プロダクト・チームと協調していく。モバイル開発において重要な事は、それぞれのチームが自身のプロダクトについて、隅から隅まで責任を負うことである。また、コアとしての共有メトリクス/信頼性/性能の指標を確立し、そこにアプリを立ち上げたときや、連続して使用したときの、信頼性を加える一方で、問題の解決方式を認識していく。

To solve the slow network problem there’s a whole other talk. This time the talk is given by Andrew Rogers, Engineering Manager at Facebook, and it’s titled Tuning Facebook for Constrained Networks. Andrew talks about three methods to help deal with network problems: Image Download Sizes, Network Quality Detection, Prefetching Content.

低速のネットワークに関連する問題を解決するという、包括的なテーマがある。今回は、Facebook の Engineering Manager である Andrew Rogers の、Tuning Facebook for Constrained Networks というタイトルが付けられたトークを紹介したい。Andrew の話は、ネットワークに関連する問題を解決する、Image Download Sizes/Network Quality Detection/Prefetching Content という、3つの方法論に集約される。

Overall, please note the immense effort that is required to operate at Facebook scale. Not only do you have different phones like Android and iOS, you have different segments within each type of phone you must code and design for. This is crazy hard to do.

総論として、Facebook のスケールで運用するには、膨大な労力が要求される点に注意してくほしい。そこには、Android と iOS といったモバイルの種別だけではなく、それぞれのデバイスごとのセグメントがあり、それに対してコーディングしていく必要があるのだ。それを実践していくことは、まさしくクレイジーである。

Reducing Image Sizes -  WebP saved over 30% JPEG, 80% over PNG

  • Image data dominates the number bytes that are downloaded from Facebook applications. Accounts for 85% of total data download in Facebook for Android and 65% in Messenger.
  • イメージ・データは、Facebook アプリにダウンロードされる、バイトの大半を占める。 Android 用の Facebook においては、全ダウンロード・データの 85% を占め、Messenger では 65% を占めている。
  • Reducing image sizes would reduce the amount of data downloaded and result in quicker downloads, especially on high latency networks (which we learned were typical).
  • イメージ・サイズを削減すれば、ダウンロードされるデータの量が低減され、より迅速なダウンロードが達成されるだろう。それは、高レイテンシのネットワークにおいて、特に有効な手段となる(そこから、私たちは学んだ)。
  • Request an appropriate image size for the viewport
  • 表示環境にあわせた、適切なサイズのイメージを要求する。
  • Resize on the server. Don’t send a large image to the client and then have the client scale the image down to a smaller size. This wastes a lot of bandwidth and takes a lot of time.
  • サーバー上で、イメージのサイズを変更する。クライアントへ向けて大きなイメージを送信し、クライアント側でイメージを小さくするという手法を取ってはならない。 そのような方式だと、大量の帯域幅を無駄にし、長時間を要することになる。
  • Send a thumbnail (for profile pictures) and a small preview image (this is seen in the newsfeed), and then a full image (seen in photo stories) when a user asks to zoom in it. A low-res phone may never need a full image. Most of the time a thumbnail and a small preview is all you need.
  • サムネイル(画像のサムネイル)と、小さなプレビュー・イメージ(例 NewsFeed)を送信し、ユーザーが拡大を要求したときに、フル・イメージを送信する(例 Photo Story)。低解像度のスマホの場合は、フル・イメージが不要かもしれない。また、大半のケースにおいて、サムネイルとプレビューで、すべての要求に応えられる。
  • Significant savings. Scaling a 960 pixel image that is 79KB is size to 240 pixels wide yields a 86% size reduction, to 480 pixels is a 58% size reduction, to 720 pixels is at 23% size reduction.
  • データ転送量を、大幅に削減できる。たとえば、960 pixel スケールのイメージは 79KB であるが、240 pixel なら 86%、480 pixel なら 58%、720 pixel なら 23% の削減が達成される。
  • With screen sizes becoming larger scaling images isn’t as effective as it used to be. Still worth doing, but the payoff isn’t as much.
  • スクリーン・サイズより大きなイメージを、効果的に利用できるケースはほとんど無い。何らかの価値があるかもしれないが、その代償は大きい。
  • Change the image format
  • イメージ・フォーマットの刷新
  • 90% of images sent to Facebook and Messenger for Android use the WebP format.
  • Android 用の Facebook および Messenger では、90% のイメージで WebP フォーマットが用いられている。
  • WebP format released by Google in 2010.
  • WebP フォーマットとは、Google が 2010年にリリースしたものである。
  • WebP saves 7% download size over JPEG for equivalent quality.
  • WebP は、同品質の JPEG に対して、7% のサイズ圧縮を実現にする。
  • WebP saved over 30% download size over JPEG by tuning quality and compression parameters with no noticeable quality differences. A big savings.
  • WebP は、画質チューニングと圧縮パラメータにより、JPEG に対して 30% のデータ削減を可能にするが、視覚的な劣化は生じない。 それにより、ダウンロード・サイズを大幅に削減できる。
  • WebP also supports transparency and animation, which is useful for their Stickers product.
  • さらに WebP は、透過性とアニメーションをサポートするため、Sticker などのプロダクトに適している。
  • WebP saves 80% over PNG.
  • WebP は PNG の 80% に、データ量を低減する。
  • For older versions of Android the images are transported using WebP but transcoded on the client to JPEG for rendering on the device.
  • Android の古いバージョン用のイメージは、WebP を使って転送されるが、レンダリングのためにクライアント上で JPEG に変換される。

Network Quality Detection – Adjust Behavior to Network Quality

  • On the same network technology 2G, 3G, LTE, WiFi, connections speeds in the US were 2-3x faster than in India and Brazil.
  • 2G, 3G, LTE, WiFi といった、それぞれのネットワーク・テクノロジーにおいて、India や Brazil に対して U.S. は、2倍〜3倍の接続速度を有する。
  • LTE is often faster than WiFi, so you can’t just base the connection speed on technology.
  • 大半のケースにおいて、LTE は WiFi より高速であるため、テクノロジーの接続速度を論拠にはできない。
  • Built into the client the ability to:
  • Measure throughput on all large network transfers
  • 以下の機能を、クライアント内に作り込む:
  • 大規模ネットワークを通過する際のスループットを測定する。
  • Facebook servers provide a Round Trip Time (RTT) estimate in the HTTP header in every response
  • Facebook のサーバーは、すべてのレスポンスにおける HTTP ヘッダー内で、Round Trip Time (RTT) 推定値を提供している。
  • The client maintains a moving average of throughput and RTT times to determine network quality.
  • そのため、クライアントは、ネットワーク品質を判断するために、変動するスループットと RTT 時間の、平均値を保持できる。
  • Connections are bucketized into the following groups: Poor is < 150kbps. Moderate is 150-600kbps. Good is 600-2000kbps. Excellent is > 2000kbps.
  • 接続スピードは、以下のグループに分類される:Poor 150kbps 以下:Moderate 150〜600kbps:Good 600〜2000kbps:Excellent 2000kbps 以上。
  • Feature developers can adjust their behavior depending on the connection quality.
  • それらの接続品質に応じて、それぞれの機能の振る舞いを適正化していく。
  • Some possible responses based on quality:
  • その通信品質に基づき、いくつかの対策がある:
  • Increase/decrease compression.
  • Issue more/fewer parallel network requests. Don’t saturate the network.
  • 圧縮比の増減。
  • 並列ネットワーク・リクエストの増減。それにより、ネットワークをサチらせない。
  • Disable/enable auto-play video. Don’t cause more traffic on slow networks.
  • ビデオ自動再生の ON/OFF。 低速ネットワークでは、大量のトラフィックを要求しないようにする。
  • Pre-fetch more content.
  • より多くのコンテントを、プリ・フェッチする。
  • A tool developed at Facebook called Air Traffic Control supports the simulation of different traffic profiles. Each profile can be configured: bandwidth, packet loss, packet loss-correlation, delay, delay correlation, delay jitter. Extremely helpful in finding unexpected behaviour on slow networks.
  • Facebook では、内製のツールである Air Traffic Control により、各種のトラフィック・プロファイルのシミュレーションを行なっている。それそれのプロファイルは、帯域幅/パケット損失/パケット損失相関/遅延/遅延相関/遅延ジッタなどで構成されている。低速のネットワーク上で、予期できない動作などを見つけるのに、きわめて便利である。
  • There are buckets for videos, but not sure what they are.
  • ビデオ・トラフィックに関しては、その内容が不明である。

Prefetching Content

  • Issuing network requests for content ahead of when the content is actually needed on the device.
  • 実際にデバイスでコンテントが必要になる前に、ネットワーク・リクエストを発行する。
  • Prefetching is especially important on networks with high latency. Waiting to issue a download request for an image the user will be looking at a blank screen.
  • プリ・フェッチングは、とりわけ高レイテンシのネットワークで重要となる。イメージをダウンロードするリクエスト発行を待っているのでは、ユーザーにブランクの画面を見せることになる。
  • Issue network requests for feeds early in the app startup process so the data will be present when the feed is displayed to the user.  The download can occur in parallel with other initialization tasks.
  • アプリ起動プロセスで、フィードの先頭へのネットワーク・リクエストが発行されていれば、ユーザーに対して表示するときに、すでにフィードの準備が整うことになる。このダウンロードは、他のイニシャル・タスクと並行して、引き起こすことが可能である。
  • Keep a priority queue of network requests. Don’t block foreground network requests on background network requests or the user won’t see the data they are currently interested in.
  • ネットワーク・リクエストの、プライオリティ・キューを維持する。バックグラウンドのネットワーク・リクエストにより、フォアグラウンドのネットワーク・リクエストをブロックしてはならない。また、ユーザーが興味を持っているデータを、見せないような状況も避けるべきだ。
  • Monitor for overfetching and excess consumption of device resources. Over fetching could fill up the disk or waste a lot of money on the user’s data plan.
  • 過剰なフェッチングとデバイス·リソース消費をモニタリングする。フェッチングが行き過ぎると、全体的なディスク容量が不足し、また、データ・プランによっては、ユーザーのコストを増大させる。

Miscellaneous

  • Client uploading to servers. The idea is to send fewer bytes over the wire from the client to the server, which means resizing images on the client side before they are sent to the server. If an upload fails retry quickly. It’s usually just a problem in the pipe.
  • クライアントからサーバーへのアップロードに関しても、サーバーに送信する前にクライアント側でイメージをリサイズし、データ転送量を低減すべきである。アップロードに失敗した場合は、速やかに再試実行する。 一般的に、この問題はパイプ内のもとと認識すべきだ。
  • There are 20 different APKs (Android application package) for the Facebook app, cut by API level, screen size, and processor architecture.
  • Facebook アプリ用として、20種類の APK(Android Application Package)が存在する。 具体的に言うと、API レベルや、スクリーン・サイズ、プロセッサ・アーキテクチャなどにより分類されている。

Related Articles

Update: Instagram Improved Their App’s Performance. Here’s How.

ーーーーー

この長い記事を訳しながら、似ているなぁと思い始めてきたのが、Google の Street View 撮影部隊の話です。 どちらも、データセンターに積み上げたコンピューティング・パワーや、優秀な頭脳から生み出されるアルゴリズムでは解決の出来ない、労力と根気の世界の話です。 とは言え、このような労働集約型の作業に、膨大なリソースを投じるには、その正当性を裏付けるだけのストラテジーが必要です。 言い換えれば、途上国のマーケットに賭ける、Facebook の強い思いが生み出した唯一無二の方法論が、そこにあるはずなのです。 そして、そのノウハウを、こうして開示してくれる Facebook と、分かり易く整理してくれた Todd Hoff さんに感謝です。すばらしい!

ーーーーー

<関連>

FB+WhatsApp+Instagram のユーザー数は、世界の 1/3 に相当する 22億人だ!
Facebook の Graph API がアップデートされ、AD API も強化されたようだ!
Instagram が史上最大のマイグレ:200億枚のイメージを AWS から FB へ!
Facebook が買収し続けている特許の内容が、とても興味深い
Youtube と Facebook がモバイル・トラフィックの 1/3 を占有している

Comments Off on Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!

モバイル・ユーザーが使用するアプリは、平均で 30タイトルを下回る:それを示す1枚のチャート

Posted in Mobile, Post-PC, Research by Agile Cat on July 6, 2014

CHART OF THE DAY: Most People Don’t Use More Than 30 Apps Each Month
http://wp.me/pwo1E-7DR

Dave Smith – July 2, 2014
http://www.businessinsider.com/chart-of-the-day-most-people-dont-use-more-than-30-apps-each-month-2014-7

_ Business Insider

There are literally millions of mobile apps out there for you to download, but according to new data from Nielsen charted for us by Statista, there seems to be an “upper limit” to how many apps people actually use each month.

何百万ものモバイル・アプリが提供され、それらを誰もがダウンロードしているが、Nielsen の最新調査の結果をまとめた、この Statista のチャートによると、実際に人々が使用するアプリを1ヶ月という期間で区切ってみると、そこには「上限」があるように思えてくる。

_  space

Statista

On average, mobile users tend to use about 22 to 28 apps each month, with younger users spending more time using more apps on average.

その平均において、若年層のモバイル・ユーザーは、1ヶ月の間に 22〜28 種類のアプリを使用する傾向があり、また、それらのアプリを使用する時間も長いようだ。

Even more interesting: Though users are spending more time on mobile applications each year, the number of mobile apps actually used each month hasn’t changed much over the last few years.

さらに興味深いのは、人々がモバイル・アプリに費やす時間が、毎年のように伸びているのに対して、1ヶ月の間に使用されるタイトル数が、ここ数年において大きく変化していない点である。

ーーーーー

なるほどと思い、Agile_Cat も自分の Android デバイスを眺めてみましが(右のイメージをクリックで拡大)、たしかに、いつも使うアプリとなると、この画面に収まっているもの以外に、あと数本という感じです。おおまかなところで、メッセージ系、ソーシャル系、カレンダー系、メディア系、メモ・ドキュメント系で、あとは、迷子にならないためのマップ系と、写真や音楽という程度の使い方のようです。 そして、Nexus 7 になっても、用途として増えてくるのはリモート・デスクトップ系くらいであり、さらに言えば Mac のデスクトップを見ても、それほどの変化はありません。モバイルの使い方って限定されている感じがしますが、データの大半がクラウド上で整理され、コンピュータの使い方が、それくらいの範囲に上手く集約されてきたと捉えることも可能です。 自分なりの結論ですが、数年前までの PC だけに依存する環境と比べてみると、とても効率が良くなっていることを実感します。モバイル+クラウドは素晴らしい!

ーーーーー

<関連>

世界のメディアは モバイルのために存在する:それを示す1枚のチャート
ファブレットが絶好調になってきた:スマホとタブレットを上回る成長を1枚のチャートで
これからの5年で、アジアがモバイル市場を完全支配する:それを示す1枚のチャート
Chrome が Explorer をアメリカでも逆転: この大きな流れを Adobe の調査が裏付ける
Hybrid がクラウド・チャンプになるという、TechNavio の分析とは?

Comments Off on モバイル・ユーザーが使用するアプリは、平均で 30タイトルを下回る:それを示す1枚のチャート

Facebook モバイル艦隊の快進撃が始まる:それを示す1枚のチャート

Posted in Facebook, Google, Post-PC, Research by Agile Cat on May 8, 2014

Facebook’s Impressive Suite Of Mobile Applications
http://wp.me/pwo1E-7tr
Jay Yarow – Apr. 30, 2014
http://www.businessinsider.com/facebooks-impressive-suite-of-mobile-applications-2014-4

_ Business Insider

Earlier this week, we published a chart showing Google’s incredible opportunity based on all the billion user properties it owns. Today, we present Facebook’s version of the same chart.

Google は、10億超えのプラットフォームを、いくつか所有している。今週の初めに紹介したのは、その億単位のユーザープロパティをベースにした、信じられないほどのビジネス・チャンスを、Google が手にしていることを示すチャートである。そして今日は、それと同じ視点から、Facebook バージョンのチャートを提供する。

_  space

Statista/Business Insider

Right now, Facebook’s apps don’t have 1 billion users. But, it’s not hard to imagine WhatsApp and Instagram getting there eventually. And unlike Chrome, or Android, for Google,  it’s not hard to envision Facebook’s applications making a lot money.

これまでのところ、Facebook は自身のモバイル・アプリに、10億人のユーザーを紐付けてはいない。しかし、WhatsApp と Instagram が加われば、そのレベルに到達すると、簡単に想像できる。そして、Google における Chrome や Android とは異なり、たくさんのビジネスが Facebook アプリ上に生じると推測するのは、それほど難しいことでもない。

ーーーーー

TAG indexこうしてみると、WhatsApp の買収が、とても大きな結果をもたらしていることが分かりますね。 まぁ、2兆円の買い物なのですから、そうでなければ困りますが・・・ 🙂 そして、文中で紹介されている、Google の 億単位ポートフォリオを眺めてみると、なにがなんでも WhatsApp を買収したかった、Facebook の立ち位置も見えてきます。 そして、Google は Project Loon で、また、Facebook は Internet.org でと、モバイルでアクセスできる世界を広げようとしているわけですが、その背景も見えてくるように思えてきます。 __AC Stamp 2

ーーーーー

<関連>

快速 WhatsApp は、すでに5億ユーザーに到達している!
① 買収額の $19 Billion を、歴史の中に位置づけてみる
② 10億人というユーザー数に、Facebook よりも早く到達できるのか?
③ Facebook を上回る、ユーザーを惹きつけるパワー
④ Skype や Line と、どのように世界を住み分けているのか
⑤ 今年の試算だと、テレコムたちは $33 Billion も奪い取られる
⑥ キャリアの SMS ビジネスを、メッセージ・アプリたちが破壊する

Comments Off on Facebook モバイル艦隊の快進撃が始まる:それを示す1枚のチャート

%d bloggers like this: