By Sam Tingleff
One of our members recently brought to our attention a concern around the impact of GDPR consent strings on URL lengths. It seems worth a short discussion and an advisory.
The Transparency and Consent Framework introduces the concept of a “consent string”, which is a piece of encoded data indicating acquired consent (or not) for some set of the vendors registered on the Global Vendor List (GVL). This consent string is stored on the device in a cookie and is read via a standardized javascript exposed by Consent Management Platforms.
For example, here’s the global consent string currently on my browser:
BOSSotLOSSotLAPABAENBc-AAAAgR7_______9______9uz_Gv_v_f__33e8__9v_l_7_-___u_-33d4-_1vX99yfm1- 7ftr3tp_86ues2_XqK_9oIiA
What all that actually means is a question for another day. What’s important here is that this string is long, and it is necessary to include this string in every request to monetization platforms with a direct integration on-page.
As of this writing there are more than 500 vendors listed on the GVL, each of whom requires a bit (1 or 0) to be stored within the consent string (although compressed). While the rate of increase has slowed down, the list of vendors continues to grow in length and should be expected to continue to grow.
Header Bidding
This consent string is read by header bidding tags and other on-page javascript tags and is passed downstream to exchanges. While many header bidding tags use HTTP POST, some continue to use GET requests. These requests include any number of additional dynamic data attributes collected on the device along with the consent string. An encrypted DigiTrust ID is an example of another piece of data which adds to request length.
While real-world data on maximum URL length is difficult to find, the canonical discussion of this topic occurs in this stackoverflow post. The conclusion today – I know this is nuts in 2018 – remains that URLs greater than 2,000 bytes should be avoided.
All of this suggests that platforms should move from HTTP GET to POST for in-browser ad serving integrations. POST requests do not suffer from limitations in URL length and in modern browsers there is little downside to using XHR POST requests.
In a brief survey of prebid.js adapters, I found that about 75% of them use POST. The rest of you – get with the program by upgrading to support HTTP(S) POST! ?
ABOUT THE AUTHOR
Sam Tingleff, Chief Technology Officer, IAB Tech Lab