Facebook tries to “black box” application developers, gets massive pushback.

This past week a large portion of the Facebook population re-posted a phony status about Facebook’s privacy settings. Besides the false content, the status claimed that you could stop Facebook from taking your user information and “protect” your data by simply posting a status. Much of the data gathered from Facebook users is used for advertising purposes, giving Facebook a large amount of power in terms of advertising. The billion-dollar social media giant has an estimated 1.5 billion monthly users, making the demographic data extremely favorable for advertisers. Facebook recently made the advertising headlines for their power play in the app market (mobiledevmemo). In May, Facebook announced that it would be making changes to the policies around device level user data on applications (AdExchanger). The first change was to cease passing device-level campaign data back to the application owner. Facebook claimed that not providing user data from downloaded apps would somehow lead to more installs and reduce and/or eliminate privacy abuse.

Facebook's second change was going to allow publishers to access their lifetime value (LTV) and cohort (demographic group) calculations only if they turned over large portions of their organic search data to Facebook (VentureBeat.com). Here is an example: Candy Crush receives approximately 1,200 installations a day with 600 of them coming from Facebook, while the other 600 installs come from organic clicks (non-Facebook locations). Under Facebook's changes, the user IDs associated with the 600 non-Facebook installs would have been handed over to Facebook in exchange for post-install data. That means the advertiser would not be allowed to see the user results of the ads they paid for on Facebook, unless they handed over all data from the app publisher. Once publishers became informed of the changes to Facebook, their reactions were not at all what Facebook was looking for (VentureBeat.com).

The original date for these changes was to take place on August 20th, 2015, but because some of the top developers were pushing back, Facebook decided to delay the implementation until November 4th.  Facebook hoped by delaying, that the additional time would have been enough to convince both advertisers and developers. In July, Facebook released a statement that stated that they would not require those who advertise with them to turn over user information, and never would (VentureBeat.com). This still didn’t sit well with the advertiser and publisher community.  As time went on, Facebook failed to present why less information being delivered to advertisers and app publishers, with all information being delivered to Facebook, was a good thing for anyone other than Facebook.On August 4th, Facebook decided to ditch this plan altogether. Why? Because advertisers were given little explanation on why a massive power grab from Facebook was going to benefit them. Many application publishers rely on device level data to determine whether their campaign was successful or not, based on user information like gender and age. And with over 30 million applications that use Facebook’s app platform, the backlash was massive (DMS).

This posed a great question: Why would Facebook attempt to obtain device level data? Multiple publishers believe that this was a power move by Facebook to start handling the measurement of mobile data “internally” versus externally so they could create a new metric for determining the success or failure of a campaign. This might be the case, but it’s concerning to think that an app developer would be required to turn over their own data to Facebook in order to get data about their own published application.

This is another reason why El Toro is opposed to “metrics of success.”  The hard truth is that the only “metric of success” is success.  Your campaign is either successful, or it’s not. Facebook was trying to improve the way we look at advertising success of a campaign, but they went about it with poor planning.