變更紀錄項目分為以下類別:
新功能、變更項目和淘汰項目只會影響這個版本。90 天期限重大變更會影響所有版本。
此處並未包括重大變更,因為重大變更並非與特定版本相關聯。
Released April 18, 2017 | Available until July 18, 2019
Read After Write - Graph API POST
requests now support returning specified values of an object during the same request as a write, saving a round trip for clients. If a fields
parameter is specified (explanation of the syntax), the request will first do the write, then read the created or updated object, selecting fields using the fields
parameter, as the response. Read-after-write is now enabled for all versions of the Graph API. Visit our docs page to learn more.
New short_names
Field on the User Object - The following field has been added to the user
endpoint:
short_name
- first_name
assumes the universally friendly way to refer to a person is by their first name. However, in many cultures (especially Chinese, Japanese, Korean, Thai, Indic, and a few others), it's inappropriate to address people by their first name. The new short_name method understands the culture-specific rules for how to address a person with a short name. So, for a viewer in the US, they'll continue to see friends in China, Japan, Korea, and India addressed by their first name, but their friends in East and South Asia will see friends with full names.Business App Page Mapping - The user
node has two new edges, ids_for_pages
and ids_for_apps
, for de-referencing a person's ID for an app or a page. The ids_for_pages
edge returns other IDs that person has for pages owned by the same business. Similarly, the ids_for_apps
edge returns other IDs that person has for apps owned by the same business. See Connecting with People Across Apps and Bots in Messenger.
Page POST Support to Add Pages to Crosspost Videos - Approve and accept a crossposting relationships request from another page by POST /{page_id}/crossposting_pages
.
Webhooks IDs Are Serialized as Strings - Numeric IDs are converted to strings in this webhooks update.
Granular Permissions - This new feature gives people more control over managed object permissions. During the login step, if a permission related to pages, business, or groups is granted, the user will have the option to select which managed objects the permission applies to. This means that you might see fewer pages, businesses and groups. Users can manage the following permissions at a granular level:
Current Place - The following fields have been added:
GET /current_place/results
- Helps determine what place a person is currently at by using location signals. User permission is required.POST /current_place/feedback
- Allows you to provide feedback about whether they were actually there. For more information, see Places GraphGET /search?type=place
- The following parameters have been added:
categories
- Search by category.matched_categories
- Indicate which categories the resulting place matches. Must be used with categories
.Time Spent in Video Metrics for Page - The following metrics have been added. For more information, see Insights Metric /{object-id}/insights/{metric}.
page_video_view_time
- The time spent on videos on the page.post_video_view_time_by_country_id
- The time spent on videos on the page by country. Apps Can Receive Changed Values for User's Profile Updates with Webhooks Updates - When a user changes a field, your app can receive the new value as part of the update, saving the step of checking the value. Previously, whenever a user changed one of their fields, we would notify the app of the field that changed without sending the new value.
Documentation - Webhooks now has reference documentation for topics and fields you can subscribe to. This documentation is on Facebook Developers site under Webhooks Reference in the Graph API.
Sample Sender Tool - The new tool makes it easier for developers to test out the Webhooks update structure before subscribing to the topic. In the past, developers had to subscribe to a field and then try to trigger the update by making a change through Facebook. For example, an app might need to know when a user (users that installed the app and granted needed permissions) changes their profile picture. The app would subscribe to the profile picture field in the Webhooks framework. However, to test how this works, you had to change the profile picture on some user that had installed the app to see the structure of the update we send. The sample sender tool allows apps to test the update structure without having to make an unnecessary change. You can find the sample sender tool in the webhooks section of your app's dashboard.
Versioning - Webhooks versions are now the same as Graph API. Any existing Webhooks subscriptions will be running on the oldest supported version of the app. Previously, Webhooks subscriptions didn't support versioning. The only way to make changes was by making breaking changes. For more information on Webhooks versions, see Versioning.
The Batch API returns an error rather than a null response for aborted request items in the Batch API. For more information, see Graph API, Making Batch Requests.
GET /{url}/share
- The share
endpoint has been removed and replaced with:
engagement
field with subfields:
comment_count
comment_plugin_count
reaction_count
share_count
/{page-id}/feed
- Backdated posts are included in the {page_id}/feed
request if the backdated_time
of the post is within the since
and until
time range. The created_time
is the actual creation time. (See changes to Posts below.)
page-restaurant-services
- All fields now return false
or true
instead of 0
or 1
.
overall_star_rating
— If there are 0 or a small number of ratings, the overall_star_rating
field will not be returned. GET /{post-id}
- The following field has been added to this endpoint:
promotable_id
- Previously, certain posts could not be promoted, only their contents. In such cases, the id
field would return the contents ID, rather than the ID for the post. Posts now always return their own ID in the id
field, and a new field, promotable_id
, is added to the GET {post-id}
endpoint to be used when promoting the post.created_time
value. Instead, it will duplicate the original, but with created_time
and backdated_time
set to the new value. The original post will keep its old created_time
value and gain the new backdated_time
and value. Finally, GET {post-id}/feed
will no longer return the original post, but instead will return the newly created duplicate.Expose dash preview URL for live video instead of RTMP URL.
GET /{page_id}/crosspost_pending_approval_pages
- List all the Pages your Page has sent crossposting requests, but that have not accepted yet.
GET /{page_id}/crosspost_whitelisted_pages
- List all the pages you have given crossposting permission.
POST /{video_id}/allow_crossposting_for_pages = [{"page_id": {page_id}, "allow": {true/false}]
- Allow or disallow the permission for certain Pages in your crossposting allow list to crosspost a specific video.
POST /{page_id}/crossposting_pages=[{"page_id": {page_id}, "allow": false, "action": "EXPIRE_ALL_CROSSPOSTS_ON_SHARED_ASSETS"}]
- Remove pages from your crossposting allow list and expire all previously crossposted content.
POST /{page_id}/crossposting_pages=[{"page_id": {page_id}, "allow": false, "action": "NO_ACTION"}]
- Remove pages from your crossposting allow list without affecting previously crossposted content.
GET /{app-id}/subscriptions
- This endpoint now returns versions for fields. Before Webhooks versioning was introduced, the endpoint returned only a list of subscribed fields. Now the endpoints return the list of fields with their respective versions.GET /{message-id}
- The following field has been deprecated:
subject
GET /{thread-id}
- The following field has been deprecated:
tags
The following fields are deprecated for edges and dialogs that allow attaching links to posts:
caption
description
name
picture
thumbnail
The edges and dialogs for which these are deprecated include:
POST /{event-id}/feed
POST /{group-id}/feed
POST /{page-id}/feed
POST /{user-id}/feed
share
and feed
dialogspaid
and organic
metrics are deprecated. The following Webhooks fields from the user topic are deprecated:
about_me
birthday_date
contact_email
current_location
education_history
hometown_location
sex
statuses
tv
work_history
Instead use:
about
birthday
education
email
gender
hometown
location
status
television
work
透過行銷 API 在 Facebook 上建立全螢幕互動廣告行銷活動。廣告商可透過聲光效果動人的影片格式,有效地同時達到品牌和成效型廣告目標。詳情請參閱行銷 API:全螢幕互動廣告。
動態廣告目錄品質 - 我們推出新的 API 以協助您成功刊登動態廣告: 檢查 API 和品質 API。利用檢查 API,您可驗證信號來源是否提供足夠資訊,以透過動態廣告投遞適合的廣告。利用品質 API,您可檢查並驗證目錄和動態是否有足夠的高品質資訊,以投遞動態廣告。如需詳細資訊,請參閱動態廣告:目錄和信號品質。
單一項目的多個圖像 - 在輪播格式的動態廣告中,顯示同一項目的多個圖像。我們現在對於輪播格式的動態廣告,可支援以最多 20 個目錄圖像代表同一項目。這可讓您使用多個圖像來展示單一項目,如旅館或目的地。我們提供新的選項以支援此一功能:force_single_link = true
和 show_multiple_images = true
。如需詳情,請參閱動態廣告:廣告管理中的廣告創意範本。
廣告文案 - 您現在可利用廣告文案 API 來複製現有的行銷活動、廣告組合和廣告。透過這種方式,您無需每次從頭重新建立廣告,而是複製成效卓越的廣告,以及建立廣告範本架構。請參閱廣告創意、刊登版位和畫面預覽。
預估單日觸及人數 - 我們在廣告帳號和廣告組合層級提供新的端點 /delivery_estimate
。這個端點可讓您針對指定廣告組合,取得預估出價,以及單日觸及人數和轉換率的預測成果。請參閱目標設定:預估單日觸及人數。
規則引擎 API — 您可使用規則引擎 API,根據所設定的商業規則,以更簡便快速且更具智能的方式管理廣告。規則引擎採用推播式模型,您無需持續查詢 API 來取得廣告最新資訊,而是在符合規則條件時,由我們主動向您傳送推播通知並執行指定動作。請前往此處深入瞭解規則引擎 API。
批次 API - 將要求集合起來,然後非同步地傳送要求。將多個圖形 API 呼叫集合成一個 HTTP 要求,然後非同步地執行這些呼叫,而無需封鎖。您也可以指定相關作業之間的相依性。Facebook 會以平行流程處理每一項獨立作業,並且循序處理相依作業。 請參閱非同步和批次要求:批次 API。
effective_
版位 API,您可針對所選擇的版位和指定的廣告目標,確定 Facebook 實際投遞的廣告版位。透過建議 API,您還可瞭解部分版位遭篩選掉的原因。請參閱目標設定進階選項與有效版位。推薦影片版位 - 這是 Facebook 動態版位的一部分;如果您使用動態版位,便會自動選擇使用此一版位。在第 2.9 版中,我們將「推薦影片」版位從動態版位中分離出來,所以即使您選擇使用動態版位,也能選擇不使用「推薦影片」版位。在第 2.8 版和更早版本中,如果您選擇使用 Facebook 動態版位,我們不再自動將您的廣告投遞到「推薦影片」。
打響本地市場知名度目標 - 我們已淘汰這項行銷活動目標 LOCAL_AWARENESS
。在第 2.9 版中,我們不會接受以 LOCAL_AWARENESS
作為目標來建立新的行銷活動。若要以單一地點廣告組合打響本地市場知名度,請使用 REACH
目標建立行銷活動。我們不再支援多個地點的 LOCAL_AWARENESS
。如果您現有的行銷活動仍有這個目標,您還是可讀取或編輯這項行銷活動,並且可在其中建立新的廣告組合和廣告。如果您複製現有的行銷活動,可否成功複製將取決於該行銷活動的類型。如果原本指定 LOCAL_AWARENESS
和單一地點,我們會在複製時指定 REACH
。如果原本指定 LOCAL_AWARENESS
和多個地點,您將無法複製行銷活動。
行動廣告目標 - 為了簡化行動廣告目標,我們將淘汰 CanvasAppEngagement
、CanvasAppInstalls
、MobileAppInstalls
及 MobileAppEngagement
。這些行動廣告目標分別又稱為 CAE
、MAE
、CAI
及 MAI
。從第 2.9 版起,您無法在建立新的行銷活動時使用這四個目標。我們會轉而支援:
對於 LINK_CLICKS
行銷活動的 CAE
廣告組合,您需要使用 LINK_CLICKS
,才能建立 CAE 廣告的行銷活動。
對於行銷活動目標為 LINK_CLICKS
或 CONVERSIONS
的 MAE
廣告組合,您應改為使用 LINK_CLICKS
或 CONVERSIONS
來建立 MAE 廣告的行銷活動。
對於目標為 APP_INSTALLS
的 CAI
廣告組合,您應該使用 APP_INSTALLS
來建立 CAI 廣告的行銷活動。
對於目標為 APP_INSTALLS
的 MAI
,您應該使用 APP_INSTALLS
來建立 MAI 廣告的行銷活動。
行動廣告目標相容性 - 當您複製含行銷 API 或 Facebook 工具的 CAE
、MAE
、CAI
和 MAI
行銷活動時,我們會自動將這些淘汰的目標轉譯為第 2.9 版中的同等目標。
MAI
或 CAI
行銷活動會轉換為 APP_INSTALLS
目標。
CAE
行銷活動會轉換為 LINK_CLICKS
行銷活動。
根據您為行銷活動中廣告組合提供的最佳化,MAE
行銷活動會轉換為 LINK_LICKS
或 CONVERSIONS
行銷活動。如果有任何針對 OFFSITE_CONVERSION
進行最佳化的子廣告組合,我們會將 MAE
行銷活動轉換為 CONVERSIONS
行銷活動,或是將 MAE
行銷活動轉譯為 LINK_CLICKS
行銷活動。
封鎖類別 - 我們淘汰部分 Audience Network、插播影片和即時文章類別,而在這些版位中改用更統一的類別。這些類別可讓您防止廣告顯示某些令人反感的內容,例如賭博、酒類等相關內容。politics
和 religion
類別已淘汰。您可使用以下類別:
對於即時文章和 Audience Network:debated_social_issues
、mature_audiences
、tragedy_and_conflict
、dating
、gambling
。
對於插播影片:debated_social_issues
、mature_audiences
、tragedy_and_conflict
。
廣告帳號和廣告層級的廣告創意中已淘汰 SUPPLEMENTAL_MEDIA_ID
。您無法再讀取這個欄位。
廣告創意中已淘汰 ACTION_SPEC
。這原本用於現已不再支援的動態贊助。
廣告創意中的 actor_image_hash
、actor_image_url
和 actor_name
欄位已經在第 2.9 版和第 2.8 版中淘汰。這些原本用於也已淘汰的 action_spec
。
廣告創意中 call_to_action
的 link_title
和 link_description
已淘汰。若要設定廣告創意的標題和說明,請使用 link_data
中的 name
和 description
,或是 video_data
中的 title
和 link_description
。
run_status=3
- 您過去能夠刪除含這個欄位值的廣告創意。這造成一些困惑,所以我們將 run_status
重新命名為 status
,並且將其值從整數變更為字串值 DELETED
。若要刪除廣告創意,請使用 status=DELETED
。
廣告創意端點上 GET
的 COVER_PHOTO_ID
中已淘汰 {creative_id}
和 {ad_account_id}/adcreatives
。這些欄位極少使用,並且僅供內部使用,且用途有限。
image_url
或 image_hash
- 您現在只可在廣告創意 object_story_spec
的 video_data
中提供其中一個。請參閱廣告創意參考文件。
廣告創意端點上 GET
的 OBJECT_INSTAGRAM_ID
已淘汰,包括 {creative_id}
和 AD_ACCOUNT_ID/adcreatives
。這個欄位並不供外部使用。
在第 2.8 版和更早版本中,instagram_story_id
是用於擷取廣告創意中的 Instagram 貼文編號。如果您在提供廣告創意時使用這個欄位,我們會擲回例外狀況,但忽略這個參數,然後傳回結果和 instagram_story_id
。如果您採用回應,會發生錯誤。為了解決這個問題,我們將 instagram_story_id
重新命名為 effective_instagram_story_id
,而您也不應使用這個欄位來提供廣告創意。
所有廣告物件的 spent
、today_spent
和 yesterday_spent
傳回類型現在都是 String
,而不是 Integer
。這項變更會影響行銷活動、廣告組合和廣告。
不可有相同產品組合 - 我們不再允許同一產品目錄中有相同的產品組合。如果您嘗試從同一產品目錄建立相同的產品組合,API 會傳回 FacebookApiException
,錯誤碼為 10803
,並包含該相同產品組合的編號。
POST /{product_feed_id}
中的 quoted_fields
已淘汰。在第 2.6 版中,我們移除 POST /{product_feed_id/product_feeds}
中的 quoted_fields
。經過進一步的清理作業,我們現在也淘汰了這個欄位。
為了持續改善動態廣告產品目錄,POST {catalog-id}/batch
端點現在會傳回 STRING
。
template_url_spec
已取代 template_url
。這可讓您執行點擊追蹤,並且將產品目錄網址以外的內容特定網址置入廣告。例如,在廣告中置入用戶選擇的進房和退房日期。請參閱動態廣告:廣告管理。
重新命名事件來源 - 過去當您建立或查詢自訂轉換時,您會使用標示為 pixel_id
、pixel_rule
和 pixel_aggregation_rule
的欄位。因為我們新增對於離線轉換資料及應用程式自訂轉換資料的支援,我們重新標示欄位,以表示擴大涵蓋範圍。這些欄位現在稱為 event_source_id
、rule
和 aggregation_rule
。
廣告轉換追蹤像素 - 這項功能已在 2017 年 2 月 15 日淘汰。同時,我們也移除了 API 所有版本中建立、更新、讀取或參照廣告轉換追蹤像素所用的所有關係連線和節點。
與事件編號相關聯的 friends_of_connection
已經從廣告目標設定選項中淘汰。這表示您無法將目標設定為已接受您 Facebook 事件邀請的用戶的朋友。
delivery_estimate
支援 - 我們變更觸及人數預估,以支援新推出的 delivery_estimate
:
已從 /reach_estimates
端點移除 bid_estimations
欄位,並已將所有記錄的功能移至 /delivery_estimate
/AD_ID/reachestimate
已淘汰。若要存取這項資訊,請使用 /ADSET_ID/delivery_estimate
。
移除 data
欄位。
date_preset
淘汰項目 - 我們淘汰數個 date_preset
值,並以新值取代。新值更容易使用、貼合廣告商實際需求,且不再包含當日資料。舉例來說,在 2 月 8 日發出的要求中使用「過去 7 天」的預設日期範圍,產生的分析報告會包含從 2 月 1 日到 2 月 7 日下午 11:59(含)的資料,而不包含 2 月 8 日的資料。以下的值已淘汰:
last_3_days
已由 last_3d
取代
last_7_days
已由 last_7d
取代
last_14_days
已由 last_14d
取代
last_28_days
已由 last_28d
取代
last_30_days
已由 last_30d
取代
last_90_days
已由 last_90d
取代
last_week
已由 last_week_sun_sat
和 last_week_mon_sun
取代
this_week
已由 this_week_sun_today
和 this_week_mon_today
取代
last_3_months
已淘汰。
對於第 2.8 版和更早版本,我們同時支援這些新值和舊有的日期預設值。
預設 date_preset
- 如果您在發出洞察報告查詢時未使用 date_preset
,原先預設會使用 last_30_days
,這會包含從今天早上 12:00(以廣告帳號的時區為準)起的活動。在第 2.9 版中,這個預設值變更為 last_30d
。這會包含過去完整 30 天(截至您帳號所設時區的昨晚 11:59),且不包含今天。
video_complete_watched_actions
已淘汰。其提供的資訊和 video_30_sec_watched_actions
相同。
unique_impression
和 unique_social_impressions
已淘汰。請改用 reach
和 social_reach
。
newsfeed_clicks
、newsfeed_impressions
、newsfeed_avg_position
、video_avg_sec_watched_actions
、video_avg_pct_watched_actions
是將要淘汰的過時指標。
以下歸屬於 action_type:
的指標已淘汰:follow
、gift_sale
、video_play
及 vote
。
click_to_play_video
現在可透過 action_video_type
資料解析存取。
洞察報告 API 中投遞資料的 placement
資料解析欄位已淘汰。第 2.9 版僅支援 ["publisher_platform", "platform_position"]
。第 2.8 版仍然支援 ["placement"]
或 ["publisher_platform", "platform_position"]
做為資料解析。
attribution_spec
- 您過去會使用洞察報告 API 中的點閱和瀏覽歸因期間兩個不同欄位。您現在應該使用 attribution_spec
來設定這兩個歸因期間。當您設定 attribution_spec
,會覆寫任何現有設定。如果您原先設定了點閱和瀏覽歸因期間,當您將 attribution_spec
設為 event_type = CLICK_THROUGH
,只會移除瀏覽歸因期間。