Executive Summary

In programmatic advertising, vendors utilize user IDs to build audience profiles and decide how to serve targeted ads. For example, a user with a given user ID might frequent a lot of gardening websites, and consequently, when ad tech vendors “see” that specific user ID, the vendors serve ads to that user ID from advertisers who are promoting gardening tools.

Some user IDs can elicit higher bids from ad tech vendors on behalf of media buyers. For example, a user ID that is thought to be associated with a doctor may elicit very high bid prices from DSPs which are trying to serve ads to healthcare providers on behalf of pharmaceutical brands.

User IDs, often in the form of cookies or other internet technologies, also play a role in frequency capping and attribution. An ad tech vendor can utilize the user ID to keep track of how many times a given consumer has seen a particular ad in a given day to avoid over-exposing them to a message, or to track when a given consumer decides to purchase a product from a given advertiser a few days after having seen the given ad.

User IDs - like page domains - can be mis-declared by publishers or ad tech vendors. For example, just like an ad tech vendor can mis-declare a low quality website as a reputable one, so too can an ad tech vendor mis-declare a given user’s cookie ID with a different user ID thought to be associated with a doctor, lawyer, prospective car buyer, or otherwise high value prospect.

When a mis-declared user ID is used for ad targeting, it can result in the targeting of individuals that do not fit the profile of the advertiser's target audience. In many circumstances, this can lead media buyers to bid and pay higher prices to serve ads to particular individuals. Furthermore, rotation of mis-declared user IDs can negate buyers' desired frequency caps as well as erroneously bias ad performance attribution.

Adalytics examined the source code of ads and bid responses served by the Trade Desk on behalf of different advertisers and on different publisher properties.

The Trade Desk was used for the purposes of this digital forensics analysis purely because Trade Desk mediated bid responses and ad creative source code are relatively straightforward to parse and analyze. Bid responses and markup from other demand side platforms (DSPs) tend to include markup or additional code that can make client-side analysis more time and resource intensive. Some DSPs’ bid responses include large amounts of extraneous code that inflates that size of their ad creative markup.

The sample of ads examined included bid responses transacted by the Trade Desk through sixteen different supply side platforms (SSPs) on a number of different websites, ranging from national news publishers to small cooking blogs. For fifteen of those sixteen SSPs, the Trade Desk user ID associated with the bid response consistently matched the Trade Desk user ID stored locally in the user’s Chrome browser cookie storage.

However, for one of those sixteen SSPs - Colossus SSP - it appeared that the user ID declared to Trade Desk at ad auction time was markedly different from the actual user ID stored in user’s Chrome browser cookie storage.

For example, a given user’s actual Trade Desk cookie user ID in their Chrome browser’s cookie storage was df2d6042-c39f-4fab-a693-ef933acc913c. The bid responses from Trade Desk - when transacting through Magnite, Xandr, TripleLift, OpenX, GumGum, Epsilon Conversant, Index Exchange, Trade Desk Open Path, Pubmatic, Sovrn, TrustX, and Yieldmo - always and consistently declared the user’s ID at auction time as df2d6042-c39f-4fab-a693-ef933acc913c.

For the exact same user and browser profile, when the bid responses from the Trade Desk were transacted by Colossus SSP, the Trade Desk bid responses declared that the user’s “tdid” user ID were multiple different values - d3c36804-bd23-44da-81f4-7ea23593d47c, 5f8b12ef-b014-47f1-898d-d4b57693b766, and ec0d2917-8cf6-43bc-bc27-e42f9619bd71.

This discrepancy between declared and actual Trade Desk user IDs when specifically transacting via Colossus SSP was observed on multiple different publishers and ads.txt/sellers.json seller IDs.

Colossus SSP appears to be integrated with a middle-layer vendor - Criteo-owned Bidswitch - when transacting with the Trade Desk DSP. A different SSP - TrustX - also appears to integrate with Bidswitch. When Trade Desk transacted via Colossus SSP and Bidswitch - there were observed discrepancies in declared versus actual user IDs. When Trade Desk DSP transacted via TrustX and Bidswitch - there were no observed discrepancies.

It is unclear whether there is a specific use case or valid technical reason for these observations. Reviewing various public written and technical documentation did not appear to mention or explain these observations. 

Specifically, there does not appear to be technical explanations related to these phenomena in sources suchs as: 

The Media Ratings Council’s (MRC) definition of Sophisticated Invalid Traffic (SIVT) includes: “Cookie stuffing, recycling or harvesting (inserting, deleting or misattributing cookies thereby manipulating or falsifying prior activity of users);”.

Colossus SSP declares on its website that: “Our partnerships include HUMAN Security for pre-bid filtering and post-bid analysis to mitigate fraud; [...] MOAT for viewability and IVT measurement.”

HUMAN Security and Oracle Advertising (which owns MOAT) are both MRC certified for “Sophisticated Invalid Traffic Detection/Filtration”. HUMAN and Oracle are also Trustworthy Accountability Group (TAG) “Certified Against Fraud”.

A Fortune 500 brand marketing executive said:

"This research shows us that it's possible the millions of dollars spent identifying target audiences, and aligning creative to said audience could be wasted. This also creates a worse experience for the consumer, as the advertising being shown could be completely irrelevant.”

Background: Cookie stuffing versus “user ID bridging”

According to Adweek, “Sell-side partners are looking for ways to identify audiences to keep marketer budgets flowing. But the extent of how shady these practices are depends on the transparency between the DSP and supply-side platforms (SSPs) [...] These allegedly clandestine targeting mechanisms often take the form of probabilistic identifiers, which use machine learning to guess who a reader of a website might be. This includes ID bridging, a technique where an ad-tech firm approximates who a user might be in a cookieless environment like Safari by linking the user to their identity on Chrome. And because the buy side does not know the exact method the sell side is using instead of cookies, some equate this to outright fraud.”

Screenshot of an Adweek article

There are valid reasons for user ID bridging, such as cross-referencing shared IP addresses data against user IDs in deterministic and probabilistic environments. CTV devices or certain web browsers might not support long term deterministic IDs, in which case ad tech vendors may have valid (and transparently disclosed) reasons for transacting a user ID even though that user ID cannot be found in a given device’s disk storage.

However, many environments continue to support deterministic user IDs that can be persisted locally on a user’s device. For example, for many users of Google Chrome’s browser, ad tech vendors can still set persistent, third party ad targeting cookies on the user’s browser. This negates the need for ID bridging.

In situations where it’s clearly possible to persist a deterministic user identifier on a given device and to periodically update or monitor the accuracy of that identifier (such as Google Chrome without any third party cookie depreciation), a mis-match in declared versus actual user identifiers can indicative of practices that fall under the Media Rating Council (MRC)’s definition of “Sophisticated Invalid Traffic” (SIVT).

Background: The Media Ratings Council defines “inserting [...] or misattributing cookies” as a form of invalid traffic

The Media Ratings Council (MRC) published an “Invalid Traffic Detection and Filtration Standards Addendum” in June 2020. On Section 1.1.2 of this addendum, titled “Categories of IVT and Associated General Requirements”, it says that “cookie stuffing” is considered to be a form of Sophisticated Invalid Traffic (SIVT).

Specifically, the MRC’s definition of SIVT states: “Cookie stuffing, recycling or harvesting (inserting, deleting or misattributing cookies thereby manipulating or falsifying prior activity of users);”

Screenshot of the MRC’s Invalid Traffic Detection and Filtration Standards Addendum, Section 1.1.2 “Categories of IVT and Associated General Requirements”. The screenshot shows that “Cookie stuffing”, including inserting or misattributing cookies is considered to be a form of SIVT.

Background: Trade Desk inventory policies only allow for deterministic cookie IDs in the user.buyeruid field

Trade Desk’s public Inventory Policies - Bid Request Transparency (https://partner.thetradedesk.com/v3/portal/ssp/doc/InventoryPolicies#bid-request-transparency) specifically state:

“Only deterministic cookie IDs are allowed in the user.id or user.buyeruid field of the bid request. The user.buyeruid field should contain only browser-specific IDs issued directly from adsrvr.org or from an exchange-held matching table that contains only entries resulting from a cookie sync with adsrvr.org. UID1 can be sent in this field. UID2 should not be sent in this field [...] Probabilistic IDs, including probabilistically mapped TDIDs, device IDs, and UID2s, must be restricted to the extended identifiers (eids field) extension in the request along with the corresponding agent type (atype field).”

Source: Trade Desk Inventory Policies - Bid Request Transparency - https://partner.thetradedesk.com/v3/portal/ssp/doc/InventoryPolicies#bid-request-transparency

Background: TDID is a Trade Desk DSP cookie and user ID

Trade Desk’s public “Unified ID Adoption Guidelines for SSPs” states: “We write an ID called TDID into the top-level cookie in this domain along with the metadata describing the status of mapping that cookie to partners.”

“SSPs currently sync cookies with Adsrvr.org at various priority levels. Given the concentration of demand that is driven from Adsrvr.org, at a minimum SSPs should make it their top cookie mapping priority and fire the pixel from anywhere they can on their footprint. JavaScript pixels should be used whenever possible so that mapping can be made in parallel. Currently, any partner set up to do cookie mapping with TTD issues their own user ID and fires cookie sync pixels across their footprint. The result of the cookie mapping is that they can store a map of their user ID to the TDID in a server-side match table and/or a cookie. For SSPs, this allows the TDID to be looked up at bid time and included in the bid request.”

Furthermore, the Trade Desk’s public partner portal states that “TDID” is “The Trade Desk unique user ID; the cookie ID”.

Screenshot of The Trade Desk’s public partner portal (https://partner.thetradedesk.com/v3/portal/reds/doc/Impressions), showing that “TDID” is “The Trade Desk unique user ID; the cookie ID”.

Research objectives

This study sought to explore under what conditions - if any - would the declared user IDs submitted to programmatic ad auctions deviate from the user IDs actually stored and associated with a given user’s device.

The study focused only on “deterministic” user IDs, such as persistent third party cookies on Google Chrome browser without third party cookie depreciation. The study did not seek to examine probabilistic identifiers or fingerprints. The study did not seek to evaluate “cookieless” environments, such as Safari or CTV.

Methodology

This study focused on a convenience sample of ad bid responses over the course of several months.

The analysis was only executed within the context of an environment that allows for persistent, deterministic user IDs.

Specifically, the analysis was scoped to Google Chrome with third party cookies enabled (no cookie depreciation). Furthermore, only deterministic user IDs, such as the Trade Desk .adsrvr.org TDID cookie, were considered. Probabilistic identifiers were not considered in the scope of this analysis.

In the parlance of the IAB OpenRTB protocol, the study focused on identifiers that would be traditionally submitted within the “user.buyeruid” attribute. The study did not look at attributes that would be submitted in the “user.eids” attribute, which oftentimes contain probabilistic IDs.

Source: IAB TechLab OpenRTB version 2.6

Source: IAB TechLab OpenRTB version 2.6

Some demand side platforms - when bidding on ad auctions and sending ad markup for rendering on the user’s device - send a variety of meta-data in the bid response. For example, bid responses from various DSPs often encoded what page URL or page domain was declared to the DSP at auction time, before the ad was rendered on the user’s device.

The encoding of declared page auction data related to page URLs or domains helped identify instances of page mis-declaration in 2022 - wherein Gannett Media mis-declare page domains in programmatic ad auctions for nine months - and in 2024, wherein Forbes and media.net appeared to mis-declare ads served on the hidden “www3.forbes.com” sub-domain as serving on the premium “www.forbes.com” domain.

Screenshot showing source code of a Bayer ad on “www3.” subdomain of Forbes. The source code of the ad shows it was transacted via Trade Desk DSP and Magnite SSP. The ad source code suggests that the page URL was mis-declared to Trade Desk’s bidder as “www.forbes.com”, when in reality the user was on the “www3.” subdomain of Forbes.

The Trade Desk demand side platform (DSP) - when returning bid responses to programmatic ad auctions - often inserts a win notification pixel into the ad markup. That win notification pixel often follows the format of “bid.adsrvr.org/bid/feedback/”, and includes the name of the SSP that the Trade Desk transacted through, the specific ads.txt seller ID that the Trade Desk bid through, and the declared user ID submitted to the Trade Desk at auction time (which is possibly the Trade Desk TDID value submitted via the “user.buyeruid” OpenRTB attribute by a given SSP).

For example, in the screenshot below, one can see an example of when Trade Desk transacted via the SSP TrustX on usatoday.com to serve an ad. The Trade Desk win notification pixel that is activated from within the ad creative when it renders on a consumer’s device says “bid.adsrvr.org/feedback/trustx”. The pixel encode the query string parameter “svpid=60”, which likely refers to TrustX seller ID “60”, as trustx.org/sellers.json indicates that seller ID 60 belongs to Gannett media (the owner of usatoday.com). The Trade Desk win notification pixel encodes the declared user ID in the “tdid” query string parameter. This appears to be the user ID that was declared or submitted by TrustX the SSP to Trade Desk at ad auction time. This would likely be the specific “user.buyeruid” attribute in the OpenRTB schema that Trade Desk decisions off when bidding into an ad auction.

In the screenshot below on Dot Dash Meredith owned investopedia.com, one can see an HTTPS request submitted via Trade Desk Open Path. The Open Path request declares the user.buyeruid field.

If a user is using a browser that has third party cookies enabled, such as Google Chrome, one can see on one’s own device what specific cookie values are assigned in reality to the given user. For example, in the screenshot below, one can confirm the exact value of the Trade Desk .adsrvr.org TDID cookie that is stored in a given user’s browser.

In the three screenshots shown above, the declared TDID value as submitted by TrustX or Open Path to Trade Desk DSP and observed in the “tdid=” query string parameter win notifications matches perfectly with the Trade Desk .adsrvr.org TDID cookie value stored in the user’s Chrome browser.

This study gathered Trade Desk bid responses submitted to consumers using Google Chrome with third party cookies enabled, and compared the declared, pre-bid “tdid=” query string parameters encoded in the Trade Desk win notification pixels against the actual “TDID” .adsrvr.org cookie values stored in each user’s Chrome browser.

The study sought to identify instances wherein the declared “tdid=” query string parameters did not match the actual “TDID” value stored in a given user’s cookie storage.

This study gathered data on ad serving mechanics on a number of different websites in order to isolate and control for whether any user ID mis-declarations originated from a specific publisher, or from an SSP that works with multiple distinct, un-related publishers. The study gathered data from both large national publisher websites as well local news, blogs, or more specialized sites. It includes sites such as usatoday.com, nypost.com, investopedia.com, cafedelites.com, easyteacherworksheets.com, blavity.com, tbdailynews.com, thenerdstash.com, and others.

The study looked at ad serving mechanics and Trade Desk win notification pixels transacted from the following SSPs or supply sources across the sample of different websites. The following Trade Desk win notification pixels were cross referenced against the actual .adsrvr.org. TDID user IDs.

Trade Desk win notification pixels with “tdid=” query string parameter values:

• Magnite (“bid.adsrvr.org/bid/feedback/rubicon”, “bid.adsrvr.org/bid/feedback/rubicondirectconnect”)

• Xandr (“bid.adsrvr.org/bid/feedback/appnexus”)

• TripleLift (“bid.adsrvr.org/bid/feedback/triplelift”)

• OpenX (“bid.adsrvr.org/bid/feedback/openx”)

• GumGum (“bid.adsrvr.org/bid/feedback/gumgum”)

• Epsilon Conversant (“bid.adsrvr.org/bid/feedback/epsilon”)

• Index Exchange (“bid.adsrvr.org/bid/feedback/casale”)

• Colossus SSP (“bid.adsrvr.org/bid/feedback/colossus”)

• Trade Desk Open Path (“bid.adsrvr.org/bid/feedback/cafemedia”, “bid.adsrvr.org/bid/feedback/nypost”, and others)

• Pubmatic (“bid.adsrvr.org/bid/feedback/pubmatic”)

• ShareThrough (“bid.adsrvr.org/bid/feedback/sharethrough”)

• Google (“bid.adsrvr.org/bid/feedback/google”)

• TrustX (“bid.adsrvr.org/bid/feedback/trustx”)

• Yieldmo (“bid.adsrvr.org/bid/feedback/yieldmo”)

• Medianet (“bid.adsrvr.org/bid/feedback/medianet”)

• Primis (“bid.adsrvr.org/bid/feedback/primis”)

The Trade Desk was used for the purposes of this digital forensics analysis purely because Trade Desk mediated bid responses and ad creative source code are relatively straightforward to parse and analyze. Bid responses and markup from other demand side platforms (DSPs) tend to include markup or additional code that can make client-side analysis more time and resource intensive. Some DSPs’ bid responses include large amounts of extraneous code that inflates that size of their ad creative markup. There is no implication that The Trade Desk is complicit or even permissive of misdeclaration. In fact, Trade Desk has public, written policies which explicitly dictate what types of user IDs can be declared in the user.buyeruid OpenRTB field.

Source: Trade Desk Inventory Policies - Bid Request Transparency - https://partner.thetradedesk.com/v3/portal/ssp/doc/InventoryPolicies#bid-request-transparency

Lastly, this study reviewed the public technical documentation provided by various vendors, including DSPs, SSPs, and other ad tech vendor providers. This included source code in Github.

Results: Out of sixteen SSPs analyzed, Colossus SSP is the only one for which consistent mis-declarations of declared user IDs were observed

This study gathered data from a variety of unrelated publishers, and compared the declared, pre-bid user IDs (as observed in the “tdid=” query string parameter in Trade Desk win notification pixels) with the actual .adsrvr.org TDID user ID values located in user’s Chrome browser cookie storage.

For fifteen SSPs, the declared “tdid=” query string parameter seen in a Trade Desk win notification pixel was always perfectly aligned with the actual user cookie value. For example, in the two screenshots below, one can see a Trade Desk win notification pixel for an ad that was transacted via Pubmatic. The “bid.adsrvr.org/bid/feedback/pubmatic” pixel - which was rendered after Trade Desk bid on and won an ad auction through Pubmatic seller ID 156595 on tbdailynews.com - perfectly matches the actual .adsrvr.org TDID user ID stored in the user’s Chrome browser cookie storage.

For Magnite, Xandr, TripleLift, OpenX, GumGum, Epsilon Conversant, Index Exchange, Trade Desk Open Path, Pubmatic, ShareThrough, Google, TrustX, Yieldmo, Medianet, and Primis, all observed ad impressions in this study’s sample had alignment between the declared “tdid=” query string parameters and the actual .adsrvr.org TDID user ID cookie value in the user’s chrome browser storage.

For one SSP - Colossus SSP - the majority of observed impressions had a mis-match between the declared “tdid=” query string parameter and the actual .adsrvr.org TDID user ID in the user’s chrome browser storage.

For example, during the course of a single browsing session on blavity.com, it was observed that when the Trade Desk transacted twice through Colossus SSP, in both instances a different “tdid=” query string parameter was visible in the “bid.adsrvr.org/bid/feedback/colossus” win notification pixel. In the first screenshot below, one can see that the “tdid” parameter was mis-declared as “ec0d2917-8cf6-43bc-bc27-e42f9619bd71”. This value does not align with the actual .adsrvr.org TDID user ID value in the user’s Chrome cookie browser storage.

In the second screenshot below, from the same page view session on blavity.com, one can see that the “tdid” was mis-declared as “5f8b12ef-b014-47f1-898d-d4b57693b766”. This value does not align with the actual .adsrvr.org TDID user ID value in the user’s Chrome cookie browser storage.

The data table below shows a sample of HTTPS requests to various Trade Desk win notification pixel endpoints. The table illustrated the declared “tdid=” query string parameter values observed in various Trade Desk transacted ads that were rendered, and also shows what the actual user “TDID” cookie value was in the browser. The table shows in what situations there was a mis-match between the actual user cookie value, versus the declared “tdid=” value see in the bid response.

The second table below shows another set of HTTPS requests with different “tdid=” and adsrvr.org TDID values.

The only reproducible observation of “tdid=” query string parameter win notification pixel and adsrvr.org TDID cookie value mismatches observed in this study was when ads were transacted via various Colossus SSP seller IDs on different websites.

This pattern did not appear to be isolated to any specific publisher.

Colossus SSP appears to transact via Criteo-owned Bidswitch

Colossus SSP appears to utilize or transact via Criteo-owned Bidswitch.

Bidswitch is a “middleware” software vendor, which helps connect various SSPs with DSPs. Bidswitch’s public documentation states: “This lets all parties integrated with BidSwitch conduct business with each other through a single point of integration.”

Header bidding responses transacted via colossusssp.com appear to contain notification pixels from bidswitch.net.

Given this observation, one might reasonably inquire whether it is possible that user ID mis-declarations observed in this report when Trade Desk transacts via Colossus SSP can be due to some Bidswitch mediated software services.

However, a review of Bidswitch’s public documentation regarding Supplier User Matching (“https://protocol.bidswitch.com/support/cookie-matching.html”) does not appear to contain any information on how Bidswtich might “override”, “inject”, “substitute”, or “replace” user cookie IDs sent to it by an SSP partner.

Source: Bidswitch Cooke Matching - Supplier User Matching Flow (https://protocol.bidswitch.com/support/cookie-matching.html)

Furthermore, one might note that other SSPs that appear to transact via Bidswitch do not appear to exhibit user ID mis-matches when transacting with the Trade Desk DSP. For example, it appears that the SSP TrustX also transacts via Bidswitch, but there were no observed instances in this study wherein a Trade Desk bid response win notification pixel for “bid.adsrvr.org/feedback/trustx” has a “tdid=” query string parameter that is mis-matched with the Trade Desk .adsrvr.org TDID cookie value stored in the user’s Chrome browser.

In all observed cases, the “tdid=” query string parameter for “bid.adsrvr.org/feedback/trustx” (TrustX) appeared to match the Trade Desk .adsrvr.org TDID cooke value stored in the user’s Chrome storage.

Screenshot showing a Trade Desk DSP ad transacted via TrustX SSP and Bidswitch. The “tdid=” query string parameter in the Trade Desk win notification pixel matches the value of the .adsrvr.org TDID value stored in the user’s Chrome browser.

Colossus SSP works with Oracle Moat and HUMAN

According to Colossus SSP’s websites (https://colossusmediassp.com/dsps), Colossus works with numerous vendors to filter out fraud. Colossus’ website states:

“Our partnerships include HUMAN Security for pre-bid filtering and post-bid analysis to mitigate fraud; Confiant for creative scanning and blocking to prevent malware; MOAT for viewability and IVT measurement.”

Screenshot of Colossus SSP’s website, showing that Colossus works with HUMAN and Oracle Moat

Both HUMAN and Oracle Moat are accredited by the Media Ratings Council (MRC) for Sophisticated Invalid Traffic Detection/Filtration (https://www.mediaratingcouncil.org/accreditation/digital).

Screenshot from the MRC’s website (https://www.mediaratingcouncil.org/accreditation/digital) showing vendors who are accredited SIVT Detection/Filtration. HUMAN is accredited for SIVT Detection/Filtration

Screenshot from the MRC’s website (https://www.mediaratingcouncil.org/accreditation/digital) showing vendors who are accredited SIVT Detection/Filtration. Oracle Moat is accredited for SIVT Detection/Filtration

HUMAN and Oracle (Moat) have also been given the “Certified Against Fraud” seal by the Trustworthy Accountability Group (TAG). Oracle has also been given the “Certified For Transparency” seal.

Screenshot of the Trustworthy Accountability Group (TAG) website, showing that HUMAN is TAG “Certified Against Fraud”

Screenshot of the Trustworthy Accountability Group (TAG) website, showing that Oracle Advertising is TAG “Certified Against Fraud” and “Certified for Transparency”.

To be TAG “Certified Against Fraud”, the TAG Certification Guidelines state:

“A company choosing to comply with the requirement by accreditation to a TAG-Recognized standard must provide evidence of accreditation via the provisions of the following TAGrecognized standards as follows: [...] Media Rating Council’s (MRC) Invalid Traffic (IVT) Detection and Filtration Guidelines Addendum.”

Screenshot of the TAG “Certified Against Fraud - Certification Guidelines”

Conclusion

Caveats & limitations

Interpreting the results of this observational study requires nuance and caution.

This observational study makes no assertions with regards to the actual knowledge or intent of any parties observed or cited in this study. The study cannot comment on whether any phenomenon, such as apparent mis-matches in various user ID related code parameters, were engineered for some specific reason. It is ostensibly possible that any such mis-matches were due to valid ad serving behavior or due to new advances in user ID targeting technologies.

This study reviewed various public written and technical documentation. This included:

If any of the parties cited in this study would like to provide additional commentary or insight, please reach out.

Furthermore, the study uses client-side digital forensics to observe various query string parameters and other references within ad source code. However, this methodology can be prone to false positives in the case of low entropy strings, ad ops and trafficking errors, or other situations where a string references something other than what was inferred or deduced. As such, media buyers and vendors are encouraged to evaluate the observations in this study by examining their own logfile data.

The study relied entirely upon publicly accessible or available data; it made use of no proprietary or internal data on how ads are placed or paid for. Because the study was entirely based on browser client-side observations, it is unable to deduce if there are any post-ad impression reconciliations or corrections that take place. For example, it is possible that if an anti-fraud vendor, SSP, or DSP detected that an ad was served improperly, they could block any monetary value from changing hands. Thus, even if a brand, SSP, DSP, or media agency was transacting ads wherein there were user ID mismatches, it is possible that this had no monetary consequence for that entity.

This study used a convenience sample of data that was readily obtainable. However, it cannot deduce the relative or absolute abundance of certain phenomena observed in this study. It is theoretically possible that the phenomena observed in this study constitute only a small percentage of ad transactions for a given vendor.

Brands and ad tech entities are encouraged to audit their own media buys to analyze how much each entity transacted with any given vendor and whether the ad delivery via that vendor was consistent with their expectations.

Lastly, The Trade Desk was used for the purposes of this digital forensics analysis purely because Trade Desk mediated bid responses and ad creative source code are relatively straightforward to parse and analyze. Bid responses and markup from other demand side platforms (DSPs) tend to include markup or additional code that can make client-side analysis more time and resource intensive. Some DSPs’ bid responses include large amounts of extraneous code that inflates that size of their ad creative markup. There is no implication that The Trade Desk is complicit or even permissive of misdeclaration. In fact, Trade Desk has public, written policies which explicitly dictate what types of user IDs can be declared in the user.buyeruid OpenRTB field.

Other DSPs besides The Trade Desk are known to transact via Colossus SSP. For example, a previous Adalytics research study on “Made for Advertising” MFA sites found that hundreds of different brands had their ads served on “Made For Advertising” websites via Google DV360 DSP, Yahoo DSP, or Adelphic DSP.

Discussion

A Fortune 500 brand marketing executive said:

"This research shows us that it's possible the millions of dollars spent identifying target audiences, and aligning creative to said audience could be wasted. This also creates a worse experience for the consumer, as the advertising being shown could be completely irrelevant.”

If an ad tech vendor does in fact mis-declare user IDs (user.buyeruid) in OpenRTB requests sent to DSPs such as the Trade Desk, this could degrade ad targeting, frequency capping, and attribution.

Furthermore, if a consumer had targeted ads served to them via mis-declared user IDs, this could impair that consumer’s ability to exercise their “right to know” privacy rights under Europe’s GDPR or California’s CPRA legislation. The consumer would likely be unable to prove that they have a specific (mis-declared) cookie or user ID in their possession.