ドキュメント Campaign Campaign Classic v7 ドキュメント

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

最終更新日： 2026年5月13日

適用対象：
Campaign Classic v7

トピック：
{"id":"a7760dfc-5c44-4d77-bb68-c50b1e265c93"}

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

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

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

レコメンデーション

上記を使用していないことを検証して確認するには、Campaign汎用クエリエディターを介してトラッキング URL テーブルでクエリを実行するか、クエリアクティビティでフィルター条件を使用するワークフローを作成します。 Campaign v8 ドキュメントを参照してください。

例：

ワークフローを作成し、クエリ アクティビティを追加します。 Campaign v8 ドキュメントを参照してください。
クエリ アクティビティを開き、次のようにnmsTrackingUrl テーブルにフィルターを作成します。

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

URL署名

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

NOTE

形式が正しくない署名済みURLをクリックすると、このエラーが返されます：Requested URL '…' was not found.

さらに、機能強化を使用して、以前のビルドで生成されたURLを無効にすることもできます。この機能はデフォルトで無効になっています。この機能を有効にするには、カスタマーケアにお問い合わせください。

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

Campaign ホスト版、Managed Cloud Servicesまたはハイブリッド版のお客様の場合、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" ... >）は、次の方法で置き換えることができます。

code language-sql

<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 は次のようになります。

code language-sql

<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>

note
NOTE
`$(loginId) = 0 or $(login) = 'admin'`を`hasNamedRight('admin')`に置き換えて、管理者権限を持つすべてのユーザーがこれらのパスワードを表示できるようにすることができます。

PIでページを保護

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

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

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

Web サーバー（ApacheまたはIIS）のルートにrobots.txt ファイルを追加します。このファイルの内容は次のとおりです。

code language-sql
`# 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のプライバシー管理と実装の手順について詳しくは、このページを参照してください。また、ベストプラクティスや、ユーザープロセスおよびペルソナの概要についても説明します。

recommendation-more-help

campaign-classic-help