1770982098
2026-02-13 09:27:00
概要
Optimizely Web Experimentation は、Web 実験の評価のためにレンダリングされたスクリプト スニペットに基づいて MAU をカウントします。したがって、Web サイトにスニペットをグローバルにインストールすると、カウントする必要のないページの MAU がカウントされる可能性があります。また、実験が行われないため、Web Ex を必要としないページ タイプも存在する可能性があります。見る https://support.optimizely.com/hc/en-us/articles/4410284235789-Monitor-monthly-active-users-MAUs この消費に関する情報については、
記事では、スクリプトをレンダリングしないか、次のスクリプトを使用してオプトアウトすることが推奨されています。
しかし、どうやってそれを知ることができるのでしょうか！
解決
Web 実験用の REST API は、ユーザーベアラートークンを使用して特定のプロジェクトのアクティブな実験を返すことができます https://docs.developers.optimizely.com/web-experimentation/reference/list_experiments
したがって、ドメイン/サブページにアクティブな実験があるかどうかを知るロジックをプラグインすることが可能です。
概念実証として (実際のプロジェクトではまだ使用していません) を作成しました https://github.com/scottreed/Optimizely-Web-Experimentation-Evaluator/
このプロジェクトは、Web 実験ユーザーのベアラー トークンを使用して、REST API 経由で Optimizely Web Experimentation を評価することに関する POC です。
Web 実験 ページにレンダリングされたばかりのスクリプトに基づいて月間アクティブ ユーザーをカウントし、実験を実行する必要があるかどうかを評価します。これは、Web 実験スニペットをレンダリングするたびに、それを実行する必要がない場合でも、ユニーク ユーザー数が MAU として評価されることを意味します。
実行する必要のないユーザーをカウントするため、コストが増加する可能性があります。これは、ページまたはサブサイトの特定のセクションで実験を実行しない可能性があるマルチサイトでは特に重要です。
プロジェクト概要
これは次のような標準的なプロジェクトです。
- .NET 8.0
- ASP.NETコア8.0
- 最適化SDK
- 最小限の API
- インメモリキャッシュ
特徴
このプロジェクトには次のような特徴があります
- ステータス フラグの過去に基づいて、Web 実験 REST API から実験のリストを返します。
- 複数のパス基準 (Web サイトのサブパスやルートなど) に基づいて実験のリストをフィルタリングします。
- のブール値
ExperimentFilterServiceURL に一致する基準がない場合に実験を返すことを許可するサービス。 - 実験はメモリ内にキャッシュされるため、15 分の時間枠で常に再評価する必要がありません。
- Webhook JSON Post 形式に一致する最小限の API。この Webhook はプロジェクトの設定で構成でき、プロジェクトに変更があったときに通知します。この最小限の API は、プロジェクト ID に基づいてキャッシュをクリアします。
上の画像では、いくつかのテストを行う必要があったため、アーカイブされたプロジェクトも返すように設定しました。ただし、このプロジェクトを実行するときは、アクティブで実行中のプロジェクトだけになるように調整することをお勧めします。
結論
これを使用すると、Web 実験スクリプトをレンダリング (または選択) する必要がない場合、バックエンド コードから能動的に知ることができます。このようにして、具体的に MAU のカウントを停止し、必要な分だけコストを削減することができます。
これは単なるエバレータであることに注意してください。そのため、これをオーバーライドしてレンダリングする必要がある場合（追跡/視聴者基準またはその他の機能のために）、これを調整できます。
これは単なる POC であり、アイデアなので、ご意見がございましたらお知らせください。
2026 年 2 月 13 日
#REST #API #を使用した #Web #実験の #MAU #の削減