Version 2.9

Graph API | Marketing API

變更紀錄項目分為以下類別:

  • 新功能 — 新產品或服務,包括新的節點、關係連線和欄位。
  • 變更項目 — 對既有產品或服務的變更(不包括淘汰項目)。
  • 淘汰項目 — 要移除的既有產品或服務。
  • 90 天期限重大變更 — 版本發佈日期 90 天之後會生效的變更和淘汰項目。

新功能變更項目淘汰項目只會影響這個版本。90 天期限重大變更會影響所有版本。

此處並未包括重大變更,因為重大變更並非與特定版本相關聯。


Graph API

Released April 18, 2017 | Available until July 18, 2019


New Features

General

  • 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.

Pages

  • 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.

Permissions

Places Graph

  • 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 Graph
  • GET /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.

Video APIs

  • 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.

Webhooks

  • 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.


Changes

General

  • 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

Pages

  • /{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.

  • 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.

Posts

  • Backdating a post will no longer update the post's 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.

Video API

  • 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.

Webhooks

  • 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.

Deprecations

Messages

  • GET /{message-id} - The following field has been deprecated:
    • subject
  • GET /{thread-id} - The following field has been deprecated:
    • tags

90-Day Breaking Changes

  • 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 dialogs

Video

  • Insights Edge - All paid and organic metrics are deprecated.

Webhooks

  • 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 第 2.9 版新功能

廣告創意

透過行銷 API 在 Facebook 上建立全螢幕互動廣告行銷活動。廣告商可透過聲光效果動人的影片格式,有效地同時達到品牌和成效型廣告目標。詳情請參閱行銷 API:全螢幕互動廣告

動態廣告

  • 動態廣告目錄品質 - 我們推出新的 API 以協助您成功刊登動態廣告: 檢查 API 和品質 API。利用檢查 API,您可驗證信號來源是否提供足夠資訊,以透過動態廣告投遞適合的廣告。利用品質 API,您可檢查並驗證目錄和動態是否有足夠的高品質資訊,以投遞動態廣告。如需詳細資訊,請參閱動態廣告:目錄和信號品質

  • 單一項目的多個圖像 - 在輪播格式的動態廣告中,顯示同一項目的多個圖像。我們現在對於輪播格式的動態廣告,可支援以最多 20 個目錄圖像代表同一項目。這可讓您使用多個圖像來展示單一項目,如旅館或目的地。我們提供新的選項以支援此一功能:force_single_link = trueshow_multiple_images = true。如需詳情,請參閱動態廣告:廣告管理中的廣告創意範本

廣告管理

  • 廣告文案 - 您現在可利用廣告文案 API 來複製現有的行銷活動、廣告組合和廣告。透過這種方式,您無需每次從頭重新建立廣告,而是複製成效卓越的廣告,以及建立廣告範本架構。請參閱廣告創意、刊登版位和畫面預覽

  • 預估單日觸及人數 - 我們在廣告帳號和廣告組合層級提供新的端點 /delivery_estimate。這個端點可讓您針對指定廣告組合,取得預估出價,以及單日觸及人數和轉換率的預測成果。請參閱目標設定:預估單日觸及人數

  • 規則引擎 API — 您可使用規則引擎 API,根據所設定的商業規則,以更簡便快速且更具智能的方式管理廣告。規則引擎採用推播式模型,您無需持續查詢 API 來取得廣告最新資訊,而是在符合規則條件時,由我們主動向您傳送推播通知並執行指定動作。請前往此處深入瞭解規則引擎 API。

  • 批次 API - 將要求集合起來,然後非同步地傳送要求。將多個圖形 API 呼叫集合成一個 HTTP 要求,然後非同步地執行這些呼叫,而無需封鎖。您也可以指定相關作業之間的相依性。Facebook 會以平行流程處理每一項獨立作業,並且循序處理相依作業。 請參閱非同步和批次要求:批次 API

廣告版位

  • 有效廣告版位 - 您可在目標設定規格中指定廣告版位,不過您無法得知 Facebook 是否確實將廣告投遞到所有版位。如果您對指定廣告目標選擇了無效版位,Facebook 並不會在該版位投遞廣告。過去您必須刊登廣告並進行實驗,才能確定實際成果為何。透過 effective_ 版位 API,您可針對所選擇的版位和指定的廣告目標,確定 Facebook 實際投遞的廣告版位。透過建議 API,您還可瞭解部分版位遭篩選掉的原因。請參閱目標設定進階選項與有效版位

行銷 API 第 2.9 版重大變更

廣告管理

  • 推薦影片版位 - 這是 Facebook 動態版位的一部分;如果您使用動態版位,便會自動選擇使用此一版位。在第 2.9 版中,我們將「推薦影片」版位從動態版位中分離出來,所以即使您選擇使用動態版位,也能選擇不使用「推薦影片」版位。在第 2.8 版和更早版本中,如果您選擇使用 Facebook 動態版位,我們不再自動將您的廣告投遞到「推薦影片」。

  • 打響本地市場知名度目標 - 我們已淘汰這項行銷活動目標 LOCAL_AWARENESS。在第 2.9 版中,我們不會接受以 LOCAL_AWARENESS 作為目標來建立新的行銷活動。若要以單一地點廣告組合打響本地市場知名度,請使用 REACH 目標建立行銷活動。我們不再支援多個地點的 LOCAL_AWARENESS。如果您現有的行銷活動仍有這個目標,您還是可讀取或編輯這項行銷活動,並且可在其中建立新的廣告組合和廣告。如果您複製現有的行銷活動,可否成功複製將取決於該行銷活動的類型。如果原本指定 LOCAL_AWARENESS 和單一地點,我們會在複製時指定 REACH。如果原本指定 LOCAL_AWARENESS 和多個地點,您將無法複製行銷活動。

  • 行動廣告目標 - 為了簡化行動廣告目標,我們將淘汰 CanvasAppEngagementCanvasAppInstallsMobileAppInstallsMobileAppEngagement。這些行動廣告目標分別又稱為 CAEMAECAIMAI。從第 2.9 版起,您無法在建立新的行銷活動時使用這四個目標。我們會轉而支援:

    • 對於 LINK_CLICKS 行銷活動的 CAE 廣告組合,您需要使用 LINK_CLICKS,才能建立 CAE 廣告的行銷活動。

    • 對於行銷活動目標為 LINK_CLICKSCONVERSIONSMAE 廣告組合,您應改為使用 LINK_CLICKSCONVERSIONS 來建立 MAE 廣告的行銷活動。

    • 對於目標為 APP_INSTALLSCAI 廣告組合,您應該使用 APP_INSTALLS 來建立 CAI 廣告的行銷活動。

    • 對於目標為 APP_INSTALLSMAI,您應該使用 APP_INSTALLS 來建立 MAI 廣告的行銷活動。

  • 行動廣告目標相容性 - 當您複製含行銷 API 或 Facebook 工具的 CAEMAECAIMAI 行銷活動時,我們會自動將這些淘汰的目標轉譯為第 2.9 版中的同等目標。

    • MAICAI 行銷活動會轉換為 APP_INSTALLS 目標。

    • CAE 行銷活動會轉換為 LINK_CLICKS 行銷活動。

    • 根據您為行銷活動中廣告組合提供的最佳化,MAE 行銷活動會轉換為 LINK_LICKSCONVERSIONS 行銷活動。如果有任何針對 OFFSITE_CONVERSION 進行最佳化的子廣告組合,我們會將 MAE 行銷活動轉換為 CONVERSIONS 行銷活動,或是將 MAE 行銷活動轉譯為 LINK_CLICKS 行銷活動。

  • 封鎖類別 - 我們淘汰部分 Audience Network、插播影片和即時文章類別,而在這些版位中改用更統一的類別。這些類別可讓您防止廣告顯示某些令人反感的內容,例如賭博、酒類等相關內容。politicsreligion 類別已淘汰。您可使用以下類別:

    • 對於即時文章和 Audience Network:debated_social_issuesmature_audiencestragedy_and_conflictdatinggambling

    • 對於插播影片:debated_social_issuesmature_audiencestragedy_and_conflict

  • 廣告帳號和廣告層級的廣告創意中已淘汰 SUPPLEMENTAL_MEDIA_ID。您無法再讀取這個欄位。

  • 廣告創意中已淘汰 ACTION_SPEC。這原本用於現已不再支援的動態贊助。

  • 廣告創意中的 actor_image_hashactor_image_urlactor_name 欄位已經在第 2.9 版和第 2.8 版中淘汰。這些原本用於也已淘汰的 action_spec

  • 廣告創意中 call_to_actionlink_titlelink_description 已淘汰。若要設定廣告創意的標題和說明,請使用 link_data 中的 namedescription,或是 video_data 中的 titlelink_description

  • run_status=3 - 您過去能夠刪除含這個欄位值的廣告創意。這造成一些困惑,所以我們將 run_status 重新命名為 status,並且將其值從整數變更為字串值 DELETED。若要刪除廣告創意,請使用 status=DELETED

  • 廣告創意端點上 GETCOVER_PHOTO_ID 中已淘汰 {creative_id}{ad_account_id}/adcreatives。這些欄位極少使用,並且僅供內部使用,且用途有限。

  • image_urlimage_hash - 您現在只可在廣告創意 object_story_specvideo_data 中提供其中一個。請參閱廣告創意參考文件

  • 廣告創意端點上 GETOBJECT_INSTAGRAM_ID 已淘汰,包括 {creative_id}AD_ACCOUNT_ID/adcreatives。這個欄位並不供外部使用。

  • 在第 2.8 版和更早版本中,instagram_story_id 是用於擷取廣告創意中的 Instagram 貼文編號。如果您在提供廣告創意時使用這個欄位,我們會擲回例外狀況,但忽略這個參數,然後傳回結果和 instagram_story_id。如果您採用回應,會發生錯誤。為了解決這個問題,我們將 instagram_story_id 重新命名為 effective_instagram_story_id,而您也不應使用這個欄位來提供廣告創意。

  • 所有廣告物件的 spenttoday_spentyesterday_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_idpixel_rulepixel_aggregation_rule 的欄位。因為我們新增對於離線轉換資料及應用程式自訂轉換資料的支援,我們重新標示欄位,以表示擴大涵蓋範圍。這些欄位現在稱為 event_source_idruleaggregation_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_satlast_week_mon_sun 取代

    • this_week 已由 this_week_sun_todaythis_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_impressionunique_social_impressions 已淘汰。請改用 reachsocial_reach

  • newsfeed_clicksnewsfeed_impressionsnewsfeed_avg_positionvideo_avg_sec_watched_actionsvideo_avg_pct_watched_actions 是將要淘汰的過時指標。

  • 以下歸屬於 action_type: 的指標已淘汰:followgift_salevideo_playvote

  • 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,只會移除瀏覽歸因期間。