令和のネットマーケティング」。第3部のセッション「大手アプリマーケ担当が語る!データを活用した攻めと守りのマーケティングの取り組みと事例」では、ネットマーケティング(Omiai)、Gunosy、イグニス(with)という大手のアプリパブリッシャーでマーケティングを担当する方々が登壇しました。データを活用し、「攻め」ながらも「守る」アプリマーケティングを実現するために取り組んでいるアドフラウド対策について、広告主目線で語られたセッションの模様をお伝えします。モデレーターを務めさせていただく株式会社Phybbitの佐藤と申します。今回のセッションでは3名のアプリのマーケティング担当者様にご登壇いただきました。これまで弊社では、アドネットワークなどの事業者を招いてアドフラウド勉強会を開いてきたのですが、その中で「広告主側ではどのように考えているのか?」という声をいただくことが多かったため、今回はこうした機会を設けさせていただきました。皆さま自己紹介をお願い致します。株式会社ネットマーケティングの有江(ありえ)と申します。弊社では「Omiai」というマッチングサービスを運営しておりまして、日本で初めてのFacebook認証型のマッチングサービスとなります。私の役割としては、アプリのデジタルマーケティング領域を担当しております。Gunosyの石渡(いしわた)と申します。弊社ではニュースアプリ「グノシー」など、メディアを中心にアプリを運営しております。私自身は3年半ほどプロモーションサイドで広告出稿を担当しておりまして、今はアドテク事業部で出稿側ではなく逆に入稿を担当しているのですが、本日は出稿側としてお話できればと思います。イグニスの山本と申します。私は、有江さんの競合になるのですが(笑)、マッチングアプリ「with」という婚活サービスを運営しておりまして、マーケティング全般を担当しております。ありがとうございます。それぞれ各社のマーケティング活動やアドフラウド対策について、各社の取り組みを伺っていこうと思います。Omiaiの有江さんにお聞きします。アプリのアドフラウド対策といえば、基本的にインストールについて見ていくことが多いかと思います。弊社でもそこは大前提です。インストールのフラウドは、「インストールからのコンバージョン(登録)率が低い」といった点や、デバイスや言語設定の偏りなどを見て検知していくのですが、それらをすり抜けるフラウドの手口は次々と出てくるので、どうしても“いたちごっこ”になってしまうところがあります。そこで弊社では「最も深いKPIから逆算してフラウドを検知する」というやり方を採っています。Omiaiはマッチングサービスなので、ユーザーのデータを自社で持っているのですが、それをSDKで取得したローデータと紐づけるようにしていて、そのデータをもとに、メディアやパブリッシャー、サイトIDまで、私たちが追っているKPIに見合っているのかどうかという点を細かい粒度で見るようにしています。わかりやすいところで言うと、課金ですね。そこは一人でやっているのですが(笑)、最初の頃はほぼ丸1日かけて1週間分のローデータを引っ張ってきて分析していました。最近ではSQLを書いたり、クエリを作るなどして少し効率的に分析できるようにはなっています。最終的には管理画面を作りたいと考えています。弊社の中だけで持っているデータでしか検知できないフラウド、例えば「名前」や「ドメイン」がおかしいものを管理画面上で出てくるようにして、代理店にお伝えできるようなシステムがあると良いよね、ということを社内でも話してちょうど今設計を進めているところです。基本的に先ほど話したようなことですが、予算規模や獲得の件数が増えていく中で、「私ひとりが把握していて私しか対応できない」状況になることは理想的ではありません。何より、広告の一番近くで触ってくださってるのは代理店なので、代理店にも最も深いKPIでここまで追っているということをお伝えしたうえで施策を実施していくと、こちらから「これおかしくないですか?」ということを伝えるまでもなく、向こうから「ちょっとここのKPIがブレているので、深掘って調べてみます!」といったことを言ってくださるんですね。感覚としては「手数と頭が増える」といった感じです。データはこちらだけで持つのではなく、できるだけお渡しして、共にパートナーとしてフラウドと戦ってもらえる体制を組むようにしています。いまお願いしている代理店では、当初からコミュニケーションをしっかり取らせていただいているので、大変だったことは正直無いですね。私がいつも意識しているのは、その代理店が得意としている分野を、プロとしてお任せするということです。一人の担当者が多くの媒体を抱えて一生懸命営業するという状況を作るよりは、その担当者に「このメディアにここまでの予算規模でどんどん乗せていきたいので、運用からコンサルまで頑張ってください」というようなコミュニケーションをとってお任せすることが多いかもしれないですね。ありがとうございます。...ネットワーク型だと、フラウドが起きない媒体は無いです。ネットワークによって多い少ないはありますね。多いものだと本当に半分くらいがフラウドですし、少なければ10%以下ですね。ありがとうございます。次、石渡さんよろしくお願いします。「計測SDKの不正防止システムを導入している」というところですね。あとは有江さんと同じようなことで、代理店にちゃんとデータを渡して見てもらう、ということは弊社でも取り組んでいます。弊社で特徴的なのが、計測SDKのデータを可視化するために「Re:dash」というダッシュボードツールを使っています。この「Re:dash」で可視化されたデータの中で、「この獲得はフラウドっぽい」「フラウドじゃないかもしれないけど怪しい」というものを、例えば「きのう1日のインストールが10件以上あって、そのうちタブレットや海外の割合が何%以上あった」という定義にかかった時にSlackに通知するようにしています。計測SDKの不正防止システムは、基本的に“全クライアント・全媒体共通の基準”でブロックするものだと思っていまして、そうすると、自分たちのKPIに合致する/しないという視点から見ると、全て防ぎきれているわけではありません。「海外が何%以上」という基準についても、英語学習アプリの広告であったらその割合が10%や20%を超えていてもおかしくないように思いますよね。その基準を超えたらすべてアウトというわけではないのですが、弊社ではそれらも一旦怪しもうということで通知が届くようにしています。弊社の場合ですと、「これは大丈夫」というネットワークを一つ決め、その数値を基準としています。本当はこれでもゆるいかもしれないですね。弊社では2017年5月ごろにCPIネットワークへの配信を増やしました。GoogleやFacebook等に出稿していたのですが「そろそろ獲得が頭打ちになってきたな」と感じてきたタイミングで、色々なネットワークや代理店から提案を受け導入しました。するとだんだん怪しい獲得が増えてきたことに気づき、対処するためにアドベリフィケーションツールの仕組みなどについて勉強したところ「このパターンはツールで検知しきれず漏れるんだな」ということがわかってきたので、それをカバーするために自分で作りました。ありがとうございます。一例を挙げると、グノシーは記事を無料で読んでいただくメディアなので、アプリを開いたのに記事を1個も読まずに閉じてしまうユーザーはそれほど居ないんですね。その割合が一定を上回ると、ログデータを出して、この獲得に対してこのユーザーは何記事クリックした、というのを紐づけて、「Re:dash」で見やすくして渡す、ということをやっています。弊社の場合ですと、計測SDKのシステムのログデータをAWSに溜めるところまではエンジニアにやってもらっています。これについては、定期的なメンテナンスが必要になるものではないので、一旦作ってもらえばそれで終わりです。先ほどお話ししたような、基準を見たりログデータを引っ張ってきたりという定常的な作業については、マーケティングチームが行なっています。全員がSQLを書けるように勉強してもらいまして、私もGunosyに入るまで全く書けなかったのですが、必死で覚えました。他にも「体制やメンバーの強化、適切なKPI設定」も大事だということですが。CPIや獲得数だけで追ってしまうと、とにかくそれを伸ばせば何をやっても正義だという方向にメンバーの志向が向いてしまいがちなので、そういったものを評価軸にしないように気をつけています。弊社でご提案させていただく広告主の中にも、トライアルしてみた結果「アドフラウドが多く検出されました。これから改善していきましょう!」と担当者に伝えたところ「あー、わかりました」と返され、その後全く連絡をいただけない方がたまにいらっしゃいます(笑)。インストールの獲得数がKPIになってしまっていると、アドフラウドが多い現状を上に報告しづらいというのが担当者レベルではあるようです。この業界ですと2年や3年で転職される方もかなり多いので、「この3年を事なかれ主義で過ごせればいい」という発想になってしまっている人も中にはいらっしゃるかもしれないですね。ありがとうございます。続いて、withの山本さんお願いします。はい、まず計測SDKの不正防止システムを入れているという点はグノシーさんと一緒ですね。当時FacebookやTwitterへの出稿だけだと少し心許ないなと感じていたことや、ちょうどマッチングアプリの繁忙期が近づいていたこともあり、メニューを広げていきたいと考えていました。そんな中いくつか少額で始めたところ、CPAもROASも良いものを見つけたのでどんどん拡大していったのですが、「少しヤバいかもしれないな」という空気も感じていまして。そこで、ゲーム事業の担当に相談したところ計測SDKの不正防止ツールを勧められたので導入してみました。すると...そのメニューではける予算がかなり少なくなりまして(笑)。はい、私自身、勉強しなければいけないと反省した大事件でした。それから弊社のツールも使っていただいているんですよね。計測SDKの不正防止システムを入れて1年ほど経った頃に、SpiderAFについて話を聞く機会があり、計測SDKのそれとは検知の仕方が違うということを知りました。ひとつのツールだけではすり抜けてしまう可能性があると感じていたので、導入することを決めました。SpiderAFを選んだのは、私自身SQLを業務レベルで書けるわけではないので、ダッシュボードやCSVなど代理店にそのまま渡せる形でデータを落とせるかという点も大きかったです。時期によって増減はありますが、平均すると3割ほどかと思います。今後代理店とコミュニケーションを密に取ってもっと下げていきたいです。ありがとうございます。最後に、ご登壇の皆さまから「これからアドフラウド対策を実施する広告主に向けてのアドバイス」や「代理店やネットワークに期待したいこと」などひとこと伺えればと思います。石渡さんも仰っていたのですが「マーケティングの成果とサービスの売り上げはイコールではない」ということですね。細かい獲得人数や獲得数だけを追っていくことは、必ずしも売り上げには直結しない可能性があることを意識したほうが良いと思います。広告主だけでなく代理店側にも、「自分の携わっているサービスを一緒になって大きくしていきたい」と意識していただけると、本当にパートナーとしてサービスのグロースに向けて進んでいけるのではないかと思います。SQLは書けたほうがいい、ということを申し上げましたが、まずは「CVRが異常だな」「CTRがおかしいな」といったことに気づくことから分析はスタートすると考えています。アプリ内でキャンペーンを展開した際に、設計が甘く、アンインストールしてもう1回インストールしたらまた応募できてしまったりとか、そういったことはアプリの行動ログを見れば気づくことなので、まずは広告関係なくそういった点から分析を始めてみるのがいいのではないかと思います。第2部のセッションで「ワイルドな広告を受け入れる媒体があるからワイルドな広告が無くならないんだ」という話がありましたが、広告主の立場から見ても同じだと思っています。「ワイルドなネットワーク」に広告を流してしまう広告主が存在するが故にそういったネットワークが残ってしまうので、この点については皆さん一緒になって意識を変えていかなければならないと考えています。統一基準が存在しないので、それを業界全体で統一していただけるとありがたいですね。私はとにかく「データを見ましょう」ということです。私自身、データを見ていれば気づけて防げたこともありましたので(苦笑)。不正に対して少しでも知識を得た上で見てみると気づけることはかなりたくさんあるはずです。データの整理も今やツールでより簡単になっています。Inc.PAGETOP。