Clarification on Vendor ID Usage in Consent Macro and Piggybacking

[groyoh]

Summary of Clarifications Needed

1. The exact role of the vendor ID in the consent macro
2. Proper handling of vendor IDs in piggybacking scenarios
3. How vendor IDs should be assigned when an intermediary (our company) forwards requests
4. How vendor IDs should be assigned when an intermediary (our company) forwards and process requests

Context

Hello!

The current documentation states:

Since the pixel is in an <img> tag without the ability to execute JavaScript, the CMP API cannot be used to obtain the TC String. All parties in the ad supply chain who transact using URLs must add a macro in their URLs where the TC String is inserted. Any caller with access to the applicable TC String must insert it within a URL containing the macro ${GDPR_CONSENT_XXXXX}, where XXXXX is the numeric Vendor ID of the vendor receiving the TC string.

For example, for Vendor A with ID 123 to receive a TC String, an image URL must include a key-value pair with the URL parameter and macro gdpr_consent=${GDPR_CONSENT_123}.

The resulting URL is:

https://vendor-a.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_123}

While this explanation is clear for standard use cases, I have several questions regarding how the vendor ID should be handled in more complex scenarios, such as piggybacking and redirection.

Note: I have looked through issues and the wiki and couldn't find a proper answer to those questions.

Questions

1. Purpose of the Vendor ID in the Consent Macro

What is the exact purpose of the vendor ID in the consent macro (instead of having a generic ${GDPR_CONSENT})?

I've come across PRs (#251, #214) discussing its usage, but they don’t fully explain its role. Additionally, issue #233 directly asked this question but doesn’t appear to have received a clear answer.

2. Handling Vendor IDs in Piggybacking Scenarios

In a scenario where Vendor A's tracking pixel is piggybacked onto Vendor B's tracking pixel, the URL might look like:

https://vendor-a.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_xxxxx}&redir=https://vendor-b.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_yyyyy}

(Note: Parameters are not URL-encoded for readability.)

In this case:

• Should xxxxx and yyyyy represent the vendor IDs of Vendor A and Vendor B, respectively?
• Or should both use Vendor A’s ID since the consent is initially being passed through its tracking pixel?

3. Redirecting Through an Intermediary (Our Company’s Domain)

Our company is a registered vendor in the GVL, but for technical reasons, we now use our own domain for tracking pixel URLs of vendor A. The request first goes through our servers, which then forward (via proxy) it to Vendor A (and eventually to Vendor B due to piggybacking).

In this case, the URL might look like (note the domain name change):

https://my-company.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_xxxxx}&redir=https://vendor-b.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_yyyyy}

Important note: We do not store, log, or process any user data or TC strings—we only forward them and no cookie is stored on our domain.

In this case:

• Should the consent macro use our company’s vendor ID (since we receive the request), or
• Should it retain Vendor A and B’s vendor IDs (since they ultimately process the TC string)?

4. Best Practices for Building Our Own Piggybacked Tracking Pixel

We are considering implementing our own tracking pixel that piggybacks on other vendors. Our tracking pixel would look like:

https://my-company.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_zzzzz}

When triggered, we would track user data according to the user consent and then redirects to our other vendors:

https://vendor-a.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_xxxxx}&redir=https://vendor-b.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_yyyyy}

Given this setup:

• Since our tracking pixel initiates the request, should we include our own vendor ID (zzzzz) in the consent macro?

• Should we also include Vendor A and B’s vendor IDs in our initial request? For example:

  https://my-company.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_zzzzz}&gdpr_consent_vendor_a=${GDPR_CONSENT_xxxxx}&gdpr_consent_vendor_b=${GDPR_CONSENT_yyyyy}

  However, this seems to conflict with the documentation, which states:

  The creator of the URL should ensure these parameters are added only once and are passed to services that expect and can handle them properly.

---

Any clarification on these points would be greatly appreciated. Thank you! 🙏

[HeinzBaumann]

From an email exchange with @groyoh

Hello Yohan!

Thank you for your inquiry and sorry for the late reply. Things were a little busy and my traveling didn't help either, Sorry for that.

Here are my thoughts on these questions.

1. The exact role of the vendor ID in the consent macro
   The reason why the numeric Vendor ID of the vendor receiving the TC string needs to be added in macros is that personal data such as IP addresses or callee cookies may be passed as part of the request. The Vendor ID should be used by the service making the call to ensure the receiving Vendor has a legal basis for processing.
   The vendor ID macro is used in the case where the consent string cannot be obtained on the web page (no JS script available). Typically in pixels. In this case the consent macro will be in the form of ${GDPR_CONSENT_XXXXX}, where XXXXX is the numeric Vendor ID of the vendor receiving the TC string. The vendor encoded in this macro is then required to obtain the TC string and replace the gdpr_consent with the actual TC string. (see consent string and vendor list format V2 spec.

2. Proper handling of vendor IDs in piggybacking scenarios
   

When a redirect is added to the pixel that means a new vendor will receive the request and that new vendor will need to resolve the consent string. Two options here: the original vendor's consent macro is replaced with the consent string at the time the piggybacking happens, no need to add a vendor consent macro to the redirect. If the consent string is not available, the new vendor's consent macro will need to be added to the redirect, so the vendor receiving the call can request the consent string.

3. How vendor IDs should be assigned when an intermediary (our company) forwards requests
   

When forwarding the request, the vendor should obtain the TC String and replace the consent macro with the consent string before redirecting. It's assumed that this happens on the server and a call to obtain the consent string can be made.

4. How vendor IDs should be assigned when an intermediary (our company) forwards and processes requests
   When forwarding and processing the request, the vendor should obtain the TC string and replace the consent macro with the consent string before redirecting. It's assumed that this happens on a server and a call to obtain the consent string can be made.

[groyoh]

@HeinzBaumann thanks for taking the time to answer here as well. For your information, I have moved to a different job since I opened this issue so I am no longer involved with this topic.

If you need some feedback, I'd suggest you reach out to @RemiPrevost or @ThomasChaf.

[HeinzBaumann]

Under review by the FSWG