問題
バックグラウンド更新は、重要な修正のために遅すぎます
バックグラウンド更新の問題
ユーザーがバグのあるアプリを開く
アップデートは利用可能ですが、ユーザーはバグのあるバージョンを表示します。バックグラウンドダウンロードは静かに開始されます。
ユーザーはバグを経験します。
ユーザーは修正した同じ問題に遭遇します。失望が生まれます。1つの星の評価を残すかもしれません。
NEXTの起動時にアップデートが適用されます。
修正は用意されていましたが、ユーザーはバグを経験する必要がありました。重要な問題では、これは受け入れられません。
バックグラウンドアップデートにより、ユーザーは修正された後もバグを少なくとも1回経験します。重要な問題では、これは多すぎます。
セッションがすべて重要な場合
決済フローが破壊されました。
ユーザーは購入を完了できません。修正されていないセッションはすべて失われた収益です。
セキュリティの脆弱性
セキュリティの欠陥が発見されました。ユーザーは code を一度も実行しないようにしてください。
法的要件の期限
正午に新しい規制が発効します。すべてのユーザーはすぐに更新された利用規約を確認する必要があります。
The Solution
アプリが表示される前に適用される更新
Direct Updatesは、ユーザーがアプリを開くたびに更新をチェックし、適用します - それらが何も表示されない間です。体験は滑らかで、すべてのセッションで最新のcodeが実行されます。
バックグラウンドモード (デフォルト)
ユーザーは常に古いバージョンと一緒に1つのセッションを経験します。更新をプッシュしたあとに。
Direct Mode (即時)
ユーザーは常に最新の code. 0の例外、0の古いセッション
// Enable Direct Updates - one config change
CapacitorUpdater: {
autoUpdate: true,
directUpdate: true, // Updates apply immediately on app open
}
// That's it. When users open your app:
// 1. Capgo checks for updates (~50ms)
// 2. If available, downloads immediately (~200-500ms)
// 3. Applies before your app renders
// Users always see the latest version. Zero exceptions.現実世界の影響
QuickCartが1晩で支払い失敗を排除した方法
QuickCart
E-Commerce - フラッシュセールアプリ
QuickCartはピークイベントの間に100,000+の同時ユーザーでフラッシュセールを実行します。支払いゲートウェイの更新がチェックアウトフローを壊したとき、販売中の4時間後にそのことを発見しました。バックグラウンドアップデートの場合、既にアプリを開いたユーザーはバグに遭遇しました。
エンジニアリングチームは23分で修正をプッシュしました。ただし、バックグラウンドアップデートの場合、23分間でアプリを開いた40,000以上のユーザーは、現在のセッションでバグに遭遇しました。平均注文金額は47ドルで、$1.8百万のリスク収入を表します。
Direct Updatesに切り替えた後、次のインシデントは0の影響を受けた取引で解決されました。修正は18分でデプロイされ、ユーザーがアプリを開いた後から直ちに修正されたバージョンを取得しました。CFOはすべての顧客向け支払いフローでDirect Updatesを要求しています。
結果
"Background updates are fine for feature releases. But for anything touching payments, authentication, or compliance? Direct Updates are non-negotiable."
David Park、QuickCartのエンジニアリングVP
Direct Updatesを選択する理由
Direct Updatesは、バックグラウンド更新では解決できない問題を解決します。ここでは、違いをご紹介します。
セッションの古さがゼロ
ユーザーがアプリを開いた後、すぐに最新のバージョンが取得されます。例外はありません。1つのセッションも、バグが残ることはありません。すべてのセッションで、最新のcodeが実行されます。
- codeの最新版が100%のセッションで実行される - 95%、99%ではなく100%
- 重要なバグ修正はユーザーがバグを経験する前に到達する
- すべてのデバイスで即時効果のあるコンプライアンス更新
100%
codeの最新版が実行されているセッションの割合
即時バグ解決
バグ修正をプッシュすると、実際に修正された状態になります。ユーザーは、修正が次のリリースまで待つ必要なく、バグを再び経験することはありません。修正が適用された直後、ユーザーがアプリを開くと、修正されたバージョンが表示されます。
- 修正をデプロイした後も、サポートチケットの「そのバグをもう一度」は必要ありません
- 監視は即時的な改善を示し、徐々にロールアウトされる曲線は表示されません
- デプロイ後にオンコールエンジニアはすぐに寝ることができます
0
修正をデプロイした後もバグの経験
最適化されたユーザー オンボーディング
新規ユーザーがアプリをダウンロードする際には、常に最良のオンボーディングフローを受け取ります。A/Bテストで勝者を発見した場合、すべての新規ユーザーがそれを即座に受け取ることができます - 背景のダウンロードサイクル後ではなく
- 新規ユーザーは古い導入フローを見ることはありません
- A/B テストの勝者は即座に100%の新規ユーザーに展開されます
- 最初の印象は常に現在の最良の体験です
+34%
初日からの保持率の向上
Direct Updates の使用時期
Direct Updates は、即時の一貫性が不可欠なシナリオでは、不可視の更新よりも優先される場合に適しています。
Critical Bug Fixes
支払い失敗、認証問題、データ破損 - 1 回だけ経験しても多すぎるバグ
新規ユーザー導入
最初の印象は重要です。新規ユーザー全員が最初のセッションから最適化された導入体験を受けられるようにしてください。
イベントベースの機能
特定の時期に結びついた機能 - ハロウィーンのセール、製品のリリース、ライブイベント。イベントが始まる時点でライブでなければなりません。
セキュリティパッチ
Vulnerability discovered? Users shouldn't run vulnerable code even once after you've patched it.
ユーザーは、パッチを適用した後も一度も脆弱性のある__CAPGO_KEEP_0__を実行してはなりません。
A/Bテストのロールアウト
勝ち組のバリアントを見つけた場合?
ゆっくりとバックグラウンドでアップデートを待つのではなく、100%のユーザーに即座に配信してください。
法的要件のアップデート
新しい規制、更新された条項、必要な開示。法的期限はバックグラウンドでダウンロードを待つのではなく、即座に適用する必要があります。
直接アップデートは、迅速である必要があります。私たちのグローバルなインフラストラクチャにより、更新が1秒未満で適用されます。
通常のバンドルダウンロード時間
アプリレンダリングまでの合計時間
インフラストラクチャの稼働率
チームタイプによるソリューション
チームのニーズに合ったソリューションを探す