In June 2020, Apple announced a new iOS 14 AppTrackingTransparency framework, requiring apps to show a discouraging prompt, that will have hard hitting implications for businesses that advertise on mobile devices and across the web. We disagree with Apple’s approach and solution. We understand how disruptive Apple’s changes may be to your business, and are committed to helping you manage through them.
In early 2021, Facebook will begin to show Apple’s App Tracking Transparency (ATT) prompt. Once Facebook and Instagram show Apple’s ATT prompt, those that optimize, target, and/or report on mobile web events from any of our business tools will be impacted given Apple’s required limits on data sharing.
Today, in order to help minimize disruption, we are providing you an update with our solutions that require actions you can take immediately, and actions you need to plan for in early 2021.
Aggregated Event Measurement: Facebook will introduce Aggregated Event Measurement to support measurement of web events from iOS 14 users once Apple requires the ATT prompt. It is designed to help you measure campaign performance in a way that is consistent with consumers’ decisions about their data.
Event Limits: You will be limited to the use of 8 conversion events per domain (i.e., 8 <pixel, event> or <custom conversion> per domain). You will not need to make changes to the pixel or your Conversions API implementation as event selection will be done in Events Manager beginning early 2021.
- Ad sets optimizing for an event beyond the 8 that are prioritized will be paused.
- The 8 conversion events per domain will be ranked based on priority. If multiple events are completed by a user (i.e. “add to cart” and “purchase”) only the higher prioritized event will be reported.
- After the initial configuration, the domain owner will be able to configure which 8 events are tracked for a given domain in Events Manager.
Actions to take now:
Domain verification in Business Manager: We ask that you verify your domain using the steps outlined in the Facebook Help Center. This is critical for businesses with pixels used by multiple Business Managers or personal ad accounts. Domain verification will ensure no immediate or future disruption in the ability to configure conversion events.
Note: Domain Verification must be done at the effective top level domain plus one (eTLD+1 ). For example, for www.books.jasper.com, books.jasper.com and jasper.com the eTLD+1 domain is jasper.com.
Plan for 8 conversion events per domain: If you use more than 8 conversion events per domain for optimization or reporting, prepare an action plan for how to operate with 8 conversion events per domain based on your business priorities. You will not need to make changes to the pixel or Conversions API implementation as event configuration will be done in Events Manager.
VALUE OPTIMIZATION (VO)
- VO will transition from Ads Manager to Events Manager and value set will need to be enabled.
- If you have previously used VO, value sets will be automatically assigned based on historical data and turned on in Events Manager.
- If you are eligible and use VO infrequently or have never used it, value sets must be configured manually.
- You will be able to have a maximum of 8 value sets. Note: turning on value sets will automatically utilize 4 out of the 8 events allowed for campaign optimization and reporting for a given domain.
- For optimal performance, events with value sets turned on should be placed in higher priority slots within the Events Manager.
Actions to take now:
There are no specific changes for Dynamic Ads for Retargeting, but you may see performance and audience sizes decrease. We expect minimal impact to you using Dynamic Ads to reach Broad Audiences.
Actions to take now:
- Verify product URL domains in the catalog feed and avoid the use of URLs redirecting users to a different domain.
- Prepare to use only 1 pixel per catalog to optimize for prioritized conversion events across all catalog items.
Ads Reporting (Ads Manager, Ads Reporting, Ads Insights API):
- 28-day click-through, 28-day view-through, and 7-day view-through attribution windows will not be supported. Historical data for these windows will remain accessible via the Ads Insights API.
- Statistical modeling will be used for certain attribution windows and/or metrics to account for less data availability from iOS 14 users. In-product annotation will communicate when a metric is modeled.
- Certain attribution windows will have partial reporting and metrics will not include all events from iOS 14 users. In-product annotation will communicate when a metric is partial. This will launch in early 2021.
- Delivery and action breakdowns will not be supported for offsite conversion events.
- Offsite conversion events will be reported based on the time the conversions occur and not the time of ad impressions. As a result, you may notice small fluctuations in cost metrics, as cost per conversion will reflect spend over a given period divided by conversions that took place over the same period, whereas today, cost per conversion reflects spend over a given period divided by conversions driven by ad impressions that took place over the same period.
Attribution Window Selection: We will be replacing the account-level attribution window with a new attribution setting at the ad set level that can be accessed during campaign creation. This attribution setting ensures that the conversions we measure are the same ones used to inform campaign optimization, and will allow for increased flexibility and clarity when analyzing ad performance. We will introduce a new API parameter to allow for the querying of results based on this new attribution setting.
For automated rules: In early 2021, attribution window settings for existing and newly created automated rules will no longer be supported, and a default window of 7-day click-through for non-iOS conversions and the SKAdNetwork window for iOS conversions will be implemented.
Actions to take now
Prepare for attribution window changes (deprecation of 28-day click-through, 28-day view-through, and 7-day view-through windows):
- Adopt the Comparing Windows feature to see how conversions attributed to ads compare across different attribution windows. This allows you to better anticipate the impact to reported conversions as a result of upcoming attribution window changes.
- Update any automated rules currently using a 28-day attribution window to prevent any unexpected adjustments in spend once the new 7-day click-through window default goes into effect.
DEVELOPER APIs (Marketing API, Ads Insights API, Targeting API)
Numerous Endpoint Changes: Our Marketing API, Ads Insights API, and Targeting API will have endpoint changes according to the changes referenced in the Event Management, Delivery, and Measurement sections of this document.
What you can do now
Take action on the changes mentioned in this blog, and review the changes coming to our APIs. These have not gone into effect and cannot be implemented at this time, however, we want to give you as much notice as possible. You can view the changelog here.
What you should plan for early 2021:
Implement API changes: We anticipate having API updates ready for implementation by mid-January of 2021, some of which may result in same day breaking changes. Technical information regarding API changes that will be required in early 2021 will be shared in our developer documentation.
For information on iOS 14 impact to App based developers please see our separate Developer blog post here.
For information on how to plan for changes to our Marketing API, please see our changelog.
Preparing our Partners for iOS 14: Changes to Marketing API and Ads Insights API beginning January 19th, and beyond
If you do not provide action_attribution_windows when pulling results we will use 7d_click and 1d_view by default instead of 28d_click and 1d_view.
The use_account_attribution_setting field will be ignored, as we will be replacing the account-level setting with a new attribution setting that can be set at the ad set level during ads creation. Below you will find details for two new fields related to attribution settings that can be used: use_unified_attribution_setting and attribution_setting.
Please note, when Apple enforces the AppTrackingTransparency prompt, we will update the default to 7d_click only due to limitations in view-through signal.
New use_unified_attribution_setting field:
This field can be used in GET and POST requests to /adcampaigngroup/insights, /adcampaign/insights, /adgroup/insights, and /adaccount/insights.
If you set use_unified_attribution_setting to true, your query’s conversion metric attribution and campaign optimization will use the attribution_setting of the ad object(s) being queried — a single period of time during which conversions are credited to ads and used to inform campaign optimization.
If use_unified_attribution_setting is set to true, we:
- Cannot aggregate conversion metric values across different attribution settings.
New attribution_setting field:
This field can be used in GET and POST requests to /adcampaigngroup/insights, /adcampaign/insights, /adgroup/insights, and /adaccount/insights. This field is used to indicate which attribution setting is used by a conversion metric. The attribution setting is set at the ad set level during ads creation, and ensures the conversions our system optimizes for are the same ones you want to measure.
For queries of ad objects that are using mixed or SKAdNetwork-dependent settings, attribution_setting will return the following:
- mixed: indicates when a campaign or account has ad sets using multiple attribution settings
- skan: indicates when SKAdNetwork attribution setting is used for iOS 14 app install campaigns
- na: indicates when a campaign or account doesn’t have an ad set within
atribution_setting will return values only when use_unified_attribution_setting is true, else response will not return attribution_setting.
Product Catalog – Image fetching logic
Facebook product catalog, which is a container to hold information about the product items you want to advertise or sell across Facebook’s ecosystem, is used to power various products like Dynamic ads, Collection Ads and Marketplace. Billions of product updates are sent to Facebook on a daily basis, but we don’t fetch images for all the products in the inventory. The following FAQs cover some of the common scenarios.
When are images fetched?
When a feed upload finishes, we don’t schedule fetch for all the items in the catalog. We will schedule the item for image fetch, only when an item has a pixel fire/app event or is pulled in for ad recommendation. Until then, the status of a newly created item will be “Not Fetched”.
When the image url of a previously fetched item is updated, we change the status of the item to “Outdated” and schedule it again for image re-fetch. The item can remain in “Outdated” state, if the image fetch request fails for any reason. Items with outdated images are not filtered out from ad impressions. We will continue to display the previously fetched images for these products.
When are images not fetched?
- If the URL of the item didn’t change but the content behind the URL changed (e.g. sometimes advertiser adds or removes “SALE” sticker), we will not re-fetch the image.
- If the image fetch request failed due to various HTTP errors like service unavailable, request forbidden error, not found error or if the advertiser is throttling Facebook’s requests.
- If the advertiser blocks Facebook image crawler.
- We throttle image fetching for items that modify the image URL without changing the content of the image.
We do not recommend adding a timestamp to the URL to make sure the images are downloaded. There is a high chance that we will stop rescheduling image fetching for those items.
What are the various image fetch statuses?
- If the main image URL of the item could not be fetched, the main image and its additional images will not be updated and the image fetch status of that item will change to “Fetch Failed”.
- If the main image could be fetched but some of the additional images of the item could not be fetched, the image fetch status will be set to “Partial Fetch”.
- Items for which images were not fetched will have “Not Fetched” status.
What happens if I am throttling image fetch requests from Facebook image crawler or if the requests failed for other reasons?
If the image fetch fails consecutively, we will block requests for image fetch for that item for 12 hours. If the fetch requests continue to fail, there is a very high chance that we will not schedule it for image fetch.
What other statuses at product level should I know of?
A product is scheduled for review to ensure it doesn’t violate any policies. Product review status refers to the status of that integrity check. The products are scheduled for review upon pixel fire or app event or product recommendation. We review all text fields and all images that are or can be made visible in an ad via dynamic templates. The status of the review changes to either “Approved” (item is ready to be shown to the users) or “Rejected” (item seems to be violating our policies, users can choose to appeal it). When a previously reviewed product is updated, we reschedule it for review and the status of that product changes to “Outdated”.
Reflecting on a year of innovation with our developer and creator ecosystem
As a team committed to enabling growth and innovation, we feel so honored to create opportunities that drive value for global developers and creators – and the projects, businesses and ideas that matter to them.
By curating events like hackathons and developer jams, as well as providing access to technical resources and our product teams, we’re able to connect innovators with experiences that strengthen their expertise, supercharge their solutions, and offer some great perks and prizes as well.
Harry Banda’s ‘Rabbit Coder’ hackathon submission, built with Spark AR
After running a series of in-person hackathons at the end of last year, we kicked off 2020 with our first-ever Facebook Online Hackathon in February – where we welcomed participants to submit entries across PyTorch, Messenger and Spark AR. We were struck by the potential of so many of the submissions – including a winning entry by Harry Banda of Zambia who used the power of Spark AR to gamify a learn-to-code experience called Rabbit Coder.
Harry, who has competed in all of our hackathons this year, said, “I’ve learned how to create mobile and web applications with React Native, boost my Messenger experiences with artificial intelligence components from Wit.ai, and implement complex gamification using Spark AR. The balance of competition and collaboration within the hackathons motivates me to become a better innovator.”
Gina Choi’s ‘Notes for Heroes’ project from the #BuildforCOVID19 hackathon
When the pandemic triggered widespread lockdowns around the world in March, we put our heads and hearts together with peers from the tech industry, as well as health and science partners including the World Health Organization and UNICEF, to support the #BuildforCOVID19 Global Online Hackathon. This virtual event brought together nearly 19,000 innovators to address a broad set of challenges related to the pandemic.
There were so many important and impactful solutions that came out of the hackathon, but one that continues to move us is high school student Gina Choi’s project, Notes for Support – an online platform for sending notes of gratitude to frontline healthcare workers, and well-wishes to COVID-19 patients. Gina’s web application has so far powered over 11,500 notes to more than 160 hospitals. She even received support from major organizations including the San Francisco 49ers football team, who promoted the service via their Instagram and Facebook channels. You can check out more details on Gina’s solution on this highlighted projects website created by our friends at Hack Club, a student-led coding organization.
Dimas Nashiruddin Al Faruq’s ‘HayLingo!’ hackathon submission, built with Messenger – now a startup!
In May, we continued with our second Facebook Online Hackathon, providing opportunities for developers to build with Messenger, Spark AR and – for the first time – our artificial intelligence product, Wit.ai. The momentum continued with some truly groundbreaking solutions including Indonesia-based Dimas Nashiruddin Al Faruq’s project, HayLingo! – an immersive language learning companion built on Messenger.
“We set out to create a valuable education experience that was both conversational and intuitive. We leveraged Messenger features including Quick Reply, as well as Wit.ai’s natural language processing capabilities, to create a virtual classroom designed to entertain and challenge students. The access to expert resources and documentation provided throughout the hackathon really helped us polish the final solution – so much so, that I’ve now taken the next step and launched HayLingo! as a startup!” – Dimas Nashiruddin Al Faruq
Our third and final hackathon of the year kicked off at the end of July, with a continued focus on supporting builders who are passionate about Messenger, Spark AR and Wit.ai. The hackathon coincided with the launch of Instagram Reels, prompting a range of entertaining and imaginative Spark AR submissions, but we also saw some brilliant Wit.ai solutions too – like Spanish developer Javier Campos’ project, Fitness Voice. Fitness Voice is an AI voice-controlled ‘personal trainer’ for web browsers, leveraging Wit.ai’s natural language processing capabilities, as well as body pose recognition and a strong focus on user privacy.
“I believe that artificial intelligence and natural language processing have the power to revolutionize so many of our day-to-day activities for the better. I created Fitness Voice for people who might not feel safe or healthy working out in public right now. During the hackathon, I was able to join Q&A live streams with Wit.ai product experts, and tap into the buzzing Facebook hackathon community to test out ideas.” – Javier Campos
Javier was also a participant in October’s Wit.ai Developer Jam. This week-long, online event brought together leading Wit.ai developers in late October with the goal of immersing them in AI technology, and providing support as they created solutions for a Design Challenge.
Another participant, US-based AI developer Yu Sun, said, “The troubleshooting advice I received helped me take my solution to the next level and equipped me with a bunch of learnings to apply. Having this direct forum with the Wit.ai team connected me with insights across custom models and built-in entities specifically, which were crucial for my project goals.”
You can learn more about the Jam in the Wit.ai team’s blog here.
Hsing Huang’s Spark AR tutorial from this year’s Developer Circles Community Challenge
Rounding out our final opportunity of 2020, I wanted to recognize the inspiring submissions we received in this year’s Developer Circles Community Challenge.
This time around, we tasked participants with uplifting their fellow innovators by creating tutorials about solutions and code that leverage Facebook products. After our regional winners announcement in November, we were thrilled to reveal the overall global winners last Friday December 18 and shine a light on some brilliant, ecosystem-led documentation across Messenger, PyTorch, React, React Native, Spark AR and Wit.ai.
Our first place winner in the intermediate/advanced category was Taiwan-based creator Hsing Huang, who developed a detailed, step-by-step guide for empowering artists to dive into the technical world of augmented reality by crafting playful pop-up cards with Spark AR.
We can’t wait to continue raising the profile of the winners and their work by showcasing the tutorials on our social and digital channels as catalysts for innovation.
Looking ahead to 2021
Throughout such a challenging year, we’ve been deeply inspired by the resilience and resourcefulness of our ecosystem – and it’s been our privilege to offer support and guidance as they #BuildwithFacebook.
Coming up next year, we have so many fresh and exciting opportunities lined up for our thriving community of innovators. To be among the first to find out about all of the latest experiences, don’t forget to register for our Facebook for Developers newsletter.
And, lastly, on behalf of the whole Facebook team – I just wanted to thank and celebrate everyone who took part in our programs for some truly amazing innovation this year, under the most difficult of circumstances.