Adobe Target の仕組み
JavaScript ライブラリ(Adobe Experience Platform Web SDK および at.js)の詳細など、Adobe Target の仕組みを説明します。 この記事では、ユーザーが作成できる様々なアクティビティタイプ、Target 用数カウント戦略、Target Edge Network、SEO およびボット検出についても説明します。
主なポイント:
- JavaScript ライブラリ: Target JavaScript ライブラリの詳細:Adobe Experience Platform Web SDK および at.js。
- サーバーコールの使用戦略:エンドポイント、単一の mbox、バッチ mbox、実行、プリフェッチ、通知の呼び出しなど、様々なサーバーコールの数 Target を把握します。
- Edge Network: Target が Adobe Experience Platform Edge Network とどのようにやり取りするかを確認します。
- 保護されたユーザーエクスペリエンス:Adobe がターゲティングインフラストラクチャの可用性とパフォーマンスを確保する方法について説明します。
- SEO ガイドライン:Target アクティビティを SEO ガイドラインに合わせるためのベストプラクティスに従います。
- ボットトラフィック:テストやパーソナライゼーションアルゴリズムのゆがみを回避するために Target がボットトラフィックを処理する方法を説明します。
Adobe Target JavaScript ライブラリ
Target と web サイトの統合(Experience Platform Web SDK または at.js を使用):
- Adobe Experience Platform Web SDK:このクライアントサイド JavaScript ライブラリを使用すると、Adobe Experience Cloud のお客様は Experience Platform Edge Network を通じて様々なサービスを操作できます。 Adobe では、新規の Target ユーザーに Experience Platform Web SDK を実装することをお勧めします。
- at.js:Target 用のこの実装ライブラリは、web 実装のページ読み込み時間を改善し、単一ページアプリケーション向けのより優れたオプションを提供します。 新機能を使用して頻繁に更新される Adobe、すべての at.js ユーザーを最新バージョンにアップデートすることをお勧めします。
サイトの各ページの Experience Platform Web SDK または at.js を参照します。 例えば、グローバルヘッダーにこれらのライブラリのいずれかを追加します。 または、Adobe Experience Platformのタグを使用して Target を実装します。
次のリソースには、Experience Platform Web SDK または at.js の実装に役立つ詳細情報が含まれています。
訪問者が Target 用に最適化されたページをリクエストするたびに、ターゲティングシステムにリアルタイムリクエストが送信され、提供するコンテンツが決定されます。 このリクエストは、マーケターが制御するアクティビティやエクスペリエンスの管理の下で、ページが読み込まれるたびに行われ、実行されます。 コンテンツは、個々のサイト訪問者をターゲットにし、応答率、獲得率、売上高を最大化します。 パーソナライズされたコンテンツは、訪問者の反応、インタラクション、購入を保証するのに役立ちます。
ま Target、ページ上の各要素は、複数の要素を含めることができる単一のエクスペリエンスの一部です。
表示されるコンテンツは、作成するアクティビティのタイプによって異なります。
A/B Test
基本的な A/B テストでは、コンテンツは割り当てられたエクスペリエンスからランダムに選択されます。 各エクスペリエンスにトラフィック配分の割合を設定できます。 最初は、ランダムな分割によってトラフィックが不均等に分散される可能性がありますが、トラフィックが増加するとイコライズされます。 例えば、2 つのエクスペリエンスを使用する場合、開始エクスペリエンスはランダムに選択されます。 低トラフィックは 1 つのエクスペリエンスに対して訪問者の割合をゆがめる可能性がありますが、この状況は多トラフィックでバランスします。
各エクスペリエンスの割合のターゲットを指定します。 表示するエクスペリエンスを選択する乱数が生成されます。 結果の割合は、ターゲットと完全には一致しない場合がありますが、トラフィックが多いほど、ターゲット目標に対する割合が近くなります。
- 顧客が、サーバーからページをリクエストして、ブラウザーに表示します。
- ファーストパーティ cookie は、顧客のブラウザーに設定され、行動を保存します。
- ページから、ターゲット設定システムが呼び出されます。
- コンテンツは、アクティビティルールに基づいて表示されます。
詳細については、「A/B テストの作成」を参照してください。
Auto-Allocate
Auto-Allocate は、2 つ以上のオプションの中から勝者エクスペリエンスを識別します。 その後、より多くのトラフィックを勝者に自動的に再割り当てし、テストの実行と学習を継続しながらコンバージョンを増やします。
詳細は、Auto-Allocate を参照してください。
Auto-Target (時)
Auto-Target は、高度な機械学習を活用して、パフォーマンスの高い複数のマーケターが定義したエクスペリエンスから選択します。 Auto-Target は、個々の顧客プロファイルと類似のプロファイルを持つ以前の訪問者の行動に基づいて、各訪問者に最適なエクスペリエンスを提供します。 Auto-Target を使用してコンテンツをパーソナライズし、コンバージョンを促進します。
詳細については、自動ターゲットを参照してください。
Automated Personalization (AP)
Automated Personalization (AP)は、オファーやメッセージを組み合わせ、高度な機械学習を使用して各訪問者にマッチする様々なバリエーションを提供します。 AP は、個人の顧客プロファイルに基づいてコンテンツをパーソナライズし、上昇率を高めます。
詳しくは、Automated Personalizationを参照してください。
Experience Targeting (XT)
Experience Targeting (XT)では、マーケターが定義したルールや条件を基にして、特定のオーディエンスにコンテンツを配信します。 ジオターゲティングを含め、XT は、特定のオーディエンスに特定のエクスペリエンスやコンテンツをターゲット設定するルールを定義する際に役立ちます。 アクティビティで複数のルールを設定して、様々なオーディエンスに異なるコンテンツのバリエーションを提供します。 訪問者がサイトを表示すると、XT は訪問者を評価して、条件を満たしているかどうかを判断します。 選定されると、アクティビティにエントリし、向けに設計されたエクスペリエンスを確認します。 単一のアクティビティ内で、複数のオーディエンスに対してエクスペリエンスを作成できます。
詳しくは、エクスペリエンスのターゲット設定を参照してください。
Multivariate Test (MVT)
Multivariate Testing (MVT)はページ要素内のオファーの組み合わせを比較し、特定のオーディエンスに対して最も効果が高い組み合わせを特定します。 MVT は、アクティビティの成功に最も影響を与える要素を特定するのに役立ちます。
詳しくは、多変量分析テストを参照してください。
Recommendations
Recommendations のアクティビティは、以前のアクティビティやその他のアルゴリズムを基にして、顧客が興味を持つ可能性のある製品やコンテンツを自動的に表示します。 Recommendations により、顧客が関心を持つ商品を積極的に紹介することが可能になります。
詳細については、Recommendations を参照してください。
Target がサーバーコールの使用状況をカウントする方法
Target は、顧客に価値を提供するサーバー呼び出しのみをカウントします。 次の表に、エンドポイント、単一の mbox、バッチ mbox 呼び出し、実行、プリフェッチおよび通知呼び出しの Target のカウント方法を示します。
次の表に示すように、次の情報は、サーバー呼び出し Target 使用されるカウント方法を理解するのに役立ちます。
- 1 回カウント:API 呼び出しごとに 1 回カウントされます。
- mbox の数をカウント:単一の API 呼び出しのペイロード内の配列の下にある mbox の数をカウントします。
- 無視:まったくカウントされません。
- ビュー数をカウント(1 回):ペイロード内の配列の下のビューの数をカウントします。 通常の実装では、ビュー通知の通知配列の下には 1 つのビューしかなく、これはほとんどの実装で 1 回カウントするのと同等になります。
rest//v1/mbox
rest/v2/batchmbox
/ubox/[raw|image|page]
rest/v1/delivery
/rest/v1/target-upstream
エッジネットワーク
「Edge」は、コンテンツをリクエストする訪問者の場所に関係なく、最適な応答時間を確保する、地理的に分散された配信アーキテクチャです。
応答時間を改善するために、Target Edge はアクティビティロジック、キャッシュされたプロファイル、およびオファー情報のみをホストします。
アクティビティおよびコンテンツのデータベース、Analytics データ、API およびマーケター向けのユーザーインターフェイスは、Adobe 中央クラスターに格納されます。 アップデートは Target Edge に送信され、中央クラスターと自動的に同期されて、キャッシュされたアクティビティデータが継続的に更新されます。 また、1:1 モデリングがすべて各エッジに保存されるので、複雑なリクエストをローカルで処理できます。
各Edge クラスターには、訪問者のコンテンツリクエストに対応し、分析データを追跡するために必要なすべての情報が含まれています。 訪問者のリクエストは、最寄りのエッジクラスターに転送されます。
詳しくは、『Adobe Target セキュリティの概要』ホワイトペーパーを参照してください。
Target は、世界中のAdobeが所有するデータセンターおよびAdobeがリース契約を結んでいるデータセンターでホストされています。
中央クラスターの場所には、データ収集センターとデータ処理センターの両方が格納されています。 Edge クラスターの場所には、データ収集センターのみが含まれています。 個々のレポートスイートは特定のデータ処理センターに割り当てられています。
お客様のサイトのアクティビティデータは、最も近い 7 つのEdge クラスターによって収集されます。 その後、このデータは、事前に決定された中央クラスター(オレゴン、ダブリンまたはシンガポール)に送られ、処理されます。 訪問者プロファイルデータは、サイト訪問者に最も近いエッジクラスターに保存されます。Edgeクラスター拠点には、中央クラスター拠点のほか、バージニア、ムンバイ、シドニー、東京が含まれます。
すべてのターゲティングリクエストを 1 か所で処理する代わりに、訪問者に最も近いEdge クラスターでリクエストを処理します。 このアプローチは、ネットワークとインターネットの移動時間の影響を軽減します。
Target 中央クラスターは、以下を含む、Amazon ウェブサービス(AWS)でホストされています。
- オレゴン(米国)
- ダブリン(アイルランド)
- シンガポール共和国
AWS でホストされる Target のエッジクラスターには、以下が含まれます。
- ムンバイ(インド)
- 東京(日本)
- バージニア(米国)
- オレゴン(米国)
- シドニー(オーストラリア)
- ダブリン(アイルランド)
- シンガポール共和国
Target Recommendations サービスはオレゴンの Adobe データセンターでホストされています。
必要に応じて、Target のエッジクラスターを許可リストに追加できます。詳しくは、Target のエッジノードを許可リストに加えるを参照してください。
ユーザーエクスペリエンスの保護
Adobe は、ターゲット設定インフラストラクチャの可用性とパフォーマンスの可能な限りの安定を確保しています。 ただし、訪問者のブラウザーと Adobe サーバー間の通信が切断されると、コンテンツ配信が中断される可能性があります。
サービスの中断や接続の問題を防ぐために、すべての場所は、デフォルトコンテンツ(クライアントが定義)を含めるように設定されています。このデフォルトコンテンツは、訪問者のブラウザーが Target に接続できない場合に表示されます。
訪問者のブラウザーが、定義されたタイムアウト期間(デフォルト:15 秒)以内に接続できない場合は、ページは変更されません。 このタイムアウトのしきい値に達した場合、デフォルトの場所のコンテンツが表示されます。
Adobe は、パフォーマンスを最適化し、安全性を保つことで、ユーザーエクスペリエンスを保護します。
- Adobe は、Adobe Service Level Agreement が保証する業界標準に基づくパフォーマンスベンチマークを保証します。
- エッジネットワークによって、タイムリーなデータ配信を実現しています。
- Adobe では、アプリケーションを保護するための多層型アプローチを採用し、お客様に対して最高レベルの可用性と信頼性を提供しています。
- Target コンサルティングは、導入支援と継続的な製品サポートを行っています。
検索エンジン最適化(SEO)対応テスト
Adobe Target はテストのための検索エンジンガイドラインに従っています。 Google は、ユーザーのテストを推奨し、特定のガイドラインに従っている場合は、A/B および Multivariate Testing がオーガニック検索エンジンのランキングに悪影響を与えないことを宣言します。
Adobe Target はテストのための検索エンジンガイドラインに従っています。
詳しくは、次の Google のリソースを参照してください。
ガイドラインはGoogle ウェブマスター向け公式ブログの投稿として公表されています。この投稿は 2012 年のものですが、この問題に関する Google の最新の発言であり、ガイドラインはまだ関連性があります。
-
クロークなし:クロークでは、ユーザーに対して一連のコンテンツを表示し、ボットを特別に識別して異なるコンテンツをフィードすることで、検索エンジンボットに異なるコンテンツを表示します。
Target は、検索エンジンボットを他のユーザーと同様に扱うよう設定されています。 その結果、ボットがランダムに選択され、テストのバリエーションを「確認」した場合、アクティビティに含めることができます。
-
rel="canonical"を使用する:バリエーションを付けるために、A/B テストに異なる URL が必要な場合があります。 この場合、元の(コントロール) URL を参照する rel="canonical" タグをすべてのバリエーションに含める必要があります。 例え Adobe、各バリエーションに異なる URL を持つホームページをテストする場合、ホームページの次の正規タグを各バリエーションの
<head>
タグに配置する必要があります。<link rel="canonical" href="https://www.adobe.com" />
-
302 (一時的な)リダイレクトを使う:テストでバリエーションのページに異なる URL を使用する場合、302 リダイレクトを使用してトラフィックを直接テストバリエーションにリダイレクトすることを Google 勧めします。 302 リダイレクトは、リダイレクトが一時的で、テストの実行中にのみアクティブになることを検索エンジンに通知します。
302 リダイレクトはサーバーサイドのリダイレクトですが、Target とんどの最適化プロバイダーはクライアントサイドの機能を使用しています。 したがって、Target は、リダイレクトに関する Google の推奨事項に完全に準拠していません。 ただし、影響を受けるのはテストのごく一部に限られます。 Target でテストを実行するための標準的なアプローチでは、1 つの URL 内でコンテンツを変更するので、リダイレクトの必要がなくなります。 テストバリエーションに複数の URL が必要な場合、Target はJavaScript
window.location
コマンドを使用します。リダイレクトが 301 か 302 かを示すものではありません。Adobe は、検索エンジンガイドラインに完全に準拠するソリューションを積極的に探しています。 テスト用に別々の URL を必要とするクライアントの場合、Adobe では、正規タグを正しく実装することで、関連するリスクを軽減できると考えています。
-
実験を必要な期間のみ実行:Adobe では、「必要な期間」を統計的有意性に到達するために必要な時間として定義します。 Target には、テストがこの時点に到達したかどうかを判断するためのベストプラクティスと Adobe Target サンプルサイズ計算ツールが用意されています。 Adobe では、勝者テストのハードコード実装をテストワークフローに組み込み、適切なリソースを割り当てることをお勧めします。
Target を使用して勝者テストを「公開」することは、恒久的なソリューションとしては推奨されません。 勝者テストが常に 100% のユーザーに対して公開されている場合、このアプローチを一時的に使用して、勝者テストをハードコーディングできます。
テストが変更した点を考慮します。 ボタンの色などの小規模な更新も、オーガニックのランキングには影響しません。 ただし、テキストの変更はハードコードする必要があります。
また、テストするページのアクセシビリティも考慮してください。 検索エンジンからアクセスできず、オーガニック検索でランク付けすることを意図していないページの場合、これらの考慮事項は適用されません。 例えば、メールキャンペーン専用のランディングページがあります。
Google によると、これらのガイドラインに従えば、「テストがサイトの検索結果に及ぼす影響はほとんどあるいはまったくない。」とのことです。
これらのガイドラインに加えて、Google はまた、Content Experiments ツールのドキュメンテーションでもう 1 つのガイドラインを提供しています。
- 「バリエーションの各ページは、元来のページ内容の主旨を保持する必要があります。こういったバリエーションは、元来の内容に対しユーザーが持つ全般的イメージを変えてはいけません。」
Google は例として、「ユーザーに表示される組み合わせに関連しないキーワードでサイトの元来のページが読み込まれる場合、そのサイトを Google のインデックスから外すことがあります」と記述しています。
テストのバリエーション内 Adobe 意図せず元のコンテンツの意味を変更するのは難しいと感じています。 Adobe だし、ページのキーワードテーマに注意して、それらのテーマを維持することをお勧めします。 ページ内容を変更、特に関連のあるキーワードを追加したり削除したりすると、オーガニック検索でのその URL のランキングが変わってしまう場合があります。Adobe では、テストプロセスの一環として、SEO パートナーに協力を仰ぐことをお勧めします。
ボット
Target は、DeviceAtlas 指標「isRobot」を使用し、リクエストヘッダーで渡されたユーザーエージェント文字列に基づいて既知のボットを検出します。
ボット生成と識別されたトラフィックには、引き続きコンテンツが提供されます。 ボットは通常のユーザーと同様に扱われ、Target が SEO ガイドラインに従っていることを確認します。 ただし、ボットトラフィックは、通常のユーザーのように扱われると、A/B テストやパーソナライゼーションアルゴリズムをゆがめる可能性があります。 したがって、Target アクティビティにおける既知のボットトラフィックの扱いは異なります。 ボットトラフィックを削除すると、ユーザーアクティビティをより正確に測定できます。
既知のボットトラフィックの場合、Target は次を行いません。
- 訪問者プロファイルの作成または取得
- プロファイル属性のログまたはプロファイルスクリプトの実行
- Adobe Audience Manager(AAM)セグメントの検索(該当する場合)
- Recommendations、Auto-Target、Automated Personalization、Auto-Allocate の各アクティビティにおけるパーソナライズされたコンテンツのモデリングまたは提供時のボットトラフィックの使用
- レポート用のアクティビティ訪問の記録
- Adobe Experience Cloud プラットフォームに送信されたログデータ
既知のボットトラフィックの場合、Analytics for Target (A4T)を使用すると、Target は次を実行しません。
- Analytics にイベントを送信
既知のボットトラフィックに client_side
ログを使用する場合は、Target は次を返しません。
tnta payload