Google は、プライバシーを重視したデジタル広告エコシステムへの継続的な取り組みの一環として、EU ユーザーの同意ポリシーの適用を強化しています。
EEA のユーザーに関するデータをカスタマー マッチ パートナーを利用してアップロードしている場合は、ご利用のカスタマー マッチ パートナーと協力して、必須の同意シグナルを Google に渡していただく必要があります。
仕組み
Google Ads API v15 に導入された同意オブジェクトでは、2 種類の同意情報が指定されています。EU ユーザーの同意ポリシーに準拠して、EEA のユーザーにカスタマー マッチを使い続けるには、カスタマー マッチ アップロード パートナーが Google Ads API v15 を組み込んで、カスタマー マッチに関するデータをアップロードする際に同意シグナルを設定する必要があります。
これらの同意シグナルがない場合、同意の値は「同意なし」と判断されます。同意を得ていない EEA ユーザーからのデータは処理されず、カスタマー マッチを使った広告のパーソナライズに使用できません。
2024 年 3 月より、EEA で使用されるカスタマー マッチ リストに関しては、ConsentStatus 型の同意フィールドを両方とも [GRANTED]（付与）に設定し、必要な同意をユーザーから得ていることを示す必要があります。該当する同意フィールドは次のとおりです。
| 名前 | 型 | 説明 |
|---|---|---|
ad_user_data |
ConsentStatus | 広告掲載を目的として Google にユーザーデータを送ることに対する同意を設定します。 |
ad_personalization |
ConsentStatus | 広告のパーソナライズに対する同意を設定します。 |
よくある質問
1. 同意フィールドの適用対象はジョブ内のすべてのユーザー レコードですか、それとも EEA のユーザー レコードだけですか?
同意設定は、1 つのジョブでアップロードされた全ユーザーに適用されます。したがって、同意シグナルが異なるユーザーについては、別のジョブを使ってアップロードする必要があります。
たとえば、1 つのジョブ内に EEA 以外のユーザーと EEA のユーザーのレコードが存在し、同意ステータスが [GRANTED] で送られた場合、この [GRANTED] の同意ステータスが、そのジョブ内のすべてのレコードで使われます。
2. 同意レベルの異なるメンバーを 1 つのユーザーリストに含められますか？たとえば、1 つのオーディエンスを更新する 2 つのジョブを用意して、同意ステータスが [UNSPECIFIED] の ID を最初のジョブで送信し、同意ステータスが [GRANTED] の ID を 2 つ目のジョブで送信することは可能ですか？
同意設定は、1 つのジョブでアップロードされた全ユーザーに適用されます。したがって、同意ステータスが異なるユーザーについては、別のジョブを使ってアップロードする必要があります。ご提示いただいた例の場合は、2 つのジョブを使います。1 つは、ad_user_data パラメータと ad_personalization パラメータの同意ステータスが [UNSPECIFIED] のユーザーをアップロードするジョブ、もう 1 つは、これら 2 つの同意パラメータの同意ステータスが [GRANTED] のユーザーをアップロードするジョブです。
3. 1 つのユーザー ID が 2 つのジョブで送信され、1 つのジョブでは同意ステータスが [GRANTED]（ad_user_data と ad_personalization の同意ステータス）、もう 1 つのジョブでは同意ステータスが [DENIED]（ad_user_data と ad_personalization の同意ステータス）だった場合、適用される同意ステータスはどのように決まるのですか？基準になるのはジョブが始まる順ですか、処理される順ですか？
同意ステータスを [DENIED] に設定すると、エラーが表示されます。詳しくは、Google Ads API で [DENIED] を設定した場合の動作をご覧ください。 同じユーザー レコードについて、1 つのジョブで同意ステータス [GRANTED] が送られ、別のジョブで同意ステータス [DENIED] が送られると、同意ステータスが [DENIED] の 2 番目のジョブにエラー メッセージが表示されます。同意ステータスは、ジョブが処理される順に解決されます。
4. 同意ステータスの値 [DENIED] を、パートナーはどのように使うべきですか？オーディエンスから該当メンバーを削除するのと何が異なりますか？
同意ステータスを [DENIED] に設定すると、エラーが表示されます。詳しくは、Google Ads API で [DENIED] を設定した場合の動作をご覧ください。同意パラメータの ad_user_data か ad_personalization のいずれかに [DENIED]（同意拒否）を送ると、カスタマー マッチがエラーとなり、そのジョブ内のデータは広告のパーソナライズで使えなくなります。
ただし、その EEA ユーザーのデータが 2024 年 3 月より前に同意を得ていたか存在していた場合、そのデータはカスタマー マッチで引き続き使用されます。
オーディエンス リストからユーザー レコードを削除すると、その EEA ユーザーのデータで、2024 年 3 月より前に同意を得ていたか存在していたデータも、カスタマー マッチで使えなくなります。
5. カスタマー マッチ パートナーは、同意の変更をどのように管理すべきですか？オーディエンス リストから対象ユーザーのデータを削除すべきですか？それとも、個々のユーザーの同意フラグを変更すればよいですか？
オーディエンス リストに追加されたユーザーが 2 つの同意（ad_user_data、ad_personalization）のいずれかを後から取り消した場合、カスタマー マッチ パートナーの対処方法としては、カスタマー マッチ関連 API を使って既存のオーディエンス リストから対象ユーザーを削除するか、同意していないユーザーを除いたオーディエンス リストに置き換える方法があります。
注: 過去に ad_user_data と ad_personalization の両方に同意していた EEA ユーザーの場合は、そのオーディエンス リストの有効期限が切れるまで、あるいは広告主様やパートナーによってその EEA ユーザーのデータが明示的に削除されるまで、そのデータがカスタマー マッチで引き続き使われます。
6. カスタマー マッチ パートナーが定期的に更新しているオーディエンス リストで、2024 年 3 月より前に作成されたものはどうなりますか？同意のアップロードが必要になるのは、更新されるオーディエンス リストに新たに追加されるレコードだけですか？
2024 年 3 月以降もカスタマー マッチを EEA ユーザーに継続的に適用するには、新たにアップロード / 更新される EEA ユーザーのすべてのデータについて、2 つの同意フィールドの両方を [GRANTED] に設定する必要があります。
2024 年 3 月より前にアップロードされたユーザーリストは、その有効期限が切れるか、広告主様やパートナーによって明示的に削除されるまで、カスタマー マッチで引き続き使われます。そうしたユーザーリストの使用が継続されるのは、2024 年 3 月より前に使われていた Google サービスに限られます。
7. 広告主様から同意情報が提供されない場合に、パートナーがデフォルト値として [UNSPECIFIED] を送るとどうなりますか？
同意ステータスが [UNSPECIFIED] に設定されると、同意がないものとみなされるため、そうした EEA ユーザーのデータは広告のパーソナライズで使用できなくなります。
8. 広告主は、カスタマー マッチで店舗販売データを使用するために、同意ラベルごとに個別のアップロード ジョブまたはファイルを送信する必要がありますか？
いいえ。広告主様は、EEA ユーザーの店舗販売データをアップロードする際に、同意ラベルごとに個別のアップロード ファイルまたはジョブを送信する必要はありません（API によるアップロードと手動アップロードの両方に適用）。Google は、同意ラベルへの準拠を徹底するために、店舗販売データとそれに関連付けられている同意の値を、アップロードされた各ファイル内の各行単位で処理します。このアプローチにより、すべての同意ラベルが適用され、同意が拒否された行の個人データが処理されなくなります。カスタマー マッチと店舗販売の両方について、Google に渡された同意ラベルが適用されます。
9. 店舗販売データによるカスタマー マッチを使用するためには、どの同意パラメータが必要ですか？
カスタマー マッチ機能を引き続きご利用いただくには、広告主様は、EEA ユーザーの広告ユーザーデータと広告のパーソナライズの両方についての同意の値とともに、店舗販売データを渡す必要があります。店舗販売データによるカスタマー マッチに使用できるのは、[GRANTED] の値を持つデータのみです。EEA における同意の更新について詳しくは、こちらをご覧ください。
