表示の問題や、 Adobe Target Visual Experience Composer (VEC) および 拡張 Experience Composer (EEC) を使用します。
次の Chrome リリースを使用する際の VEC と EEC に影響する変更点に注意してください。
次の変更は、以下に示す 3 つの更新すべてに影響します。
SameSite=None
および Secure
属性セット。Chrome 94(2021 年 9 月 22 日):Chrome 94 リリース(2021 年 9 月 22 日)に予定されている差し迫った変更により、次の変更が Chrome 94 以降のブラウザーバージョンを使用しているすべてのユーザーに影響します。
--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure
が削除されます。Chrome 91(2021 年 5 月 26 日):Chrome 91 リリース(2021 年 5 月 26 日)用に実装された変更点では、次の変更は Chrome 91 以降のブラウザーバージョンを使用するすべてのユーザーに影響します。
#same-site-by-default-cookies
および #cookies-without-same-site-must-be-secure
~から取り除かれた chrome://flags
. この動作は、デフォルトで有効になりました。Chrome 80(2020 年 8 月):2020 年 8 月に実装された変更により、Chrome 80 以降のブラウザーバージョンを持つすべてのユーザーは、次のようになります。
adobemc.com domain
. この属性がない場合、ブラウザーはこれらの Cookie を拒否し、EEC が失敗します。SameSite cookie の実施ポリシーが原因でブロックされた cookie を判断するには、Chrome の開発者ツールを使用します。
Chrome で VEC を表示した状態で開発者ツールにアクセスするには、 省略記号 Chrome の右上隅にあるアイコン > その他のツール > 開発者ツール.
次をクリック: ネットワーク タブをクリックして、ブロックされている cookie を探します。
以下を使用: Cookie をブロック済み チェックボックスをオンにして、ブロックされた cookie を検索しやすくします。
次の図は、ブロックされた Cookie を示しています。
バージョン 0.7.1 以降、 Adobe Target VEC ヘルパーブラウザー拡張機能は、 SameSite=None
および Secure
拡張機能 UI で「Cookies」切り替えがオンになっている場合に、VEC 内で編集された Web ページからの応答に関するすべての cookie の属性。
VEC と EEC が引き続き期待どおりに動作するようにするには、次のいずれかのオプションを使用します。
更新されたをダウンロードして使用 VEC ヘルパー拡張機能.
Mozilla Firefox ブラウザを使用します。 Firefox は、このポリシーをまだ適用していません。
2021 年 9 月 21 日までコマンドラインからGoogle Chrome を実行するには、次のフラグを使用します。 9 月 22 日以降、ログインや cookie の同意のポップアップなど、cookie を必要とする機能は VEC では機能しなくなります。 Chrome 94 に更新した場合、 SameSite=none
および Secure
を Web サイト上でクリックします。
--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure
Target は、複数レベルの iframe をサポートしていません。Web サイトが子 iframe を持つ iframe を読み込むと、at.js は親 iframe とのみやり取りします。 Target ライブラリは子 iframe とやり取りしません。
回避策として、子 iframe の URL を持つエクスペリエンスにページを追加できます。
この状況は、URL に#文字が含まれている場合に発生する可能性があります。 この問題を修正するには、Visual Experience Composer を「参照」モードに切り替えて、その後「構成」モードに戻します。スピナーの表示が消えて、ページが読み込まれます。
Web サイトの CSP ヘッダーによって Target ライブラリがブロックされることにより、Web サイトは読み込まれるものの編集できない場合は、Target ライブラリがブロックされないようにします。
以下の情報に加えて、Google Chrome 用 Adobe Target VEC ヘルパーブラウザー拡張機能を使用できます。
次のように、Requestly ルールを設定して CSP ヘッダーを削除することで対処できます。
VEC 内でのリソースの読み込みを妨げているヘッダーに、同様の Requestly ルールを設定できます。
Requestly の場合、ヘッダーを削除する必要があるときは必ず次のいずれかを実行する必要があります。
Web サイトが、エクスペリエンスの定義後に Visual Experience Composer 外で変更された場合、それよりも前にアクションがおこなわれたセレクターは、アクティビティを再編集で開くときに検出できません。ページは壊れているように表示され、警告は表示されません。
デフォルトでは、Visual Experience Composer は JavaScript 要素をブロックします。Visual Experience Composer の設定で JavaScript を無効にすると、これらの要素を使用できます。セットアップするサイトによっては、それでも一部のアイテムの表示が正しくなかったり表示できなかったりする場合があります。
同じ DOM 要素 ID がページ内の複数の要素に使用されている場合、それらの要素のいずれかを変更するとその ID の要素がすべて変更されます。この現象を予防するには、各ページで ID は 1 回のみ使用するようにしてください。これは、標準のHTMLのベストプラクティスです。 詳しくは、 ページ修正のシナリオ.
この問題は、拡張 Experience Composer を有効にすることで対処できます。クリック 管理 > Visual Experience Composerをクリックし、拡張 Experience Composer を有効にするチェックボックスを選択します。 拡張 Experience Composer は、編集するページの読み込みに、アドビが管理するプロキシを使用します。このプロキシを使用すると、iFrame バスティングサイトでの編集が可能になり、Adobe Targetコードをまだ追加していないサイトやページでの編集が可能になります。 コードが追加されるまで、サイトにアクティビティは配信されません。サイトによっては、拡張 Experience Composer を介して読み込むことができない場合があります。その場合は、このオプションをオフにして、iFrame を介して Visual Experience Composer を読み込むことができます。
ローカルでホストされているページや、ネットワーク外からアクセスできないページは、アドビのプロキシサーバーにアクセスできず、EEC で開くことができません。こうしたページには、ステージング URL、ユーザー受け入れテスト(UAT)URL またはローカルでホストされているページなどがあります。
上記の「iFrame バスティングのサイトのエクスペリエンスを編集できない」を参照してください。
Visual Experience Composer で A/B またはエクスペリエンスターゲット設定アクティビティに「テキスト/HTML を編集」を使用したり、自動パーソナライゼーションまたは多変量分析テストアクティビティに「テキスト/HTML を変更」を使用して、テキストに太字や斜体を設定すると、Visual Experience Composer でこれらのスタイルがページに適用できないか、ページからテキストが消えることがあります。これは、リッチテキストエディターがこれらのスタイルを適用する方法が Web サイトのマークアップに影響を与える可能性があるためです。
この問題が発生した場合、次の手順に従ってください。
リッチテキストエディターの HTML ボタンをクリックして、ソース編集モードに入ります。
スタイルテキスト要素を検索します。
太字テキストの場合は、<strong>
要素を<b>
に変更します。
斜体の場合は、<em>
要素を<i>
に変更します。
場所に画像オファーを追加するときは、VEC または EEC の元の画像スペースのフルサイズが利用されます。配信時には、画像が拡大されずそのまま表示されるので、配信には影響しません。