you88blog

広告とかwebとかプログラミングやら

メニュー 閉じる

カテゴリー: webサービスについて

webサービスのマネタイズ手法色々触って思ったこと(広告、プレミアムやらなんやら)

この記事について

今までプレミアム会員のチームや広告プロダクトの開発などをしてきてwebサービスのマネタイズ手法を広く勉強できた気がするのでどういった手法があるか?とそれぞれやってみて思ったことをまとめる。

マネタイズ手法

  • 広告
  • プレミアム課金
  • コンテンツ課金

広告のARPUは上がり続ける。今後もwebマネタイズの中心にいるだろう

広告はwebサービスのマネタイズのメインといっていいと思うし、今後もそうあり続けると思う。一時、プレミアム課金をcookpadが成功させて広告よりもプレミアムをという流れもあったがアドテクの発達で正直プレミアム課金で稼ぐよりもプレミアムになる率を考えると相当効率良くなっている。例えばfacebookはARPUが400円を超えており、この金額は全ユーザーがプレミアム課金しているのとそんなに変わらない収益性である。

www.cnbc.com/2017/11/02/facebooks-revenue-topped-5-per-user-for-the-first-time.html

また正直webサービスで機能制限で課金させるのは相当難しい。やはりwebサービスの大半は無料ユーザーであり、ここへのサービスを手厚くしようとするとプレミアムサービスとかち合うからだ。それはプレミアムユーザーの機能だから提供できないとまごついている間に他のサービスがそのサービスを提供して負けるというのが今後増えてきそう。facebook、google、twitterのように無料にどんどん機能開放し、回遊率、アクティブ率をあげて広告で稼ぐにより寄ってくる。

プレミアム課金はすぐに課金するユーザーとかなり使った後に課金するユーザーの二極化する

プレミアム課金で課金するユーザーは結構2極化するパターンが多いように感じる。プレミアムのサービスを目的でサービスを使い始めたユーザーはすぐにプレミアム課金をする。newspicksなどコンテンツをそもそもプレミアム課金しないと見れないと言った設計だとここが多くなる。もう一つがサービスを長期間使ったユーザーでお気に入りの個数に制限をかけるなどより多くストックさせたいなどのプレミアムサービスの場合、ここが多くなる。

投稿サービスなどで無料ユーザーの利用もサービスにとって必要な場合、無料ユーザーも使えるけどより使うにはプレミアム課金という設計が多くなりがちである。

広告でマネタイズするユーザーとプレミアム課金でマネタイズするユーザーを分けるべき

ユーザーによってマネタイズ手法を変えるべきなんじゃないかというのは最近思っていて絶対にwebの広告は踏まない。でもサービスへのロイヤリティは高いみたいなユーザーにより使いやすくなるプレミアム課金をすすめたりなどは考えるべきかなと思っている。ユーザーによって適切な関わり方をできるサービス設計をしたい。

コンテンツ課金かサブスクリプションか。サブスクはコンテンツ業界のアンバランスさを考えないと難しい。

【定義】

・コンテンツ課金→単体のコンテンツを買い切る形の課金
・サブスクリプションモデル→サービスに対して定期課金する課金形態

コンテンツを扱っている所のマネタイズは二極化してきてサブスクモデルが最近は大きく伸ばしている。音楽ではダウンロードの減り分を大きく補っている。サブスクであうなと思うのはコンテンツというよりそのコンテンツを消費する時間がほしい場合。例えば音楽はその曲を聞きたいというより、通勤時間に聞ける音楽がほしいなどライフスタイルに組み込まれるようなコンテンツは相性が良さそうだなと思う。

ただサブスクモデルで難しいのはコンテンツホルダーへの返金方法でユーザーから集めた金を視聴回数の割合で分配するという形を取った場合、ヒットコンテンツを出す側としては上限がそこに設定されてしまうので美味しくない。総取りできるコンテンツ課金の方が嬉しい。コンテンツ業界は上位数%のヒットコンテンツで売上が成り立っているためここにキャップが決められると厳しい。

そのためヒットコンテンツ以外のコンテンツでサブスクサービスには参加するコンテンツホルダーが多くなり、そのサービスの魅力が半減する。netflixなどは自社でコンテンツを作ったりヒットコンテンツには違う契約形態を設けたりして回避している。今後もヒットコンテンツへの付き合い方がサブスクモデルでは課題になりそう。

【1週間ブートキャンプ】文系職が夏休みを使ってプログラミングを覚えた話

去年の夏の話なのでかなり前だが夏休みを使ってプログラミングを覚えようと思って一週間ぐらいでプログラミングの基礎を一気に身につけられないかと勉強方法を模索した。rubyとrailsを一から勉強してどれくらい身につけられるかみたいなタイムアタックをしたくて効率性を重視したやり方を見つけられたと思うので文系職で自分でwebサービスを作ってみたいと思っている人に読んでもらいたい。ちなみにこの勉強のあと日曜大工的に毎週プログラミングしていてfirebaseとrails、vue.jsでチャット作ったり、今はtwitterで趣味友達を募集できるサービスの開発をしてたりします。

個人開発者の人とも仲良くなりたいので気軽にフォローしてください。

twitter.com/you8802

動機

僕はちなみに今までいくつかのプロダクトのディレクターやったりプロダクトマネージャーをしたりしています。現在は広告プロダクトを見ていてこういったものを作っています。

inside.pixiv.blog/yattyo/3420

もともと受託をやってたり、起業して自分でもプロダクト立ち上げたりしてて、マークアップはがっつりやってたのとwordpressやphpもエンジニアと一緒にちょっとしたものならやってたのですがちゃんと体系的に学んでいないような状態でした。それがなんで今さら勉強しようかと思ったかというと

  • 自分で小さくサービス作れたら色んなPDCAを回せるなと思った
  • ディレクション能力も上げたい
  • 単純にプログラミングに興味あった

上記の理由で一番はまあ自分でサービスまた作りたいなという興味本位。次が現在のチームが技術的な難易度が高いチームでディレクションするにあたって技術的なことを理解しないと厳しかったから。ディレクターの仕事はエンジニアの働きやすい環境を提供することも入っているので彼らが技術的なことを説明するコストをこちらが勉強することで削減できると考えたからだ。

個人的に思う文系職のプログラミング挫折ポイント

環境構築

最初プログラミング勉強しよう!と思ったらまず環境構築をすると思うのだが死ぬほどつまらないのと面倒なのでここで大分モチベを削られる気がする。今回は環境構築をしなくてもプログラミングを始められるprogateでまず勉強をはじめて回避したのとその後、環境構築する際は同僚に助けてもらった。

全体像がわからなくなる

細かい記法にばかり目がいって結局なんの機能作っているのかよく分からなくなる。一通り書いてみたがなんでこう書いたのか分からんというのもモチベをさくし、結局身につかない。

勉強に使ったサービス・本

  • progate
  • qiita
  • dotinstall
  • パーフェクトruby
  • teratail

感動したポイント

progate

2-3年前に勉強した際と大きく違うのはprogateが有るかないかと言っていいくらい感動した。まず環境構築無しでいきなりプログラミングを勉強できる点がいいし、間違った際の指摘が本当に細かい。相当パターン別に文言用意していると思う。

qiita

qiitaがいいのが間違いを指摘し合う文化が有る所で全く知らない人から指摘が来る。しかもなんで間違えてんねんって感じではなく本当に教えるみたいなテンションで来て滅茶苦茶ユーザーがあったかい。

teratail

これも本当にびっくりしたが質問してほぼ100%当日中にいい感じの回答が来る。ツールの設定など特殊なパターンなど資料に載ってなさそうな細かいつまりに対応する際には重宝する。

勉強方法

勉強サイクル

  • progateで勉強
  • dotinstallで同じ箇所勉強
  • qiitaに全体像をまとめる
  • よう分からん所はteratailで質問

忘却曲線と戦う

とにかく人は忘れる生き物なのでどう定着させるかが重要だと思った。でも本何回も読むのもだるいのでprogateを何周もすることに。毎日progateやって計4周ぐらいした。(公文式方式)

ただprogateは本当にさわりなのでdotinstallで補強しつつ、重要な部分はパーフェクトrubyを読んだほうがいい。

(星の横にあるのがやった回数)

木を見て森を見る

個人的に今回めっちゃ当たった勉強法はqiitaに都度都度まとめるでまとめると全体像を把握できるし、親切な人が間違い指摘してくれたりするので非常にいい。プログラミングは記法などに目が行きがちだが値をどこで入力してどこに溜めてどうやって出力するかを意識するといいかも。

やってよかったこと

やっぱりエンジニアとのコミュニケーションがより密になった気がする。ただ気をつけないといけないのが彼らの方がプロだということ。なにか彼らの決めたことに対して意見するための技術ではなく、彼らがビジネス職、文系職に説明するときのコストを減らすための技術であってやんややんや言うのはダメ。ちゃんと技術に関しての決定は彼らに委ねる。なぜなら彼らはプロだからだ。

もう一つは趣味ができたこと。日曜大工は材料費がかかるがwebサービスは材料費がかからない。

github.com/you88

この辺でチャット作ったりしている。

qiita.com/you88

ココにも逐一記事をあげてて非常に面白い。最近はvue.jsやAWSを頑張っている。物を作るのも楽しいし、プロダグラミング自体、パズルのようで面白い。今公開できるサービスを作り中なので自分のサービスの広げかたも研究できるようにしたい。

事業会社の開発チームの動かし方を考えてみた

受託もやって事業会社での開発もやってといろんな形態で色んなプロダクトの開発をやってきて最近色んな知見が溜まってきた気がしたのでちょっと整理してみる。開発チームを動かす上でメンバーに対してどう接するべきかなあなどなど。

全体最適をしらない者に部分最適は難しい

全体最適、つまりプロダクトをどうすべきか分からないとエンジニアも部分最適化をできない。例えばエンジニアが実装するなかでこの条件どうしようとかDBの設計をどう拡張をもたせるかなど部分部分で細かい判断が必要だがそれは全体としてどうなるかが分かっていないと判断できない。そしてそういった局所的な判断がプロダクトの質を高めていく。

この全体最適をちゃんと理解してもらうのはプロダクトマネージャーやディレクターの役割であり、責任になる。

何回言っても伝わらないは当たり前

ただそういった方針や全体の動きは何度言ってもなかなか伝わらないものだ。正直2,3回とかのレベルでも伝わらないことはあるし、すぐに忘れる。これは当たり前なんだなあと最近思うようになってきた。何回も同じテンションで説明し続けられる、プロダクトの思想を伝えることができるという精神性は意外と重要なスキルなんじゃないかなと思う。あいついつも同じこと言ってんな。しつけえぐらいがちょうどいい。

経営者マインドが!プロダクトマネージャーマインドがねえも当たり前

よくメンバーに経営者マインドが足りないとかプロダクトマネージャーのような全体感を持ってくれないと嘆く人を見るがそれは当たり前でじゃあ君はエンジニアのマインドを持っているかと聞いてみたい。別にどの職種でも言えることだが他人の職種のマインドを100%持つなんて不可能でそれは経営者やプロダクトマネージャーだけの悩みではない。また当事者意識を持とうと言っても当事者に100%なるのはできない。お互いが互いを理解するように努力するのが大切。

常に不安がちょうど良さそう

互いに100%理解するのが難しいと分かっていれば常に不安になって相手の観察を怠らないと思う。そしてマネージャー、ディレクターなどメンバーを調整する役割を持つ職種はそれぐらいの気持ちでいるのがちょうどいいんじゃないかなあと思う。自分のチームのメンバーは皆楽しく仕事をしています!とまじで言い切ってしまう人よりこいつらにちゃんと俺の考え伝わっているかな?楽しく仕事できているかなと不安で常に改善策を考えるマネージャーの方がチームに取っていいんじゃないかなと思うのです。

事業会社はどう広告を考えれば良いのか?-広告はプロダクトの一部-

プロダクトを見る人間が広告をどう考えたら良さそうか、どこまで知っていたほうが良いか、手法の選択する際に意識することなんかを個人的な偏見を存分に入れて考えてみた。なんでまとめようかと思ったかというと田端さんのこのtweetをみてホンマにそうだなと思ったからである。

僕もマーケティングは専門性が高いのにもかかわらず、日本では総合職が片手間にやることも少なくなく、ノウハウの蓄積に失敗しているところが多いなと思っている。なので逆に事業会社が最低ここは把握したほうが良いんじゃないか、こういう捉え方をしたほうが良いんじゃないかというのをまとめてみた。

広告はプロダクトの一部

広告はユーザーにプロダクトが接する最初の面なのでこことプロダクトは一貫した体験になるように設計しないといけない。ユーザーは

広告

(LP)

プロダクト

(購入や課金などのCV)

の順で体験するが広告で付いたイメージが一致していないと最後まで到達しない可能性が高い。どんなユーザーを連れてくるか?どんなイメージをもたせるかはユーザー体験の一部である。

自社にノウハウは溜まっているのか?

決して代理店を否定するわけではないが日本の事業会社では広告を代理店にまかせ過ぎな事業者が多いように感じる。上記のようにユーザー体験に大きく影響をあたえるところなのでユーザー体験を向上させるなら広告もその一部として見直していかないといけないし、ノウハウを溜めないといけない。代理店などは広告手法のプロではあるがサービスのユーザー体験などは事業会社側が把握しているべきだ。どんなクリエイティブでどうイメージさせるかをちゃんとコントロールしているか考え直してみるといいかもしれない。

プロダクトマネージャーが把握したほうがいいと思う広告手法の分類

プロダクトマネージャー(事業会社側)が最低限下記を把握して代理店と一緒に広告手法を話せると良さそうというのをまとめてみた。ちなみに分類は個人的に勝手にやったもので一般的なものではない。

pull型とpush型

pull型
SEOなどユーザーを待ってとってくる手法。ユーザーの行動の先においておくものなので基本的にはニーズが顕在化されているユーザーで継続率は高い。

push型
twitterなどユーザーにこちらからpushでプロダクトを押していくのがpush型。潜在的にニーズがあるであろうユーザーを見極めるのが大切。

具体的な広告手法

pull型

  • SEO
  • ASO
  • リスティング
    • 検索結果に広告出すやつ。検索キーワードでセグメントができ、ユーザーの層ではなく、ユーザーのニーズでセグメントできる。ぶっちゃけかなりユーザーのニーズが顕在化されているのでかなり優秀。

push型

  • UAC
  • twitter
  • facebook
    • push型は潜在的にニーズを持っているだろうユーザーをデモグラや背景で読まないといけないがfacebookはそのデモグラが最も正確な媒体と言って良い。push型において最強だと思う。

プロダクト戦略を考える上で気をつけてる情報収集法

もともと社内の新人に見せるように作ったものだが社内以外でも応用できるなと思ってブログにも書くことにした。自分がプロダクトの戦略を考える上で意識している情報収集方法をまとめてみました。もちろんひとつの考え方でむしろもっとこうした方がいいよというのがあったらどんどん意見いってほしい。

なぜ情報収集が大切か

基本的に意思決定の際に

  • 情報収集
  • 施策立案
  • 選択
  • 実行

を意識しています。大抵の人は他の人がやっている行動をしていて情報収集や、施策を自分で作る所をしない。網羅的に情報を集め網羅的に施策案を出し、それらを吟味していく作業というのは実はなかなかされていないんじゃないかという印象。でも選択肢のどれかを選ぶのは実はそこまで差がつかないと考えていて、ちゃんとした情報があれば誰でもそりゃそうだよねってことが大半です。(ただ政治的な理由でできない場合はある)そのためどんな情報をどの速度で得るか、そしてその情報からどういう施策をだすかが良い意思決定には最も重要であるというのが個人的な最も基本となる意思決定の考え方です。

情報を点で捉えず線で捉えよう

なにかの情報を見た時その情報をそのまま捉えるだけでなくそこから2手3手先を読むようにしている。2流は情報を点でしか捉えられず、1流はそこから2手、3手先を読んで線で情報を捉える。超一流は数パターンの2手、3手先を読んで立体的にものを見れる。訓練としては企業ごとにニュースを並べるというのがオススメ。それをすると一つのニュースをみて次どんな手をうつかのパターンを覚えることができる。

具体的な情報収集の方法

英語の一次情報を見るように

日本のIT業界は基本的にアメリカのパクリなのでアメリカのIT情報を英語で取っていれば予測できる。(最近だと中国もだが)一歩早く把握するために1つのメディアでいいから(techcrunchとかミーハーどころでいい)フォローしておくとよいかも。

海外のIT企業をcrunchbaseで見る癖をつけよう

www.crunchbase.com/

ここで資金調達の情報を中心に企業ごとにニュースを見れる。

IRをチェックしよう

調査対象が上場企業ならIRを見よう。

スタートアップをなめるな

IT系はつねにスタートアップの脅威を考えていないとすぐに抜かれる。しかし、スタートアップの情報は意識しないと取れない。おすすめはwantedlyを定期的に見る。wantedlyを見ればスタートアップの求人情報が見れ、求人は会社が将来やりたい事の要約である。ここを追っていれば予測ができる。

本よりSNS

本より優秀な人のSNSを見よう。anypayの木村さんは神。

twitter.com/taiga__
twitter.com/ashikagunso
twitter.com/ariyasu
twitter.com/pengin_two
twitter.com/santamariaHORI
www.facebook.com/hkunimitsu?fref=ts
twitter.com/ka2aki86
twitter.com/usksato
twitter.com/shinzizm2
twitter.com/ari_kou

本ではなく自分で調べる、研究するのが最速

本で学ぶことは半年以上前の事象であることが多い。つまり自分で日夜研究している人と本でしか物事を研究しない人では半年以上差がつく。そのためニュースやプロダクトの数字などで常に自分で研究するようにするとよいかも。逆に自分のプロ領域で本ではじめて知ることが多い場合、恥ずかしく思わないといけない。本を読んでいや知っとるわい!となるのが理想。

推薦図書

  • プロフィット
    • toBの交渉をする際にまず気をつけたいのがその会社が何を利益にしている会社なのかということ。そこを見誤ると交渉が平行線になる。この本を読めば大抵の会社のビジネスモデルを網羅できる。
  • 起業のファイナンス
    • 上にも書いたようにスタートアップを中心に競合他社の動きには常に気を使わないといけない。株主情報やファイナンスの情報は長期的な戦略をよく表しているのでファイナンスの知識を網羅し、IR、株主比率などを見れば違った見方ができる。
  • ポール・グレアムのエッセイ
    • IT企業にいるなら読んでいないと恥ずかしいやつ。ポール・グレアムの考え方でセールスについての考え方は特に参考になる。営業経験や小売経験があるとどの商材にどれくらい人が金を払い、どんな表情でどれくらい考えるかが分かる。セールスに行き、顧客の表情を見る経営者、プロマネは非常にその辺のセンスが鋭敏。
  • なぜ日本は〈メディアミックスする国〉なのか
    • 製作委員会がメディアミックスに及ぼす影響についてよくまとめられている。マンガアプリは今後どうアニメ化、映画化させるかが非常に重要な産業なのでこの辺の仕組みは勉強しよう。

プロダクトがうまくいかないときに陥りがちなこと

プロダクトは基本的にいきなりうまくいかないもので色々試行錯誤して方向性を決めていくもの。ただうまくいかないと陥りがちなことというのは結構パターンがあるなと最近感じてきた。最も多いのは社内のプレッシャーに押され、短期的な成果を上げる施策にばかりフォーカスしてしまうことだと思う。

プロダクトを作ってその方向性を決める。つまり幹となる部分を探す段階においては長期的に効く、再現性の高い施策を探さないといけない。しかし、うまくいかないと社内のプレッシャーやら何やらですぐに成果を出したいと思いがちである。そうなるとたいして再現性がないのにちょっとした成果をあげられる施策に走りたくなる。その結果、小さい成果しかあげられない小さくまとまったプロダクトになってしまう。

とは言え、社内やメンバーのまだ成果でないのかよ。。。このプロダクトは大丈夫なのか。。。という声はプロダクトマネージャーなどプロダクトの方向性を決める人間に取って死にそうになるぐらいつらい声かも知れない。でもそれの対策は小さい短期的な施策で行うべきではない。ある程度の期間そういった声をあまんじて受け、最終的に本質的な施策を行い、その成果で黙らせるべきだ。

それにはプロダクトマネージャーだけでなくて社長やもっと上の経営層の覚悟も必要かもしれない。

というのをセンゴク一統記の13巻で学べます。徳川家康が豊臣秀吉に戦い挑むんかーと尻込みしているときにここで戦わないと長期的に見たときにまた弱小大名として周りの目をきにしていきないといけない。ここで勝負しようと叱咤する場面は何千回読んでも泣ける。

音声UI(VUI)が台頭する時代にどうプロダクトづくりをしていくか

最近googlehomeを使っていて本当に便利だなあと思った。買う前になにを具体的にやろうかとリストアップしたんだが正直そこまで使う機会無いなあと思いつつも一応買うみたいなテンションだったがいざ使ってみると生活が変わった気がする。といって僕は音楽聞くのとchromecastの操作とアラームぐらいなんだがやはり数秒でも早くなるともう戻れなくなる。これから本格的にVUIが浸透してくるんだろうなと思いつつ、僕らプロダクト作る側はなにを意識しないといけないのか考えてみた。

今までとは違うUIの作り方

今までのGUIだと

  • 選択肢を見せて
  • ユーザーに選ばせる

が基本だったがVUIは見せることができないのでユーザーがもともと知っているものに限定される。新しいコンテンツを選ぶみたいなことが難しく、コンテンツリコメンドの精度やもともとリストを持っている所が強い。例えばVUIを起点に音楽サービスを展開しようとしてもspotifyのほうがそのユーザーのすきな曲のリストを持っているのでユーザーが音声で選びやすい。

また何ができるのか想像しやすいものでないと難しい。(提示がその都度できないので)

広告ビジネスはどうなるのか?

音声での広告というとラジオを思い浮かべるがラジオのようにコンテンツの中に挟み込むのはありだがAIスピーカーで起動するのを早くするツール系のサービスは広告を挟むのが難しい(広告が来ると時間がかかり本末転倒)基本webサービスは広告ビジネスを行ってきたがここは大きく発想を変えないと難しそう。

  • AIスピーカーでの用途で終わらないであくまで補助のもの
  • 音声コンテンツを提供するもの
  • サブスクリプションモデルで課金させるもの

が増えそう。

入り口を数社が握るということ

スマホでもそうだがAIスピーカーでも専用端末が入口になるため数社が寡占するだろう。その中でどう生きていくのかが重要。

KURASHIRUとcookpadでwebサービスの潮目を感じる

最近趣味でKURASHIRUとcookpadについて調べてて2-3年前から出始めてたwebサービスの潮目をよく体現した現象だなと思ったのでまとめてみた。

結論から言うと今までcookpadのようにCGM+コンテンツマーケティング(SEOメイン)がwebサービスのメインの勝ちパターンだったけどアプリに主戦場が移り、コンテンツが検索エンジンに引っかからなくなりプロモーションと第一想起がより重要になっているなあと思った。

これはもう3-4年前(いやもっと前か?)から起きていたけど同じ業界でcookpadをKURASHIRUが追い上げているのがこの現象をより体現しているなあと思った。今後も色んなカテゴリーでこの現象は起こり続けると思う。

そもそものwebサービスのコンテンツについて

そもそも昔から続いているwebサービスってCGMがめちゃくちゃ多い。なぜかというともちろんそれでネット特有の面白いコンテンツが生まれる、よりユーザーが参加できるというのもあるが、単純に昔はweb業界にコンテンツをオールドメディアに勝てるほど作れる所が無かったってのが一番だと思う。CGMという原価がほぼ無い方法でないと収益とコンテンツ制作費が見合わなかった。

しかし、今webサービスの収益性はアドテクの進化とメジャー層へのリーチの広がりでかなり改善された。そのためKURASHIRUのようにある程度コストかけてコンテンツを作っても収支が見合うようになってきた。

コンテンツの量=マーケティング力だった時代

またwebの流入の割合で検索流入がめっちゃ全体的に多かったのも大きい。コンテンツの量が多ければ検索エンジン上で引っかかるページ(入り口)も多くなるのでコンテンツの量がそのままユーザーへのリーチになっていた。つまり昔はひたすら低単価でコンテンツを作り、検索エンジンの海に放り込んでいるのがマーケティング効率が良かった。

コンテンツの量から質やマッチング率に移っている

しかし、アプリの世界ではコンテンツは検索で引っかからない。そのため上記の情勢が変わった。コンテンツの量が入り口の量だったのである程度の数が必要だったため同じようなコンテンツが重複しているのもむしろ良かった。しかし、それらのメリットが低くなり、量よりも質の高いものにのみ接触できることが重要になってきた。

business.nikkeibp.co.jp/atcl/report/15/110879/082300723/?P=2

堀江:クックパッドには200万レシピが掲載されています。よく投資家に「置き換えるって言うけど、全部動画にできるの?」ってよく聞かれるんですが、僕は「それは違う」と反論します。料理と食材で、1000通りも想像できないですよね。1000通り想像できたとしても、それぞれに10のレシピがあれば、十分、消費者は満足できるはずです。グーグルで検索して実際にクリックするのって、上位10件くらいでしょう? つまり、動画が1万本あれば十分なんです。クックパッドの200万レシピのうち、トラフィックが集まるのは上位1〜5%のコンテンツだけですよ。残り95%以上は要らない。動画化する必要なんてないんですよ。

腹落ちしかしない記事だったが、コンテンツはマッチングしているコンテンツが1つあれば事足りる場合が多い。(ただこれはエンタメ系とhowto系で大きく違う。)今まではマーケ的な価値があったのでコンテンツの量がある程度重要だったがアプリの世界では量ではなく、質やマッチング率の方が重要。

promotionの殴り合い

アプリの時代である現在ではpromotionが重要であり、どう獲得コストを抑えるかの勝負になってきている。しかし、CGM+検索エンジンで大きくなった企業の中にはどうもこの動きについていってない所が多い気がする。今後promotionを事業戦略の重要部分に置けない会社、もしくは精密に戦略をひけないマネージャーのプロダクトは相当厳しいと思う。

© 2018 you88blog. All rights reserved.

テーマの著者 Anders Norén.