pornpare.comの開発日記

www.pornpare.comの開発日記です。

振り出しに戻った1週間

今週1週間は色々とありました。

 

* ec2インスタンスのサイズが小さくなった

* PVが減った

* 広告を導入した

* クローラサーバーの刷新を決めた

 

どれもこれも先週の記事

pornpare.hatenablog.com

に付随する内容ではあります。

 

* ec2インスタンスのサイズが小さくなった

さすがにサーバー負荷増加のペースが早すぎるだろうということで、

その後NewRelicを導入して負荷解析を進めた結果、

動画詳細ページでredis cacheをしている部分が負荷の原因だと判明しました。

ここを修正した結果インスタンスサイズを小さく低コスト化をすることができました。

before/afterはこんなかんじ、もっと早く導入していればよかったですね。

f:id:pornpare:20171011014105p:plain

 

* PVが減った

Pornpare.comに掲載させていただいているサイトさんはチャネルとしてインバウンド/アウトバウンド両方とも存在します。

で、ユーザビリティ低いサイトを掲載するのは私のポリシーに反するということで、掲載前にある程度サイトを見た上で判断を行っているのですが、いくつかのサイトを掲載後のタイミングで掲載を停止する判断を行いました。

対応内容としては今後記事を掲載しないというのはもちろんなのですが、過去掲載した記事についても全削除を行いました。

結果として2000/50000程度の記事を削除したため、流入経路となっていた記事が幾つか消滅しPV減少に繋がったかたちとなります。

f:id:pornpare:20171015194410p:plain

数字的にはおもったよりもダメージが大きかったのですがまぁ仕方なしかなと思っています。

 

* 広告を導入した

クリック保証型の広告の導入を行いました。

前回の記事の話に付随しますが、改めてサービスを安定的に提供するためにはマネタイズもセットで考えなければならないなと思ったためです。

広告という制約がある中で、いかにユーザビリティを上げるかが重要だなと今は考えています。

 

* クローラサーバーの刷新を決めた

こちらは最優先で進めたい開発に関わるものです。

技術的な話はほどほどにしますが、

pornpareの記事クローリングにはphantomjsというヘッドレスブラウザを使っています、刷新内容としてはこのphantomjsでのクローリングからgoogle提供のHeadless Chromeによるクローリングへの変更が主になります。

あわせてphantomjsをrailsで動かしていましたが、headless chromeを操作するAPIpythonかnodejsのものしか現状有力なものがなさそうでしたの下記のもので実装を進めます。

github.com

 

理由としてはこのphantomjsが今後積極的な開発が行われないと決定したことにあわせて、html5実装であるvideo周りの操作にも対応をしていないというのが決め手になりました。

 

そんな感じでサービス拡大にあわせて、

今まで手をつけようにもつけられなかった問題に着手しようと決定したのが今週のハイライトになります。

 

以上今月もよろしくお願いします

(クローラ周りの回収は劇的にユーザビリティ上がるはずなので今月で実装終えたいところです)

 

消耗戦の様相を呈してきた開発

およそ10日ぶりの投稿となります。

 

開発のほうは相変わらずコツコツ行っておりまして、

ユーザビリティはだいぶあがってきたかなと思います。

 

一方で表題の通り課題が発生してきたというのがここ1週間での進捗となります。

簡単にいうと収益と支出のバランスが取れていないということなんですが、まぁそれはもともとわかっていたことではあります。(というかもともと収益あげる施策は特に売っていなかったです)

 

* 支出

まずは支出側の話。

Pornpare運用にあたっての主な支出は言うまでもなくサーバーなどのインフラ支出なのですが、ネックになっているのがAWSの料金体系です。

以前の記事でも書いたかもしれませんが、Pornpareはec2インスタンスで運用されています、このec2インスタンス(t2)でいまいま問題になっているのがCPUクレジットです。簡単にいうと通常のサーバーであれば固定で持っているはずのCPUリソースがクレジットという名の通り増えたり減ったりするということです。

一定の割合を超えてインスタンスのCPUを利用していると、クレジットが減っていきCPUの性能が落ちていく、という具合です。

これの何が問題なのかというと、本来持っているはずのサーバースペックをフルに利用する前にインスタンスタイプのサイズをあげなければならないということです。

難しく言いましたが、普通に自分でサーバー立てるよりだいぶ割高だということですね。

 

** PV数の増加の影響

そしてこの割高の料金体系にあわせて頭を悩ませているのが、PV数が急激に増えているということです。処理できるアクセス数とサーバースペックは比例するので、コーディング等々アプリケーション側での対応はあるものの、基本的にはサーバースペックをあげることでしか対応できないのです。

EC2のt2インスタンスですと1つスペックをあげるだけで料金が倍になります。

 

* 収益

次に収益の話。

10月に入ってからちまちまと広告運用をはじめました。

今はスマートフォン向けにクリック保証型のアフィリエイトを貼り付けているだけですが、上記PV数の増加に対応するために早期に収益をあげることが必要になってきました。(今のところPV数は伸び悩む気配がないので、一社員の自分が維持できるサーバーサイズにも限界がくると思います。)

ということで早いうちにインフラ維持費の足しになる程度の収益は得たいというのが今の心境です。

アプリケーションの開発についてはそれなりに知見はあるものの広告運用や収益化についてはほぼ未体験ゾーンなので苦労しそうな印象。

 

* まとめ

何度も述べている通りですが、私はエロサイトであってもユーザーファーストで作りたいと思っています。一方で広告を貼り付けるというのは基本的にユーザビリティを下げる施策でありあまり乗り気ではありません。将来的にはアフィリエイト以外の収益モデルを見つけたいと思いますし、広告もなるべくユーザビリティに関与しないものにしたいというのが私の意思です。

 

しばらくは試行錯誤をするので鬱陶しい広告が増えるかもしれませんがご了承いただけると幸いです。

 

引き続きよろしくお願いいたします。

 

9月の振り返り KPI編

pornpare.hatenablog.com

 

引き続き9月の振り返りです。

KPIは以下のとおり。

* リピーターUU改善

f:id:pornpare:20171001035123p:plain

 

UU自体は9/1が17人、9/30が255人なのでだいぶ増えてはいるのですが、全体UUに対してリピーターが占める割合については実はそれほど伸びていなかったりします。ユーザーに愛されるサービスを作りたいという私の思想に従うならば、単純にリピーターUUではなく割合でリピーターを評価するべきだったなと9月中は考えていました。

10月からは全体UUにリピーターが占める割合を指標として追いかけたいと思います。

 

* 新規ユーザー直帰率改善

f:id:pornpare:20171001035037p:plain

 

こちらは、新規ユーザーの流入経路としてもっとも多いmoviesディレクトリの直帰率推移になります。9月頭では80%台で推移していたものが9月末では70%前後まで改善しました。この結果については比較的満足しておりサービス全体の直帰率も同様に改善が見られ9月末時点でおよそ60%となっています。

下記の記事を参考にするに、50%前後の直帰率が良いサービスの指標と言えるのかなと思っています。またPV/セッションもサービスの良し悪しを判断する指標としては有用なようです。

メディア別に、滞在時間や一人あたりのPV数を調べてみた |UI/UXデザイン アプリ/サービス開発 | UI/UXデザインのアジケ ajike

 

以上を踏まえて、

10月の方針についてですが、

10月はPVやUUは追いかけずサービスの質を判断できるものをKPIに据えたいと思います。といっても9月とそれほど方針は変わりません。

 

* リピーターUU/全体UUの改善

全体ユーザー数に占めるリピーター数の割合をあげていきます。

* 新規ユーザー直帰率の改善

現在60%前後となっていますが、50%程度まで改善させたいと思います。

* リピーターのページ/セッションの改善

上記リンクページで指標となっていたものを新たに導入したいと思います、

2.xページ/セッションが目安 となりそうです。

なぜリピーターに限定しているかというと9月のリピーターのページ/セッションが、体感ですが少し少ないかなと感じているためです。

f:id:pornpare:20171001040645p:plain

昨日時点で3.xページ/セッションとなっており、実際に私がアダルトサイトを利用する場合と比べると明らかに少ないなという印象を持っています。

10ページ/セッション程度であっても全然おかしくはないと思いますので、こちらを優先して改善していきます。

 

それでは10月もよろしくお願いいたします。

 

9月の振り返り 開発編

9月末ということでpornpare.comの振り返りを行いたいと思います。

 

9月の方針については下記参照

 

pornpare.hatenablog.com

 

大方針としては

* リピーターUU改善

* 新規ユーザーの直帰率改善

ということで開発を行いました。

 

やったことを大きくあげると以下の通りです。

* gaタグ埋め込みまくり

* movies詳細ページとトップページのレイアウト修正

* キャッシュ機構導入

 

それぞれ詳しめに解説すると

* gaタグ埋め込みまくり

これは文字通りですが上記方針を実行するにあたり現状の課題を明確に把握するためにユーザーの動向をより細かく把握する必要があったためです。具体的にはaタグにクリックイベントを仕込んでどのボタンがよく押されているのかであったりを取得するようにしました。

f:id:pornpare:20170930022931p:plain

 

* movies詳細ページとトップページのレイアウト修正

gaタグを埋め込んだ結果が上のとおりです。

もともと抱えていたmovies詳細の離脱率が高いという課題については上記gaタグの話とはまったく別で関連する動画のリンクをページ下部に差し込み導線を増やしました。

トップページについてはgaタグ埋め込みの結果を参考に、カテゴリー一覧/女優一覧といったユーザにとって重要度の低いものをヘッダー部分に移動させてコンテンツを大きく見せるといった具合に変更を加えました。

 

ヘッダーのこのあたりとかです。

f:id:pornpare:20170930193105p:plain

 

 

* キャッシュ機構導入

以前述べたとおりですが、ユーザの行動履歴を取得するためにelasticacheの導入を行いました。またせっかくなのでということでカテゴリー一覧/女優一覧の集計周りのデータ保持をelasticacheに任せることで読み込み速度の高速化を図りました。

 

以上9月の開発のダイジェストになります。

 

集客目的の開発とユーザー中心の開発

久しぶりの投稿になります。

 

機能開発もある程度進んできまして、

最低限UIを含めての実装が落ち着いたかなというタイミングです。

 

今後サービスを作るにあたって、

色々方針を考えたりしているのですが、

今考えていることが表題の通りで、

集客目的の開発とユーザのための開発の両立になります。

 

ご存じの方もいるかもしれませんが、

アダルトアンテナサイトを取り巻くプレイヤーは3名います。

* アダルトアンテナサイト自体

* アンテナサイトに掲載されるエログ

* 利用ユーザー

各人がそれぞれ目的を持ってサービスを利用したり運用したりしているわけで、

私が今のところ把握している一般的な各人のモチベーションは以下の通り。

 

* アダルトアンテナサイト自体

自サイトに集客を増やすことにより収入を得ること

* アンテナサイトに掲載されるエログ

自サイトに集客を増やすことにより収入を得ること

* 利用ユーザー

性欲を満たすこと

 

まま、当たり前のことです。

 

ここでキモになるのがいかにして集客を増やすかになりますが、

アダルトサイトの特性としてSNS等でのシェアはほぼほぼ期待できないので、

相互集客orオーガニックサーチが主な自サイトへの流入チャネルとなります。

オーガニックサーチはSEOが強くなれば自然と伸びていくので、

相互集客、オーガニックサーチどちらにしても相互リンクを貼ることで、

目的は満たせるわけです。

 

そういう観点からアンテナサイトを眺めてみると、

やはり栄えているサイトはうまくやっているなという印象で、

相互集客、相互リンクを増やすために様々な工夫をしています。

エログに対してランクという概念を導入して、自サイトへのリンクを促す等々。

 

この施策自体は非常に良くできたものだと思いますし、

Pornpare.comにおいてもわりと優先度の高い実装項目ではあるのですが、

イマイチ踏み切れずにいます。

 

それは第3のプレイヤーであるユーザーのことを気にしているからです、

特に気にしているのはユーザビリティ

集客優先になるがゆえに

ユーザーにとって使いにくいサイトになったり、

潜在的であれ目的の動画にたどり着かないことが増えるのではないかという点です。

 

アンテナ側ではそれほど意識することはないと思いますが、

相互集客用のブログパーツが乱立してユーザビリティが低下したエログは、

頻繁に目にする気がします。

 

この辺を考えながら三方良しな施策があればなーと思ってはいるのですが、

意外と私の考え過ぎかなと思ったり思わなかったり。

でも目指すならアダルトアンテナ会のgoogleになりたいなと思い、

妥協せず引き続きサービスの運用を行いたいと思っています。

 

では本日は以上になります。

 

http://www.pornpare.com/

moviesディレクトリの正式な直帰率とかプラットフォーム的な構想とか。(9/12)

 

* 正味の直帰率のお話
昨日movies詳細ページの外部リンククリック数を取得するようにしました。
 
GAのonClick引数のnoninteraction true設定すればそもそも、
クリックイベントを直帰率から排除できるんですが。
クリックイベント数から逆算した速報値です。
 
概算ですが、
(PV * 直帰率 - クリック数) /PV
直帰したセッションからクリック数を引いたものを実直帰とみなしてます。
 

(1380 * 0.7751 - 374)/1380

= 0.504
 
およそ50%くらいですかね?
 
* やはりプラットフォームを目指したい。
プラットフォーム、説明は難しいですが、
わかりやすいところでいうとgoogleやyahoo。
アダルトでいうとアンテナサイトのような情報が集約されるような場所の
イメージです。
 
pornpare.comは現状はアンテナサイト的な立ち位置になっていますが、
情報が集まればどのような記事が集客しやすいかとか、
今はこの女優が熱いといったアダルトブログを運用する方に対しても、
有益な情報を提供できるのではないかと考えています。
 
そのためにはクローリングする記事数を増やすことと、
ユーザーの行動履歴を貯めることが必要なので、
引き続き頑張っていきたいと思います。
 
今日はここまで。