Adobe Target の仕組み

Adobe Target の仕組みを学びます。これには、Adobe Experience Platform Web SDK および JavaScript ライブラリ(at.js と mbox.js)に関する情報も含まれます。この記事では、Target を使用して作成できる様々なアクティビティタイプについても紹介します。また、Target エッジネットワーク、検索エンジン最適化(SEO)、および Target によるボットの検出方法についても説明します。

Target Platform Web SDK および JavaScript ライブラリ

Target Web サイトとの統合(Experience Platform Web SDK または JavaScript ライブラリを使用):

  • Adobe Experience Platform Web SDK:Experience Platform Web SDK は、新しいクライアント側 JavaScript ライブラリです。The Experience Platform Web SDK を使用すると、Adobe Experience Cloud のお客様は、Experience Platform Edge ネットワークを介して、Experience Cloud の様々なサービス(Target など)を操作できます。Adobe では、新しい Target ユーザー全員に、Experience Platform Web SDK を実装することを推奨します。
  • at.js: at.js ライブラリは、Target の新しい実装ライブラリです。at.js ライブラリは、Web 実装のページ読み込み時間を改善し、シングルページアプリケーション向けのより優れた実装オプションを提供します。at.js は、頻繁にアップデートされ、新しい機能が追加されます。Adobe では、at.js を使用するすべてのお客様に、実装を最新バージョンの at.js にアップデートすることをお勧めします。
  • mbox.js: mbox.js library ライブラリは、Target のレガシー実装ライブラリです。mbox.js ライブラリは、2021年3月31日(PT)以降はサポートされなくなります。

サイトの各ページの Experience Platform Web SDK または at.js を参照します。例えば、グローバルヘッダーにこれらのライブラリのいずれかを追加できます。または、Adobe Experience Platform のタグを使用して Target を実装することを検討してください。

次のリソースには、Experience Platform Web SDK または at.js の実装に役立つ詳細情報が含まれています。

訪問者が Target 用に最適化されたページをリクエストするたびに、リクエストがターゲティングシステムに送信されます。このリクエストは、その訪問者に提供するコンテンツを決定するのに役立ちます。このプロセスはリアルタイムで発生します。ページが読み込まれるたびに、コンテンツへのリクエストが作成され、システムで処理されます。コンテンツは、マーケティング担当者が制御するアクティビティおよびエクスペリエンスのルールによって管理され、個々のサイト訪問者がターゲットになります。各サイト訪問者が最も反応する、インタラクションをおこなう、または最終的に購入する可能性が最も高いコンテンツが提供されます。コンテンツをパーソナライズすることで、応答率、獲得率および売上高を最大化できます。

Target では、ページ上の各要素は、ページ全体に広がる単一のエクスペリエンスの一部です。各エクスペリエンスには、ページ上の複数の要素が含まれている可能性があります。

訪問者に表示されるコンテンツは、作成するアクティビティタイプによって異なります。

A/B テスト

基本的な A/B テストで表示されるコンテンツは、アクティビティに割り当てたエクスペリエンスからランダムに選択されます。各エクスペリエンスにトラフィック配分の割合を割り当てることができます。このランダムなトラフィック分割の結果、トラフィックの割合が均等化するまでの初期のトラフィック量が多くなる場合があります。例えば、2 つのエクスペリエンスを作成した場合、最初のエクスペリエンスはランダムに選択されます。トラフィック量がほとんどない場合は、訪問者の割合が一方のエクスペリエンスに偏っている可能性があります。トラフィックが増えるにしたがって、割合は等しくなります。

エクスペリエンスごとに割合のターゲットを指定できます。この場合、乱数が生成され、その乱数を使用して、表示するエクスペリエンスが選択されます。結果の割合が指定したターゲットと完全に一致しないこともありますが、トラフィックが多いほど、エクスペリエンスがターゲットに近い割合で分割されます。

  1. 訪問者が、サーバー上のページをリクエストしてブラウザーに表示します。
  2. 訪問者のブラウザー内にファーストパーティ Cookie が設定され、訪問者行動を保存します。
  3. ページから、ターゲット設定システムが呼び出されます。
  4. アクティビティのルールに基づいてコンテンツが表示されます。

詳細については、「A/B テストの作成」を参照してください。

自動配分

自動配分は、2 つ以上のエクスペリエンスのうちの勝者を識別します。自動配分は、より多くのトラフィックを勝者エクスペリエンスに自動的に再割り当てするので、テストの実行と学習を継続しながらコンバージョンを増やすのに役立ちます。

詳細については、「自動配分」を参照してください。

自動ターゲット(AT)

自動ターゲットでは、高度な機械学習を使用して、パフォーマンスの高い複数のマーケティング担当者が定義したエクスペリエンスから選択します。自動ターゲットは、各訪問者に最適なエクスペリエンスを提供します。エクスペリエンスの配信は、個々の顧客プロファイルと、類似のプロファイルを持つ以前の訪問者の行動に基づきます。自動ターゲットを使用して、コンテンツをパーソナライズし、コンバージョンを促進します。

詳細については、「自動ターゲット」を参照してください。

自動パーソナライゼーション(AP)

Automated Personalization(AP)は、オファーやメッセージを組み合わせ、高度な機械学習を使用して各訪問者のオファーのバリエーションを一致させます。エクスペリエンスの配信は、個別の顧客プロファイルに基づき、コンテンツをパーソナライズしてリフトを促します。

詳しくは、Automated Personalizationを参照してください。

エクスペリエンスのターゲット設定(XT)

エクスペリエンスのターゲット設定(XT)では、マーケティング担当者が定義した一連のルールや条件を基にして、特定のオーディエンスにコンテンツを配信します。

エクスペリエンスのターゲット設定(ジオターゲティングを含む)は、特定のオーディエンスに特定のエクスペリエンスまたはコンテンツをターゲット設定するルールを定義する際に有効です。アクティビティで複数のルールを定義して、様々なオーディエンスに異なるコンテンツのバリエーションを提供します。訪問者がサイトを表示すると、エクスペリエンスのターゲット設定(XT)は、その訪問者を評価して、設定した条件を満たしているかどうかを判断します。条件に一致した場合、その訪問者はアクティビティに組み込まれて、条件が一致したオーディエンス用に設計されたエクスペリエンスが表示されます。単一のアクティビティ内で、複数のオーディエンスに対してエクスペリエンスを作成できます。

詳しくは、エクスペリエンスのターゲット設定を参照してください。

多変量分析テスト (MVT)

Multivariate Testing(MVT)はページ上の各要素のオファーの組み合わせを比較し、特定のオーディエンスに対して最も効果が高い組み合わMultivariate Testing せを特定します。MVT は、アクティビティの成功に最も影響を与える要素を特定するのに役立ちます。

詳しくは、多変量分析テストを参照してください。

Recommendations

Recommendations のアクティビティは、以前のユーザーアクティビティまたはその他のアルゴリズムを基にして、顧客が興味を持つ可能性のある製品またはコンテンツを自動的に表示します。Recommendations により、顧客が関心を持ちそうな商品を積極的に紹介することが可能になります。

詳細については、「Recommendations 」を参照してください。

エッジネットワーク

「エッジ」は、コンテンツをリクエストするエンドユーザーが世界中のどこにいても、最適な応答時間を確保できる、地理的に分散された配信アーキテクチャです。

応答時間を改善するために、Target Edge はアクティビティロジック、キャッシュされたプロファイル、およびオファー情報のみをホストします。

アクティビティおよびコンテンツのデータベース、Analytics データ、API、およびマーケティング担当者向けのユーザーインターフェイスは、アドビの中央クラスターに格納されます。その後、最新情報が Target Edge に送信されます。中央クラスターとエッジクラスターは自動的に同期され、キャッシュされたアクティビティデータが継続的に更新されます。また、1:1 モデリングが各エッジに保存されるので、複雑なリクエストもエッジ上で処理できます。

各エッジクラスターには、訪問者のコンテンツリクエストに応答し、そのリクエストに関する分析データを追跡するために必要な情報がすべて格納されます。ユーザーリクエストは最寄りのエッジクラスターに送信されます。

詳しくは、『Adobe Target Security Overview』ホワイトペーパーを参照してください。

Target ソリューションは、世界中のアドビが所有するデータセンターおよびアドビがリース契約を結んでいるデータセンターでホストされています。

管理サーバー拠点には、データ収集センターとデータ処理センターの両方が設置されています。エッジクラスター拠点には、データ収集センターのみが設置されています。個々のレポートスイートは特定のデータ処理センターに割り当てられています。

顧客サイトのアクティビティデータは、最も近い 7 か所のエッジクラスターによって収集されます。このデータは、お客様が事前に決定した中央クラスター(オレゴン、ダブリン、シンガポールのいずれか)に送られ、そこで処理されます。訪問者プロファイルデータは、サイト訪問者に最も近いエッジクラスターに保存されます。エッジクラスター拠点には、中央クラスター拠点と、バージニア、ムンバイ、シドニー、東京が含まれます。

1 か所ですべてのターゲティングリクエストに応答するのではなく、訪問者に最も近いエッジクラスターでリクエストを処理します。このプロセスにより、ネットワークやインターネットでの通信時間の影響を緩和できます。

各種のターゲットサーバーを示すマップ

Target 中央クラスターは、以下を含む、Amazon ウェブサービス(AWS)でホストされています。

  • オレゴン(米国)
  • ダブリン(アイルランド)
  • シンガポール共和国

AWS でホストされる Target のエッジクラスターには、以下が含まれます。

  • ムンバイ(インド)
  • 東京(日本)
  • バージニア(米国)
  • オレゴン(米国)
  • シドニー(オーストラリア)
  • ダブリン(アイルランド)
  • シンガポール共和国

Target Recommendations サービスはオレゴンの Adobe データセンターでホストされています。

重要

Adobe Target では現在、中国にはエッジクラスターを持っていません。中国の Target のお客様には、訪問者パフォーマンスは引き続き制限されます。国内のファイアウォールとエッジクラスターが不足しているため、Target がデプロイされたサイトのエクスペリエンスに影響が及ぶ可能性があります。エクスペリエンスのレンダリング速度が低下し、ページの読み込みに影響する可能性があります。また、マーケティング担当者が、Target のオーサリング UI を使用する際に遅延が発生することがあります。

必要に応じて、Target のエッジクラスターを許可リストに追加できます。詳しくは、Target のエッジノードを許可リストに登録するを参照してください。

ユーザーエクスペリエンスの保護

アドビは、ターゲット設定インフラストラクチャの可用性とパフォーマンスが可能な限り安定するようにしています。ただし、エンドユーザーのブラウザーとアドビのサーバー間の通信が切断されると、コンテンツ配信が中断される可能性があります。

サービスの中断や接続の問題を防ぐために、すべての場所は、デフォルトコンテンツ(クライアントが定義)を含めるように設定されています。このデフォルトコンテンツは、ユーザーのブラウザーが Target に接続できない場合に表示されます。

ユーザーのブラウザーが、定義されたタイムアウト時間(デフォルトは 15 秒)以内に接続できない場合は、ページは変更されず、デフォルトのままになります。このタイムアウトのしきい値に達した場合、デフォルトの場所のコンテンツが表示されます。

アドビは、パフォーマンスの最適化と保護によってユーザーエクスペリエンスを保護しています。

  • アドビは、業界標準に基づいたパフォーマンスベンチマークを実施しており、このベンチマークはアドビのサービス契約によって保証されています。
  • Edge ネットワークによって、タイムリーなデータ配信を実現しています。
  • アプリケーションをセキュリティ保護するための多層型アプローチを使用し、お客様に対して最高レベルの可用性と信頼性を確保しています。
  • Target コンサルティングは、導入支援と継続的な製品サポートをおこなっています。

検索エンジン最適化(SEO)対応テスト

Adobe Target はテストのための検索エンジンガイドラインに従っています。

Google はユーザーに対し、テストを推奨しています。Google はドキュメントの中で、A/B と多変量分析テスト(Multivariate Testing)が、特定のガイドラインに従ってもオーガニック検索エンジンのランキングは損なわれないと述べています。

詳しくは、次の Google のリソースを参照してください。

ガイドラインはGoogle ウェブマスター向け公式ブログの投稿として公表されています。この投稿は 2012 年のものですが、この問題に関する Google からの最新の発言であり、ガイドラインは現在でも通用します。

  • クロークなし:クロークとは、ユーザーに対して1 連のコンテンツを表示し、検索エンジンボットには別のコンテンツを表示することです。クロークは、ボットを特別に識別し、異なるコンテンツを意図的にフィードすることで実行されます。

    Target は、プラットフォームとしては検索エンジンボットを他のユーザーと同様に扱うよう設定されています。その結果、ボットがランダムに選択され、テストのバリエーションを「確認」した場合、そのボットをアクティビティに含めることができます。

  • rel=“canonical” を使用する:バリエーションを付けるために、異なる URL を使用して A/B テストを設定する必要が出ることがあります。これらの場合、元来の(コントロール)URL を参照する rel="canonical" タグをすべてのバリエーションに含ませます。例えば、Adobe がバリエーションごとに異なる URL を使用してホームページをテストするとします。ホームページの次の canonical タグは、各バリエーションの <head> タグ内に配置されます。

    <link rel="canonical" href="https://www.adobe.com" />

  • 302(一時的な)リダイレクトを使う:テストでバリエーションのページに異なる URL を使用する場合、Google では、302 リダイレクトを使用してトラフィックを直接テストバリエーションにリダイレクトすることを勧めています。302リダイレクトは、リダイレクトが一時的であり、テストが実行中の間のみアクティブとなることを検索エンジンに通知します。

    302 リダイレクトは、サーバーサイドのリダイレクトであり、Target は他の大多数の最適化プロバイダーと同様、クライアントサイドの機能を使用します。このため、リダイレクトは Target が Google の推奨事項に完全に準拠していない領域になります。ただし、これが影響するのは、ほんの一部のテストのみです。Target でテストを実行するための標準的なアプローチでは、1 つの URL 内でコンテンツの変更を呼び出すため、リダイレクトの必要はありません。クライアントのテストバリエーションを表すように複数の URL を使う必要が出ることもあります。この場合、Targetは JavaScript window.location コマンドを使用します。このコマンドは、テストのバリエーションをユーザーに指示します。テストのバリエーションは、リダイレクトが 301 と 302 のどちらであるかを明示的に示しません。

    Adobe では、検索エンジンのガイドラインに完全に合致する実行可能なソリューションを引き続き探しています。テストに別々の URL を使用する必要があるクライアントの場合、Adobe は、正規タグを適切に実装することで、このアプローチに伴うリスクが軽減されると確信しています。

  • 実験は必要な期間にのみ実行する:Adobe では、「必要な期間」を統計的有意性に到達するまでの期間と考えます。Target は、テストがこの時点に到達した時を判断するためのベストプラクティスを提供します。Adobe では、勝者テストのハードコード実装をテストワークフローに組み込み、適切なリソースを割り当てることをお勧めします。

    Targetプラットフォームを使用して勝者テストを「公開」することは、恒久的なソリューションとしては推奨されません。勝者テストが 100% のユーザーに対して 100% の時間公開されている場合、このアプローチは、勝者テストをハードコーディングするプロセスが完了している間使用できます。

    テストが変更した点に留意することも大切です。単純にページ上のボタンの色や、その他の文字ベースでない小さなアイテムを更新しても、オーガニックランキングには大きな影響はありません。ただし、文字の変更はハードコードする必要があります。

    テストしているページへのアクセスのしやすさに留意することも大切です。検索エンジンからアクセスできず、オーガニック検索でランク付けするように設計されていないページの場合は、上記の考慮事項は一切適用されません。例えば、電子メールキャンペーン専用のランディングページがあります。

Google によると、これらのガイドラインに従えば、「テストがサイトの検索結果に及ぼす影響はほとんどあるいはまったくない。」とのことです。

これらのガイドラインに加えて、Google はまた、Content Experiments ツールのドキュメンテーションでもう 1 つのガイドラインを提供しています。

  • 「バリエーションの各ページは、元来のページ内容の主旨を保持する必要があります。こういったバリエーションは、元来の内容に対しユーザーが持つ全般的イメージを変えてはいけません。」

Google は例として、「ユーザーに表示される組み合わせに関連しないキーワードでサイトの元来のページが読み込まれる場合、そのサイトを Google のインデックスから外すことがあります」と記述しています。

Adobe は、テストのバリエーション内で意図せず元のコンテンツの意味を変更するのは難しいと感じています。ただし、Adobe では、ページのキーワードテーマを認識し、それらのテーマを維持することをお勧めします。ページ内容を変更、特に関連のあるキーワードを追加したり削除したりすると、自然検索でのその URL のランキングが変わってしまう場合があります。また、テストプロトコルの一部として、SEO パートナーに協力を仰ぐことをお勧めします。

ボット

Adobe Target は、DeviceAtlas 指標「isRobot」を使用し、リクエストヘッダーで渡されたユーザーエージェント文字列に基づいて既知のボットを検出します。

メモ

Server-Side リクエストの場合、リクエストの「コンテキスト」ノードに渡された値は、ボット検出用のユーザーエージェント文字列よりも優先されます。

ボットによって生成されたと識別されたトラフィックには、引き続きコンテンツが提供されます。ボットは通常のユーザーと同様に扱われ、Target が SEO ガイドラインに従っていることを確認します。ボットトラフィックの使用は、通常のユーザーのように扱われると、A/B テストやパーソナライゼーションアルゴリズムをゆがめる可能性があります。したがって、Target アクティビティで既知のボットが検出されると、そのトラフィックの処理はわずかに異なります。ボットトラフィックを削除することで、ユーザーアクティビティをより正確に測定できます。

特に、既知のボットトラフィックの場合、Target は以下をおこないません。

  • 訪問者プロファイルの作成または取得
  • プロファイル属性の記録またはプロファイルスクリプトの実行
  • Adobe Audience Manager(AAM)セグメントの検索(該当する場合)
  • Recommendations、自動ターゲット、Automated Personalization または自動配分の各アクティビティにおけるパーソナライズされたコンテンツのモデリングおよび提供時のボットトラフィックの使用
  • レポート用のアクティビティ訪問の記録
  • Adobe Experience Cloud プラットフォームに送信されたログデータ

このページ