Agile Cat — in the cloud

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

iOS から Android へ : Facebook は優先順位を切り替えるのか?

Posted in .Selected, Apple, Facebook, Google, Mobile, Post-PC by Agile Cat on December 9, 2014

Facebook Is Seeing More And More App Developers Go Android-First
http://wp.me/pwo1E-85q
Jim Edwards – Nov. 5, 2014
http://www.businessinsider.com/facebook-sees-android-first-app-developer-trend-2014-10?&platform=bi-androidapp

_ Business Insider

Facebook is seeing a trend in Europe of app developers going "Android-first."

Facebook は、ヨーロッパにおけるアプリ開発者の、Android-First へと移りゆく動向を注視している。

That’s significant because for years, Apple’s iOS operating system for iPhone and iPad has been the preferred first stop for any company launching an app. If an app succeeds on iOS, then only later will a company think about making a version for Android. Often months or years later, and sometimes never.

それが、大きな意味を持つのは、この数年にわたり iPhone と iPad で走る Apple の iOS が、あらたなアプリを立ち上げる、あらゆる企業が最初に取り組むプラットフォームとして、不動の地位を維持し続けてきたからである。そして、対象となるアプリ が iOS 上で成功した後にのみ、デベロッパーたちは Android バージョンを考えるというのが常である。多くの場合、それらのアプリの iOS 版と Android 版には、数ヶ月から数年の時間差があり、時には iOS のみというケースもあった。

Stephan Ridgway
Flickr, CC

That’s why Android apps tend to look and feel a bit second-rate compared to the same apps on iPhone — they often are just that. The iOS/Android split is weird because globally 80% of users are on the Android system, yet iOS and its roughly 10% of users are the top priority for developers.

そこに、Android アプリののルック&フィールが、同じアプリの iPhone の二番煎じになりやすい理由があるのだ。そして、実際に、そのようなケースが多々ある。グローバル・ユーザーの 80% が Android システムを利用している一方で、およそ 10% という iOS のシェアが、開発者にとってトップ・プライオリティになっている。 それなのに、iOS と Android のアプリを切り分けるのは、ちょっと奇妙な選択となる。

So it would be dramatic for companies to reverse that trend.

つまり、トレンドが逆転するという、ドラマティックな展開もあり得るのだ。

Yet that is what Facebook is seeing among some companies in Europe, according to Facebook’s Europe, Middle East, and Africa platform director, Julien Codorniou. Developers are beginning to sense that because more people are Android users than Apple users, they’re losing money by working on the smaller iOS platform first, he told Business Insider UK.

しかし、Facebook はヨーロッパにおいて、いくつかの企業の動きを見続けていると、同社の Europe, Middle East, and Africa Platform Director である Julien Codorniou は Business Insider UK に述べている。そして、デベロッパーたちは気付き始めているのだ。Apple ユーザーよりも Android ユーザーの方が多数を占め、また、最初に規模の小さい iOS プラットフォームに対応することで、ビジネス・チャンスを失っていることに。

Historically, Apple has been the preferred platform. Apple’s higher-income users are often more lucrative targets for app advertisers and in-app payments and shopping. It’s also simpler for developers to use, Apple has only one version of iOS running at any one time (the newest one) and the vast majority of Apple users keep their devices updated to the newest version. Android, by contrast, is "fragmented" into several different versions across hundreds of different phones — and all those versions are a headache for developers who must make a separate app tailored for each one.

歴史的にみて、Apple は好ましいプラットフォームだと捉えられている。 Apple のユーザーは高所得者に偏っているため、広告/アプリ/ショッピングを展開する際に、ビジネスのターゲットに成りやすいのである。その一方で、デベロッパーにとっても、取り組みやすい環境となっている。つまり Apple は、常に最新の iOS バージョンのみをプッシュし、大半の Apple ユーザーは最新バージョンにアップデートされたデバイスを手にしている。それとは対照的に、Android は各種のスマホ上の、各種のバージョンとして「断片化」されている。 そして、それらのバージョンごとの、個別アプリを開発する必要性が、デベロッパーにとって頭痛の種となる。

Julien Cordoniou: "People look at the numbers. They want downloads, installs. They know that the monetization is catching up on Android."

But Codorniou told us Facebook has a team of evangelists encouraging Android developers to use Facebook as a way to build and promote their apps: "As of today, I have four guys from my team in Paris talking to Android developers about the greatness of Parse, Facebook login, app links, app events. It’s a very important bet for us."

しかし、Codorniou が言うには、デベロッパーたちが自身のアプリを構築し、プロモートするための手段として Facebook を活用するよう、Android の開発環境を支援するためのエバンジェリスト・チームがあるようだ。そして、 「現時点において、4人で構成されるチームが Paris にある。そして、Parse/Facebook LogIn/App Link/App Event の素晴らしさを、Android デベロッパーたちに説明している。 それは、私たちにとって、きわめて重要な賭けである」と、私たちに語ってくれた。

Wait, Android developers? Android-first, really?

なぜ、Android デベロッパーなのか? ほんとうに、Android-First を考えているのだろうか?

"People look at the numbers," he says. "They want downloads, installs. They know that the monetization is catching up on Android. Of course iOS is the better platform when it comes to monetization, but it’s easier to update your app on Android. There are many people on an Android phone. … The world you described [in which Apple is dominant] was true a year ago, but I see that things are changing."

彼は、「 開発者たちは、数字に注目している。彼らは、数多くのダウンロードとインストールを望んでいる。そして、Android におけるマネタイズが、iOS を捕まえかけていることを知っている。もちろん、マネタイズに関しては、iOS の方が優れたプラットフォームであるが、Android アプリのアップデートも簡単になっているのだ。周知のとおり、Android フォンには、膨大なユーザー数がある。あなた方が、Apple が支配する世界と説明してきたことは、1年前には本当だったが、物事が変化していることを、私は目にしている」と述べている。

"The vision we have with Parse and with the platform in general is to accelerate the time to market. It should not take you six months to develop from iOS to Android."

そして、「Parse と汎用プラットフォームを活用する、私たちのビジョンにより、出荷までの時間が大幅に短縮される。 iOS から Android に切り替わったとしても、その開発のために、6ヶ月も要することなど、あり得ないはずだ」と、彼は続ける。

"There is a pattern coming from Eastern Europe. The Russian developers develop on Android first because of a big audience, and it maybe being easier to develop. They liked the fact that they could submit a new version of the app every day. [With Apple, you have to get each new version of the app approved before it hits the App Store. There is no version-approval system for Android.] This is a trend that I see and I think it is going to accelerate."

最後に、「 Eastern Europe で生まれた、開発のパターンがある。それは、Russian のデベロッパーたちの進め方であり、多数のユーザーがいる Android の優先順位を上げるが、おそらく容易な開発を実現している。彼らは、新しいバージョンのアプリを、毎日のようにサブミットできる状況を好んでいる。Apple の場合には、App Store に出す前に、それぞれのバージョンについて承認を得なければならない。 しかし、Android では、バージョンに関する承認の仕組みは存在しない。そこに、Android が加速している要因があると、私は見ている」と、彼は述べていた。

Do you work at an app developer that switched to go Android first? Contact Business Insider UK at jedwards@businessinsider.com to tell us your story.

ーーーーー

途上国マーケットを支援するための Internet.org を作り、貧しい人々のためにインターネット環境を整備しようとしている Facebook にとって、Android ファーストへの転換は、きわめて整合性の高い戦略となるはずです。 とは言え、Apple 自体に対してはまだしも、iOS エコシステムを構成するデベロッパーには、気遣うことになりそうですね。 また、Facebook の収益の 66% が、モバイル広告からもたらされていることを考えれば、いずれは Android ファーストになっていくのでしょう。 問題は、そのタイミングですが、いつ頃なのでしょうか? とても気になりますね。

ーーーーー

<関連>

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

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 を占有している

Facebook の Graph API がアップデートされ、AD API も強化されたようだ!

Posted in Advertising, API, Facebook, Open Graph by Agile Cat on November 18, 2014

Facebook Releases Updated Graph API
http://wp.me/pwo1E-825
David Cohen – October 30, 2014
http://allfacebook.com/graph-api-2-2_b135773

_ All Facebook

Facebook announced the release of version 2.2 of its Graph API and updated software-development kits for iOS and Android to support the updated application-programming interface, also revealing that its ads API now supports versioning.

Facebook が、Graph APIVer 2.2 のリリースについて発表した。そして、最新の API をサポートするために、iOSAndroidi の SDK をアップデートし、さらには、バージョニングをサポートすることになる、Ads API についても明らかにした。

Software engineer Mahesh Sharma wrote in a post on the Facebook developer blog that applications created starting Thursday may only call version 2.2 of the Graph API or greater, adding that version 2.1 will be depreciated Oct. 30, 2016.

ソフトウェア・エンジニアである Mahesh Sharma は、この木曜日(10/30)以降に作成されるアプリのみが、Graph API の Ver 2.2 を利用できるようになり、また、2016年10月30日には、これまでの Ver 2.1 は価値を失うと、Facebook Developer Blog で述べている

Facebook had announced at its F8 global developer conference in San Francisco April 30 that version 1.0 will be depreciated April 30, 2015.

なお、今年の 4月30日に San Francisco で開催された、F8 Global Developer Conference で Facebook は、 2015年4月30日に Ver 1.0 が終了することも発表している。

Sharma offered some highlights of new features of version 2.2, saying that the full list of additions, changes and depreciations can be found in the change logs for the Graph API and the iOS and Android SDKs, as well as the upgrade guide:

Sharma は、Ver 2.2 の新機能から、いくつかのハイライトを提供している。具体的には、Graph API および iOSAndroid SDK のために、追加/変更/廃棄のフル・リストが、更新ログ内で参照できるようになり、また、Upgrade Guide も提供されると言及している:

  • アプリ群からプログラムを介して、ページ・ポスト上のコメントを表示/非表示に設定できる。
  • ユーザー・オブジェクト上に新たに提供される token_for_business フィールドにより、1つの企業が所有するマルチ・アプリ間をまたいで利用するユーザーを、容易に特定できるようになる。
  • そのために特化された subscribed apps edge を経由して、ページ・サブスクリプションをリアル・タイムで更新するための、新たな管理手法を提供する。
  • ページ・ノードおよび settings edge を介した API により、より詳細なページ属性の編集が実現される。

Sharma wrote on the addition of support for versioning to the ads API:

Sharma は、Ads API のバージョニング・サポートについて、以下の項目を追記している:

We recently announced new access levels for the ads API. In addition, from v2.2 onward, the ads API now supports versioning.

先日、私たちは、Ads API に関する、新しいアクセス・レベルについて発表した。 また、V2.2 以降より、Ads API はバージョニングをサポートするようになる。

For developers using the ads API, versioning means increased control over how you opt into new ads API features. Rather than changing a migration setting in your app dashboard, you can now control the behavior by specifying the version number in your client codebase.

Ads API を使用するデベロッパーがバージョニング機能を利用すると、新しい Ads API 機能にオプトインする際の、コントロールの幅が広がるようになる。それぞれのアプリのダッシュボードで、マイグレーション設定を変更するのではなく、クライアント・コード・ベースのバージョン番号を指定することで、その動きをコントロールできるようになる。

Our advertising products continue to evolve at a fast pace. To ensure that developers take advantage of this progress, the ads API will follow a 90-day breaking-change policy. To make this behavior clear, ads API methods will be removed from a version 90 days after the next version is released.

私たちのアド・プロダクトは、きわめて速いペースで進化し続けている。そのアドバンテージを、デベロッパーに対して保証するために、Ads API は 90日間のブレーキング・チェンジ・ポリシーに従う。具体的に言うと、Ads API における各メソッドは、次のバージョンがリリースされた90日後に削除されることになる。

As v2.2 is the first release for the ads API, ads API methods will be removed from v1.0, v2.0 and v2.1 in 90 days’ time. Developers using the Ads API should update their apps to call v2.2 before Jan. 28, 2015. After that date, all calls to ads API methods that do not specify v2.2 (including calls that do not specify any version) will result in an error.

v2.2 の Ads API が最初にリリースされた時から、90日が経過した時点で、古い広告 API メソッド群は、V1.0/V2.0/V2.1 から削除されることになる。Ads API を使用しているデベロッパーは、2015年1月28日以前に、自身のアプリから V2.2 を呼び出すよう、変更する必要がある。その日以降、V2.2 で指定されていない、すべての Ads API メソッド群への呼び出しは(バージョンを指定しない呼び出しも同様)、エラーを返すことになる。

For full details on the changes to the Ads API in v2.2, see the ads API blog and the dedicated ads API change log and upgrade guide.

Ads API V2.2 での変更に関する詳細は、ads API blog で参照できる。 また、専用の ads API change log および upgrade guide も参照して欲しい。

Finally, Sharma reminded developers of policy changes tied to the release of version 2.1 of the Graph API, which take effect at the end of their 90-day depreciation period, Nov. 5:

最後に、Sharma はでデベロッパーに対して、Graph API Ver 2.1 のリリースに関連する、ポリシーの変更について再確認している。それは、Facebook が規定した 90日後となる、11月5日に廃棄されることになる:

The recommendation bar plugin is deprecated and will stop appearing on your pages after Nov. 5. Please remove the <fb:recommendations-bar/> XFBML tag from your pages at the earliest opportunity.

Recommendation Bar プラグインが廃止されるため、11月5日以降は、ページ上での表示が行われなくなる。できるだけ早い時期に、ページの <fb:recommendations-bar/> XFBML タグを削除して欲しい。

You must not incentivize people to use social plugins or to like a page. This includes offering rewards, or gating apps or app content based on whether or not a person has liked a page. From Nov. 5, the liked field within the page property of the signed_request object will return true for all apps created before Aug. 7, 2014, when those apps are rendered inside a page tab.

ソーシャル・プラグインおよびページへの LIKE を用いて、人々にインセンティブを提供してはならない。つまり、人々がページに LIKE を付けていてもいなくても、賞金/アプリ/コンテンツなどを含む、一切の利益供与は禁止される。 11月5日以降、signed_request オブジェクトのページ・プロパティ内の LIKE フィールドは、2014年8月7日以前に作成されたアプリに関して、それらがページ・タブの内側にレンダリングされるときに、True を返すようになる。

The insights edge will be removed from the application object in v1.0 and v2.0. You should update your apps to call /v2.1/{app_id}/app_insights or /v2.2/{app_id}/app_insights to take advantage of the new app insights API.

V1.0/V2.0 の Application オブジェクトから、insights edge は削除されることになる。 新しい App Insight API のアドバンテージを得るためには、以下を呼び出すよう、あなたのアプリをアップデートする必要がある。

/v2.1/{app_id}/app_insights or /v2.2/{app_id}/app_insights

Developers: What are your initial thoughts?

デベロッパーたちへ:あなたの第一印象は どうだろう?

Related Stories

ーーーーー

今年の 2月に、「Facebook が Open Graph の デベロッパー・コレクションを停止した:とても残念!」という抄訳をポストしましたが、Graph API 自体は残っていたのでしょうね。 いずれにしろ、Facebook が Graph という考え方を捨てることはないはずであり、デベロッパーに開放する API を、新たに整理し直しているように思えます。 いずれにしろ Graph API は面白そうですし、Facebook のアーキテクチャとストラテジーを理解する重要な切り口になるはずなので、とてもワクワクしています。 そして、Open Graph というカテゴリを、残しておいて良かったと思っています :)

ーーーーー

<関連>

Facebook の News Feed は、どう 変わったのか? なぜ 変わったのか?
Facebook が提供する、Open Graph のベスト・プラクティスとは?
Facebook の超高速ストレージ : TAO の詳細を説明しよう
Facebook が発表した TAO : これで MySQL と Memcached を接続する
Facebook は Open Graph へと ユーザーを誘う

Facebook がビッグ・ウェーブに乗った:すでに収益の 66% をモバイルから稼いでいる!

Posted in Advertising, Facebook, Mobile by Agile Cat on November 15, 2014

CHART OF THE DAY: All Of Facebook’s Revenue Growth Is Coming From Mobile Ads
http://wp.me/pwo1E-81x
Dave Smith – Oct. 28, 2014
http://www.businessinsider.com/chart-of-the-day-facebook-growth-comes-from-mobile-ads-2014-10

_ Business Insider

Facebook reported earnings for its fiscal third quarter of 2014 on Tuesday. Revenue and earnings per share were slightly above Wall Street’s expectations — it reported $3.2 billion in total revenue and $2.96 billion in ad revenue, a 64% increase from the year-ago quarter — but other metrics like monthly active users fell right in line.

Facebook は、この火曜日(10/28)に、2014年 Q3 の業績をレポートした。 収益および EPS は、わずかに Wall Street の予想を上回ったが($3.2 billion の収益/$2.96 billion の広告収入/64% の前年比成長)、MAU などの指標は期待値を下回ってしまった。

_  space

Business Insider Intelligence

Based on company data charted for us by BI Intelligence, most of Facebook’s revenue growth is coming from mobile advertising and payments. Non-mobile revenue and revenue from payments and fees like in-app purchases through Facebook continue to remain consistent, but mobile revenue has exploded since 2012, as it now makes up roughly 66% of Facebook’s total revenue.

しかし、BI Intelligence がチャート化してくれた同社のデータを見ると、Facebook における成長の大半が、モバイルに関連する広告と支払いから生じていることが分かる。モバイルを除いたところで(PC など)、その広告収益と、アプリ販売などは、一定のレベルを保っているが、2012年に立ち上がったモバイル・ビジネスが、爆発的な成長を遂げていのだ。 そして、いまでは Facebook の収益全体の、66% を占めるに至っている。

SEE ALSO: CHART OF THE DAY: Twitter Is Having A Hard Time Attracting New Users»

ーーーーー

昨日にポストした、Android の MAU が 11.5 億に近づいている のチャートと、なんとなくイメージが重なりますね。 どちらもグローバルのデータであり、飽和しつつある欧米のマーケットから、果敢に飛び出していった結果なのです。 それにしても、約 2年の間に、その収益構造を大きく転換してしまった、Facebook のスピードは圧巻です。この決算の詳細に関しては、Facebook の 2014 Q3 決算を分析する を参照してください。

ーーーーー

<関連>

モバイル・アドの急成長:2018年には全米デジタル広告の 50% を超えるだろう!
モバイル広告:トラッキング/自動入札/ビデオが、広告の在り方を激変させる
Facebook アドが 外の世界へ: Atlas が Google に 本気で挑んでいく
Google の収益構造を分析してみた:その気になるポイントとは?
Facebook 脅威の Q2 決算:3000 億円の売上げと 48% の粗利率 !

クッキーは死んだ:そして Facebook/Google/Apple の広告が激変している

Posted in .Chronicle, .Selected, Advertising, Apple, Facebook, Google, Mobile, Post-PC, Strategy by Agile Cat on November 12, 2014

The cookie is dead. Here’s how Facebook, Google, and Apple are tracking you now
http://wp.me/pwo1E-80T
October 6, 2014 – Richard Byrne Reilly
http://venturebeat.com/2014/10/06/the-cookie-is-dead-heres-how-facebook-google-and-apple-are-tracking-you-now/

_ VB

The lifespan of the tracking cookie is about to expire. With the rapid emergence of mobile devices, the big three — Facebook, Google, and Apple — have turned to new and more potent methods for advertisers to keep track of you across multiple devices.

クッキーのトラッキングという手法だが、その寿命が尽きようとしている。モバイル・デバイスの急速な台頭により、Big-3 である Facebook/Google/Apple は、マルチ・デバイスを前提としてユーザーを追跡する、より新しく強力な手法を、広告主のために作りだそうとしている。

Image Credit
SVLuma
Shutterstock

The impending death of the cookie can be traced to the launch of the iPhone in 2007. Apple decided to disable cookie functionality in iPhones because it believed advertisers would be able to garner too much personal information as they tracked you across websites, according to Medialets chief executive Eric Litman. Third-party cookies still work on Google’s Chrome browser and the Android OS, but they don’t function effectively on a large number of smartphones and tablets produced by other companies. Also, because cookies can only track you while you’re using a browser — not a mobile app — they have very limited relevance on mobile devices.

クッキーに差し迫った死であるが、その発端は、2007年 の iPhone の発売まで遡ることになる。Medialets の CEO である Eric Litman によると、複数の Web サイトをまたいでユーザーを追跡するのは、あまりにも多くの個人情報を、広告主が集めすぎるという考えに基づき、Apple は iPhone のクッキー機能を無効にすることに決めたのだ。サードパーティのクッキーは、依然として Google の Chrome ブラウザおよび、Android OS 上で動作しているが、その他の企業が作成した多様なスマホやタブレットの上では効果的に機能していない。さらに言えば、クッキーはブラウザ上のみで有効であり、モバイル・アプリ上でのトラッキングができない。つまり、モバイル・デバイス上のクッキーは、きわめて限定された関連性を持つのみである。

Here’s how each of the big mobile players is trying to replace the cookie with its own brand of tracking.

それらのモバイル・ビッグ・プレイヤーたちが、自身のトラッキング手法を用いて、どのようにクッキーを置き換えようとしているのか、以下に示していく。

Facebook

For Menlo Park, Calif.-based Facebook, it all comes down to the billions of metric tons of highly personal metadata the company has amassed from its 1.3 billion users, such as shoe size, hair color, where your grandmother is buried, and where you went to school, for example.

Menlo Park, Calif. ベースの Facebook には、1.3 billion のユーザーから集まってくる、気の遠くなるほど膨大で、きわめてパーソナルなメタ・データが降り注いでいる。それらのデータには、靴のサイズや髪の色だけではなく、祖母の眠る墓地や、通っていた学校まで含まれる。

The social network relies on its SSO (Single Sign-On) to follow the movement of users. SSO allows you to use your Facebook credentials on third-party websites and apps. When you do this, Facebook is watching, following, and cataloging your destination points. This data drives, to a degree, what ads turn up on your Facebook news feed. Maybe you’ve noticed.

このソーシャル・ネットワークは、ユーザーの動きを追いかけるために、SSO(Single Sign On)という仕組みに依存している。SSO を利用するユーザーは、サードパーティの Webサイトやアプリに、自身の Facebook のクレデンシャルを適用することも可能だ。そのような操作が行われると、ユーザーのディスティネーションは、Facebook により参照/追跡され、さらにはカタログ化されることになる。このデータにより、ユーザーの Facebook のニュース・フィードにアップされる広告が、ある程度まで絞り込まれることになる。おそらく、誰もが、それに気づいている。

Facebook-owned apps, WhatsApp and Instagram, along with the company’s internally developed apps like Messenger and Paper, increase the data flow, though for now, these apps don’t yet feature ads.

Facebook は WhatsApp と Instagram を所有しており、Messenger や Paper といったアプリも内製している。それらが、データ・フローを増加させているが、現時点では、まだ広告を展開していない。

But this method only works within Facebook’s ecosystem. The company is looking to expand and recently unveiled a new version of the Atlas ad platform (which Facebook acquired from Microsoft last year) at Advertising Week in New York. The new platform is Facebook’s attempt to serve ads outside its existing ecosystem, on both desktop and mobile.

しかし、この手法は、Facebook エコシステム内だけで機能するものである。同社は、それを拡大していくが、先日に New York で開催された Advertising Week では、広告プラットフォームである Atlas の新バージョンを発表している(昨年に Microsoft から買収)。この新しいプラットフォームにより、Facebook は自身のエコシステムの外側で、デスクトップとモバイルの両方に広告を提供しようとしている。

Google

Like its Facebook friends just down the freeway, Google also relies heavily on its SSO. Logging into any of your Google accounts ties you to the entire Google network, which is massive.

Facebook のトモダチがフリーウェイを駆け下りてくるように、Google も自身の SSO に大きく依存している。つまり、ユーザーが Google の何処かにログインすると、その広大な Google ネットワーク全体と結び付けられることになる。

And then of course, Google has its Android mobile operating system, which assigns each user a Google Ad ID. Many of Google’s ad products — AdSense, AdMob, and DoubleClick — pull in your device’s ad identifier. Together with the information it already has from its many web properties, including YouTube, Gmail, Voice, and Search, the company can compile a dossier, as it were, of your digital history. The websites you visit tell Google plenty, and the information comes in handy no matter what device you’re using.

そして Google は Android モバイル OS を持っているため、そのプラットフォーム上の各ユーザーは、Google Ad ID を割り当てられることになる。そして、Google における多様なアド・プロダクトである、AdSense/AdMob/DoubleClick などが、ユーザー・デバイスの Ad ID を引き出していく。 YouTube/Gmail/Voice/Search といった、Web プロパティに取り込まれている情報を集約することで、ユーザーのデジタル・ヒストリーとも言える関連書類一式を、同社は容易に編纂することが可能となる。どのようなデバイスを利用していようと、ユーザーが訪問した Web サイトが、完全かつ使い易い情報として、Google に伝えられるようになる。

Apple

As for Apple, its tracking techniques are focused primarily on two things: your email address, which ties you to all of Apple’s services running on any iOS or OS X device, and your iTunes account, which gives Apple your credit card data and ties you most closely to its ecosystem.

Apple におけるトラッキング技術は、主として 2つの項目にフォーカスしている。1つはメール・アドレスであり、あらゆる iOS/OS X デバイス上で実行されている、すべての Apple サービスを結び付けている。もう1つは、iTunes アカウントであり、ユーザーのクレジットカード・データを Apple に提供させることで、そのエコシステムとの間で最も密接な関係を構築していく。

Your login identity is tied to your Apple “identifier for advertisers,” or IDFA. It’s a unique string of characters assigned to every user buying and using an iOS device. So when ads run on Apple’s advertising network iAd for example, Apple is able to determine who’s receiving the ad, and potentially to connect that back to everything that person did elsewhere in Apple’s system.

ユーザーのログイン ID は、Apple の IDFA(Identifier For Advertisers)と接続されている。それは、すべてのユーザーが購入/使用している iOS デバイスに割り当てられた、ユニークな文字のことである。したがって、Apple の広告ネットワークである iAd で、なんらかの広告が展開されるとき、Apple は広告を受け取ったユーザーを識別できる。そして、Apple システムの何処かで実施された、すべての事柄の履歴に対して、接続するという可能性も有する。

Fix it, or opt out

If that’s not enough, many big advertisers also rely on extremely detailed data from third parties like LiveRamp and Experian. LiveRamp, for instance, can deliver clients huge volumes of data about everyday online transactions with only a single email address. And these companies can tell whether an ad displayed to an online user led to a purchase at a store.

それでも不十分だという場合だが、大手広告主の大半は、LiveRamp や Experian といったサードパーティから、きわめて詳細なデータを取得するようになる。実際のところ LiveRamp の場合は、日々のオンライン・トランザクションの中から、単一の電子メール・アドレスと結び付けられる、膨大なデータをクライアントに提供できる。それらの企業は、オンラインでユーザーに示された広告が、現実の店舗における購入行動につながったのかどうかを、見分けることも可能にする。

“Google, Apple, and Microsoft, as the dominant operating system vendors, could easily fix this problem of cross-device user identification for advertising in a consistent, privacy-friendly way if they wanted to,” Litman said. “IDFA and Google AdID are steps in the right direction, and hopefully Apple and Google will continue to improve them and and create a standard that everyone can support.”

Litman は、「 OS を支配するベンダーとしての Google/Apple/Microsoft は、その必要性に応じたプライバシー・フレンドリーな方式で、広告のためのクロス・デバイス・ユーザーの識別という問題を、一貫性を保持しながら実現できるだろう。 IDFA と Google の Ad ID は、正しい方向への踏み出している。 それらを、Apple と Google が改善することで、誰もがサポートできるスタンダードが、うまく構築されることを願っている」と述べている。

But it’s also crucial to remember that, whether you’re using an iOS or Android device, you are able to turn off most of the tracking mechanisms — the settings menus of both operating systems help you do this.

しかし、忘れてはならないのは、あなたのデバイスで iOS が走っていようが、Android が走っていようが、そのトラッキング・メカニズムの大半を解除できる環境が必要になるということだ。 双方のオペレーティング・システムにおける設定メニューが、それを実施するのに役立つ。

And for people who don’t want to be tracked by Atlas, Eyeo released an updated version of its popular AdBlock browser plug-in, AdBlock Plus, on October 1.

なお、Atlas にトラッキングされたくない人々のためには、Eyeo の Ad Block Plus がある。この、ポピュラーな AdBlock ブラウザ・プラグインの、アップデート・バージョンが 10月1日に提供されている。

ーーーーー

モバイルへの移行が上手くいっている Facebook と、なかなか上手くいかない Google という対比を、いろいろなところで見ますし、この Agile_Cat でも何度か ご紹介してきました。 しかし、このポストを見つけるまで、その背景や経緯を、分かり易く説明してくれるものに、お目にかかったことがありませんでした。 ーーー いくつかのキーワードでググってもみましたが、2013年2月26日の TechCrunch の、Appleがクッキーを利用しているアプリを拒絶へ: Ad Identifierへの統一がねらい といものが、唯一の関連記事でした。 ーーー Google が全力で Andorid を立ち上げた背景にも、Facebook が早々にモバイル・アプリにシフトした背景にも、この クッキーの廃止に関連する、ターゲティング広告の手法が絡んでいたのでしょうね。 なんというか、自分にとっての大きなナゾが解けて、とてもスッキリした気分です。

ーーーーー

<関連>

Facebook の 2014 Q3 決算を分析する:モバイル広告の伸びがスゴイ!
モバイル・アドの急成長:2018年には全米デジタル広告の 50% を超えるだろう!
モバイル広告:トラッキング方式/自動入札/ビデオが、広告の在り方を激変させる
Facebook アドが 外の世界へ: Atlas が Google に 本気で挑んでいく
モバイル・アドに苦悩する Google と、答えを見つけ出した Facebook

Facebook の 2014 Q3 決算を分析する:モバイル広告の伸びがスゴイ!

Posted in Advertising, Businesses, Facebook, Mobile by Agile Cat on November 11, 2014

Facebook continues strong earnings streak
(and WhatsApp and Instagram aren’t even making real money yet)
http://wp.me/pwo1E-80K
Carmel DeAmicis Oct 28, 2014
https://gigaom.com/2014/10/28/even-without-revenue-from-mobile-acquisitions-facebook-continues-strong-earnings-streak/

_ Giga Om

Summary: Facebook just introduced ads on Instagram, and hasn’t tried to make money off WhatsApp yet, but the company’s revenue is robust nonetheless.

Summary:  Instagram に広告を導入したばかりの Facebook だが、WhatsApp におけるマネタイズには手を付けていない。 とは言え、同社における売上は、順調に伸びている。

ーーーー

Facebook beat analyst expectations for the ninth straight quarter in its third quarter earnings report Tuesday. Here are the numbers:

この火曜日(10/28)に発表された Facebook の収支報告だが、9つの四半期を通じて、アナリストたちの予測値を上回る結果となった。以下に、その数字を列挙する:

photo:Thinkstock

Revenue:

Analysts expected — $3.12 billion

Facebook actual — $3.20 billion

Earnings per share:

Analysts expected — $0.40

Facebook actual — $0.43

Monthly active users:

2nd quarter 2014: 1.32 billion

This quarter: 1.35 billion

Despite Facebook’s strong showing, its stock dipped a bit — 2 percent — in after-hours trading. Investors may have hoped for accelerated user growth, and Facebook’s user acquisition decelerated this quarter (just as it did at Twitter). That deceleration was by less than one percent, though.

Facebook が強さを見せつけたにもかかわらず、その発表が行われた後の時間外取引で、同社の株価は 2% ほど低下した。投資家たちは、ユーザー数の増大に期待していたようだが、その比率が少しだけ低下したのだ(Twitter と同様)。とは言え、Q2 と Q3 の比較において、その減速率は 1% 未満に過ぎない。

_  space

_  space

Stock fell even further during the earnings call, down ten percent, possibly because Facebook had conservative estimates for its revenue during the holiday quarter.

この収支報告が行われている最中に、Facebook 社の株価は 10% ほどダウンしたが、この Q4 における収益の見通しについて、同社が控えめな数字を示したからだと思われる。

Otherwise, though, the company looks to be very healthy. It pulled in $2.96 billion in advertising revenue, and its mobile monthly active users totaled 1.12 billion, a whopping 83 percent of its general monthly active users. Facebook has solved the problem of making money off users on smartphones, with 66 percent of its advertising revenue coming from mobile.

しかし、そのような状況にならなければ、同社は順調に成長していくだろう。同社は、広告収入として $2.96 billion を計上し、また、モバイル MAU(monthly active users)は 1.12 billion となり、全 MAU の 83% に到達したのだ。そして Facebook は、広告収入の 66% をモバイルから稼ぎ出し、スマートフォンおけるマネタイズという問題を解決している。

All this progress is occurring before Facebook has even started seriously tapping its key mobile properties, messaging service WhatsApp and photo sharing site Instagram. Instagram is in the early stages of experimenting with promoted images from advertisers. When ads are put into full swing, Instagram is expected to rake in boatloads of cash for Facebook. WhatsApp doesn’t have ads at all (yet).

つまり、すべての進捗は、メッセージング・サービスの WhatsApp や、フォト共有サイトの Instagram といった、Facebook が大切にしているモバイル資産を、真剣になって揺り動かす以前に発生している。Instagram に関しては、広告主のプロモーション・イメージを用いるという、実験の初期段階にある。この広告がフル回転すれば、Instagram は Facebook のために、莫大なキャッシュをすくい上げてくると予想される。さらに言えば、依然として WhatsApp は、まったく広告を行なっていない。

_  space

_  space

During the earnings call, CEO Mark Zuckerberg was asked about his “portfolio approach” to apps, and whether standalone products like WhatsApp and Instagram actually hurt Facebook’s user metrics. He denied that was the case, and said that consumers can expect more standalone apps from Facebook in the future. “The use cases for products like Instagram and WhatsApp are actually more different and nuanced than the products Facebook built,” Zuckerberg told the analyst. “[Facebook] Messenger and WhatsApp are growing quickly in a lot of the same countries…which suggests they’re more different than you would intuitively have thought.”

この収益報告において CEO である Mark Zuckerberg は、アプリに関する自身のポートフォリオ·アプローチについて質問を浴びていた。 つまり、WhatsApp や Instagram といった独立したプロダクトが、Facebook の目指すユーザーに関する目標を妨げないかというものである。彼は、そのようなケースを否定した。 そして、将来的にみてコンシューマたちは、Facebook から切り離された数多くのスタンドアロン・アプリを望むだろうと述べている。「Instagram や WhatsApp といったプロダクトのユースケースは、Facebook が構築してきたプロダクツを微妙に異なる。Facebook の Messenger と WhatsApp は、たとえば同じ国においても、双方とも急速に成長している。つまり、直感的な思い込みとは、大きく異なるものがあると示唆している」と、Zuckerbergは アナリストたちに述べている。

This quarter Facebook relaunched the Atlas ad server to take on Google’s DoubleClick. Add that property to the company’s mobile ad Audience Network, and it’s a good time to be Facebook. As each month passes, the company looks less and less like a simple social media play and more and more like a multi-pronged behemoth to rival Google.

この四半期において Facebook は、Google の DoubleClick を追走するために、Atlas アド・サーバーをリニューアルしている。 そして、同社のモバイル広告である Audience Network に、この新しい資産を追加できることも、Facebook にとって良い結果をもたらすだろう。数ヶ月後の Facebook は、シンプルなソーシャル・メディアから多頭巨獣へと変容し、Google に対抗していくことになるのだろう。

Google acknowledges the competitor in its midst; on its earnings call last week Google even admitted it was following Facebook’s lead on mobile ad targeting.

Google は、誰が最大の競争相手なのかを知っている。先週に行われた同社の収支報告において、モバイルのターゲット広告で Facebook にリードを許していると、Google は認めているのだ。

This story was updated Tuesday afternoon with information from Facebook’s earnings call.

Related research

ーーーーー

この決算の焦点は、なんといってもモバイル広告の成長ですね! すでに、Facebook の広告収入における 66% が、モバイルから得られているという状況には、とても驚いてしまいました。 きっと、Google が聞いたら、地団駄を踏んで悔しがるほどの、素晴らしいモバイル戦略だと思います。 そして、年間を通じた売上に関しても、すでに1兆円企業の規模に達しています。 イイネをたくさん付けてあげたい気分です :) 

ーーーーー

<関連>

Facebook が買収し続けている特許の内容が、とても興味深い
Facebook アドが 外の世界へ: Atlas が Google に 本気で挑んでいく
モバイル・アドに苦悩する Google と、答えを見つけ出した Facebook
Facebook + WhatsApp + Instagram のユーザー数は、世界の総人口の 1/3 だ!
Facebook 脅威の Q2 決算:3000 億円の売上げと 48% の粗利率 !

%d bloggers like this: