Kameleoon Command Queue
KameleoonのAPIとやり取りする最も効率的な方法は、ゴールのコンバート、カスタムデータの設定、イベントのトリガー のいずれにおいても、タグマネージャー(例: Google Tag Manager)の既存のトリガーと Kameleoon Command Queue を組み合わせて活用することです。これは、Kameleoonに JavaScript を追加する際の主要なアプローチとすべきです。Kameleoon に長い JavaScript コードを直接書く代わりに、タグマネージャー内のたった2行のコードで同じ結果を得ることができます。例
- 売上ゴールをコンバートする タグマネージャーで、確認ページに売上を取得するトリガーを作成し、以下のコードを追加します:kameleoonQueue を利用できない場合は、以下で詳述する各利用可能なスクリプトに対する具体的な推奨事項を参照してください。
グローバルスクリプト & バリエーションスクリプト
Activation API で JavaScript の実行を最適化する
Kameleoon の Activation API を活用して、適切なタイミングでバリエーションを適用します。このアプローチは、パフォーマンスの問題を防ぎ、訪問者にシームレスな体験を提供するのに役立ちます。 以下は、訪問者体験を向上させるために使用できる Activation API の重要な関数です:runWhenConditionTrue: 特定の条件が満たされたときにコードを実行します。デフォルトでは200ミリ秒ごとに実行されます。ただし、決して解決されない可能性のある条件には注意してください。不要なループにつながる可能性があります。関数が明示的にtrueを返すまでループは継続することに注意してください。falseやundefinedを返してもループは停止せず、コールバックもトリガーされません。
true が返されることはなく、ループが無限に実行されます:
ページタイプに関する情報を取得しようとするときなど、
dataLayer や遅延読み込みされる他のオブジェクトを待つために runWhenConditionTrue に依存するよりも、URL や Cookie/localStorage を使って情報を取得する方が望ましいです。このアプローチにより、より高速な実行とより良いパフォーマンスが保証されます。runWhenElementPresent: このメソッドは、特定の要素がDOMに存在する場合にのみコードが実行されるようにし、動的に読み込まれる要素による不要な遅延を回避します。
重要な考慮事項
- デフォルトで Mutation Observer を使用します(パフォーマンスのため推奨)。
- サイトで Mutation Observer が無効になっている場合は、このメソッドの第3引数としてポーリング間隔を指定できます。
- 要素が DOM に動的に挿入される場合は、このメソッドの第4引数として
isDynamicElementをtrueに設定します:
コードのスコープを特定のページに設定する
パフォーマンスを最適化するため、コードが関連するページでのみ実行されるようにしてください。これはrunWhenConditionTrue や runWhenElementPresent のようなループベースのメソッドを使用する場合に特に重要です。これらのメソッドをサイト全体で実行すると、不要な実行が発生してパフォーマンスに影響を与える可能性があります。たとえば、dataLayer で売上情報を待つ場合は、URLが確認ページに対応しているかをチェックする条件でコードをラップしてください。このアプローチにより、コードがサイト全体でトリガーされるのではなく、確認ページでのみ実行されることが保証されます。
例: ループを実行する前に特定の確認ページをターゲティングする
3. 視覚的な変更には JavaScript ではなく CSS を優先する(特にスクリプト内のバリエーションを扱う場合)
JavaScript の代わりに CSS を使用すると、レンダリングがより速く、よりスムーズになります。CSS は要素の非表示や変更、ブロックの入れ替え、スタイルやテキストの変更に活用できます。シングルページアプリケーション(SPA)の処理
シングルページアプリケーション(SPA)や動的に更新されるページ上で実験を実行する場合、特定の実装手順が必要です。従来のウェブサイトとは異なり、SPA はページ全体をリロードしないため、Kameleoon はコンテンツの更新がいつ起こるかを識別する必要があります。ベストプラクティスについては、シングルページアプリケーションでの実験のセットアップに関する ガイド を参照してください。セグメント / トリガー
最初のベストプラクティスは、ページの読み込み時に即座に利用可能なデータに基づいてターゲティングを行うことです。これには、ページのURL、ブラウザのタイプ、デバイスのタイプ、Cookie やローカルストレージに保存されているデータなどの情報が含まれます。 ターゲティングが即座にアクセスできないデータを必要とする場合は、効率的な実行を保証し、不要な遅延を避けるために以下のガイドラインに従ってください。1. カスタム JavaScript 条件
この条件では、カスタム JavaScript を使用して訪問者をターゲティングできます。主に2つのオプションがあります: ####- a. 条件をすぐにチェックする このスクリプトは、DOM が完全に読み込まれる前は75ミリ秒ごとに、その後は250ミリ秒ごとに実行されます。デフォルトではundefined を返し、明示的に true(訪問者を含める)または false(訪問者を除外する)を返すまでスクリプトはループ内で実行され続けます。不要なループを防ぐため、条件が最終的に true または false に解決されることを必ず確認してください。最適化された例は以下のとおりです:
- 特定の要素をターゲティングしたい場合は、代わりにネイティブの条件「ページ上の要素」を使用してください。
- ページ上の情報を待ちたい場合は、上記の「条件をすぐにチェック」オプションを使用してください。
2. カスタムイベント
カスタムイベントの使用は、訪問者をターゲティングする効果的でパッシブな方法です。条件を継続的に監視するのではなく、定義した特定のカスタムイベントをリッスンし、そのイベントが発生したときにターゲティングをトリガーします。このアプローチは、特に以下の2つの主要なシナリオで有用です:シナリオ1: ターゲティングロジックが複雑な場合
すべてのロジックをターゲティング内の JavaScript 条件に直接埋め込むことは避けた方が良いです。代わりに、グローバルスクリプトでカスタムイベントを定義できます。たとえば、カート内に少なくとも3つの商品があり、合計金額が30ドルを超えるカートページの訪問者をターゲティングしたい場合、JavaScript セグメント条件内にすべてのロジックを書く代わりに、これらの条件が満たされたときにグローバルスクリプトでイベントをトリガーします。シナリオ2: 複数のセグメントが類似のロジックを共有する場合
複数のセグメントが同じ条件、またはわずかに異なるバリエーションの同じ条件を必要とする場合、カスタムイベントを使用することで冗長なコードを防ぎ、保守性を高めます。 例: 異なるカート金額に基づいて訪問者をターゲティングする必要があります。複数のセグメントでロジックを重複させる代わりに、グローバルスクリプトで単一のスクリプトを定義し、各セグメントに対して異なるカスタムイベントをトリガーします:カスタムデータ
カスタムデータは、カスタムイベントと同様に、値を保存して再利用できるようにすることで重複コードを防ぐのに役立ちます。グローバルスクリプトや他のスクリプトでカスタムデータを定義し、セグメント内で利用できます。ただし、カスタムデータは2つの重要な点でカスタムイベントと異なります:a. スコープオプション: 「ページ」、「訪問」、または「訪問者」
現在のページにのみ適用される カスタムイベント とは異なり、カスタムデータは複数のページとセッションにわたって持続できます:- 訪問スコープ: 訪問者のセッション全体で値を保持します。
- 訪問者スコープ: Cookie ポリシーに応じて、最大365日間値を保存します。