LINEが目指す“理想の広告プラットフォーム”の仕組みと工夫

LINEが目指す理想の広告プラットフォーム

渡邉直樹氏：みなさま、こんにちは。サーバーサイドエンジニアとして広告プラットフォームの開発をしています、渡邉直樹と申します。よろしくお願いします。

演台の上に上がってみると、やや緊張するものですね。こちらのスライドの方は英語になっているんですが、もともとのタイトルは日本語です。「LINEが目指す理想の広告プラットフォーム」と題して、お話をさせていただきます。

最初に、みなさまに簡単なアンケートをしたいと思います。LINEのアプリの中で、広告を見たことがある方、挙手していただいてもよろしいでしょうか。

（会場挙手）

ありがとうございます。予想していたよりちょっと少ないですね。「LINEの広告」と聞いて、どこまでが広告で、どこからが広告ではないのかということがわからない方もいらっしゃると思います。

LINE Ads Platformでは、このようなかたちで広告を表示しています。

LINEアプリの中では、タイムラインとニュースタブ。LINEマンガは別のアプリですね。そしてスライドの一番左のLINE BLOGですが、こちらはWebのページになっています。

こうした様々な面に、様々なかたちで広告が表示されているのがおわかりいただけると思います。

LINE Ads Platformは、これらのLINEの広告面に広告を配信できる唯一のプラットフォームになっていて、なんと月間7,800万人ものユーザーに広告を出稿できる、国内最大規模の広告プラットフォームです。

Programatic advertisingの仕組みと特徴

プラットフォームの特徴としては、Programatic advertisingをサポートしている点です。このProgramatic advertisingは、あまり聞き覚えのない言葉かもしれません。実は私も、このスライドを作っていて、初めて使った言葉です。というのは、日本では「運用型広告」という呼び方のほうが主流になっているからです。

このProgramatic advertisingにはいくつか特徴があります。

1つ目の特徴は、広告主がリアルタイムに、予算や広告を配信する対象を変更できるという点です。2つ目の特徴は、Pay per click、つまり成果報酬型で、クリックや動画が再生されて、初めて課金される形式になります。

そして3つ目が一番の特徴なんですが、広告を選ぶ際に、リクエストを受け取ってから初めてそこでオークションを行い、そのオークションによって返す広告を選ぶかたちをとっています。まずは、このオークションの部分について、簡単にご説明したいと思います。

このオークションのプロセスには、2つのプラットフォームが登場します。SSPとDSPです。

SSPは”Supply Side Platform”の略で、広告が表示されるメディア側の管理をしています。みなさまが広告が表示されるアプリやWebページにアクセスした時に、初めにメディア側からSSPにリクエストが飛びます。

SSPは、そのサイトにどんな広告が表示できるか……例えば画像の大きさはどれくらいなのか、どんなパーツが必要なのか、タイトルは何文字まで入るのかといった情報を条件として付け加えて、DSPに広告のリクエストを行います。

DSPは”Demand Side Platform”の略で、主に広告を管理しています。SSPからリクエストを受け取ったDSPは、その条件に合う広告を選び出し、内部的にオークションを行います。この例ですと、真ん中の3.5ドルとつけている広告が1番高値でビットしている広告なので、この広告がDSPからSSPに返却されて、みなさまのお手元に届くわけです。

このオークションプロセスは短時間で返す必要があり、我々は50ms以内を目標に返却するようにしています。

もしここにあまり時間をかけてしまうと、そもそも広告を表示する機会を失ってしまうからです。この50msが非常に厳しい目標で、さまざまな工夫のしどころでもあったりします。

この一連の仕組みがリアルタイムビッティングで、頭文字をとってRTBと呼びます。

最近の広告配信では、このRTB形式が主流になっています。

広告プラットフォームに関わる3つのプレイヤー

さて、今見てきたようなオークションだけで、広告を選んでしまってよいでしょうか？　実はやや問題があります。

広告プラットフォームには3タイプのプレイヤーが存在し、それぞれ違ったニーズを持っています。1つ目のプレイヤーは、広告主です。広告主は費用に対する効果を最大化したいと考えています。2つ目は、メディアです。メディアは、広告を表示することにより利益を最大化したいと考えています。

そして3つ目は、オーディエンス、つまりユーザーです。ユーザーのみなさまは、広告が表示されることでサイトやアプリの操作性が損なわれないこと、あるいはもし広告が表示されるのであれば、自分にとって興味の持てるような広告が表示されることを望んでいるのではないでしょうか。こうしたニーズを、最大限に満たしていく必要があります。

この三者三様の異なるニーズを満たしているか、何らかの指標を使って判断する必要があります。そこで指標の1つとして使うのが、CTRです。

ここに数式が表示されていますが、非常に簡単な数式になっていて、CTRは「とある広告がクリックされた数を、表示された回数で割ったもの」です。

広告主にとっては、目標達成を測るコンバージョン率といった指標はありますが、コンバージョンを達成するためには、まずは広告をクリックしていただかなくてはいけないので、これがまず第1の指標となります。

先ほど「成果報酬型」というお話をしましたが、メディアにとってはクリックをされると課金されるので、このCTRが上がれば上がるほど利益が上がっていくということになります。

最後に、オーディエンスにとっては、クリックしたということは、その広告に興味があったということなので、このCTRを「その広告に対して興味があったか」のバロメーターとして使うことができます。

広告配信では、ほかにもさまざまな指標を使っていますが、3つのプレイヤーに対して統一的に、横断的に使えるものとして、このCTRはとくに重要です。ですので、今日はここを中心にお話をしていきたいと思います。

CTRを最大化することこそが大きな目標であり、我々が理想とする広告プラットフォームにするために、非常に大事なことになります。

CTRを最大化させるための3つの戦略

実は、LINE Ads Platformは、2016年からサービスを開始しました。そして今年の2018年8月にほとんどのシステムを作り直して、リニューアルして生まれ変わりました。これは、我々が理想とする広告プラットフォームを作るために必要だと考えたからです。このリニューアルの中では、さまざまな工夫が取り入れられており、今日はその工夫の一部も紹介していきたいと思います。

CTRを最大化するために、基本的な戦略は大きく分けて3つあります。

1つ目は、オーディエンスの情報を知ること。次に、CTRを予測すること。そして最後に、広告の配信に必要な情報を可能な限りリアルタイムで分析することです。

まず、オーディンスの情報についてどのように知るのかをご説明したいと思います。ここでもう1つのプラットフォームが登場します。データマネジメントプラットフォーム、DMPです。

DMPでは、オーディエンスの推定情報が、ほかのプラットフォームでも利用しやすいようなかたちで管理されています。

また、LINE Tagという仕組みを使って、サイトの訪問やコンバージョンなど、イベントを記録して管理しています。ここで集めたユーザー情報・オーディエンス情報を使ってグルーピングをしたり、Look a likeという機能で似ているオーディエンスを探したりできます。

オーディエンスの属性情報はあまりもっていない

1つずつ見ていきましょう。LINEでは、オーディエンスの属性情報をそのまま扱ってはいません。意外に思われるかもしれないですが、LINEはオーディエンスの属性情報はあまり持っていないんですね。

みなさまがLINEをインストールした時に、年齢や性別を入力するところはなかったと思います。年齢認証はあるのですが、あれは未成年か成人かだけを判断しているので、情報としては持っておらず、フラグとしてしか持っていません。

そこで、規約で同意いただいている情報の中から、これらの情報を機械学習で推定しています。推定している情報としては、年齢は5歳刻みで9つのブロックに分けて、どこに該当するのか。そして性別や、どんなことに興味があるのか……また、このスライドには書いていないんですが、おおよその居住地域なども（情報として）持っています。

例えば20代女性と30代男性では、興味の領域が大きく異なりますよね。広告配信において、オーディエンスに興味を持ってもらう広告を選ぶために、これらの情報が非常に大きなヒントになります。

次はLINE Tagです。これはJavaScriptで書かれており、あるページを訪問したオーディエンスをグループとして記録することができます。

また、広告のランディングページや購入完了画面に埋め込んでおくと、コンバージョンを計測することができます。

広告配信でどのように使うかと言うと、例えば広告主のホームページにこのLINE Tagを埋め込んでおきます。そうすると自動的にそのページにアクセスしたユーザーの情報がだんだん溜まっていきます。広告主は、例えば「自分のホームページに過去30日間以内にアクセスしたことがあるユーザー」をターゲットとして、広告を配信することが可能になります。

Look a likeで精度を高める

LINE DMPの中で最も特徴的で強力なのが、このLook a likeです。

先ほど「オーディエンスのグループを作れる」とお話ししましたが、このグループをSeedグループとして、LINEを使っているオーディエンスの中から似ているオーディエンスを探して、新たにグループとして作成することができます。

この図の中だと、青くなっている部分がLook a likeのオーディエンスグループです。どのように使うかと言うと、例えば、とあるアプリをインストールしているユーザーをリストとして抽出し、DMPにアップロードします。そのアップロードしたグループをシードとして、LINEの全ユーザの中から「このユーザーたちに似ているユーザーを探してください」という処理をすると、Look a likeのオーディエンスグループができます。

このLook a likeのオーディエンスグループにいるユーザーたちは、「今、そのアプリをインストールしているユーザーたちに似てはいるけれども、まだアプリを使っていないユーザー達」です。こうしたオーディエンスに対して広告を打つと、年齢や性別だけでターゲティングするよりも、はるかに高い精度が得られることになります。

CTRを推定する

さて、オーディエンスの推定情報が集まったので、これを利用してCTRの推定を実際に行っていきましょう。広告プラットフォームではこの推定がとても重要なファクターで、我々だけではなく、Google、Facebook、Twitterなど、多くのプラットフォーマーが日々研究しています。

先ほどの式がまた出てまいりました。これはあくまで事後にCTRを計算しているだけなので、これを配信する前にリアルタイムに推定したいと思います。

そこで、少し式を変形させてみます。先頭に「P」をつけてみました。このPは、PredictionのPです。どのように推定するかと言うと、いま配信できる広告や、アクセスしてきたリクエストの情報を使って、「この広告がどれぐらいクリックされるか」を判定します。

このリクエストからは、広告を表示しようとしている場所や、DMPのところで見てきたオーディエンスの推定情報、そしてアクセスしてきている時間など、いくつかの特徴が得られます。

この特徴について、もう少し見てみましょう。

推定のオーディエンス情報としては、DMPのところで触れたように、年齢・性別・興味、エリアなどです。広告からは、広告そのものを表すIDだけではなく、その広告を配信している広告主がどういった広告主なのか。そして、その下にあるフリークエンシー……これは、その広告をあるユーザーに対して何回表示したことがあるかを示すものです。

一般的に、同じ広告を何度も同じユーザーに配信すると、だんだん目が慣れてきてCTRは低下していきます。ですので、こういったものも特徴の1つと捉えて、CTRの推定に活かしています。

表示しているサイトからは、そのサイトがどういったカテゴリーに類するサイトなのか、リクエストしている時間はいつなのか、また広告が表示される場所はどこか、つまりそのサイトの中でどこに広告が表示されるのかといったものも、特徴として使っています。ここに挙げた特徴量は、すべて同時に使っているわけではありません。この中から、いくつかをピックアップして、組み合わせて使っています。

少しわかりづらいので、具体例を見てみましょう。今回は非常にシンプルに、年齢と性別と時間を組み合わせて、全部の広告に対して計算してみます。この場合、性別が2パターン、年齢は全部で9個のブロックに分かれるので、9パターンです。そして、1日は24時間なので24をかけると、これだけで432通りのパターンになります。そして、配信できる広告が1,000個あったとすると、なんと43万2,000通りものパターンができることになります。

このように、特徴の組み合わせ次第で特徴量の次元が爆発的に増加してしまいます。こういった膨大な数の特徴量も、リアルタイムに扱って推定していく必要があります。どの特徴をどうやって組み合わせるか、これは日々のABテストで確認しつつ、「こういうものを特徴として使ってみたらどうかな」という新たな特徴量の提案に対しても、実際に追加してABテストをしてみたりします。そういった工夫がされています。

CTRの分析スペック

LINE Ads PlatformでのCTR分析のスペックを、簡単にご紹介したいと思います。

いま見てきたような組み合わせ次第で、数百万にも及んでしまう特徴量を扱うため、メインモデルにFactorization Machines、オンラインの学習にはFTRL……これは2013年にGoogleが開発した「Follow the Regularized Leader-Proximal」というアルゴリズムですが、それらを使っています。

これらのアルゴリズムの組み合わせは非常に強力なんですが、貪欲なアルゴリズムです。どういうことかと言うと、CTRが高い広告を選ぶのはいいのですが、苦手なこともあります。それは、新たに参加してきた広告主や、新たに登録された広告は、まだログが溜まっておらず、情報があまりありません。よって、うまく扱えないケースが出てきます。つまり、未知の情報が苦手なんです。

そこで、我々はこうした未知の広告もうまく取り扱うために、補足的にではありますが、Multi armed Banditアルゴリズムを採用しています。Banditアルゴリズムの特徴は、ある程度未知のデータを探索しながらも、総体としては利益を最大化するように動作します。このBanditアルゴリズムとして、我々はContextual Thompson Samplingというアルゴリズムを使っています。

この3つのアルゴリズムを組み合わせることで、未知の広告や既存の広告など、さまざまなタイプの広告をうまく扱うことができます。こういった機械学習はリアルタイムに、なんと数msで予測することができます。

広告配信は、機械学習が多々使われる技術領域の1つです。LINE Ads Platformでは、今日紹介したCTRのPredictionだけではなく、CVR、（つまり）コンバージョンのPredictionや、広告の予算を1日の中でどのように配分すると最も利益が良くなるかといったことを調整するBudget optimization、そもそもオークションに参加する時の価格を自動的にコントロールするAuto biddingなど、広告主の収益と利便性を高めるために、さまざまな機能が用意されています。

機械学習においては、予測データを作るだけでなく、結果を分析し、さらに予測の精度を上げていくといったことが重要になってきます。

広告をリアルタイムで分析する

次は、分析の話です。

分析には2つの側面があります。リアルタイムにロギングするものと、集めたログを分析するAnalysis clusterです。これを担当するのが、Data pipelineです。

広告プラットフォームでは、いま見てきたように数多くのプラットフォームが存在し、お互いに連携しながら動いています。

ここでなにかの問題があったり、なにかがうまく動いていないといったことがあった時に、どのコンポーネントで問題が起きているのか判別するのが非常に困難であるという特徴があります。我々も広告プラットフォームを運用しながら、この点に非常に苦労してきました。

そのため、今では各プラットフォームで細かくログを収集する仕組みを、広告専用に用意してます。

例えばSSPであれば、メディアからどんなリクエストを受けて、どんなレスポンスを返したか。DSPであれば、SSPからどんな条件で広告をリクエストされて、内部的にどんなオークションが行われて、その結果どの広告を返したか。そういった細かいログをすべて記録しています。

このログは、各プラットフォームからKafkaを通じてElasticsearchに格納しており、リアルタイムにKibanaで参照することや、grafanaでモニタリングすることができます。

スライドの写真はKibanaの例です。Kibanaでログをほぼリアルタイムに検索したり、フィルターしたりして確認することができます。

Elasticsearchだけでなく、すべてのログはHadoopクラスタや、Druidにも格納しています。こちらはビジネス指標の参考に使ったり、データを分析して機械学習の教師データとして使ったりしています。

大量のデータが流れるData pipelineは、安定して運用されている必要があります。なぜかと言うと、ここに流れているデータはお金に関係するものだからです。失うことができないんですね。そこで我々は、Apache MesosとApache Auroraを使って、サーバーのモニタリングやオートスケーリングを実現しています。

プラットフォームを運用するうえで大切な要素

一旦、ここまでのまとめです。

理想の広告プラットフォームのためには、できる限り多くの情報を集め、その情報をもとにリアルタイムで機械学習で予測し、その結果を可能な限り早く分析しながらPDCAを回して、常に精度を高めていくことが重要だと我々は考えています。

そのためには、どうしても必要なものがいくつかあります。

安定したサーバーとネットワーク。サービス間で膨大なデータをやり取りするためのパイプライン。そして全データをストアして分析するための設備です。

これらはなにも、広告プラットフォームに限ったことではないんですが、幸いなことに、LINEではこのあたりであまり思い悩むことはないと言えます。なぜかと言うと、LINEにはこれらのプラットフォームがすでに整備され、提供されているからです。

安定したサーバーとネットワークとして、我々はVerdaというプライベートクラウドを持っています。これはインフラのプロフェッショナルたちが運営してくれており、サーバーからストレージ、ロードバランサーに至るまで、GUIでポチポチと押すだけで作ることができます。

次に、高速にデータを受け渡しするパイプラインです。

実は先ほど話に出ていますが、私たちはKafkaクラスタをいろいろなところで使っています。サービス間でのデータの受け渡しや、キューやジョブスケジューリングなど、最近のアプリケーションを書く上では欠かせないプラットフォームになっています。

LINEの内部では、IMFと言われるKafkaクラスタを各サービスから利用することができます。もともとLINEの内部データを受け渡しするためのクラスタで、常に膨大な量のデータが流れています。

そして最後は、ストレージです。

データレイクと呼ばれる、巨大なHadoopクラスタがあります。ここにはLINEのありとあらゆるサービスのデータが集約されていて、このデータレイクに入ったデータは、ふだんはSparkやPresto、Hiveなどを使って分析しているんですが、コンソールとして使うツールには、既存のソフトウェアで、我々のニーズに応えるもの、満足できるものがありませんでした。

そこで、PrestoクライアントのyanagishimaやApache ZeppelinライクなOASISというソフトウェアを、自分たちで開発して使っています。アドホックな分析からビジネスダッシュボードまで、幅広い用途で使われています。

広告プラットフォームを支えるチーム

LINEには、こういった夢のインフラが揃っているというだけではありません。これらのプラットフォームを運用して開発しているプロフェッショナルたちが、いつでも我々の相談に乗ってサポートしてくれます。

例えば、広告プラットフォームにはよくある話なんですが、「明日から広告枠が1つ増えます」となった時に、トラフィックが一気に跳ね上がることがあります。「明日から“5万リクエスト／秒”増えるんでよろしくね」みたいなことがあるんです。

そうした時、ネットワークのチームに「明日からトラフィックが増えるんですけど、ネットワークは大丈夫でしょうか」とか「ロードバランサーは大丈夫ですかね」みたいなことを気軽に相談できます。これが、非常に強力なサポートになっています。おかげで我々は、短期間にいくつものサービスを高速に開発して、広告プラットフォームのほとんどすべての機能を開発することができました。

広告プラットフォームを開発しているチームにも、少し特色があります。

これは、LINE Ads Platformのオフサイトミーティングをした時の写真です。たくさんのメンバーが関わっていることがおわかりいただけると思い、持って参りました。

ここに写ってるメンバーは、全員が開発のメンバーではないんですが、セールスのメンバーとか、企画のメンバーも写っています。非常にたくさんの人々が関わっているプロジェクトであるということがおわかりいただけると思います。

2つの国で開発をするということ

今日は「LINE DEVELOPER DAY」ということなので、開発チームについての統計を持ってまいりました。現在、開発チームは日本と韓国の2つの国にまたがっています。真ん中に「100 developers」とあるんですが、これはたまたまGitHubのOrganizationのメンバーが100人だったので、「これはいいな」と思って載せてみました。この100人が全員、今の広告の開発をしているわけではないんですが、非常にたくさんのメンバーが関わってきたプロジェクトです。

リポジトリの数は、なんと102個もありました。私も少し驚いたんですが、とてもたくさんの機能が開発されています。

日本と韓国の2つの国で開発していると言うと、「どのようにコミュニケーションを取っているのか」という質問をよくいただきます。基本的に我々は、即時通訳を挟んだオンラインミーティングをしています。またLINEでグループを作って、そこに翻訳BOTを呼んで、直接コミュニケーションを取るといったこともしています。

幸いなことに、日本語と韓国語は文法がほとんど一緒です。語順も一緒なんですね。ですので、機械翻訳にかけてもかなりの精度で翻訳することができるため、慣れてきたメンバーは、翻訳機を通して冗談を言ってみたりもしています。広告プラットフォームでサービスのリリースがあった時には、みんなでLINEのスタンプを送り合ってお祝いし合う文化になっています。

とはいえ、直接顔を会わせてミーティングすると、情報量がぜんぜん違います。よって我々は頻繁にお互いが出張をして、直接話す機会を大事にしています。毎月誰かが出張していたり、出張に来ていたり……私も来週か再来週、韓国に出張しようかなと思っています。

LINEの広告プラットフォームのこれから

さて、長々と話してまいりましたが、今年の「LINE DEVELOPER DAY」のテーマは「Next LINE」ですので、これから先の話をしたいと思います。我々は、いくつかチャレンジしていきたいなと思っています。

まずはグローバル化です。すでに日本だけでなく、タイや台湾などでも広告の配信が始まっています。LINEが広く使われる国はほかにもありますので、さらに対応する国を増やしていきます。広告プラットフォームは、国が変わると広告主も広告も変わるので、そういった配信ができる広告をもっともっと増やしていく必要があります。

2つ目はインベントリーです。こちらは聞き馴染みのない言葉かもしれませんが、広告面のことです。我々は、実はまだ、LINEのごく一部の面にしか広告を配信していません。今後、さらに配信できる範囲を広げて、広告主にとって多様な層にリーチできるようにしていきたいと思っています。

3つ目は、機械学習です。今日ご紹介した予測だけでなく、画像を解析する技術を使って、見ているユーザーに応じてクリエイティブの色味が変わって見えたり、LPやクリエイティブのクオリティをスコアとして算出して、CTRの予測に活かしたり、そもそも広告のクリエイティブを自動で作成したりと、やりたいことは山積みです。

そして現在、新しいタイプの広告を検討しています。ARの技術を使った広告や、オーディエンス参加型のインタラクティブな広告などです。こちらも、きっと楽しいものができると思うので、時期がきたらみなさまにお知らせしたいと思います。

途中でお話しした広告プラットフォームに関わる3つのロールの中で、何よりも大切なのは、オーディエンスのみなさまです。我々は、みなさまがもっと楽しめるような広告を配信できるプラットフォームを作っていきたいと思います。それこそが、我々が考える理想の広告プラットフォームです。ぜひ楽しみにしていてください。

本日はありがとうございました。

（会場拍手）