Capgoでは、3つの値がカウントされ、理解することが重要です

• ユーザー数
• ストレージ
• 帯域幅

それぞれ少し異なるカウント方法があります

ユーザー

ユーザーがCapacitor JSアプリをダウンロードして開くたびに、アップデートが利用可能かどうかを確認するためにCapgoバックエンドにリクエストを送信します。 アプリがこれを行うとき、最も重要な情報であるDeviceIDを含む少量の情報を送信します。

DeviceID: デバイスのOSによって定義される一意のID（UUID）で、このIDはアプリのインストールごとに一意です。

アカウントが新しいDevice IDを受け取るたびに、データベースに保存されます。 古いDeviceIDがアップデートをリクエストする（アプリを開く）たびに、そのレコードが更新されます（データベースのupdated_at）。

このデータは2つの場所に保存されます：

• deviceテーブル（update_at値を含む）
• app_stats（今日アクティブになり、今月アクティブでなかったデバイス数を表す日次カウンター）

プラン制限には100%信頼性のある最初の方法が使用され、チャートの表示には2番目の方法が使用されます。 アカウントのホームページで両方を確認できます：

• チャートには2番目の方法
• アプリテーブルには最初の方法

Capgoはエミュレーターと開発ビルドを使用量にカウントしません。トライアル後、それらが3%を超えるとアカウントがロックされることに注意してください。修正するまでロックは解除されません。

Capgoはデータのフィルタリングも行っています。Google PLAYにバージョンを送信するようにCI/CDを設定している場合、Googleは毎回20以上の実デバイスでCapacitorアプリを実行します。新しいバンドルの最初の4時間の間、それらがカウントされるのを防ぐためにGoogleデータセンターのIPをブロックしています。

このデータは毎月ゼロからスタートします。

• デバイスリクエストごとにデータベースでデバイスを作成または更新
• 今月アクティブでなかったアクティブデバイス数を日次カウンターに追加

最初の方法では900以上のユーザー 2番目の方法では200以上のユーザーとなります プラン制限には100%信頼性のある最初の方法を使用し、チャート表示には2番目の方法を使用します。 アカウントのホームページで両方を確認できます。

ストレージ

バンドルをアップロードするたびに、アップロードのサイズだけこの数値が増加します。

このデータはアップロードサイズのみに関連し、アプリサイズが小さいほど、プラン内に収まりやすくなります。

制限に近づいたり達した場合、CLIでバンドルを一覧表示できます： npx @capgo/cli@latest bundle list クリーンアップ対象を確認でき、バンドルを削除するとストレージは解放されますが、統計は削除されません。

クリーンアップの準備ができたら、このコマンドで複数のバンドルを削除できます： npx @capgo/cli@latest bundle cleanup

PS: これは地球にも、あなたの財布にも良いことです 💪。

アップロードの--externalを使用して、プランにカウントせずに自分のストレージを使用することもできます。

帯域幅

この値の計算は少し複雑ですが、考え方はストレージと同じです。

ユーザーがバンドルをダウンロードするたびに、ダウンロードのサイズだけこの数値が増加します。

このデータはダウンロードサイズのみに関連し、Capacitor JSアプリのサイズが小さいほど、プラン内に収まりやすくなります。

重要な注意点として、Capgoはダウンロードされたサイズを確認できず、バンドルのサイズのみを確認できます。そのため、大きなバンドルがあり、多くのユーザーがダウンロードに失敗する場合、制限に早く達してしまいます。

プラン内に収まる最良の方法は、小さなバンドルを持つことです。それができない場合は、ユーザーにダウンロードバーを表示し、残りのダウンロード量を知らせることです。

将来的に、Capgoは一度でバンドルをダウンロードする確率を高めるためにダウンロードシステムを改善する予定です。