問題
バックグラウンド更新は、重要な修正のために遅すぎます
バックグラウンド更新の問題
ユーザーがバグのあるアプリを開く
アップデートは利用可能ですが、ユーザーはバグのあるバージョンを表示します。バックグラウンドのダウンロードは静かに始まります。
ユーザーはバグを経験します。
ユーザーは修正した同じ問題に遭遇します。失望が生まれます。もしかしたら、1つ星のレビューを残します。
NEXTの起動時にアップデートが適用されます。
修正は用意されていましたが、ユーザーはバグを経験する必要がありました。重要な問題の場合、それは受け入れられません。
バックグラウンドのアップデートにより、ユーザーは修正された後もバグを少なくとも1度経験します。重要な問題の場合、それは多すぎます。
セッションがすべて重要な場合
決済フローが破綻しています。
ユーザーは購入を完了できません。修正されていないセッションはすべて失われた収益です。
セキュリティの脆弱性が発見されました。ユーザーは __CAPGO_KEEP_0__ の脆弱なバージョンを一度も実行してはなりません。
A security flaw was discovered. Users shouldn't run the vulnerable code even once.
__CAPGO_KEEP_0__
正午に新しい規制が発効します。すべてのユーザーはすぐに更新された利用規約を確認する必要があります。
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百万のリスク収入に相当しました。
QuickCartは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
なぜチームが直接アップデートを選ぶか
直接アップデートは背景アップデートが解決できない問題を解決します。ここでは、違いを知ってみましょう。
Every user who opens your app after an update gets the new version immediately. No exceptions. No 'one more session with the bug.' Every single session runs your latest 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秒未満で適用されます。
通常のバンドルダウンロード時間
アプリレンダリングまでの合計時間
インフラストラクチャの稼働率
チームタイプによるソリューション
チームのニーズに合ったソリューションを探す