開発者の幸福度指標（“счастье разработчика”、「開発者の幸福」）は、私たちは Yandex Code Assistant に、開発者のコード作成を手助けし、開発者を幸せにすることをどのように教えたか で説明されているとおり、Yandex Code Assistant を手がけるチームが提案した、インラインのコード提案のための複合指標である。一連の提案を、受け入れられた提案の長さの合計から、受け入れ 1 回ごとの固定のペナルティ、表示されたすべての提案の長さに比例する小さなペナルティ、そして却下 1 回ごとの大きなペナルティを差し引いて採点する。チームの「formula v1.0」はこれを Σ(AcceptedLength − 3·NumAccepts) − 0.05·ΣShowSuggestLength − 14·ΣNumDiscards と書いている。
用法
この指標は、受け入れ率 — 見た提案に対する受け入れられた提案の比率 — の代わりとして導入された。チームは、受け入れ率が上がる一方でユーザーが離れていくのを目にしたのである。記事の診断によれば、受け入れ率は受け入れられたものの長さを無視しており、1 つの長い提案の代わりに受け入れやすい短い提案を多数表示することで水増しできてしまう。幸福度指標は代わりに、明示された 4 つの前提を組み込んでいる。受け入れられた提案は長いほどよい。Tab を押すこと自体が手間なので、タイプした方が早いような短い提案が得をしてはならない。表示された提案はどれも、ユーザーがその後どうするかに関わらず読まなければならない注意散漫の元である。そして却下は明示的な否定的フィードバックであり、余分なキー入力も伴うので、最も重くペナルティが科される。
適用される場面
これは 1 つのチームが 1 つの製品のために作った指標であり、確立された尺度ではなく、その根拠もそのチーム自身のものである。係数は、勝者がすでに分かっている過去のオンライン A/B 実験のサンプルに対する線形最適化で当てはめられた。小さな差がより早く有意に達するよう、勝者と敗者の差の対数を最適化している。チームは、その後すべての勝者・敗者のペアが正しく、かつ有意に判定されたこと、そしてこの指標に切り替えた後、それが追うことを意図していたビジネス指標であるリテンションが、受け入れ率は当初下がったにもかかわらず大きく上昇したことを報告している。A/B テストを実施できるだけのトラフィックがあるオンライン環境を前提としており、チームはそれを、実験をユーザー単位ではなくリクエスト単位で分割することで得た。記事のより広い注意書きは、どんな受け入れの指標も疑ってかかるべきであり、再び変更が必要になるかもしれない、というものである。