オンラインサロンは理屈で語ることが難しいサービス

金子幸三郎氏:この発表では、オンラインサロンという感情的なビジネスを科学的に捉えて改善していくことや、それに対してどのように取り組んでいるのかを紹介したいと思います。

まず簡単に自己紹介をして、そのあとオンラインサロンとはどういうビジネスなのか、抱える課題とそれを解決するためにどのような取り組みをしているのか。そしてこれからどのような未来へ進んでいくのかをお話しします。

私は情報システム部に入社して、社内の従業員向けにWebサービスを開発するチームで仕事をしていました。例えばカレンダーシステムをGoogleカレンダーに置き換えるときに古いシステムからGoogleカレンダーに予定データを移行するコードを書いたり、従業員の情報を一元管理して検索できるWebシステムを開発したりしていました。

その後オンライン事業部に移動して、フロントエンドを中心としながら、今回お話しするデータ分析のプロジェクトを進めています。

オンラインサロンがどういうビジネスなのか、という概要はすでに紹介していると思うので、違った角度から紹介したいと思います。ここに書いてあるんですが、オンラインサロンは「人間くさくて」「情緒的で」「理屈で語ることが難しい」サービスだと思っています。

人間くさくて理屈で語ることが難しいサービスです。例えば、オーナーの方が大きな失敗をしてとても苦しんだんですが、そこから立ち直って成功したので、みんなにそのノウハウや考え方を伝えたいといって、サロンを始めます。

会員がそんなオーナーの生き方とストーリーに共感して、そのオーナーを応援しながら自分も学びたいという行動が生まれたりしますね。これはあくまで一例なんですが、こんな感じの、情緒的な行動が発生します。

もちろん、シンプルにものを買うときにも感情は動くんですが、そのようなシンプルな購買行動よりも、もうちょっと人間くさくて、エモーショナルな行動が起きるところが、このサービスの特徴だと感じています。

サービスの構造がどうなっているかなんですが、このようなかたちになっていて、DMMからオーナーに対して、管理機能や分析機能を提供しています。ここは完全にBtoBの領域です。

もう1つ、DMMが独自に開発したSNSをオーナーに提供しています。何ができるかというと、例えば文字や写真を投稿したり、その投稿にコメントしたりできます。一般的なSNSの機能をイメージしてもらえればいいかなと思います。

オーナーはFacebookグループか独自のSNSのどちらかでサロンを運営していて、そこで投稿や写真や動画などをコンテンツとして会員に提供します。

BtoBとBtoCが混在していて、BtoBtoCというかたちになっています。BtoBは管理機能と分析機能で、BtoCは独自のSNSですね。これらを開発チームの我々が開発しているので、我々はどちらかだけではなく、どちらにも関わることができます。

BtoBであればオーナーからフィードバックをもらって、BtoCであれば直接会員の声を聞くので、ずっと同じことをやるとか、ずっと同じ考え方で同じシステムを開発するということはありません。わりと刺激の強い仕事環境だと思っています。

オンラインサロンビジネスを科学的に捉えるための仮説

感情的な側面が強く、BtoBtoCという複雑なビジネス構造なのでビジネスの全体像を捉えるのが難しいです。ここに書いてあるんですが、サロンにもすごく個性があって。オーナーが提供するコンテンツはもちろん異なってくるんですが、内容も違うし、頻度や密度も変わってきます。

もちろん同じオーナーであっても、違うブランディングのサロンを開くこともあるので、オーナーの個性もあるし、サロンにも個性があります。

もう1つは、会員の楽しみ方の違いで、同じサロンだったとしてもあまり積極的に関わらないROM専(Read Only Member 専門)の会員がいたり、逆にすごく積極的にオーナーやほかの会員とコミュニケーションを取るタイプもいます。なので、オンラインサロンと一括りにするのがすごく難しいです。

このような、オンラインサロンというビジネスをどうやって科学的に捉えて理解していくか、どうやっていこうかと考えたときに出てきた仮説が、次のものです。

オンラインサロン全体としては難しくても、サロン単位で見ていけばもうちょっと理解できるんじゃないか、対象を細かく分解して見ていくことで解決できるんじゃないかと考えました。この仮説を起点として、事業を科学的に捉えようというプロジェクトが動き始めました。

DMMではTech Visionという、開発職の従業員向けのスローガンや指標的なものを4つ据えていてその1つがScientificという要素です。

これは「科学的に事業を捉えること」「数字をベースにコミュニケーションをすること」を大切にしていこうという意味合いがあります。なので、ここで言う「理解する」は、「科学的に捉える」と定義します。

データが大切だという雰囲気を優先的に作った

科学的に捉えて理解していきたいんですが、理解するためのデータがないという課題がありました。2点あって、例えば新機能を追加したり、UIを変えたりしたときにどういうふうな効果があったのか。良かったのか、悪かったのかという効果測定もしていませんでした。

あとオーナーが会員に提供するコンテンツですね。どういったコンテンツを提供したらどういったリアクションがあった、という効果測定ができていませんでした。

2つ目は、少し被るところもあるんですが、我々が提供するシステムの中でユーザーがどのように行動しているのかをトラッキングしていなかったので、結果的に理解するためのデータがない状態でした。なので、データを計測するために、どうやって計測するのか、何から手をつけるのかを考えました。

データ計測よりも前に、データが大切だという雰囲気を作ることが大切だと私たちは考えました。右の図でちょっと説明したいんですが、階段のようになっていて、これは2つの意味を持っています。

下から階段を上るように順番にやっていくという意味合いがあるんですが、一番下は土台のようになっているので、下がしっかりとした土台になっていないと上が成り立たない、という意味も含んでいます。

なぜデータが大切だという雰囲気を作るのが大事かというと、ここに書いてあるとおり、やりたいことの数は常にキャパシティを上回るので、実際にデータ分析をやるためには、データ分析自体の優先度を高くキープする必要があります。

なぜそもそもデータ分析の優先度を高くキープしないといけないかというと、先ほどの理解するというところもそうなんですが、データ計測されて分析されていないと、結果的にユーザーを理解はできないし、的確なアプローチができないので、下手な鉄砲を数打つようなかたちになってしまいます。

スピードに乗れないし、何が良い施策で何が悪い施策なのかがわからない。結果的に何をやるにしても当てずっぽうになってしまうので、ほかの施策よりもデータ分析の優先度を高くキープしなきゃいけない、と考えました。

実際にこの階段を一段一段上っていくためにやったことを紹介します。1つ目が先ほどの階段の1段目ですね。数字を見る文化を醸成する。数字が大切だという雰囲気を作るところ。2つ目は2段目のところ、実際に計測するところですね。

3つ目は、今進めているところなので、今見てもらっているスライドには入っていないんですが、分析するために可視化するというところで、どうやろうとしているかを紹介したいと思います。

まず1つ目の「数字を見る文化を醸成する」というところです。開発チームで見ていくKPIを定めて、それを定期的に見るようにしました。最初の立ち上げ期間は自分自身がファシリテーターとなって、KPIを見て分析をして、自分が思うところをまとめて発表していました。

KPIのダッシュボードがあるんですが、それだけでは見えないところはSQLのクエリを書いて、こうなっていますと紹介していました。ある程度回数を重ねたあとは、チームメンバーの持ち回り制にして、一人ひとりがKPIを見て、思うところを発表していくかたちに変わっていきました。

数字を見る習慣がチームにつくことで、数字を見るという重要性が増しました。

「Google Analytics 4」を使って数字を計測

次は階段の2段目ですね。計測を具体的にどうやったのか紹介します。実際には「Google Analytics 4」を使用しました。これは2020年10月にリリースされた新しいGA(Google Analytics)のプロパティで、ユーザーIDでWebとiOSを紐づけて一気通貫で計測できるものです。

いわゆるGoogle Analyticsのページやセッション単位ではなくて、ユーザー単位でトラッキングしていく思想になっています。Google AnalyticsはWebの場合、画面遷移時にパスを自動で計測していくんですが、iOSアプリはパスの概念がないので、そこがちょっと課題でした。

あとから少し紹介するんですが、スプレッドシートでこの設計を進めました。スプレッドシートに画面一覧をまとめて、この画面は何という分岐点だと決めて、それぞれに固有の識別子を割り振って、iOSとWeb共通のものとしました。それをイベント発生時に、パラメータとしてGAに送って解決しました。

実際の設計のサンプルをちょっと見てもらいたんですが、tapというイベントが発生しました。screenというのが先ほどお話したところですね。WebとiOSで共通のものを作ったんですが、例えばここはloginという画面があったり、my_salonsという自分が入会しているサロンの一覧の画面があったりします。

例えばmy_salonsだと、identifierが実際にtapしたものになります。ログイン画面であればlogin_buttonを、my_salons画面であれば入会しているサロンの中の1つのitemをタップしたということになりますね。

どのサロンをタップしたのかをsalon_idというkeyとvalueでパラメータとして送って、スプレッドシートに書いて進めました。

データポータルとBigQueryでデータを可視化

可視化をどうやったかですが、1つはGoogleのデータポータルを使用しました。(スライドを指して)画面に出ている写真はデータポータルではなくて仮の写真です。

このデータポータルは完全に無料で使えて、データ分析をした結果のレポートを作成できます。例えばサロンIDでフィルタリングをすれば、そのサロンIDに紐づくデータしか出てこないので、サロン専用のレポートを作れます。

例えば編集権限をもつ自分たちのチームのメンバーがサロンIDでレポートをフィルタリングして、閲覧権限をつければ、ほかのサロンIDのデータを見られたり書き換えられたりしない状態で外部に共有できます。

実際、GA4(Google Analytics 4)とデータポータルを直接つないでも、ある程度のことはできるんですが十分とは言えないため、次のサービスを使うことにしました。それがBigQueryです。GA4(Google Analytics 4)は出たばかりということもあって、分析機能がけっこう弱くてまだ実用的ではなく、単独での活用はなかなか難しいところがあります。

GA4(Google Analytics 4)のデータをデータポータルに送るにしても、ネストされたイベントパラメータを取得することはできません。ネストされたイベントパラメータとはどういうことかというと、ここはパラメータで送っていて、パラメータの下にsalon_idというkeyと、実際の1や2とvalueがあるんですが、GA(Google Analytics)とデータポータルだけでは、このkeyとvalueを取ることが現状できません。なのでBigQueryでネストされたところをバラして、解除して送る必要があります。

それがBigQueryを使うことにした理由の1つなんですが、別のデータソースも一緒に分析することを考えると、間にBigQueryがあったほうがいいという判断で、BigQueryを使うことにしました。

機能とコンテンツの最適化ができた

これらを使ってどういう効果が渡されるかですが、1つ目は新機能追加の結果がわかります。新しい機能を追加したときにどういう反応があったのか、また新機能じゃなくても既存機能がどれくらい使われているのか、実際は使われていないとか、使われているとか、どれくらい使われているのかがわかります。

ほかにはオーナーが会員に対して提供するコンテンツの最適化ができます。例えばどんなコンテンツが会員にウケているのかとか、投稿頻度はどれくらいで、いつ、何曜日の何時がベストなのかもわかるようになります。

未来の話で、次にやりたいことですね。次は決済データを取り込みたいなと思っています。ユーザーの行動データが取れるようになったので、次は決済データをそれ(ユーザーの行動データ)と紐づけたいと思っています。

紐づけることでユーザーの行動と売り上げの相関を明らかにしたいなと思っていて。例えばユーザーがどういう行動を取ると高いLTV(顧客生涯価値)につながっていくのか、逆に高いLTVのユーザーがどういう関わり方をしているのか、サロンにどう参加しているのかを分析していきたいなと思っています。

データ分析について今回紹介させてもらったんですが、私自身はデータ分析のバックグラウンドは一切なくて、紹介したBigQueryやデータポータルは触ったことがないし、ユーザーコードを計測するコードをきちんと書いたこともないので、データアナリストの経験はまったくありませんでした。

ですが、DMMは本気の失敗は肯定するという価値観を大切にしています。チャレンジすれば壁にぶつかったり、うまくいかないことが絶対あるんですが、どんどん失敗していこう、チャレンジしようというメッセージをDMMは持っています。

事業にとって大切だと思ったことを主張して、やりたいと言ったらバックアップしてくれる環境が会社には整っています。私みたいに経験がなくても今回のプロジェクトがやれたし、誰もが挑戦できる環境があるのがDMMだと感じています。

自分がやりたいことにチャレンジして、どんどん成長する環境で仕事をしたい方は、ぜひDMMオンラインサロン事業部で一緒に仕事をしましょう。ご清聴ありがとうございました。