パーソナライゼーションとプライバシー

最終更新日： 2023-11-02

トピック：
Installation
このトピックの詳細を表示
Privacy
このトピックの詳細を表示
Privacy Tools
このトピックの詳細を表示
URL Personalization
このトピックの詳細を表示

作成対象：

URL のパーソナライゼーション

コンテンツにパーソナライズされたリンクを追加する場合、潜在的なセキュリティギャップを回避するために、URL のホスト名部分にパーソナライゼーションを含めないようにしてください。次の例は、すべての URL 属性 <a href=""> または <img src=""> で使用しないでください。

<%= url >
https://<%= url >
https://<%= domain >/path
https://<%= sub-domain >.domain.tld/path
https://sub.domain<%= main domain %>/path

レコメンデーション

上記を使用していないことを検証し確認するには、を使用してトラッキング URL テーブルに対してクエリを実行します。キャンペーン汎用クエリエディターまたは、クエリアクティビティ.

例：

ワークフローを作成し、 クエリ アクティビティ。詳細情報
を開きます。 クエリ アクティビティを作成し、 nmsTrackingUrl 表を次に示します。

source URL starts with http://<% or source URL starts with https://<%
ワークフローを実行し、結果があるかを確認します。
結果がある場合は、出力トランジションを開いて URL のリストを表示します。

URL 署名

セキュリティを強化するために、E メール内のリンクを追跡するための署名メカニズムが導入されました。これは、ビルド 19.1.4(9032@3a9dc9c) および 20.2 以降で使用できます。この機能は、デフォルトで有効になっています。

メモ

不正な形式の署名済み URL がクリックされると、次のエラーが返されます。 Requested URL '…' was not found.

また、拡張機能を使用して、以前のビルドで生成された URL を無効にすることができます。この機能は、デフォルトでは無効になっています。次の場所に移動して、カスタマーケアこの機能を有効にするには、をクリックします。

19.1.4 ビルドで実行している場合、トラッキングリンクを使用したプッシュ通知配信、またはアンカータグを使用した配信で問題が発生する可能性があります。その場合は、URL 署名を無効にすることをお勧めします。

Campaign がホストする、管理対象Cloud Service、ハイブリッド顧客は、カスタマーケア URL 署名を無効にする。

ハイブリッドアーキテクチャで Campaign を実行している場合は、URL 署名を有効にする前に、ホストされているミッドソーシングインスタンスが次のようにアップグレードされていることを確認します。

まず、オンプレミスマーケティングインスタンスを使用します。
その後、オンプレミスのマーケティングインスタンスと同じバージョンにアップグレードするか、少し高いバージョンにアップグレードします。

そうしないと、次の問題が発生する場合があります。

ミッドソーシングインスタンスがアップグレードされる前は、このインスタンスを通じて URL が署名なしで送信されます。
ミッドソーシングインスタンスをアップグレードし、両方のインスタンスで URL 署名が有効になった後、以前に署名なしで送信された URL は拒否されます。これは、マーケティングインスタンスから提供されたトラッキングファイルによって署名が要求されたためです。

以前のビルドで生成された URL を無効にするには、すべての Campaign サーバーで同時に次の手順に従います。

サーバー設定ファイル (serverConf.xml)、 blockRedirectForUnsignedTrackingLink 選択肢 true.
を再起動します。 nlserver サービス。
次の日： tracking サーバー、再起動 web サーバー（Debian では apache2、CentOS/RedHat では httpd、Windows では IIS）。

URL 署名を有効にするには、すべての Campaign サーバーで同時に次の手順に従います。

サーバー設定ファイル (serverConf.xml)、変更 signEmailLinks オプション、 true.
nlserver サービスを再起動します。
次の日： tracking サーバー、再起動 web サーバー（Debian では apache2、CentOS/RedHat では httpd、Windows では IIS）。

データの制限

権限の低い認証済みユーザーは、暗号化されたパスワードにアクセスできないようにする必要があります。これをおこなうには、パスワードフィールドのみ、またはエンティティ全体（ビルド >= 8770 が必要）へのアクセスを制限します。

この制限をおこなうと、パスワードフィールドを削除する一方で、外部アカウントは全ユーザー向けのインターフェイスからアクセス可能にできます。詳細情報

手順は次のとおりです。

次を参照：管理 > 設定 > データスキーマ Campaign エクスプローラーのフォルダー。
としてのデータスキーマの作成 スキーマの拡張.
外部アカウント（extAccount）を選択します。

ウィザードの最後の画面で、新しい「srcSchema」を編集して、すべてのパスワードフィールドへのアクセスを制限します。

メイン要素（<element name="extAccount" ... >）は、次の方法で置き換えることができます。

<element name="extAccount">
    <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
    <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>

    <element name="s3Account">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
    </element>
    <element name="wapPush">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
    </element>
    <element name="mms">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
    </element>
</element>

したがって、拡張された srcSchema は次のようになります。

<srcSchema _cs="External Accounts (cus)" created="2017-05-12 07:53:49.691Z" createdBy-id="0"
            desc="Definition of external accounts (Email, SMS...) used by the modules"
            entitySchema="xtk:srcSchema" extendedSchema="nms:extAccount" img="" label="External Accounts"
            labelSingular="External account" lastModified="2017-05-12 08:33:49.365Z"
            mappingType="sql" md5="E9BB0CD6A4375F500027C86EA854E101" modifiedBy-id="0"
            name="extAccount" namespace="cus" xtkschema="xtk:srcSchema">
    <createdBy _cs="Administrator (admin)"/>
    <modifiedBy _cs="Administrator (admin)"/>
    <element name="extAccount">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>

        <element name="s3Account">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
        </element>
        <element name="wapPush">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
        <element name="mms">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
    </element>
</srcSchema>

メモ

次を置き換えることができます。 $(loginId) = 0 or $(login) = 'admin' 次を使用 hasNamedRight('admin') 管理者権限を持つすべてのユーザーに対し、これらのパスワードの表示を許可する。

PI を持つProtectページ

オンプレミス版のお客様には、ミラーページや Web アプリケーションなど、個人情報 (PI) を含む可能性のあるページを保護することを強くお勧めします。

この手順の目的は、これらのページのインデックス化を防止することによってセキュリティリスクを回避することです。以下に、この目的に役立つ記事をいくつか示します。

ページを保護するには、次の手順に従います。

Web サーバー（Apache または IIS）のルートに robots.txt ファイルを追加します。このファイルの内容は次のとおりです。
```
# Make changes for all web spiders
User-agent:
*Disallow: /
```
IIS の場合は、このページ.

Apache の場合は、にファイルを配置できます。 /var/www/robots.txt (Debian)。
場合によっては、 robots.txt ファイルはセキュリティの点で十分ではありません。例えば、他の Web サイトに自社ページへのリンクがある場合は、検索結果に自社ページの情報が表示される可能性があります。

robots.txt ファイルに加え、X-Robots-Tag ヘッダーも追加することをお勧めします。Apache の場合も IIS の場合も、このヘッダーの追加は serverConf.xml 設定ファイルでおこなえます。

詳しくは、この記事.

プライバシーリクエスト

参照：このページプライバシー管理の概要とAdobe Campaignの実装手順に関する一般的な情報を参照してください。また、ベストプラクティスや、ユーザープロセスとペルソナの概要も確認できます。

パーソナライゼーションとプライバシー

URL のパーソナライゼーション

レコメンデーション

URL 署名

データの制限

PI を持つProtectページ

プライバシーリクエスト

このページ

次を表示：

学習

ドキュメント

コミュニティ

サポート

リソース

アドビアカウント

Adobe