ReactNative製のiOS/Androidアプリを楽に改善していくには

~~どうすれば~~

この記事は[React Native Advent Calendar 2019](https://qiita.com/advent-calendar/2019/react-native)の6日目の記事です。

AutoScaleでReactNativeを使って[SocialDog](https://social-dog.net/)のアプリ版の開発・運用をしている[@t0m0120](https://twitter.com/t0m0120)です。

アプリの開発から改善していくフェーズになっていく中でやって良かった事などを書ければなーと思って担当日終了3時間前に必死に書いています。


## TL;DR

ユーザーがアプリのインストールから課金などの目的を達成する流れの中で工数が少なくインパクトがデカそうなものを中心に今年は~~覚えてる中で~~下記の4つをこなしてました。

1. 色々自動化しておく
2. PlayStoreのABTestを駆使してインストール率を上げる。(☓ReactNative)
3. AppStore/PlayStoreレビュー対策を打つ
4. 課金導線など重要な導線はWebViewにしてしまって変更しやすくする。
5. Firebase A/BTestを使ってPushNotificationのTestを行ってみる。

## 1. 色々自動化しておく

この辺はもう少し詳しくQiitaか個人ブログに残すと思います。多分。

1. [Bitrise](https://app.bitrise.io/me/profile#/referrals)を使ってリリースビルドやdSYMのアップロードなどアプリファイルを扱う範囲は極力ワンクリックや自動にしておく

2. Bitriseを使ってAndroidのUITestを毎日とリリース前に簡単に走らせてスクショ確認出来る体制をつくる 
 [ReactNativeアプリをBitrise上でUITestしてみた話
](https://speakerdeck.com/t0m0120/reactnativeapuriwobitriseshang-deuitestsitemitahua)

3. レビューやインストール数などの通知はSlackにすべて飛ばしておく
[AppFollow](https://appfollow.io/jp)や[AppsFlyer](https://www.appsflyer.com/jp/)やリリース完了通知メールをSlackに飛ばすなど極力Slackのalertチャンネルを見れば追える状態にしていました。
 

## 2. PlayStoreのABTestを駆使する

流入系第1弾。
ReactNativeには関係ないので簡単に。
PlayStoreのストア掲載情報のテスト機能を使ってアイコンやスクリーンショットや文言などをFigmaで軽く色やレイアウトを変えたりマイクロコピーについての本などを参考にABTestして良さそうな物をAppStoreに輸出するというのをやっていました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/226100/289c1a43-a680-fd38-2da5-aeb13b95a01a.png)


## 3. AppStore/PlayStoreレビュー対策を打つ

流入系第2弾。
レビュー平均値の☆評価が3と4でアプリのインストール率が大幅に変わるというデータがネット上に転がっていたので以下4点を1年を通して行ってきました。

1. **ErrorBoundaryの設置**
2. Intercomなどお問い合わせの導線でストレスを減らす。
3. [KjellConnelly/react-native-rate](https://github.com/KjellConnelly/react-native-rate)を用いてストレスにならないタイミングでレビューをお願いする。
4. レビューの返信を必ずする。バグ対応は迅速に連絡する


詳細は夏に書いた[ReactNativeアプリを3ヶ月でレビュー数を10倍以上に持っていった話](https://qiita.com/t0m0120/items/775514bf1dc5fc7878de)へどうぞ。
8月の記事から更にレビュー高いまま件数が伸びておりリリース後早めに対策しておいて良かったなーと思っています。


## 4. 課金導線など重要な導線はWebViewにしてしまい変更しやすくする。

[react-native-webview/communicating-between-js-and-native](https://github.com/react-native-community/react-native-webview/blob/master/docs/Guide.md#communicating-between-js-and-native)のonMessageなどでNative側の開閉などの動作をWebView側から動かせる様になるので動作はNativeに任せておいて見た目に関してはサーバー上のHTML/CSSにしている箇所がいくつかあります。

そうする事で表示に関してはWeb側のHTMLとCSSの変更で対応出来るので
- 審査を待たずにデザインや文言の変更やテストが出来る。
- ReactNativeを書いてないメンバーにHTML/CSSの編集としてタスクを割り当てることが出来る。
など反映の手間と工数の削減が出来ました。


## 5. Firebase A/BTestを使ってPushNotificationのTestを行ってみる。

弊社のプロダクトでは[react-native-firebase](https://github.com/invertase/react-native-firebase)のFCMを使ってPushを送っているので

Firebase ConsoleのA/BTest -> Notificationsから文言と対象人数や属性を選んで文言の違いによる通知開封率 / 課金モーダルの開閉率など1度調査してみました。なぜか送られた人数が少ない？様でしたが

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/226100/5795003a-ae21-6345-5ace-e09546aef977.png)


Push通知の文章考えるだけで下記の様に通知の開封率から指定したイベント(今回は課金モーダルの開閉率)とアプリへの定着率が取れ、今後送るPush通知やパーソナライズされた文言やシーズナリティの文言など送る際の参考にできそうかなーと思っています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/226100/dcf24523-c727-9b7a-ad68-10a5775d2796.png)


## 最後に

足早に書いていてあんまりReactNative感無いな・・・と思いながらもフルタイム自分と週2日稼働のインターン2名という少ない人員の中で機能追加や修正をしながらデザインやPush文言などの細かい改善を並行して繰り返していけるのは使い慣れたReactチックな1コードでほぼ2OSを書けるReactNativeのおかげかなーと思っています。View作るだけなら本当に楽。

まだまだ楽して改善出来るポイントはあると思うので更に改善するテクニックやポイントなどあればコメントいただけると嬉しいです！！

一緒にサービスの開発から改善など行ってみたい方、話を聞いてみたい方は[Wantedly](https://www.wantedly.com/projects/386719)からどうぞ！


次回の[React Native Advent Calendar 2019](https://qiita.com/advent-calendar/2019/react-native)7日目はPIAZZAの[@okusama](https://qiita.com/okusawa)さんです！よろしくおねがいします！