サイトとアプリ運営に関するメモ的なブログ

自分で運営しているブログとかアプリについて書くところ WEB広告とかSEOがらみの話題が多くなるかも

個人事業こそシビアにビジネス面を考えないといけないのかもしれない

ここ数年、個人事業のみで生活をしている。

個人でやることなので、何をやるかやらないか自分で決められる。

それはとてもよいことなのだけど、やってみたけどまったくお金にならなかった、という事態に陥ることもしばしば…いや、かなりある。

個人の興味や好みで何をやるかを決めると、ビジネス的には全然うまくいかないことにけっこうな時間を注いでしまった、ということになりがちなのだ。

 

企業はあらかじめ企画を立て、複数人で検討し、試算などしてから事業に取り組む。

それでも成功したり失敗したりするのに、検討をろくにやらずに適当に取り組むと、ほんとにうまくいかない。

あるいはすごく収益が少なくなる。

一部の人に評判はいいのだけど、規模としては小さいものにしかならなかった、ということも多い。

 

なのでお金を稼ぐためにやるのであれば、個人の活動であってもシビアに、ビジネス的に成功するかどうかを考える癖をつけておいた方がよいのかもしれない、と思った。

周囲から何かを言われることがない分だけ、余計にそれを強く意識した方がいいのだろう。

そうしておかないと、ついつい全然お金にならないことに多大な労力を費やしてしまったりするのだ。

 

大富豪であればそんなことを考えなくていいのかもしれないが、私はそうではないので、これからは考え方を変えていこうと思う。

今年の振り返りと来年の目標

今年は外注の仕事を一切受けず、自分が作ったものから得られる収入だけで生活をすることができた。

この点がまず大きな変化だったと言える。

具体的にはスマホアプリ、電子書籍、サイト運営による収入だけで、とりあえず生活費は賄えるようになった。

 

一方でスマホアプリの広告収益は、iOSの仕様の変更に伴って、単価が30%くらいダウンしたので、なかなか厳しい状況にある。

それでも、基盤となる広告の表示回数は増加したので、それによってマイナス分が相殺され、トータルでは広告収益は微増となった。

そして今年出した新しいアプリが、ある程度の規模で安定的にダウンロードされるようになっているので、来年は増収を目指すことができそうだ。

 

電子書籍は去年一冊出したきりで、どうなるだろうかと様子を見ていたのだけど、小規模ながらも収益源として扱っていくことができそうなので、今後も折を見て新しい本を作っていきたい。

とは言え、アプリと比較すると収益性は大幅に下がるので、ほとんど趣味の領域となっていくだろう。

ただ、書籍の場合はファンがついたりもするので、金銭的な価値だけでは測れない部分もあるように思えた。

文化的な活動として位置づけていくことにする。

 

プライバシーの重視によって、スマホアプリの広告配信には制限がかかり、収益が伸びていく事は期待しづらい状況にあるので、来年は別の方面に目を向けていくことにしようかと考えている。

 

具体的にはゲームの制作に本格的に取り組むつもりだ。

いちおう、スマホ向けのゲームを1本リリースした経験はある。

とは言えブランクもあるので、まずは1、2ヶ月程度で完成させられそうな、シンプルなゲームをいくつか作り、ゲーム制作の環境を整えていきたい。

 

いまのところはスマホアプリがメインの収入源になっているが、スマホ市場がいつまで安泰かわからないし、余裕があるうちに、有料で売れる水準のゲームを作れるようになっておきたいところ。

 

広告だよりはよくないな、というのがここ数年、あれこれやってきた結果として、得られた知見でもある。

たとえば、アプリのクオリティを上げても広告単価の向上にはつながらない、という問題がある。

クオリティに比例して、入ってくるお金が増えるようなことをしていきたい。

Googleからの検索流入をあてにしない方がいいという結論

これまで数年にわたってサイトを運営してきて、それなりに収益を得てきた。
しかしそこで得られた結論は、Googleのサービスを利用することを前提として、収益の計画を立ててはいけない、というものだった。
このサービスとは、Google検索やGoogle AdSenseをさしている。

今年の6月に入ってから、突如として検索流入の数が大幅に減少した。
原因はよくわからないのだけど、わからないのが最大の問題だ。
わからないことには対処のしようがないし、文句を言える先はどこにも存在しない。
ビジネスは、こちら側で制御できない要因が多くなればなるほど不安定なものになっていくが、Googleのサービスはそれが大きくなりすぎるという問題がある。
検索のアルゴリズムはざっくりと紹介はされているけれど、詳細が分からないし、たびたび変更され、それによってアクセス数に大きな変動が出てしまう。
そして減少しても、こちらからは異議の申し立てができないし、さながらGoogleが神のごとく、思うままに、自由自在にアクセス数を変動させてしまう。
そのようなものをあてにして収益を得ようと考えるべきではない、というのが、数年間にわたってサイトを運営してきたことによって、到達した認識だ。

このことにはしばらく前から気がついていて、サイトの運営はあまり重視しなくなっていたのだけど、今年になってその思いがいっそう、強まっている。
すでに他の活動をメインにすえ、個人活動の収益源にしているので、サイトの運営がイマイチになってもまあよいのだけど、今から検索流入をあてにして、サイトの運営をやっていこう考えている人がいたら、それはやめておいた方がよいだろうと思う。

もとより、ウェブにおける広告はすっかり嫌われ者になっていて、広告ブロックを導入するのが当たり前になっている。AdSenseはそうでもないが、たちの悪い広告業者がいっこうに排除されず、ユーザーを不快な思いをさせ続けたのが原因で、改善される見込みがない。この結果、iOSでは公式にブロックを導入する仕組みが用意されるようになってしまい、将来性が乏しい分野だと言える。
こういった背景があったので、サイトの運営にはだんだんと力を入れなくなっていたのだけど、今年になって、それがいよいよ極まったという感触を得た。
文章を書いたりコンテンツを作ったりするのは好きなので、これからは別の形でそれを展開することを計画している。
それである程度、成果が出せたなら、そのことを記事に書いていきたい。

関連コンテンツユニットの位置を変えたら視認率が大きく向上した

Adsenseの関連コンテンツユニットは以前、成果がもう一つだったので設置しないことにしていた。

けれど、WordPressのテーマを変えた関係で、関連記事を自動的にいい感じで出してくれるプラグインが使えなくなってしまったので、再度導入することにした。

 

配置は

 

・本文

SNSシェア・フォローボタン

・関連コンテンツユニット

 

という順番で、視認率がわずか6%程度だった。

なので成果もあがっていなかったのだけど、ふと思いついて

 

・本文

・関連コンテンツユニット

SNSシェア・フォローボタン

 

の順番に変え、関連コンテンツユニットをコンテンツの直下に置いてみた。

変更の結果

すると視認率が20%まで上昇し、大きな変化があった。

視認率が3倍以上になったので、クリック数が大幅に増加し、収益も増えている。

視認率の改善に伴って、しばらくすれば単価も上昇してくるだろう。

また、これによって関連コンテンツユニット経由の閲覧数が増え、PVの増加につながっている。

並びを変えるだけでもけっこうな違いが出る

このように、配置を変えるだけでもけっこう違いが出るので、関連コンテンツユニットの成果がいまいちだと感じてる人は、コンテンツにより近い場所に配置を変えてみると、よい影響が出るかも知れない。

元の視認率が低い理由

それにしても6%は低すぎでは、と思った人もいるかもしれないが、これは私のサイトがページ分割をしているためで、「次のページを見る」ボタンよりも下の領域は、かなり視認率が低めになる傾向にある。

関連コンテンツユニットとページ分割は、収益の面で見ると相性がよくないということになる。

SNSボタンの変更

ところでこの結果を見ると、SNSボタンのところで14%くらいのユーザーが、それより下を見なくなっていたわけで、これほど違いがあるのかとちょっと驚いた。

私のサイトの場合、シェアボタンが6個、それに加えて「この記事が気に入ったらいいね!しよう」という大きめのボックス、さらにはRSSやpocketなどのフォローボタンまで表示していたので、スマートフォンで見ると、画面全体を占有してしまうくらい、SNS関連の領域が大きかった。

このように、サイトの運営者にとっては重要だが、ユーザーの興味はあまり引かない領域が続くことで、離脱率が上がっていたのだろう。

これはよくないかなと思い、シェアボタンはフェイスブックツイッターのみに絞り、あとはフォローボックスだけにして、SNSの領域を縮小させてみた。

もともとコンテンツのタイプが、SNSで拡散されやすいものではないので、SNSボタンに領域を割きすぎていたのは、マイナスの影響が大きかったのだろう。

SNSでの拡散が重要なサイトの場合には、関連コンテンツユニットはシェアボタンの下でもいいのだろうし、サイトのタイプによって、最適解は変わってくると思われる。

ブログのAMP使用を中止した

AMPには色々とメリットがあると聞いてワードプレスのブログに導入していたのだけど、先日使用を中止した。

メリットはモバイルでの表示速度が高速になることで、これは確かにいいと言えばいいし、AMPページの方が、若干だが広告の収益率も高かった。

しかしアクセス解析のデータがうまくとれなかったり、プラグインが干渉してAMPのページにエラーが出たりと、何かと管理に手間がかかってしまう。

サイトで新しいことをする際に、AMPに問題が出ないかを気にするのは、はっきりいって面倒くさい。

サイト管理の手間が増えるわりに、そこまで大きなメリットがあるわけでもなかったので、すっぱりと使うのをやめることにした。

エラーが出ると、その検証に手間が取られてストレスがたまる。

自分で掌握しづらいものは使わない方がいいな、とつくづく思った。

それに、日本の通信環境は安定していて高速なので、他国と比べてAMP導入のメリットが小さいのではないかと思う。

中止する方法

使用を中止する際には、AMPのページにhtaccessで301か302リダイレクトをかけ、ヘッダーに記述していた rel="amphtml" を削除する必要がある。

詳しい方法はgoogleのドキュメントに書いてあるので、参照されたし。

Remove AMP Content from Google Search  |  Search  |  Google Developers

これを設定すると、しばらくするとAMPページは消えて、普通のページに検索結果が出るようになるらしい。

というわけで、さらばAMP。

サイト運営の新しい方針を試してみている

今年は2月〜9月くらいまでが忙しくて、メインのサイトをほとんど更新できず、かなりアクセス数が下がってしまった。

以前作った人気記事の検索順位がのきなみ下がってしまい、だいたいピーク時の半分くらいのアクセス数になっている。

それでもまだ半分は残っているし、SNSアカウントのフォロワーが数百人くらいはいるので、このまま衰退させるのはもったいない。

というわけで、新しい方針を立てて運営を続けることにした。

対象は歴史関連のサイトなのだけれど、これまで国や時代区分を気にせず、自分が関心のあるテーマをランダムに取り上げていた。

そうすると書くのは楽しいのだけど、専門的にやっているサイトには、中長期的には競争力で劣ってしまう。

人気があった記事の検索順位が落ちたのは、そのあたりが影響しているのだろう。

なのでこれからはひとつひとつのテーマを深掘りし、数百単位でまとまったコンテンツを作っていくことにした。

それが完了してから別のテーマに移る、というやり方に切り替えてみる。

そうすることで、知識を深めることもにもつながるので、個人的にもメリットがある。

ひとまず時代を特定して、代表的な人物伝と、用語集を作っていくことにした。

人物伝は作るのに時間がかかるので、用語集を併設することで、更新頻度を確保している。

(人物伝は1記事ごとに数千〜数万字、用語集は千字程度になっている)

10月からそういう方針で運営をし始めているが、今のところはまだ記事を作り始めたばかりなので、大きな変化はない。

来年の一年間、継続してみて、どうサイトの状況が変動していくかを、見てみることにした。

UnityのScreen.safeAreaを使うとRectTransFormのAnchorがずれてしまう問題

UnityにはiPhoneXに対応するためにScreen.safeAreaという機能があるのだけれど、これを使ってみたところ、iPhoneX以外の端末でuguiの表示サイズがおかしくなる問題が多発した。

Screen.safeAreaはiPhoneX以外の端末ではスクリーンのサイズを返すのだけれど、uguiの Reference Resolution などを使ってアプリ内部の解像度設定を変えていると、そちらの数値を取得してしまい、端末のディスプレイサイズとの間に齟齬が生じるらしい。

そのずれを抱えたまま、safeArea向けにguiのRectTransFormのAnchorの位置を設定すると、guiの表示位置もまたずれて表示されてしまう、という問題が発生する。

この影響で、ユーザーから画面が左下に寄り、縮小されて表示されている、という不具合報告が多数届いた。

あるいは逆に、拡大されすぎてアプリの一部分しか表示されていなかったりした。

ちゃんと実機でテストしなかったのが悪いのだけれど、この現象はシミュレーターでは確認できなかったので注意が必要だと思う。

色々と試したが、結局はScreen.safeAreaを使った処理はiPhoneXでしか動作しないようにしたところ、この問題が解決した。

 

具体的には、

 

//ディスプレイのサイズを取得
var display = Display.displays[0];
var screenSize = new Vector2Int(display.systemWidth, display.systemHeight);

 

//iPhoneXのディスプレイサイズでのみ動作する条件を設定
if(screenSize.x == 1125 && screenSize.y == 2436 || screenSize.x == 2436 && screenSize.y == 1125){

//以下にsafeAreaに関する処理を記述

}

 

上記のように、iPhoneXのディスプレイサイズでのみ動作するように条件を付けた。
今後、同じサイズでiPhoneXタイプでない端末が出たらやっかいだけど、いまのところはこれで問題ないようだ。

もしかしたらそのうちAndroidで同サイズの端末が出るかもしれないので、iOSでしか動かないように、さらに条件を加えておいてもいいかもしれない。

iOS.DeviceGeneration.iPhoneXで見分けることもできるらしいのだけど、DeviceGenerationはしばしば認識しそこなって、unknownを返すことがあるそうなので、使用はやめておいた。


AWS Device Farmを使ってみた

実機のテストにはAWS Device Farmを使用した。
テスト時間が1000分までは無料で、さらにテスト中の動画が見れるので、ちゃんと表示ができているか確認できて助かった。
無料分が切れると1分17セント(19円くらい)になるらしい。
このくらいの価格なら、実機を揃えるよりはるかに手軽だし、今後も使っていくことになりそうだ。

aws.amazon.com


iPhoneX対応はめんどうなことになりそうな予感がしていたのでサボっていたのだけれど、対応してみたら案の定、トラブルが発生した。

もしかしたら1年限りでXタイプは消えるんじゃないかと思っていたこともあって、対応を伸ばし伸ばしにしていたのだけど、どうやら今年はXタイプが3機種も出るらしい。

なので観念して対応したが、今後もトラブルの原因になりそうで、不安を感じている。