Skip to main content
開発者向けのこのハンズオンチュートリアルでは、Kameleoon プラットフォーム上でフィーチャーエクスペリメンテーションがどのように動作するかを示します。サンプルアプリから始めて、Kameleoon アプリで一連のフィーチャーフラグを構成し、サンプルアプリで有効化し、フィーチャーフラグが訪問者のページにどう影響するかを確認するためのステップバイステップの手順に従います。 サンプルは TypeScript で書かれていますが、このチュートリアルを完了するために TypeScript を知っている必要はありません。重要なポイントを理解するには、最新のプログラミング言語の経験があれば十分です。

前提条件

開始する前に、いくつかのアカウントを作成する必要があります。
  • 無料の30日間の Kameleoon トライアルアカウントに サインアップ します。アカウント請求後30日以内にこのチュートリアルを完了する必要がありますが、チュートリアル自体は約30分程度で完了するはずです。
  • GitHub アカウント。

サンプルアプリを実行する

サンプルアプリは、GitHub Pages 上またはローカルマシン上のいずれかで実行できます。どちらの方法を選択する場合も、開始前に GitHub アカウントにサインインしてください。

GitHub Pages にデプロイする

GitHub Pages にデプロイすると、Web サーバーをセットアップする必要がありません。
  1. GitHub の Bouncing ball リポジトリFork をクリックします。プロンプトに従って、github.com/<your_username>/bouncing-ball にサンプルアプリのフォークを作成します。(このチュートリアル全体で <your_username> を GitHub アカウント名に置き換えてください。)
  2. GitHub の新しい https://github.com/<your_username>/bouncing-ball リポジトリで、Actions タブをクリックし、ワークフローを有効にするボタンをクリックします。
  3. Settings タブで、Pages をクリックし、Source ドロップダウンをクリックして、GitHub Actions をクリックします。
  4. Actions タブで、Deploy static content to Pages > Run workflow > Run workflow をクリックします。
ビルドおよびデプロイプロセスが完了すると (1~2分かかる場合があります)、https://<your_username>.github.io/bouncing-ball でブラウザで実行中のデモアプリが見られるはずです。次のようになるはずです。
Bouncing ball demo app

アプリをローカルで実行する

GitHub Pages にデプロイする代わりに、サンプルアプリをローカルマシンで実行することもできます。ローカルで作業すると、このチュートリアルを進める際にブラウザのコンソールでデバッグ出力を確認しやすくなります。
  1. フォークをクローンします: git clone https://github.com/<your_username>/bouncing-ball.git
  2. 依存関係をインストールします: npm install
  3. ローカル開発サーバーを起動します: npm run dev
  4. ターミナルに出力される URL を開きます (例: http://localhost:5173)。
生の http://localhost アドレスでのテストは避けてください。Kameleoon の訪問者トラッキングはクッキーに依存しており、実際のホスト名に対してより確実に動作します。マシンの hosts ファイルに、カスタムローカルドメインを 127.0.0.1 に紐付けるエントリを追加します (例: 127.0.0.1 bouncing-ball.local)。その後、そのドメインとポートでアプリを開きます (例: http://bouncing-ball.local:5173)。
このチュートリアルの残りの部分では、https://<your_username>.github.io/bouncing-ball の代わりにこのローカル URL を使用します。Kameleoon プロジェクトを作成する際のサイトの URL としても、このローカル URL を使用してください。

構成のポーリング間隔を短縮する

プロジェクトの変更を高速化するため、SDK が Kameleoon アカウントの構成変更を確認する更新間隔をプログラム的に調整できます。
  1. GitHub リポジトリの Code タブで、src/main.ts ファイルを開きます。
  2. Edit this file ボタン (鉛筆アイコン) をクリックします。
  3. /src/main.ts ファイルを見つけて編集します。次の行を見つけます。
    この行を次のコードに置き換えます。
    新しいコードは updateInterval が 1 の構成を追加します。この値は、SDK が構成の変更をポーリングする頻度を1分に1回 (デフォルトの60分から) に減らします。この頻繁なポーリングは、パフォーマンスへの影響のため本番環境では推奨されませんが、チュートリアルでは役立ちます。Kameleoon は、構成変更を SDK にただちにプッシュする プレミアムストリーミングオプション も提供しています。
  4. Commit changes… をクリックします。

Kameleoon プロジェクトをセットアップする

このセクションを開始する前に、Kameleoon トライアルアカウントのクレデンシャルが必要です。
  1. トライアルアカウントのクレデンシャルを使用して Kameleoon アプリ にサインインします。
  2. 左メニューで、Admin を展開し、Projects > New project をクリックします。
  3. ダイアログで、最初のドロップダウンの Site: Feature flags をクリックし、URL of site として https://<your_username>.github.io/bouncing-ball (ローカルでアプリを実行している場合はローカル URL) を貼り付けます。<your_username> を GitHub アカウント名で置き換えるのを忘れないでください。Add をクリックします。
  4. 次のページに表示されているサイトコードをコピーします。
    New project page with site code
  5. GitHub リポジトリの Code タブで、src/constants ファイルを編集します。siteCode の値を、今コピーしたサイトコードで置き換え、Commit changes をクリックします。
ブラウザで再びアプリを確認すると (https://<your_username>.github.io/bouncing-ball、またはローカル URL)、すべてのバウンスする円が消えているのが分かるはずです。これは、円が別のプロジェクトの Kameleoon フィーチャーフラグによって追加されていたためです。サイトコードを変更したばかりなので、現在サイトはまだ完全に構成していないあなたの Kameleoon プロジェクトによって制御されています。心配は不要です。自分自身のフィーチャーフラグでアプリに自分の円を戻すことになります。
トラブルシューティング: Slow + Random + Big のテキストとバウンスする円がまだ表示されている場合は、インコグニート (またはプライバシーモード) ウィンドウでページを開いてみてください。

フィーチャーフラグをセットアップする

フィーチャーフラグを使用すると、新機能を限定されたオーディエンスに展開して、完全な展開の前に効果をテストできます。構成は開発者または他のチームメンバーによって管理できます。Kameleoon インターフェイスでフィーチャーフラグがどのように構成されているかを理解することで、アプリ内で変数を効果的に使用できます。
  1. Kameleoon アプリの Activate メニューで、Feature flags をクリックします。
  2. New feature flag をクリックします。
  3. 次の値でフィールドを記入します。
    • Name: Bouncing ball demo
    • Project: {ドロップダウンからプロジェクトを選択}
    • Flag type: Permanent
    • Feature key: bouncing_ball_demo タグと説明フィールドは空のままにできます。
  4. Validate をクリックします。

変数をセットアップする

変数 は、アプリの動作を変更するためにアプリコードで使用する文字列、数値、ブール値、または JSON 値です。それらの値は、Kameleoon が訪問者に割り当てるバリエーションによって変化します。 たとえば、「Party time」バリエーションで訪問者にサービスを提供したときと「Hypnotize」バリエーションで提供したときに、訪問者がサイトに長く留まるかどうかを判断するには、各オプションのバリエーションをセットアップして実験を実行します。
  1. 表示される新しいページで、Set Up メニューを展開して、Variables をクリックします。
Set Up menu
  1. + Add Variable ボタンを使用して、次の値で 6 つの変数を追加します。
    入力ミスに注意してください! 変数キー名とタイプは完全に一致する必要があります。GitHub リポジトリの src/main.ts ファイルを見ると、その理由が分かります。コードサンプルは、Kameleoon が訪問者に割り当てるバリエーションに応じて、これらの正確な変数キー名を使用して変数の値を取得します。
  2. Save をクリックします。
これで、デフォルト値を持つ一連の変数をセットアップしました。デフォルト値は、訪問者に対してアクティブなキャンペーンがない場合にアプリが使用する値です。今すぐフィーチャーフラグを有効にすると、デフォルトのバリエーション (1つの緑色のボールがゆっくりとバウンスする) が表示されます。これは、まだバリエーションがセットアップされていないためです。

バリエーションをセットアップする

バリエーション は、訪問者がアプリで何を見るかを制御する変数の可能な組み合わせを定義します。Kameleoon は、訪問者がアプリに初めて訪問したときにバリエーションを割り当てます。
  1. Set UpVariations をクリックします。
  2. + Add variation ボタンを使用して、2つの新しいバリエーションを追加します。
    • Name: Party time
      • ball_size: 50
      • ball_color: random
      • ball_speed: 75
      • balls_amount: 75
      • randomize_on_bounce: True
      • title_text: Hey! Get up and dance!
    • Name: Hypnotize
      • ball_size: 200
      • ball_color: blue
      • ball_speed: 2
      • balls_amount: 10
      • randomize_on_bounce: False
      • title_text: You're getting very, very sleepy

ゴールをセットアップする

次に、ゴール をセットアップします。ゴールは、バリエーションの効果をどう測定するかを定義します。 使用可能なカスタマイズ可能なゴールタイプには複数の種類がありますが、このチュートリアルでは基本的な「time spent」(滞在時間) 指標を使用します。
  1. Set Up メニューで、Goals > + Add goal をクリックします。
  2. Configure goals セクションで + Create a new goal をクリックし、次のフィールドに入力します。
    • Name: Time spent
    • Type: Time Spent
    • Project: {自分のプロジェクトを選択}
  3. Next をクリックし、ゴールを The visitor spent more than 30 seconds に設定します。
  4. Validate をクリックします。

実験を展開する

バリエーションが構成されたので、オーディエンスのサブセットに対して2つのバリエーションを表示する実験を作成できます。1つのバリエーションを訪問者の40%に表示し、もう1つのバリエーションを別の40%の訪問者に表示します。残りの20%の訪問者は、アプリの未変更バージョン (デフォルト) を見ます。
  1. Rollout Planner セクションで、Production をクリックします。
  2. + Add a rule > Experiment をクリックします。
  3. Exposure スライダーを 80% に下げます。
  4. Variations to serve の下で、Party time をクリックし、Exposition の値を 40.00% に変更します。
  5. + Add a variation をクリックします。バリエーション Hypnotize が自動的に選択されているはずです (そうでない場合は選択してください)。Exposition の値を 40.00% に変更します。
  6. ON/OFF トグルを ON に切り替えます。
  7. Save をクリックします。

アプリをテストする

ここでは、SDK のデバッグ出力、いくつかのブラウザテクニック、および Kameleoon アプリの Live events を使用して、構成したフィーチャーフラグをテストし、すべてが正しく動作していることを確認します。

デバッグログを有効にする

デバッグレベルのログには、SDK が行うすべての内部的な判断が表示され、バリエーションが表示されなかった理由やイベントがトラッキングされなかった理由を理解するのに役立ちます。最初にアプリを開く前にデバッグログを有効にしておくと、最初の訪問から完全な可視性が得られます。
  1. src/main.ts で、SDK のインポートを変更して、KameleoonLoggerLogLevel をデフォルトのバンドルではなくフルバンドルから読み込むようにします。
  2. クライアントを作成した直後に、ログレベルを設定します。
  3. 変更をコミットします (ローカルでアプリを実行している場合は、ファイルを保存します)。
  4. アプリを読み込む前に、ブラウザの開発者コンソールを開きます。構成の読み込み、訪問者コードの割り当て、バリエーションの計算に関する詳細なログが表示されます。
ログレベルの全一覧と各レベルが報告する内容については、Logging を参照してください。

バリエーションを確認する

GitHub Pages の URL またはローカル URL のいずれかを使用して、ブラウザでアプリを開きます。3つの可能なバリエーション (Party time バリエーション、Hypnotize バリエーション、または Default バリエーション) のいずれかが表示されるはずです。
Party time variation Party time バリエーション
Hypnotize variation Hypnotize バリエーション
Default variation Default バリエーション

別のバリエーションを確認する

ブラウザはあなたを識別するユニーク ID である visitorCode を保存するため、ページを更新しても常に最初に割り当てられたバリエーションが表示されます。新しい訪問者のように見せるには、次のいずれかの方法を使用します。
  • 別のブラウザまたはデバイスに切り替えます。
  • 毎回新しいプライベートウィンドウでアプリを開きます (選択したブラウザによっては「インコグニート」、「プライベートブラウジング」などと呼ばれることもあります)。
  • Rollout Planner のシミュレーションパネルを使用して、新しい訪問者コードを生成せずに特定のバリエーションを選択します。セットアップ手順については、シミュレーションモードの使用 を参照してください。フィーチャーエクスペリメンテーションのみを使用するプロジェクトでは、Chrome 拡張機能が必要です。
十分な試行の後、3つのバリエーションすべてが見られるはずです。そうであれば、おめでとうございます! Kameleoon でフィーチャー実験を正常にセットアップしました! 🎉🎉🎉

Live events でトラッキングを確認する

ブラウザにバリエーションが表示されても、Kameleoon がその訪問をトラッキングしたことは保証されません。Kameleoon アプリの Live events を確認して、Kameleoon がイベントを受信したことを確かめます。
  1. Kameleoon アプリで、Insights > Live events に移動します。
  2. プロジェクトを選択します。
  3. Experiment イベントタイプでフィルタリングします。
  4. 最近のタイムスタンプとフィーチャーフラグの名前が付いた行を探します。
アプリが GitHub Pages で実行されている場合でも、ローカルマシンで実行されている場合でも、Kameleoon はいずれの場合もネットワーク経由でイベントを受信するため、Live events は同じように動作します。フィルタリングとイベントタイプの詳細については、Live events を参照してください。

よくある問題のトラブルシューティング

  • 毎回同じバリエーションが表示される。 ブラウザに visitorCode がすでにクッキーとして保存されています。プライベートウィンドウを使用するか、ブラウザを切り替えるか、シミュレーションパネルを使用して、訪問者コードをリセットせずに別のバリエーションをプレビューします。
  • バリエーションが表示されない、または常に Default バリエーションが表示される。 Rollout Planner でルールの ON/OFF トグルが ON になっていること、およびルールのステータスが Active になっていることを確認します。
  • ルールを変更しても、アプリに古い構成が表示され続ける。 SDK は設定された間隔 (デフォルトは60分) で構成の更新をポーリングします。構成でより短い updateInterval の値を設定し、その変更をコミットしたことを確認してから、その間隔以上の時間を置いて再度テストしてください。
  • コンソールにデバッグログが表示されない。 インポート文が @kameleoon/javascript-sdk ではなく @kameleoon/javascript-sdk/full を使用していることを確認します。デフォルトのバンドルは、サイズを削減するためにデバッグログと情報ログを除去しています。
  • バリエーションは表示されるが、Live events にイベントが表示されない。 シミュレーションパネルは、トラッキング可能なイベントを送信せずにバリエーションをプレビューするため、Live events には表示されません。確認可能なイベントを生成するには、シミュレーションパネルを使わずに通常どおりアプリにアクセスしてください。

次のステップ

  • 実験の Reporting セクションで、初期結果、利用可能な統合、アクティビティログのいくつかを確認します。トラフィックが少ないため、まだ多くの結果データにアクセスすることはできません。
  • サンプルコードを確認して、変数がコードでどのように適用されているかを理解します。TypeScript を書くのに慣れている場合は、自分の変数を追加してみてください。
  • この開発者ドキュメントと エクスペリメンテーションユーザーガイド の残りの部分を確認して、利用可能なすべてのオプションと機能について詳細を学んでください。
  • 選択した SDK をインストールし、自分のフィーチャーフラグ、パーソナライゼーション、その他の実験の構築を開始します。