開発者ガイド
Kameleoon iOS SDK をアプリケーションに初めてインストールし設定するには、次の手順に従ってください。はじめに
スターターキット
開始を支援するため、Kameleoon は SDK をテストするためのスターターキットとデモアプリケーションを提供しています。スターターキットには、SDK メソッドをアプリ内でどのように使用できるかを示すサンプル付きの完全に構成されたアプリが含まれています。スターターキット、デモアプリケーション、および詳細な手順は iOS 用スターターキットで入手できます。前提条件
- iOS プラットフォームで Swift バージョン 5.0 以上を使用してください。それ以前の iOS アプリケーション(以前の Swift バージョンおよび Objective-C アプリを含む)はサポート予定はありません。x86_64(iOS Simulator 用)および ARM(App Store への本番デプロイ用)の両方に対応する Universal Framework バージョンが利用可能です。
インストール
iOS SDK は CocoaPods または Swift Package Manager を使用してインストールできます:- CocoaPods
- Swift Package Manager
Swift Package Manager を使用して、Xcode プロジェクトにパッケージ依存関係を追加します。File > Swift Packages > Add Package Dependency を選択し、リポジトリ URL
https://github.com/Kameleoon/client-swift を入力します。または、Package.swift ファイルを直接変更することもできます:追加の設定
SDK の動作をカスタマイズするには、Xcode プロジェクトのルートディレクトリにkameleoon-client-swift.plist 設定ファイルを作成します。サンプル設定ファイルをダウンロードすることもできます。
設定できるキーは以下の通りです:
visitorCode を指定し、isUniqueIdentifier パラメータを true に設定した場合、SDK メソッドは visitorCode 値を一意の訪問者識別子として使用します。これはクロスデバイス実験に役立ちます。SDK は、フラッシュされたデータを指定された識別子に関連付けられた訪問者にリンクします。isUniqueIdentifier は、他のエッジケースシナリオでも有用です。例えば、訪問者に元々割り当てられていた匿名の visitorCode にアクセスできないが、セッションマージを通じて匿名訪問者と結びつけられた内部 ID にはアクセスできる場合などです。activityTrackingIntervalMillisecond の使用
activityTrackingIntervalMillisecond パラメータは、SDK が Data API 上の訪問者のセッションを延長するためにアクティビティイベントを送信する頻度を制御することで、ネットワーク使用量とバッテリー消費を削減するのに役立ちます。デフォルト値および許容される最小値は 60 000 ms (60 秒) で、これより低い 0 以外の値は無視され、デフォルト値が適用されます。アプリがバックグラウンドにある間はタイマーが一時停止するため、間隔はアプリがフォアグラウンドにあるときにのみ実質的に進行します。
Kameleoon クライアントの初期化
アプリケーションで SDK を設定した後、Kameleoon クライアントを作成する必要があります。クライアントは、アプリケーションと Kameleoon プラットフォームの間のブリッジとして機能するシングルトンオブジェクトです。実験を実行するために必要なすべてのメソッドとプロパティが含まれています。KameleoonClientFactory.create() メソッドはクライアントを初期化しますが、クライアントはすぐには使用準備が整いません。クライアントは、Kameleoon リモートサーバーから現在のアクティブな実験および機能フラグの構成(トラフィック分配を含む)を取得する必要があります。この取得には、クライアントがネットワークアクセスを持つ必要があり、これは常に利用可能とは限りません。Kameleoon クライアントが完全に準備できるまで、Kameleoon iOS SDK の他のメソッドを実行しようとしてはいけません。クライアントが最初の機能フラグ構成を取得した後、定期的に構成を更新します。何らかの理由で更新に失敗した場合、Kameleoon クライアントは以前の構成を使用して機能し続けます。
.ready パブリックゲッターを使用して、Kameleoon クライアントの初期化が完了したかどうかを確認できます。
あるいは、ヘルパーコールバックを使用して、実験のトリガーとバリエーション実装のロジックをカプセル化することもできます。最良のアプローチ(.ready またはコールバック)は、好みとユースケースによって異なります。SDK がまもなく使用可能になることが予想される場合は、.ready を使用することを推奨します。例えば、アプリ内をナビゲートしてから数秒または数分後にのみアクセス可能なダイアログで実験を実行する場合、.ready が適しています。実験に到達したときに SDK がまだ初期化中である可能性が高い場合は、コールバックを推奨します。例えば、アプリの起動時に表示される実験では、SDK が準備完了するか指定されたタイムアウトが経過するまでアプリケーションを待機させるコールバックを使用する必要があります。
クライアントが準備できる前にメソッドを呼び出さないようにするのは、アプリ開発者であるあなたの責任です。良い慣習として、Kameleoon クライアントがまだ準備できていない場合、アプリユーザーは実験から除外されるべきであると常に想定することです。この除外は、上記のコードサンプルに示すように、デフォルトの参照バリエーションロジックの実装に対応するため、簡単に実行できます。
初期化と使用に関するベストプラクティス
KameleoonClientは、初期化に時間がかかる可能性があるため、アプリケーション開始後できるだけ早くシングルトンとして初期化することを推奨します。初期化は非同期で行われるため、アプリケーションの起動プロセスをブロックしたり遅延させたりすることはありません。KameleoonClientを使用する前に、runWhenReadyメソッドを呼び出して初期化されていることを確認してください。そうしないと、準備完了前にクライアントを使用しようとするとエラーが発生します。- ⚠️ ほとんどの主要なメソッドはエラーをスローする可能性があるため、適切な例外処理が必要です。使用する各メソッドの潜在的なエラーを理解するために、必ずドキュメントを確認してください。
- Swift
- Swift (Async)
機能フラグの有効化
フラグ構成の取得
コードに機能フラグを実装するには、まず Kameleoon アカウントで機能フラグを作成する必要があります。 特定のユーザーに対する機能フラグのステータスまたはバリエーションを判別するには、getVariation() または isFeatureActive() メソッドを使用して、featureKey に基づいて構成を取得する必要があります。
getVariation() メソッドは、ON/OFF 状態のシンプルな機能フラグと、複数のバリエーションを持つより複雑なフラグの両方を処理します。このメソッドは、機能ルールをチェックし、バリエーションを割り当て、featureKey および visitorCode に基づいて返すことで、ユーザーに適切なバリエーションを取得します。
isFeatureActive() メソッドは、複数のバリエーションやターゲティングオプションを持つより複雑な機能フラグではなく、ON または OFF 状態のみを持つシンプルな機能フラグの構成を取得したい場合に使用できます。
機能フラグに関連する変数(例えば、各バリエーションに紐づく特定の動作)がある場合、getVariation() はVariation オブジェクトへのアクセスも可能にし、割り当てられたバリエーションとその関連実験の詳細を提供します。このメソッドは、ユーザーがターゲットになっているかどうかを確認し、訪問者に割り当てられたバリエーションを見つけ、ストレージに保存します。track=true の場合、SDK は次のトラッキングリクエストで指定された実験への露出イベントを送信します。これは SDK の tracking_interval_millisecond に基づいて自動的にトリガーされます。デフォルトでは、この間隔は 1000 ミリ秒(1 秒)に設定されています。
getVariation() メソッドでは、トラッキングを行うかどうかを制御できます。track=false の場合、SDK は露出イベントを送信しません。これは、SDK 経由でデータをトラッキングするのではなく、Kameleoon エンジンが管理するクライアントサイドトラッキングに頼ることを希望する場合に有用です。さらに、track=false を設定することは、getVariations() メソッドを使用する際に、トラッキングイベントをトリガーせずにすべてのフラグのバリエーションだけを必要とする場合に役立ちます。トラッキングの仕組みについて詳しく知りたい場合は、こちらの記事を参照してください。
レポートで訪問をターゲット、フィルター、または分解するためのデータポイントの追加
ユーザーをターゲットにするには、機能バリエーションを取得したりフラグがアクティブかどうかを確認したりする前に、プロファイルに関連するデータポイントを追加していることを確認してください。addData() メソッドを使用して、これらのデータポイントをユーザーのプロファイルに追加します。
他のデバイスで収集されたデータポイントを取得するには、getRemoteVisitorData() メソッドを使用します。このメソッドは、サーバーからデータを非同期に取得します。getRemoteVisitorData() を呼び出すことは、バリエーションを取得したり機能フラグがアクティブかどうかを確認したりする前に行うことが重要です。このデータは、ユーザーを特定のバリエーションに割り当てるために必要な場合があるためです。
利用可能なターゲティング条件の詳細については、このトピックに関する詳細な記事を参照してください。
さらに、訪問者プロファイルに追加したデータポイントは、実験を分析する際に利用可能になり、デバイスなどの要因で結果をフィルタリングおよび分解できます。完全なリストはこちらを参照してください。
自動的に収集されるもの以外の追加のデータポイントをトラッキングする必要がある場合は、Kameleoon のカスタムデータ機能を使用できます。カスタムデータを使用すると、実験に関連する特定の情報をキャプチャして分析できます。収集したデータを分析のために Kameleoon サーバーに送信するには、flush() メソッドの呼び出しを忘れないでください。
ゴールコンバージョンのトラッキング
ユーザーが目的のアクション(購入など)を完了した場合、それはコンバージョンとして記録されます。コンバージョンをトラッキングするには、trackConversion() メソッドを使用し、必須の goalId パラメータを指定します。
コンバージョントラッキングリクエストは、SDK が定期的に送信する次にスケジュールされたトラッキングリクエスト(tracking_interval_millisecond で定義) と一緒に送信されます。リクエストを即座に送信したい場合は、instant=true パラメータを指定して flush() メソッドを使用してください。
クロスデバイス実験
複数のデバイスからアプリにアクセスする訪問者をサポートするため、Kameleoon は以前に収集した訪問者データを各デバイス間で同期し、クロスデバイス実験を通じてデバイス間の訪問履歴を統合できます。Kameleoon がデバイス間でデータをどのように扱うかに関するケーススタディと詳細情報は、クロスデバイス実験に関する記事で利用できます。デバイス間でのカスタムデータの同期
カスタムマッピング同期はデバイス間で訪問者データを整合させるために使用されますが、必ずしも必要ではありません。以下は、カスタムマッピング同期が不要な 2 つのシナリオです: デバイス間で同じユーザー ID すべてのデバイスで同じユーザー ID が一貫して使用されている場合、カスタムマッピング同期なしで同期が自動的に処理されます。複数のデバイス間で収集されたデータを同期したい場合は、getRemoteVisitorData() メソッドを呼び出すだけで十分です。
一貫した ID を持つマルチサーバーインスタンス
複数のサーバー(例えば、分散サーバーインスタンス)が関与する複雑なセットアップで、サーバー間で同じユーザー ID が利用できる場合、追加のカスタムマッピング同期なしで、サーバー間の同期(getRemoteVisitorData() を使用)で十分です。
追加のデータが必要な顧客は、getRemoteVisitorData() メソッドの説明を参照してください。以下のコードでは、正確なデータ取得のために、2 つのデバイス間で同じ一意の識別子(この場合は visitorCode、userId とも呼ばれる)が一貫して使用されていると仮定しています。
収集されたデータをリアルタイムで同期したい場合は、カスタムデータのスコープに**訪問者(Visitor)**を選択する必要があります。
- Swift
- Swift (Async)
Device A
Device B
セッションマージのためのカスタムデータの使用
クロスデバイス実験は、訪問者の各デバイスにわたる履歴を結合(履歴調整)することを可能にします。履歴調整により、異なる訪問者セッションを 1 つにマージできます。訪問履歴を調整するには、CustomData を使用して訪問者の一意の識別子を提供します。詳細については、専用ドキュメントを参照してください。
クロスデバイス調整が有効になった後、userId パラメータを指定して getRemoteVisitorData() を呼び出すと、指定されたユーザーの既知のすべてのデータを取得できます。
同じ識別子を持つセッションは、実験で常に同じバリエーションが表示されます。実験結果ページの訪問者ビューでは、これらのセッションは単一の訪問者として表示されます。
SDK の構成により、関連するセッションは常に実験の同じバリエーションを参照するようになります。ただし、クロスデバイスバリエーション割り当てに関するいくつかの制限があります。これらの制限はこちらに記載されています。
Kameleoon プラットフォーム上でカスタムデータを設定するには、クロスデバイス履歴調整の有効化ガイドに従ってください。
その後、通常通り SDK を使用できます。セッションマージのコンテキストで役立つ可能性のあるメソッドは以下の通りです:
getRemoteVisitorData()にisUniqueIdentifier=trueをKameleoonClientConfigに渡す - すべてのリンクされた訪問者のデータを取得します。trackConversion()またはflush()にisUniqueIdentifier=trueをKameleoonClientConfigに渡す - 別の訪問者に関連付けられた特定の訪問者の一部のデータをトラッキングします。
- Swift
- Swift (Async)
getVisitorCode() メソッドで取得できます。ユーザーがログインした後、匿名訪問者はユーザー ID に関連付けられ、その訪問者の一意の識別子として使用されます。
カスタムバケットキーの使用
デフォルトでは、Kameleoon は一意の匿名訪問者 ID(visitorCode)を使用して、ユーザーを機能フラグのバリエーションに割り当てます。この ID は通常、ユーザーのデバイス上で生成および保存されます(クライアントサイドおよびサーバーサイド SDK ではブラウザの cookie に、モバイル SDK では永続ストレージに)。ただし、特定のシナリオでは、同じ組織のすべてのユーザーが同じ機能フラグのバリアントを参照することを保証する必要がある場合があります。
カスタムバケットキーオプションを使用すると、独自のカスタム識別子をバケッティングに提供することで、このデフォルトの動作を上書きできます。この上書きにより、Kameleoon の割り当てロジックはデフォルトの visitorCode の代わりに指定されたキーを使用するようになります。
ユースケース
カスタムバケットキーの使用は、特に以下の状況で、機能フラグ割り当ての一貫性と正確性を維持するために不可欠です:- アカウントレベルまたは組織レベルの実験: B2B 製品または同じ組織のすべてのユーザーを同じバリエーションに割り当てたいシナリオでは、
accountIdなどの識別子を使用できます。カスタムバケットキーは、チームまたは企業全体に影響する機能の A/B テストには不可欠です。
技術的な詳細
機能フラグにカスタムバケットキーを設定すると、アプリケーションのデータからの特定の識別子を Kameleoon に提供することになります:- カスタムキーの提供:
addData()メソッドを使用して、Kameleoon SDK にカスタム識別子を提供します。このメソッドでは、選択したカスタムバケットキーをCustomDataオブジェクトとして渡します。ここで、newVisitorCodeはバケッティングに使用する識別子(例えば、新しいuserIdまたはaccountId)を指します。
- バケッティングロジック:
addData()メソッドを通じてカスタムバケットキーが提供されると、ユーザーをバリエーションに割り当てるためのすべてのハッシュ計算は、デフォルトのvisitorCodeの代わりにnewVisitorCode(カスタムキー)を使用します。newVisitorCodeを使用することで、バケッティングの決定がカスタム識別子に紐付けられ、その識別子が存在するさまざまなコンテキストで一貫した割り当てが保証されます。 - データトラッキングと分析: 重要な点として、
newVisitorCode(カスタムキー)はバケッティング決定に使用されますが、それ以降のすべてのデータ(例えば、トラッキングイベントやコンバージョン)は、元のvisitorCodeに関連付けられて送信されます。 この分離により、バケッティングがより高いレベル(アカウントなど)または複数のデバイス/セッションで実行される場合でも、実験のより広いコンテキスト内で個々のユーザージャーニーやインタラクションを正確に反映するアナリティクスが可能になります。元の訪問者データは包括的なレポートのためにそのまま保持されます。
技術要件
カスタムバケットキーを効果的に使用するには:- キーは
Stringでなければなりません。 - バケッティングを意図するエンティティに対して一意である必要があります(例えば、
userIdを使用する場合、各ユーザーの ID は一意である必要があります)。 - そのユーザーまたはリクエストに対して機能フラグの判定が評価される正確な瞬間に、キーが SDK に利用可能でなければなりません。
ターゲティング条件
Kameleoon SDK は、キャンペーンでユーザーをターゲットにするために使用できるさまざまな事前定義済みのターゲティング条件をサポートしています。この SDK がサポートする条件のリストについては、訪問履歴を使用してユーザーをターゲットするを参照してください。 独自の外部データを使用してユーザーをターゲットすることもできます。ロギング
SDK は、さまざまな内部プロセスや問題を反映するログを生成します。ログレベル
SDK は、ログレベルによるロギングの制限の構成をサポートしています。ログのカスタム処理
SDK はデフォルトでログをコンソール出力に書き込みます。この動作はオーバーライドできます。ログレベルによるロギング制限は、ログ処理ロジックとは別に実行されます。
訪問者コードを WebView に渡す
場合によっては、Engine.js や Web 用 JavaScript または React SDK を使用する WebView にネイティブアプリケーションから訪問者コードを渡す必要がある場合があります。次の例は、これを実現するための推奨方法を示しています:- SwiftUI
- SwiftUI (iOS 26+)
Apple プライバシーコンプライアンス
2024 年 5 月 1 日以降、Apple は Kameleoon iOS SDK のようなサードパーティ SDK を含むアプリにプライバシーマニフェストファイルを含めることを要求しています。SDK の最新バージョンはコード署名され、コンプライアンスに準拠しており、SDK と一緒に有効なマニフェストファイルが含まれています。Kameleoon iOS SDK バージョン 4.2 以降を使用している場合、アクションは必要ありません。リファレンス
これは Kameleoon iOS (Swift) SDK の完全なリファレンスドキュメントです。初期化
アプリケーションに SDK をインストールした後、Kameleoon を初期化する必要があります。実験のトリガーなど、アプリケーションと SDK の間のすべてのやり取りは、この Kameleoon クライアントオブジェクトを使用して行います。create()
SDK を初期化するには、他のメソッドの前にこのメソッドを呼び出します。このメソッドはKameleoonClientFactory にあります。create() は、SDK とアプリ間のすべてのやり取りを管理する KameleoonClient のインスタンスを作成します。
構成オブジェクトを提供することで SDK の動作(例えば、環境、認証情報)をカスタマイズできます。それ以外の場合、SDK は構成ファイルを探し、それを代わりに使用します。
引数
戻り値
スローされる例外
ready
モバイル SDK では、Kameleoon クライアントの初期化は即座には完了しません。SDK は、すべてのアクティブな実験の現在の構成を取得するためにサーバー呼び出しを実行する必要があります。実験をトリガーする前に、このメソッドを呼び出して SDK の準備が整っているか確認してください。あるいは、コールバック付きのrunWhenReady() メソッドを使用することもできます。
戻り値
runWhenReady()
- 🔄 非同期リクエストを実行します(構成が古いか欠落している場合)
KameleoonClient はすべての機能フラグの現在の構成を取得するためにサーバー呼び出しを実行する必要があるため、即座に初期化できません。クライアントが使用可能になるまで待機するには、runWhenReady() メソッドを使用します。さらに、クライアントが準備完了するまで待機する最大タイムアウト期間を設定して制御できます。
ready=true の場合、KameleoonClient は完全に初期化されており、機能フラグが評価されてそれぞれのバリエーションが割り当てられます。結果が false であるか、タイムアウトが発生した場合、初期化は完了しません。
タイムアウトが発生すると、ユーザーは機能フラグから除外されるため、コールバックまたは非同期コードは参照バリエーションの適用を処理する必要があります。
- Swift
- Swift (Async)
引数
機能フラグとバリエーション
isFeatureActive()
- 📨 トラッキングデータを Kameleoon に送信します(
trackパラメータに応じて)
このメソッドは以前
activateFeature という名前で、SDK バージョン 4.0.0 で削除されました。isFeatureActive() は、指定された機能が訪問者に対してアクティブになるかどうかを確認するために、必須の引数として featureKey を受け取ります。
訪問者がこの機能フラグに関連付けられたことがない場合、このメソッドはランダムなブール値を返します(ユーザーにこの機能を表示すべき場合は true、それ以外の場合は false)。訪問者がすでにこの機能フラグに登録されている場合、メソッドは以前の featureFlag 値を返します。
潜在的なエラーをキャッチするために、サンプルコードに示されているようにエラー処理を実装してください。
Kameleoon は、
isFeatureActive()、getVariation()、getVariations() などの特定のメソッドを呼び出すときに、セッションと訪問者を数えるためにトラッキングを使用します。訪問者をバリエーションに公開し、それらをカウントする必要がある場合は、track パラメータのデフォルト値 true を使用してください。track パラメータを false に設定するのは、訪問者を公開する前にこれらのメソッドを呼び出す場合のみにしてください。例えば、訪問者を公開する前にすべてのバリエーションを取得するために getVariations() を呼び出す場合、track パラメータを false に設定してください。この設定により、Kameleoon がセッションを早期にカウントするのを防げます。その後、訪問者を明示的に公開するときにトラッキングをトリガーできます。Kameleoon はデフォルトで毎秒トラッキングデータを送信します。この間隔は、トラッキング間隔の構成オプションを使用して最大 5 秒まで構成できます。Kameleoon は、イベント間の間隔が 30 分未満である限り、トラッキングイベントを単一のセッションにグループ化します。トラッキングイベント間で 30 分以上経過した場合、Kameleoon はそれらのイベントを別々のセッションとしてカウントします。訪問は、セッションの最後に記録されたイベントから 30 分後にレポートに表示されます。引数
戻り値
スローされるエラー
getVariation()
- 📨 トラッキングデータを Kameleoon に送信します(
trackパラメータに応じて)
Variation を取得します。
このメソッドは、必須引数として visitorCode と featureKey を受け取ります。track 引数は任意であり、デフォルトは true です。
訪問者に割り当てられた Variation を返します。訪問者がいずれの機能フラグルールにも関連付けられていない場合、このメソッドは指定された機能フラグのデフォルト Variation を返します。
潜在的な例外を管理するために、コードに適切なエラー処理が実装されていることを確認してください。
デフォルトバリエーションは、訪問者が機能フラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションを指します。言い換えれば、特定のルールでターゲットされていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェースの「その他のすべての訪問者に対しては…」セクションのバリエーションとして表されます。
引数
戻り値
スローされるエラー
getVariations()
- 📨 トラッキングデータを Kameleoon に送信します(
trackパラメータに応じて)
Variation オブジェクトのマップを取得します。
このメソッドは、利用可能なすべての機能フラグを反復処理し、指定された訪問者に関連付けられた各フラグに割り当てられた Variation を返します。onlyActive と track を任意の引数として受け取ります。
onlyActiveがtrueに設定されている場合、getVariations()メソッドは、ユーザーがoffバリエーションでバケットされていない機能フラグのバリエーションを返します。trackパラメータは、メソッドがバリエーションの割り当てをトラッキングするかどうかを制御します。デフォルトではtrueに設定されています。falseに設定すると、トラッキングが無効になります。
Variation を値として持ちます。機能フラグにバリエーションが割り当てられていない場合、メソッドはそのフラグのデフォルト Variation を返します。
潜在的な例外を管理するために、適切なエラー処理を実装する必要があります。
デフォルトバリエーションは、訪問者が機能フラグの事前定義された配信ルールのいずれにも一致しない場合に割り当てられるバリエーションを指します。言い換えれば、特定のルールでターゲットされていないすべてのユーザーに適用されるフォールバックバリエーションです。管理インターフェースの「その他のすべての訪問者に対しては…」セクションのバリエーションとして表されます。
引数
戻り値
スローされるエラー
setForcedVariation()
このメソッドにより、標準の評価プロセスをバイパスして、特定のVariation をプログラム上でユーザーに割り当てることができます。これは、通常の評価ロジックが不要またはスキップする必要がある、制御された実験で特に有用です。また、デバッグやカスタムテストなどのシナリオでも役立ちます。
強制バリエーションが設定されている場合、Kameleoon のリアルタイム評価ロジックを上書きします。セグメンテーション、ターゲティング条件、アルゴリズム計算などのプロセスはスキップされます。実験中にセグメンテーションとターゲティング条件を保持するには、代わりに forceTargeting=false を設定してください。
強制バリエーションは、評価されたバリエーションと同じ扱いを受けます。標準的な評価バリエーションと同様に、アナリティクスでトラッキングされ、ユーザーコンテキストに保存され、レポートの一貫性が確保されます。
このメソッドは、特定の条件下で例外をスローする場合があります(例えば、無効なパラメータ、ユーザーコンテキスト、または内部の問題)。アプリケーションの安定性と耐障害性を確保するため、適切な例外処理は不可欠です。
引数
スローされるエラー
ほとんどの場合、例で示されているように、基本的なエラー
KameleoonError/KameleoonError.Feature のみを処理すれば十分です。ただし、異なる種類のエラーに対する応答が必要な場合は、特定の要件に基づいて個別に処理してください。さらに、信頼性を高めるため、Error を含めることで一般的な言語エラーを処理できます。evaluateAudiences()
- 📨 トラッキングデータを Kameleoon に送信します
evaluateAudiences() は、関連するすべての訪問者データが設定または更新された後、かつ機能バリエーションを取得したり機能フラグを確認したりする直前に呼び出す必要があります。このアプローチにより、訪問者が利用可能な最新のデータに対して評価されるようになり、すべての基準に基づいた正確なオーディエンス割り当てが可能になります。
このメソッドを呼び出した後、Audiences Explorer でセグメントのパフォーマンスを詳細に分析できます。
スローされるエラー
ほとんどの場合、例で示されているように、基本的なエラー
KameleoonError/KameleoonError.Feature のみを処理すれば十分です。ただし、異なる種類のエラーに対する応答が必要な場合は、特定の要件に基づいて個別に処理してください。さらに、信頼性を高めるため、Error を含めることで一般的な言語エラーを処理できます。getFeatureList()
現在 SDK で利用可能な機能フラグキーのリストを返します。戻り値
getDataFile()
現在の SDK 構成をDataFile オブジェクトとして返します。
戻り値
スローされるエラー
ゴール
trackConversion()
- 📨 トラッキングデータを Kameleoon に送信します
goalId を必要とします。さらに、このメソッドは revenue、metadata、negative 引数も受け取ります。
trackConversion() メソッドは値を返しません。サーバー呼び出しは非同期に行われるため、このメソッドはノンブロッキングです。
引数
metadata の値は、生データエクスポートおよび結果ページからアクセスできます。
metadata パラメータが提供されている場合、Kameleoon は addData() メソッドを使用して以前に収集された値の代わりに、これらの指定された値を現在のコンバージョンに使用します。パラメータが省略されている場合、Kameleoon はコンバージョンの前および同じ訪問内で、その CustomData に対して最後にトラッキングされた値を使用します。Kameleoon は、trackConversion() メソッドのパラメータとして明示的に渡されたメタデータ値のみを考慮します。以下の例では、Kameleoon はパラメータとして明示的に提供されたカスタムデータ値(ここでは: インデックス 5、値 ‘Amex Credit Card’)とのみコンバージョンを関連付けます。イベント
updateConfigurationHandler()
updateConfigurationHandler() メソッドにより、構成が更新されたデータを持つときのイベントを処理できます。入力パラメータとして handler を 1 つ受け取ります。リアルタイム構成イベントを使用して構成が更新されるときに呼び出されるハンドラーです。
このハンドラーは、SDK がストリーミングモード(サーバー送信イベント)で実行されている場合にのみ発火します。デフォルトのポーリングモード(
refreshIntervalMinute)で実行される構成更新では呼び出されません。引数
訪問者データ
visitorCode
SDK で使用されている一意の訪問者コードを返します。戻り値
addData()
addData() メソッドは、他のメソッドが現在の訪問者をターゲットにするかどうかを決定するために使用できるターゲティングデータをストレージに追加します。
addData() メソッドは値を返さず、それ自体で Kameleoon バックエンドサーバーと対話しません。代わりに、宣言されたすべてのデータは、flush() メソッドを使用した将来の送信のために保存されます。このアプローチにより、データは通常 flush() でトリガーされる単一のサーバー呼び出しにグループ化されるため、サーバー呼び出しの数が削減されます。
trackConversion() メソッドも、flush() と同じように、以前に関連付けられたデータを送信します。実験ルールがトリガーされた場合、getVariation() および getVariations() メソッドも同様です。
引数
flush()
- 📨 トラッキングデータを Kameleoon に送信します
flush() メソッドは、訪問者にリンクされた Kameleoon データを収集します。次に、addData メソッドを使用して追加され、これらのメソッドのいずれかを使用してまだ送信されていないすべてのデータと共に、トラッキングリクエストを送信します。サーバー呼び出しは非同期に行われるため、flush() はノンブロッキングです。
flush は、指定された visitorCode に関連付けられたデータがサーバーに送信されるタイミングを制御します。例えば、addData() が 12 回呼び出される場合、addData() が呼び出されるたびにサーバーにデータを送信するのは非効率的です。代わりに flush() を 1 回呼び出します。
引数
スローされるエラー
getRemoteData()
- 🔄 非同期リクエストを実行します
このメソッドは以前
retrieveDataFromRemoteSource という名前で、SDK バージョン 4.0.0 リリースで削除されました。siteCode と key 引数(または key が省略されている場合はアクティブな visitorCode)に基づいてリモート Kameleoon サーバーからデータを取得します。visitorCode と siteCode は KameleoonClientFactory.create() で指定されます。データは Kameleoon Data API を使用して、高度にスケーラブルなリモートサーバーに迅速かつ便利に保存できます。アプリケーションはこのメソッドを使用してデータを取得できます。
- Swift
- Swift (Async)
引数
getRemoteVisitorData()
- 🔄 非同期リクエストを実行します
getRemoteVisitorData() は、Kameleoon Data API から訪問者の Kameleoon 訪問データを取得するための非同期メソッドです。このメソッドは、ターゲティング決定を行う際に他のメソッドが使用できるように、データをストレージに追加します。
このメソッドで取得されるデータは、次のような場合に重要な役割を果たします:
- 他のデバイスから収集されたデータを使用する場合。
- 以前の訪問中に収集されたカスタムデータなど、ユーザーの履歴にアクセスする場合。
デフォルトでは、
getRemoteVisitorData() は scope=Visitor を持つ最新の保存されたカスタムデータを自動的に取得し、addData() メソッドを呼び出すことなく訪問者にアタッチします。これは特に、複数のデバイス間でカスタムデータを同期するのに有用です。失敗した結果のみを確認することが推奨されます。ただし、必要に応じて、データが訪問者に追加され、ターゲティング目的(またはデバッグ用、ただしデバッグにはロギングの使用が推奨されます)に利用可能であることを確認できます。さらに、addData=false パラメータが渡されている場合、データを手動で管理できます。- Swift
- Swift (Async)
引数
RemoteVisitorDataFilter でのパラメータの使用
getRemoteVisitorData() メソッドは、訪問者データを取得する際にさまざまなパラメータを定義できる柔軟性を提供します。ゴール、実験、またはバリエーションに基づいたターゲティングであっても、同じアプローチがすべてのデータ型に適用されます。
例えば、「注文取引」のゴールを完了した訪問者のデータを取得したいとします。getRemoteVisitorData() メソッド内でパラメータを指定して、ターゲティングを絞り込むことができます。例えば、最後の 5 回の訪問でゴールでコンバージョンしたユーザーのみをターゲットにする場合、previousVisitAmount パラメータを 5 に、conversions を true に設定できます。
この例で示される柔軟性は、ゴールデータに限定されません。getRemoteVisitorData() メソッド内のパラメータを使用して、さまざまな訪問者の動作に関するデータを取得できます。
利用可能な
Types.RemoteVisitorDataFilter オプションのリストは以下の通りです:getVisitorWarehouseAudience()
- 🔄 非同期リクエストを実行します
warehouseKey パラメータは通常、内部のユーザー ID です。customDataIndex パラメータは、訪問者のターゲティングに Kameleoon が使用する Kameleoon カスタムデータに対応します。詳細については、ウェアハウスターゲティングドキュメントを参照してください。
- Swift
- Swift (Async)
引数
setLegalConsent()
訪問者が個人データの使用に法的同意を与えたかどうかを指定するには、このメソッドを使用する必要があります。legalConsent パラメータを false に設定すると、トラッキングリクエストに含めることができるデータの種類が制限されます。このメソッドは、訪問者データを責任を持って管理しながら、法的および規制上の要件を遵守するのに役立ちます。個人データに関する詳細は、同意管理ポリシーを参照してください。
引数
データ型
このセクションでは、Kameleoon でサポートされているデータ型を一覧にします。複数の標準データ型が提供されているほか、カスタムデータ型を定義するためのCustomData 型も提供されています。
Conversion
ここに保存されるConversion データセットは、それに関連付けられた任意のゴールで実験およびパーソナライゼーションレポートをフィルタするために使用できます。
CustomData
CustomData を使用すると、任意の種類のデータを各訪問者に簡単に関連付けることができます。CustomData は、セグメントのターゲティング条件として、または実験レポートのフィルタ/分解として使用できます。
カスタムデータの詳細については、この記事を参照してください。
- 各訪問者は、一意の
indexごとにCustomDataを 1 つだけ持つことができます。同じindexで別のCustomDataを追加すると、既存のCustomDataが置き換えられます。 - カスタムデータの
indexは、カスタムデータダッシュボードの「INDEX」列にあります。 - プライバシー上の理由から、SDK が選択したインデックスを持つデータを Kameleoon サーバーに送信するのを防ぐには、カスタムデータの作成時に このデータをターゲティング目的のためにローカルでのみ使用する オプションを有効にします。
- SDK インスタンスの構成が最新でない場合、または名前が登録されていない場合に名前で作成された
CustomDataインスタンスを追加すると、データは無視されます。
Device
iOS SDK
4.14.0 以降、Device は UIDevice.current.userInterfaceIdiom の値に基づいて自動的に検出されます。ただし、必要に応じて手動で上書きすることもできます。Geolocation
Geolocation には訪問者のジオロケーション詳細が含まれます。
戻り値の型
DataFile
DataFile には SDK 構成の詳細が含まれます。
クライアントが必要とする場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
FeatureFlag
FeatureFlag は、機能フラグ自体を定義する一連のプロパティ — 例えば、その Variations、Rules、環境ステータス、およびその他の関連詳細 — を表します。
クライアントが必要とする場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Rule
Rule は、ルール自体を定義する一連のプロパティ — 例えば、その Variations — を表します。
クライアントが必要とする場合、追加情報で拡張できます。詳細が必要な場合は、カスタマーサクセスマネージャーにお問い合わせください。
Variation
Variation には、訪問者に割り当てられたバリエーション(または、特定の割り当てが存在しない場合のデフォルトバリエーション)に関する情報が含まれます。
Variationオブジェクトは、割り当てられたバリエーションとその関連実験の詳細を提供します。一方、Variableオブジェクトには、バリエーション内の各変数の特定の詳細が含まれます。idまたはexperimentIdが-1である可能性のあるケース(デフォルトバリエーションを示す)を、コードが処理することを確認してください。- バリエーションに変数が関連付けられていない場合、
variablesマップは空である可能性があります。
Variable
Variable には、割り当てられたバリエーションに関連付けられた変数に関する情報が含まれます。
非推奨メソッド
getFeatureVariationKey()
- 📨 トラッキングデータを Kameleoon に送信します
代わりに
getVariation() を使用してください。featureKey を受け取ります。
訪問者がこの機能フラグに関連付けられたことがない場合、SDK はランダムに割り当てられたバリエーションキー(機能フラグルールに従って)を返します。訪問者がすでにこの機能フラグに登録されている場合、このメソッドは以前のバリエーションキーを返します。訪問者がどのルールにも一致しない場合、Kameleoon アプリで定義したデフォルトバリエーションが返されます。
潜在的なエラーをキャッチするため、サンプルコードに示されているように適切なエラー処理を設定してください。
getActiveFeatureList()
代わりに
getVariations() を使用してください。戻り値
getActiveFeatures()
代わりに
getVariations() を使用してください。getActiveFeatures メソッドは、指定された訪問者コードで利用可能なアクティブな機能フラグに関する情報を取得します。
戻り値
getFeatureVariable()
- 📨 トラッキングデータを Kameleoon に送信します
- 代わりに
getVariation()を使用してください。 - このメソッドは以前
obtainFeatureVariable()という名前で、SDK バージョン4.0.0で削除されました。
featureKey と variableKey を受け取ります。
訪問者がこの機能フラグに関連付けられたことがない場合、SDK は機能フラグルールに従ってランダムに割り当てるバリエーションキーの変数値を返します。ユーザーがすでにこの機能フラグに登録されている場合、SDK は以前に関連付けられたバリエーションの変数値を返します。ユーザーがどのルールにも一致しない場合、デフォルトの変数が返されます。
引数
戻り値
スローされるエラー
getFeatureVariationVariables()
- 代わりに
getVariation()を使用してください。 - このメソッドは以前
getFeatureAllVariablesという名前で、SDK バージョン4.0.0で削除されました。
featureKey を受け取ります。Web インターフェースで定義された [String: Any] 型のデータを返します。要求された機能が SDK の内部構成内で見つからなかった場合、例外(KameleoonError.Feature.notFound)をスローします。