バイオメトリック支払いがコンバージョンに与える影響を分析するためには、ユーザー階層でのランダム化を伴うA/Bテストを実施する必要があります。主要なメトリクスは、購入へのコンバージョン（conversion rate）で、補助的には平均注文額、ファネル深度（initiate checkout → payment success）、7日目のリテンションを含めます。さらに、デバイス（iOS/Android）や新規/リピートユーザーのコホートによるセグメンテーションが必要で、新規性の効果を明らかにします。
実験の最小デザインは、50/50のスプリットで、期間は2つの完全なビジネスサイクル（14日間）以上、テストの有効性（power）≥ 80%、有意水準（alpha）= 5%が必要です。また、SQLを使用したコホート分析で、時間経過に伴う効果の安定性を検証し、Python（SciPy、Pandas）を用いて平均比の仮説検定を行います。
問題:
フィンテックスタートアップは、iOSアプリにApple Face IDによる決済機能を導入する計画を立てました。製品チームはコンバージョンが15%向上することを予想していましたが、ビジネスは開発に要する時間（2スプリント）を懸念しました。アナリストの責任は、季節性、マーケティング活動、iOSの更新などのその他の説明を除外して、機能の有用性を正当化または否定することです。
検討された解決策:
最初の解決策は、リリース前後のコンバージョンを比較する「前後分析」（pre-post analysis）です。利点: 最小限の時間コストでユーザーの隔離を必要としません。欠点: 機能の効果を外部要因（例：同時に行われる広告キャンペーン）から分離することが不可能であり、偽陽性結論のリスクが高いです。
次の解決策は、Differences-in-Differences（DiD）法を使用した準実験です。Face IDが導入されるiOSユーザーを、トレンドを考慮してAndroidユーザー（対照群）と比較する予定でした。利点: アプリ内でのスプリット実装を必要とせず、観察データで機能します。欠点: プラットフォーム間での平行トレンドという重要な仮定が、iOSとAndroidの異なるオーディエンスによりしばしば破られ、コンファンダーが存在する場合の解釈が複雑です。
第3の解決策（選択されたもの）は、機能フラグ（LaunchDarkly）を用いた本格的なA/Bテストです。50%のiOSユーザーがFace IDにアクセス（テストグループ）、50%が旧方式での支払い（対照）を受けました。サンプルサイズの計算はRで行い、pwrライブラリを利用しました：基本コンバージョンが8%、期待されるMDE（Minimum Detectable Effect）が12%、power=0.8、alpha=0.05の場合、グループあたり≥ 12,000ユーザーが必要でした。実験は異なる曜日をカバーするために3週間続きました。
結果:
テストグループでのコンバージョンは11.3%（8.1%から9.0%へ）増加し、p値 = 0.002（双方向z検定）でした。しかし、コホート分析では、効果が統計的に有意なのは新規ユーザーに対してのみであり（+18%）、既存のユーザーベースには変更が確認されませんでした。その結果、この機能は100%のオーディエンスに展開されることになりましたが、マーケティング資料は新しいユーザーの獲得に再焦点が合わせられ、プロジェクトのROIは初期モデルに対して40%向上しました。
新規性の効果（novelty effect）と持続的改善のメトリクスの違いをどう見分けますか？
候補者はしばしば、効果の持続性を確認せずに統計的有意性に達するとA/Bテストを終了します。新規性の効果を特定するには、日ごとのメトリックの累積曲線（cumulative metric curves）を構築し、前の3日間の効果を最終週の効果と比較する必要があります。SQLのコホート分析を使用して、実験に参加した日（cohort_date）でトラフィックを分け、「古い」コホートのアップリフトが維持されているか確認します。時間と共に効果が減少する場合、それは典型的な新規性効果であり、ユーザーは好奇心から機能を試しますが、長期の行動には変化がありません。
統計的有意性（statistical significance）と実務上の有意性（practical significance）の違いは何ですか？
大きなサンプルサイズでは、コンバージョンが0.5%増加することが統計的に有意（p < 0.05）であっても、機能のコストが追加購入の収益を上回る場合、ビジネスには意味がありません。実験の開始前に、MDE（Minimum Detectable Effect）を定義する必要があります。これは（Expected Revenue per Conversion × Additional Conversions） - Cost of Featureとして計算されます。実際のアップリフトがMDEを下回る場合、p値 = 0.01であってもその機能は展開すべきではありません。計算にはPython（statsmodels.stats.power）またはEvan Millerのオンライン計算機を使用してください。
ユーザーが機能を見ているが使用できない場合（network effectまたはグループの技術的障害）はどのように処理しますか？
これは汚染（contamination）またはスピルオーバー効果の問題です。典型的な例は、テストグループに暗号通貨での支払いが含まれましたが、サービスプロバイダが30%の時間利用できなかったことです。「意図した治療」(intent-to-treat, ITT)分析は、実際に使用したかどうかに関係なく、ボタンを見た全ての人に対して効果を評価します。評価の純度を保つために、CACE（Complier Average Causal Effect）または** instrumental variables**（計量経済学上的な変数）を適用し、「グループへの割り当て」が機能の実際の使用のための指標として機能する必要があります。これをSQLで実行するには、二段階回帰または実際の操作ログとのJOINを使用し、サーバーエラーのあるユーザーを効果分析から除外しますが、グループバランスの確認のためにランダム化に保持します。