A little more than six months ago, we addressed the challenges businesses faced in complying with CCPA when it came to their use of third-party adtech such as pixels, beacons and trackers. In line with the evolving nature of CCPA, additional third-party adtech companies have recently released guidance on how they will use data under CCPA. As explained below, businesses who utilize certain adtech will need to mark their calendars for July 31, 2020, if they want to implement limited data processing to avoid selling data.
In November 2019, Google introduced a concept called "restricted data processing" (RDP) with the implication that when a business used a service with RDP enabled, Google would not share this data with third parties and would be a service provider under CCPA. At that time, Google outlined that certain services had RDP by default (such as Google Analytics), and for others, the business had to take some action to enable RDP (such as for Google Ads). This action could be a setting whereby all use of that service would be RDP, or, in some circumstances, the business may be able to use a “Do Not Sell” link to activate RDP on a consumer-by-consumer basis for those who opt-out of selling.
Basically, this approach boils down to two concepts: (1) the setting, in Google’s case RDP, changes the third-party’s behavior such that it treats data in a way that qualifies it as a service provider and, conversely, (2) when this setting is not enabled, the third-party is not behaving as a service provider so using their service will presumably be considered selling the consumer’s data under CCPA.
The reason that unrestricted data processing by an ad-tech provider could be considered a sale is that third-party adtech is a transfer of data from the business to a third party (without any restriction on how the third party can use the data) and it does not matter under CCPA if the business ever sees the data. The consumer’s data is still being passed to the third party because of a conduit on the business’s site implemented by the business. CCPA’s definition of selling has an exception for transfers of data to service providers, but the definition of service provider requires they only use it for the business’s benefit. Historically, these adtech providers used the data to build profiles that they would then monetize in ways that are outside the CCPA service provider constraints, and transfers of that data from the business could be considered selling. As we wrote back in our November update, this puts businesses in a difficult spot because using adtech that had not changed practices in many cases would be selling, but disabling this adtech at the business’s site was either very difficult to implement or disruptive to the business if they were removed entirely. Businesses need these adtech companies to provide guidance as to how they use data and, if the transfer is considered selling, provide mechanisms for the business to either change the practices to service provider-qualifying by default or a provide a technically feasible way to do it in response to a do not sell link.
In our previous post, we encouraged businesses to monitor "large players" that we reasoned would have to take a firm position at some point. Last week we finally got movement from one of the largest players, Facebook. Facebook has followed Google's lead in disclosing a method of processing data that presumably qualifies it as a service provider, which it refers to as "limited data use" (LDU). As with Google's RDP, Facebook’s framework implies that if LDU is active, the service will qualify as using a service provider and be an exception to selling under CCPA. If LDU is not implemented, then the service would be considered selling.
Facebook has implemented LDU by default for all personal information businesses share about people in California for all of these services for a "transition period" starting July 1, 2020: Facebook Pixel, App Events API, Offline Conversions, Service Side API, App Events via Facebook SDK, Audience Network Ad Requests and Bidding via Audience Network SDK. The first four Pixel, App Events, Offline Conversions and Server-Side API, will revert on July 31, 2020, unless the business takes action to either enable it by default or implement a do not sell link to have it done on a per consumer basis. The last two, App Events and Audience Network Ad Request and Bidding via Audience Network SDK, will be in a transition period with LDU enabled until an upgrade of either of these platforms or until 60 days after Facebook provides notice.
Another important piece of guidance provided by Facebook reads as follows: “Facebook Supported APIs are listed below, and other Facebook Products with Limited Data Use are described in our State-Specific Terms. If your business uses an API or other Facebook Product that isn’t supported in our initial release, with few exceptions, we will not act as your service provider for those APIs starting July 1, 2020.” The “Supported APIs” are those addressed in the preceding paragraph, so this quote suggests any other Facebook services do not qualify as using a service provider and therefore need to be treated as well.
Given this new direction, businesses should review their Facebook service usage and determine whether they are using those identified or others. If they use any of the first four where LDU sunsets on July 31, 2020, the business should act to either enable LDU by default or implement a do not sell link to allow individual consumers to opt-out. It is important that a business recognize that ignoring this framework and doing nothing after July 31 could result in the business being found selling personal information without providing the consumer an opt-out.
