カンム社マーケチームが施策前に絶対書くノートの話
前のポスト でカンム社全員SQLを書いている話をした。今回は自分が所属するマーケチームが施策を考える時に必ず書くノートの話を中心に、どういう事をやっているのかを書く。
前提
- チームサイズ
- 自分含めて4名
- やってること
- 運用型広告(インハウス/代理店)
- メディア運用
- アプリ改善へのフィードバック
- キャンペーン設計
- アライアンス営業
- 広報活動
- 計測ツール環境
- adjustレポート画面
- adjustからのリアルタイムコールバックからのredashでビジュアライズ
- Google Analytics
- 予算規模
- ﾅｲｼｮ
- (これが無いと中々全体プロセスをイメージし辛いと思うけど一旦ﾅｲｼｮです)
やりたいこと
マーケティングチームを率いるとなったタイミングで、チームとして素早く探索的に新規施策を打ち、見込みのあるチャネルを開拓し続けていく事を目標にした。
これは トラクション という本に書いてありめちゃくちゃ納得した事なのだけど、どのチャネルもどこかのタイミングでは飽和する、という話をベースにしている。理由はその場にいるユーザーにアプローチしつくしてしまった、他社が同じような施策を打ってきてCPAが高騰し始めた、等様々だが、どんなチャネルもどこかのタイミングで枯れる。そしてプロダクトのステージが変われば適切なチャネルも移動していくという話だ。ソフトウェアのボトルネックが1つ解消する度に移動していく話に似ている。
また、数年区切りの時代に何個かマーケティングには発明が生まれている。takejunさんが書いている 仕組みをハックすること、マーケティングの型を発明すること というポストにもあるように「CPI数十円」というとんでもないチャネルが必ずどこかに存在している。
特にアーリーステージのスタートアップには「ふつうに広告を出して、ふつうの成果で満足」するのではなく、仕組みをハックし「再現性を持ったマーケティングの発明」にトライする野心を持ってほしいなと思っています。 from 仕組みをハックすること、マーケティングの型を発明すること
フリルの話も凄い好きなのだけど、自分が感動した例はKurashiruのインスタ動画広告だ。動画広告は作るのにコストがかかるが、Kurashiruではその動画そのものがコンテンツなので実質広告に利用できる動画は無数に存在しており、なおかつそのフォーマットが当時開始直後くらいのインスタの動画広告フォーマットにの小奇麗な感じにバッチリはまって劇的に伸びたという話を聞いて一人で感動していた。発明やんけそんなの。インスタ動画広告フォーマットから逆算してプロダクト作る人達が生まれるくらい発明やんけ。
これらを考慮した際に、枯れる前から一定時間を割いてチームが素早く次のチャネルを開拓していけると強いなと思った為、あくまでもチームとして学習しながら探索できるような形にしたいと考えた。
やったこと0
去年始めくらいに社長に「COOやってくれ、そんでマーケ側見てくれ」と言われたとき、自分はマーケティングのマの字も知らない状態だった。とりあえずAmazonで何冊か本を注文したのだが、その時すでに上記であげた トラクション という本が会社の本棚にあったので、じゃ一旦これで…と手にとってとにかく読み込んだ。(「とりあえず会社にある本適当に読むか」みたいな人間にマーケティング側を任せていいのか…死ぬぞ…) という心の声を飲み込みながら2回読んだ。2回読んで完全に理解した気になり↑の「やりたいこと」をある程度固めた。
やったこと1
やりたいことはある程度思い描けたので、マーケティング、デザイナー陣合わせて『トラクション』に書いてあるカテゴリ別に一旦実現可能性を無視してブレストし、施策の一覧を作った。通称「108の施策」というSpreadsheetがあるんだけど今でも困るとここを覗き込んでアイディアを出そうとしている。
そこから更に本をいくつか読んでみて、チームとして読んでくれと頼んだ本が2つある。
『グロースハック完全読本』に関して言うと正直「グロースハックだぁ？バズワードをタイトルにつけやがって」くらいの気持ちで手にとったんだけど、完全に自分が間違っていた。本当にいい本だった。この本にはプロダクトの成功したディストリビューション例の詳細が書かれている。また、そのような作戦を取れるチームとはどういう性質を持つのかも書いてある。何も無いところから新しいディストリビューションの案を出す事は非常に難しい為、このような例が集まっている知識をチームが持っていることで「Dropboxのリファラルのような」みたいにコンテキストを圧縮した会話が出来ることは価値だと思う。
『ジョブ理論』においては言わずもがなだと思う。とにかく読んでくれ。結局自分がいるような小さな会社は何かの領域で圧勝しなければならない。本当に自分たちは「決済」という領域で戦っているのか？実はATMと比較されているのではないか？等の問いを常に頭に描きながら訴求を調整していくこと。これはディストリビューション効率のみを見ていると忘れてしまいがちだけど、顧客に届けるという部分を受け持っているからこそジョブの観点からプロダクトにフィードバックを行っていく必要があると思っている。
個人として読んで良かったなと思う本は以下。これもいつかなぜ良いと思ったのか書いてみたい。
- ブランディングの科学
- 欲望する「ことば」
- マネタイズ戦略
- リスティング広告 成功の法則
- 広報・PRの基本
- 逆襲の広報PR
- マーケティングの教科書――ハーバード・ビジネス・レビュー 戦略マーケティング論文ベスト10
やったこと2
108の施策から筋のありそうなものをいくつか実行してみた。ここで「これって本当に効果あったんだっけ」や「前やったあれの結果どうだったっけ。てかどういう前提条件だったんだっけ。」みたいな事が発生し始めた。このような状態ではうまくいかなかったという学びも蓄積されず、その実験によってどこの地平が新たに開拓されたのかも不明瞭になり、メンバーが新規に入ってきたら結局口伝で伝えなければいけない。チームに学びが蓄積していかない状態だ。
考えた際に出てきたのが「新規施策ノート」を書く事だった。結論から言うと以下のようなノートを必ず新規施策実施前に書きレビューを通す事にしている。例は今適当に考えたが項目としては以下で固定。
## 前提
- Twitterで誕生日の風船が飛んでるとスクショ取ってツイートしたくなる
- 祝われたいという思いを風船が飛んでる！というアレで覆って公の場に放つ的な
## 仮説
- 誕生日のお祝いプレゼントとそのスクショはエンゲージメントを高め、新規ユーザー獲得にもプラスに働くのではないか仮説
## 実施方法
- 誕生日に100円プレゼント+アニメーション+Twへの拡散動線つける
- バックエンドから誕生日確認jobをエンキューし、毎日12時くらいに定期実行させるようにする
- フロントでなんか楽しげなアニメーション出す
- フロントからTwへの動線つける
## 想定効果
- Tw上でのエンゲージメントがn RT/ m Likeくらい集まるのでは
* SNSでの拡散が50人に1人
* n万人稼働会員がいるとして誕生日は一様分布とすると1日x人くらい→z人/日くらい？
- スクショ乗ってるTwからの流入がx人/日くらいあるのでは
* 今やってるキャンペーンではy人/日くらい入ってきてるので
## 効果検証方法
- Twへの投稿数とエンゲージメントを確認する
* これは手動で一旦やってみる
- redashでorganic登録の7日間移動平均の変動を確認
* [redash url]
- 対象URLから流入した人のアクティビティを確認する
* [redash url]
## スケジュール
- 開発、リリース: 2018/xx/xx
- 検証期間: 2018/xx/xx - 2018/xx/xx
### 効果検証
- 振り返り時に記載
### 考察
- 振り返り時に記載
以下順番に項目の説明をする。
前提
前提は「その実験をしようと思った背景」と言い換える事ができる。なぜその新しいチャネル/施策が有望そうだと思ったのかを既知の事実に絡めて書く。ここで前回書いた カンム社員全員でSQL勉強会をやっている話 が活きてくる。既に観測できているユーザーの動向を全員が見れるようになっていることはやはり価値だなと思う。
仮説
施策の裏にある仮説を真か偽か判定できる形を意識して書く。
実施方法
施策を具体的に書く。施策に必要になるソフトウェア側の修正もある程度見越して書く。
想定効果
既知の事実や聞いた話から想定効果を書く。これを真面目に検討すると圧倒的にコスパ見合わないかもね、みたいなのが事前に見えてくる。
効果検証方法
上記の想定効果をどのように定量化して検証するのかを書く。より込み入った実験になれば実験対象ユーザーのグループ分けも詳細に書く。カンム社員全員でSQL勉強会をやっている話 で学んだSQLがここでも遺憾なく発揮される。可能な限りレビュー前に効果検証用のクエリを作成しておき、それもレビューを通す。
スケジュール
スケジュールを書く。いつまでダラダラやってんだみたいな形にしない基本。
効果検証
効果検証方法に従い、実際どうだったのかをまとめる。
考察
この実験によって何が学べたのかを書く。別にうまくいかなかったらうまくいかなかったで良いが学習できた内容を中心に書く。ソフトウェアエンジニアの文化にある障害発生時にポストモーテムを書くことに似ている。
ノートを書くようになった効果
これらのノートがまとまった場所に存在していれば、「どういう前提で仮説を立てて、それがどういう方法で検証され、棄却されたのか受け入れられたのか、また棄却された場合に得た学びは何か」ということが一枚のノートと検証用SQLにまとまる。更にこのノートが増えていけば後々見返すことも可能だし、後から入ってきた人が参考にすることも可能。以前似たような施策を打ったときにどういう効果があったのか、なぜうまく行かなかったのかを考える元になる。
さらに副次的な効果として、「実験前にレビューが可能になった」というのが結構大きい。ソフトウェアエンジニア側から「こういうデータがあるから検証できる」やデザイナー側から「それを検証したいのであればこういう形はどうか」みたいな建設的議論が出来るようになったと感じる。また、施策案をレビューする自分の立場からしてもフォーマットが統一されている為、「これどうやって検証するの？」みたいな基礎的な指摘が激減した。
現状はこういう形で検証サイクルを回しているが、これが100%正解だとも思っていない。まだまだ改善できる部分はかなりあると感じているし、継続的に「本当にこういう書き方でいいのか」みたいなところは議論していきたい。
まとめ
極論、何が当たるかみたいなのはわからん。ただ「わからん」と「わかる」は単純な二値ではなくグラデーションになっており、「わかる」の範囲を広げ、「わからん」の中に潜むまだ誰も見たことのないチャネルや施策をチームとして発掘しにいく、どのように進むのが良いか、という問いは常に頭の中に保持し続けていきたい。そもそも既存のデータからはなんもわからん！！とにかく良いと思うからコレをやる！！！が正解な局面だってあるだろう。その「良いと思うこと」が小さく実験を行えるものではない場合、今回紹介した方法は使えない。
可能な限り理性を使って検証していこうという姿勢はどのようなケースにおいても基礎として大切にし、いざとなったら大きく「良い」と思う方へ舵を切って施策を打つ、みたいな事ができれば良いなぁと思っている。まだまだ修行が足りない。
「良いプロダクト」というのはそのプロダクトのディストリビューションも含めた総合的なものであるという意識を忘れず、作る側であるソフトウェアエンジニアやデザイナーと協同しながら、届ける側の挟持を持って今後も「良いプロダクト」を作っていきたい。
そんなカンムのマーケチームは絶賛採用募集中です！！！興味がある方はお話だけでもいかがでしょうか！！