世界を動かす技術を、日本語で。

スタートアップにおけるPハッキング

概要

  • スタートアップ の高速な実験が p-hacking の罠に陥るリスク
  • 多重比較指標の後付け途中での打ち切り による誤った意思決定
  • Bonferroni補正事前登録逐次検定 によるリスク回避方法
  • 正しい統計手法で本当に信頼できる学びを得る重要性
  • スピードと厳密さ のバランスの必要性

スタートアップのアジャイル実験がp-hackingの罠になる瞬間

  • スタートアップ では高速なリリース圧力から、見かけ上の改善でも成果と誤認しやすい
  • p-hacking とは、統計的に有意な結果が出るまで試行錯誤し、偶然の産物を成果とする行為
  • 代表的な3つの罠とその回避策を解説

事例01:多重比較の補正なし

  • 例:ダッシュボード最適化で4種類(A/B/C/D)のレイアウトをA/B/nテスト
  • 1つのレイアウト(B)がp=0.041で有意に見えるため採用
  • しかし p値0.05 の閾値は「1回の検定」を前提
  • 4回独立検定を行うと、少なくとも1回偽陽性が出る確率は 約18.5% に上昇
  • バリアント数が増えるほど、偶然による“勝者”が出やすくなる
  • Bonferroni補正 :有意水準を「0.05÷バリアント数」に補正
    • 例:4パターンなら 0.0125 未満のみ有意と判断
  • 補正により通過する結果は減るが、信頼性は向上

事例02:結果後に指標をすり替える

  • 例:事前登録した「サインアップ率」では有意差なし
  • 焦って「リテンション率」など他指標を探索、p=0.034で有意に見える結果を発見
  • しかし、複数指標を探索するほど偶然の有意差が現れる確率が急増
    • 例:20指標探索で約 2/3 の確率で偽陽性
  • 事前登録(Pre-registration) が解決策
    • 検証する指標・仮説を事前に明記・固定
    • p値の意味が正しく保たれる
  • 医学研究でも必須の手法、スタートアップにも応用推奨

事例03:有意になるまで途中で打ち切る

  • 2週間のA/Bテストを予定しつつ、毎日p値をチェック
  • 9日目にp=0.048で有意に見え、そこで実装してしまう誘惑
  • しかし、毎日チェックすることで「9回分の検定」を無意識に実施
    • 9回のうち1回でも偽陽性が出る確率は 約37%
  • p値は「検定のストップルール」を事前に決めてこそ意味を持つ
  • 逐次検定(Sequential Testing) で途中打ち切りも正しく管理可能
    • 例:1週目はp<0.01、10日目はp<0.025、14日目はp<0.05など閾値を厳格化
  • ほとんどのチームでは「予定通り最後まで待つ」が最も安全

適切な実験運用のために

  • 仮説・指標の事前登録 を徹底
  • 多重検定補正 を忘れず実施
  • 途中経過での意思決定 には逐次検定や厳格なルール適用
  • ネガティブ結果 も正当に評価
  • 正しい統計運用で“本物の学び”を得て、無駄な施策サイクルを減少

結論

  • スピード重視 の現場ほど、 統計的厳密さ が学びの質を左右
  • 急がば回れ、 信頼できる意思決定 が長期的な成長の鍵

Hackerたちの意見

一方で、これは統計的に有意なA/Bスタイルのテストを実施する方法についての非常に良い説明だね。ただ、スタートアップがプロダクトマーケットフィットを達成していないなら、こういうことは時間の無駄だってことを強調したい!機能を作って、実際に人が使うかどうか見てみよう。

「このようなこと」とは、A/Bテストを実施すること全般を指している。正しく行わないなら、A/B / MVTテストを実施する理由は全くないよ。

A/Bテストは、マイクロ最適化を含む必要はないよ。うまくやれば、試すことのリスクやコストを減らせるからね。例えば、フルプロダクト開発に投資する前にA/Bテストを行うことができるし。MLベースの改善(新しいランキングアルゴリズムとか)を進める時にも使いたいよね。これが、プロダクト開発の参考書の表紙にカバが描かれている理由だよ。A/Bテストは、ただ「一番お金をもらっている人の意見」に従うことに対して役立つんだ。実際はもっと複雑だけど、それは組織や政治の問題だね。

「これは学術的なこだわりじゃない。命がかかっているときの医療研究のやり方だ。スタートアップの成長も同じ厳密さが必要だ。でも、本当にそうなのか?多くの企業は…まあ、「重要じゃない」ものを売ってるよね。間違っても人の命が奪われるわけじゃない。ウィジェットを売るスタートアップのユーザーサインアップをA/Bテストしても、その結果で人が生きるか死ぬかは関係ない。間違った結果の影響は…ウィジェットが少なく売れるだけ?投稿の全体的なポイントは理解できるし、同意するけど、この特定の点には異論がある。多くの企業は、テストに関して言えば、_厳しすぎる_と言えるかも。前の会社では、統計的有意性を待つのに6週間かかった。でも、48時間以内にポジティブな信号が出たんだ。コンバージョンが上がった!統計的には有意じゃなかったけど、望んでいた方向にトレンドが出てた。でも「厳密さを保つため」に、6週間待ってから結果を出したら、最終的な数字は48時間の数字とほぼ同じだった。注意:何かが良い方向にトレンドを示したらすぐにテストを止めろって言ってるわけじゃない。投稿の3つ目のシナリオがそれを欠点として指摘してる!彼らの「のぞき見」とその後のテストの提案は好きだけど、本当に、どの程度の「厳密さ」が決定を下すのに必要か、現実的に考えよう。ロケットを宇宙に打ち上げてるわけじゃない。ソフトウェアを出荷してるんだ。間違ったら修正できるし、大丈夫。世界が終わるわけじゃない。私の意見では、ここでの正しいフレーミングは、スタートアップは目標を達成するために必要な厳密さを持つべきだってこと。目標が「すべてのテストで統計的有意性」なら、確かに、間違ったら誰かが死ぬかもしれないと思って扱うべきだ。(この場合、目標が間違ってると言いたいけど、脱線しちゃった…)でも、目標が「害を及ぼさない、正しいベクトルに向かっているか確認する、そして誤ってポジティブな結果が出た場合にはピボットできると信じる」なら、医療テストと同じ厳密さで扱う必要はないよ。

それは、結果の妥当性や、成果を改善するための変更に気を使っていると仮定した場合だよ。重要度が低い状況では注意の度合いが異なるかもしれないけど、どれだけ気にしているか自分に嘘をついてはいけない。

でも、実際には改善されていない可能性もあるよね。もう一つの理由として、ただ出荷することの重要性があると思う。スタートアップは常に動き続ける必要がある。みんなを忙しく保ち、成長が遅いとか高い離脱率について心配させないために、車輪を回し続ける必要がある。スタートアップにはたくさんの闘志が必要だよ。だから、負けを認めて悪い雰囲気に悩まされるよりは、出荷する方がいいかもしれない。

完全に同意する。スタートアップのサインアップフローは、医療研究と同じ厳密さを必要としないよ。製品のパッケージングに交通工学の基準も必要ない。リスクのレベルが全く違うからね。これについては何ページでも書けるし(何時間も話したことがある)、科学的な研究のマインドセットを採用することはA/Bテストにとって非常に制限的だと思う。帰無仮説テストの既存のバイアスを持つ必要はない。同時に、人々が適応する能力には感心するよ。A/Bテストに慣れた組織は、頭の中で多変量補正を始めるようになる。これを始める人には、最初からベイジアンでやることを勧めるよ。気づいていなくても、結局そこにたどり着くから。(人々は以前の証拠を考慮してp値を見るだろう)。0.05(または任意のベイジアンの同等物)は魔法の数字じゃない。デフォルトとしてはかなり高い。より厳しい科学(再現危機にないもの)は、デフォルトでずっと厳しい値を使っている。変更のコストと害のリスクに応じて必要な信頼度を調整するべきだ。テストの段階にいるなら、変更のコストはゼロかもしれない(コンテンツ)。本当に高いかもしれないし、ネットでマイナスかもしれない!でも、ほとんどの場合、スタートアップでは、影響力のある勝利を追求するべきで、p値が0.05未満になることが多いよ。これは言うのは簡単だけど、もっと信号を引き出す方法を考える時間を無駄にしないで。単に(ただ笑)製品を改善する変更をして、方法が重要でないようにすればいい。p=0.00001なら、この記事のどの補正よりも良い信号になるよ。最初から何か特別なことを選ぶなら(ベイジアン以外で)、いつでも有効な方法を選んで。あなたはすでにのぞき見をしているだろうし(そうあるべきだ)、データがそれを反映するようにしよう。

p=0.50に設定すれば解決できるかな?期待値を暗黙的じゃなくて明示的に示してみて。0.05は完全に恣意的だよ。もし50/50の確率で正しいと思えるなら、基準をもう少し緩くしてもいいんじゃない?

医療の文脈では、選択肢が「この特定の治療法を使うか、何もしない(つまり、既存の治療法を使う)」ってことが多いよね。もしどのウェブサイトのレイアウトがベストかの統計的に有意な結果が得られなかったら、スタートアップを畳むつもりの人っているのかな?「害を与えない」という別の言い方は、無結果は「今やってることを変える理由がない」ってことだよ。

我々はロケットを宇宙に打ち上げているわけじゃない。確かにほとんどの人はそうじゃないよね。だから、今やっていることやその影響を考慮するのはいいことだと思う。ただ、時にはその境界が明確じゃないこともあるよね。もし我々があまり重要でない結果に特化していないライブラリやフレームワークを設計したら、どの方針がより理にかなっているのかが分からなくなる。

間違ったらどうなるかって…ウィジェットが売れなくなる?それが成功と失敗の境目なら、ビジネスオーナーとしてはかなり重要だよね。 > 害を与えないようにして、正しい方向に進んでいるか確認して、もし誤ってポジティブな結果が出たら方向転換できると信じる。それは合理的で、たくさんの文脈では絶対にベストなアプローチだと思う。でも、それをA/Bテストと呼ぶのはやめてほしい、だってそうじゃないから。

ほとんどの会社は、間違ったら人の命が奪われるわけじゃない。確かにそうだけど、修正するのにはお金がかかるよね。「命がかかっているときだけ重要」や「厳しすぎる」というテーマは、ストローマンだと思う。リソースは限られてるから、時間やお金、人もね。リソースを無駄に使いたくないんだ。統計的推論は、リソースを無駄に使わないための情報を得る一つの方法だけど、君が指摘したように、統計的推論にもコストがかかる。推論に必要なデータを得るためにリソースを使わなきゃいけないし、他のコストもある。サンプルサイズ推定法を使って、十分なデータを得るためのコストを見積もることができる。ゴー/ノーゴーの意思決定では、間違った決定を下すコストが統計的推論のコストの少なくとも10倍以上じゃない限り、推論を行う価値はないと思う。別の理由で推論を行う価値があるかもしれないけど、それは範囲外の話だね。例えば、医療研究での統計的推論の一般的な使い方は、治療法の効果をプラセボと比較することだよ。その動機の一つは、治療法の開発にもっとリソースを投資するかどうかを決めるためであって、間違って効果があるとされる場合に人が死ぬからではない。 > 多くの企業は、テストに関しては、過剰に厳しいと言えるかもしれない。私の業界での経験は逆だよ。企業はデータ駆動の意思決定のアイデアが好きだけど、痛点を発見するんだ。彼らは、どれくらいの変化を検出したいのか(つまり、効果量)をある程度理解しているべきだし、テストを実行するために必要なデータ量を見積もるべきだよ(つまり、サンプルサイズ推定)。モデルの不適合、キャリブレーション、複数テストの修正など、他の問題も考慮しなきゃいけない。さらに、テストを実施してデータを収集し、結果を分析して内部のステークホルダーに伝えるためのインフラを整える必要もある。これらの痛点が、EppoやStatSigのような企業が存在する理由なんだ。A/Bテストは、開発者が期待するよりも高いタッチになることが多いよ。これらの問題のどれかを間違えると、「フレークなテスト」が生じることがあって、開発者はそれを嫌うんだ。特定の効果量に対して十分なサンプルサイズを集められないのは、かなり一般的な失敗パターンだよ。 > でも「厳密さを維持する」ために、6週間待ってから結果を出したら、最終的な数字はほぼ48時間の数字と同じだった。ここで「厳密さを維持する」とは具体的に何を意味するのか、正確には分からないよ。私が理解できる唯一の文脈は、君が使っていた手続きが、テストの名目設計基準、通常は名目の偽陽性率を満たすために、もっとデータが必要だったということだと思う。これは厳密さの問題じゃなくて、統計モデルと正確さの問題だよ。時には、異なる方法を使って、より多くの(または異なる)モデルの仮定を犠牲にして、少ないデータで済むこともある。テストの仮定を満たさないと、偽陽性率が上がることがある。それが重要かどうかは、本当に君次第だよ。 > 彼らの「のぞき見」とその後のテストの提案は好きだよ。投稿が提案しているのは、提案ではなく、逐次テストと呼ばれる頻度主義的統計推論の標準的なクラスだよ。ダニエル・ラケンスのオンライン教科書(https://lakens.github.io/statistical_inferences/)には、これらの方法について第10章で簡単に説明されていて、さらに参考文献も載っているよ。 > 我々はソフトウェアを出荷している。間違ったら変更できる。これは通常真実だよね。必要なリソースがあって、それをそのように使うことに同意している限り。 > 私の意見では、ここでの正しいフレーミングは、君のスタートアップは目標を達成するために必要なだけ厳密であるべきだということだと思う。この感情には同意するけど、君はここで厳密さと正確さを混同していると思う。 > もし目標が「すべてのテストで統計的有意」なら、確かに、間違ったら誰かが死ぬかもしれないように扱うべきだね。それは誤った同等性だと思う。アメリカ統計協会もp値について声明を出しているし(https://www.amstat.org/asa/files/pdfs/p-valuestatement.pdf)、そこには「科学的結論やビジネスまたは政策の決定は、p値が特定の閾値を超えるかどうかだけに基づくべきではない」と書かれているよ。 > でも、もし君の目標が「害を与えない、正しい方向に進んでいるか確認する、そして誤ってポジティブな結果が出た場合には方向転換できると信じる」なら、医療テストと同じ厳密さで扱う必要はないよね。もしそれが君の目標なら、ただ出荷すればいい。特に、君が主張するように、変更を元に戻したり、うまくいかなかった場合に方向転換するのが経済的に可能なら、テストの努力を正当化するのは意味がないと思う。

君の言いたいことは分かるし、過剰なテストもあるけど、全てのソフトウェアの品質の基準がひどいと思う。私たちはそれに慣れすぎて、普通になってしまった。でも、誰かがもっと品質に注意を払っていたら通さなかったバグにイライラしない日がないよ。ロケットのような厳密さの話じゃなくて、今の状態よりも高い基準が必要だと思う。(それに、エロンのロケットは次々と失敗しているし、NASAが60年代に達成したこととは対照的だから、そこからも学ぶべきことがあるよ。)

それは生死に関わる問題ではない、同意するけど、ある程度までね。スタートアップは資源が非常に限られていて、長期的に決定的でない結果を無視することは、成果を上げずに資源を使っていることになる。これをやりすぎると、資金が尽きてスタートアップが死んじゃうよ。著者は、企業がなぜこういうことをするのか(テスト結果を無視したり誤読したりする)については触れていないけど、理解不足を置いておいて、私がデータサイエンティストとして働いていた時の経験から言うと、いくつかの大きな理由に集約されるよ: - 正しいと思いたい。創業者は高い自信が必要で、「自分が正しい」と感じることが重要なんだ。でも、正しいと感じることは必ずしも正しいことを意味しないし、人は自分の信念に反する証拠を無視することが多いし、それを否定する理由を見つけることもある(そのことの皮肉は分かってるよ); - 仕事を見せるプレッシャー:UIの再設計を何度もやる方が、「それは関係ない」と言うよりもパフォーマンス評価で良い。結果が決定的でなければ、何も示すものがないよりは害が少ないから、何かをやっていることで「自分の仕事が関係ない」という結論を先延ばしにしているんだ。だから、結果をBS的な解釈に変えて、もう少し時間を稼ごうとする。もう一つ十分に議論されていないのは、これらの決定的でない結果が適切に解釈された場合に何を意味するのか。決定的でないUI再設計実験が続くと、「UIは重要なのか?」という仮説が浮かぶべきだよね。でも、そういう質問は、そういうことを考えるのに最も適した人たちにとっては存在を脅かすものなんだ。もしどの企業もデータ駆動型で科学的であることを真剣に考えているなら、どこでもテストを要求し、質と厳密さに外部のコントロールを持ち、それを使って投資や撤退の戦略的決定を下すべきだよ。少なくとも、それを戦略の重要な一部として考えるべきだ。テストに基づいてすべてを行えるわけではないし、やるべきでもないけど、未来への賭けや新しいシナリオに関する仮説、テストするにはコストがかかりすぎるものもある。でも、一貫してテストを行い、テスト結果を分析することで、多くの労力とお金を節約できるかもしれない。

頻繁にA/Bテストを行うと、統計的な「クレジット」が消費されることを忘れないで。p = 0.05で勝者を出荷するたびに、あなたの偽陽性予算の5%を使ったことになる。四半期に5回それをやると、少なくとも1つがノイズである確率は1 – 0.95⁵ ≈ 23%になる。エラーのこの原因を減らすために取れるアプローチはいくつかあるよ:四半期ごとのアルファ台帳。この四半期にどれだけのリスクを取りたいか決める(例えば10%)。残りのαを実験の数で割って、それを次のローンチの閾値にする。これで「このボタンの色のテストは我々の信頼性の3%に値するか?」という会話が強制される。詳しくは「実践における逐次テスト:のぞき見が問題である理由とその解決法」(https://medium.com/@aisagescribe/sequential-testing-in-pract...) ベンジャミニ–ホッホバーグ(BH)によるメトリックの拡散。12個のKPIを見ていると、ボンフェローニが実際の向上を埋もれさせる。BHはすべてのp値を最後にランク付けし、例えば、宣言された勝者の5%だけが偽陽性になるようにカットを設定する。パワーを維持できて、毎四半期のすべての実験の主要メトリックに同じBHステップを実行して、ラッキーなローンチを捕まえることができる。詳しくは「偽発見を制御する:実験におけるBH補正のガイド」(https://www.statsig.com/perspectives/controlling-false-disco...) ベイジアン収縮 + 5%「ゴースト」コントロール 大規模なFAANGのラボは何百ものテストを行い、0.1%の向上を気にする。彼らはすべてをシンプルな階層モデルにプールする。ノイズのある効果はグローバル平均に引き寄せられるので、しっかりした向上だけが水面上に残る。ローンチ前に、テストを受けたことのない小さなトラフィックのスライスでサニティチェックを行う。勝者の呪いのインフレを約30%削減する。明確な説明者:「収縮でA/Bテストのエラーを回避する方法」(https://eng.wealthfront.com/2015/10/29/how-we-avoid-ab-testi...) と (https://www.statsig.com/perspectives/informed-bayesian-ab-te...) 四半期に10テスト未満:アルファ台帳かYOLO;数十のテストとKPI:BH;数百のライブテスト:収縮 + ゴーストコントロール。

少なくとも1つがノイズである確率は1 – 0.95⁵ ≈ 23% そうだけど、君が言ってるほど大したことじゃないよ。通常、全か無かの問題じゃないからね。通常、勝ちは加算的だし。各勝者が本物である確率はまだ95%(pハッキングがないと仮定して)だから、その5つの中で期待される勝利数は0.95 * 5 = 4.75勝(期待の線形性による)で、これは良い勝率だよ。

これはスタートアップだけの話じゃないよ。FAANGでもよくあることだ。実験は多くの場合マルチアームだし、前の実験が失敗したり、ローンチ基準を満たさなかった場合は、実験を繰り返すこともある。さらに、ローンチ基準は通常、事前に明確に定義されていないことが多い。完全に成功する確信がない限り、ローンチミーティングで実験が承認されるかどうかは分からないことがほとんどだ。主に雰囲気で決まっていて、数十または数百の「関連する」指標の動きに基づいて、ローンチミーティングにいるステークホルダーの気まぐれで決まることが多い。

あなたはデータの条件付け分析を説明しているね。GelmanとLoken(2013)はこう言っている:> 問題は、データ分析の詳細がデータに大きく依存している場合、潜在的な比較が多数存在する可能性があることで、研究者が意識的にフィッシングや複数のp値を調べる手続きを行わなくても済むということです。私たちは、データ分析の決定が以前の文献に基づいて理論的に動機づけられているが、データの選択と分析の詳細が事前に指定されておらず、その結果、データに依存しているいくつかの発表された論文の例を挙げて議論します。

これってひどいことなの?科学をやることが目的じゃないんだ。アイデアは、イノベーションをざっくりと体系化して概念化することなんだよ。選択肢を生み出して、失敗に耐えられるシステムを作ることが目的なんだ。改善の余地はあると思うけど、これは有効な実験か無効な実験かってことじゃないんだよね。

最初のテストが何をするべきなのか理解できない。著者はこう言ってるね:> 君の仮説は、レイアウトがサインアップ行動に影響を与えるということだ。そうすると、帰無仮説は「レイアウトはサインアップ行動に影響を与えない」ってことになると思う。そうなると、ANOVA(または同等の線形モデル)がこの仮説をテストするもので、4つのレイアウト(または4つの新しいレイアウトとコントロール?)を1つの要因でテストすることになると思う。もし有意なp値が得られたら(複数のテストは必要ない)、異なるレイアウト間の比較を調べるためにポストホックテストを行うべきだよ(4つのレイアウトなら、6つのテストになるはず)。でも、ここでコントロールがあると仮定すると(ユーザーの中には古いレイアウトが表示される人もいる?)、各レイアウトがそのコントロールと比較されることになるのかな?もしp値の分布を見たら、直感的に実験がパワー不足だと思う。帰無仮説のテストから得られるp値は0と1の間で均等に分布するはずだけど、これらは0.05の周りに集まっている。実験自体の設計に問題があるため、推論を行うのが難しい状況のように思える。例えば、専門的なデザイン知識に基づいて、ランダムなレイアウトをたくさん作るよりも、少ないレイアウトの方がいいと思う。最初の方が統計的パワーを高めるから、調べるテストが少ないほど、p値を調整する必要が少なくなる。さらに、レイアウトが少ないほど、グループごとのユーザー数が増える(テストはグループ間で行われるから)ので、統計的パワーも増す。この記事はp値の制御方法について全体的に間違っているわけではないけど、正しい分析をするためだけでなく、実験デザインの限界を理解し、それを成功させるために構造を整えることが重要だと思う。これを目的に、g*power [0]は、予測される

私が見たA/Bテストの中で、ANOVAについて言及しているものはほんのわずかだし、実験デザインについて真剣に考えているものも少ない。p値の理解も一般的に乏しいし、エンジニアリングやビジネスの学位での確率・統計教育は、最も軽視されている数学の一種だと思う。厳密さよりもスピードを優先したい場所でも、少なくとも考え方を変えて、p値よりも効果量を重視した方がいいと思う。若いスタートアップとして「収益を10倍にするようなことをしないといけない」って視点から見て、限界効果が「統計的に有意かどうか」を待つのは無駄だよ。

ユーザーは4つのレイアウトのうちの1つにランダムに割り当てられ、その活動を追跡します。あなたの仮説は、レイアウトがサインアップ行動に影響を与えるというものです。 > あなたは、1つのレイアウトのp値が従来の閾値0.05を下回った場合、その勝者を出荷する計画です。 テストの結果 P値 Bが勝者 0.041 Aが勝者 0.051 Dが勝者 0.064 Cが勝者 0.063 4つのオプションの結果を比較して、どれが勝者になりそうかをどうやって判断するの?どれも使われている指標では非常に良い順位をつけているよね!それとも、もっと悪い5番目の選択肢と比較されているのかな。

この種のランキングも正しくないよ。結果を比較しないといけない、p値じゃなくてね。p値でランク付けするのは馬鹿げているし、平均指標でランク付けするのも馬鹿げている。スタートアップは一般的に、高いシグナルで意思決定をしなきゃいけないから、1%の改善を100回してp=0.05だと、そんなノイズの多い環境では実際には効果が出るなんて幻想だよ。スタートアップでこんな馬鹿げたことをするのは、ただの儀式みたいなもので、長期的には、複合的な指標を最適化していると感じる人には役立つかもしれないけど、実際には何も実現しないんだ。

p値の閾値を0.05に設定することは、「偶然に見えるものを出荷する5%の確率を受け入れる」ということと同じです。いや、それは「もしそれが代替案より良くなかった場合、見た目が良くなる確率は5%しかなかったものを出荷することを受け入れる」という意味です。

これ!医療の現場でもよく見かけるよ。

あなたの発言と著者の発言の違いについて詳しく教えてもらえる?

こういう確率を扱うときは、いつも比較のためにPythonのrand()を使ってるんだ。計算の閾値をチェックするのに、間違えるリスクがすごく低いからね。もちろん、閾値を正しく計算することも大事だけど、rand()はサクッと追加できるから、簡単な確認にはもってこいなんだよね。

あなたの仮説は「レイアウトがサインアップ行動に影響を与える」というものです。これはあなたの仮説かもしれませんが、p値が関連している仮説ではありません。 > p値の閾値を0.05に設定することは、「偶然に見えたものを出荷する確率が5%を受け入れる」ということと同じです。p値は「偶然の発生」についての情報を提供するものではなく、特定の結果を観察する確率を特定の世界の状態(つまり、帰無仮説)を仮定してテストするものです。 > ボンフェローニ これは非常に厳しい(つまり保守的な)修正ですが、業界でも科学と同様に、結果を観察する動機があるため、使われないと思います。他にもっと合理的な修正方法があります。 > 結果を後から掘り下げるのは避けるべきです。合理的な解決策は、見つけた結果を無視するのではなく、適切に解釈することです。もしかしたら、その結果は実際に意図の改善を示しているかもしれませんし、逆にノイズかもしれません。探索的データとして扱いましょう。本当に改善された保持率があったなら、それは重要ですか?適切に再テストする価値があるほど重要ですか?

提案された修正、つまり事前登録や単一のメトリックテストに固執することは、最初からメトリックの設計がクリーンであることを前提にしているんだ。実際には、プロダクトのメトリックがごちゃごちゃになったり、ネストされたり、間接的な影響でいっぱいになったりするのを見てきたよ。例えば、アクティベーションレートみたいなメトリックを事前登録するかもしれないけど、それはオンボーディングUXやレイテンシ、コホートの時間、外部トラフィックの急増に影響されるんだ。だから、構造的にphackingを避けられたとしても、完全にコントロールできないプロキシに過剰適合してしまうんだ。それが盲点なんだよね。メトリック自体が実行ごとに安定していないとき、どうやってテストを事前登録するの?プロセスを複雑にするだけじゃない?私には新しいことだけど、文脈がもっと大きな役割を果たすと思う。