หากคุณได้รับข้อความแสดงข้อผิดพลาด อย่างเช่น “ขออภัย มีบางอย่างผิดปกติ” และไม่สามารถระบุสาเหตุได้ในขณะนี้ คุณมีอีกทางเลือกคือเปิดดูรายละเอียดเพิ่มเติมของข้อความแสดงข้อผิดพลาด ซึ่งอาจแสดงข้อมูลให้คุณดำเนินการเองได้ อ่านเอกสารเพิ่มเติมเกี่ยวกับการแก้ไขจุดบกพร่องที่รายงานไปยังวิธีการ init() ของ SDK ที่ https://developers.facebook.com/docs/accountkit/webjs/reference

การตรวจสอบยืนยันด่วนของ Account Kit จะข้ามความจำเป็นในการใช้รหัสยืนยันทาง SMS เมื่อผู้บริโภค Android ป้อนหมายเลขโทรศัพท์มือถือที่ตรงกับหนึ่งในหมายเลขที่ระบุไว้บน Facebook

ซึ่งจะสามารถทำได้ก็ต่อเมื่อบุคคลดังกล่าวใช้แอพ Facebook สำหรับ Android เท่านั้น หากเราไม่สามารถยืนยันการจับคู่ ระบบจะนำบุคคลดังกล่าวผ่านขั้นตอนตามปกติและรับรหัสยืนยันทาง SMS

Account Kit จะแสดง UI ที่แปลแล้วสำหรับภาษาที่อยู่ในรายการนี้: https://developers.facebook.com/docs/accountkit/languages

โปรดดูรายชื่อประเทศที่อัพเดตได้ที่นี่ รวมถึงรหัสโทรศัพท์ที่รองรับ: https://developers.facebook.com/docs/accountkit/countrycodes

ไม่ได้ เรารองรับเฉพาะการเชื่อมโยง JS SDK ผ่านทาง https://sdk.accountkit.com/en_US/sdk.js เท่านั้น สคริปต์นี้จะเรียกตัวโหลด SDK ซึ่งจะโหลด SDK ล่าสุดจาก accountkit.com หรือแคชของบราวเซอร์

สำหรับกรณีที่คุณต้องการโฮสต์ SDK ผ่านเซิร์ฟเวอร์ของคุณเอง คุณจะมีระยะเวลาผ่อนผัน 24 ชั่วโมง หลังจากระยะเวลาผ่อนผัน SDK จะเริ่มการเตือนและหยุดการทำงานหลังจากนั้น 7 วัน

กำหนดพารามิเตอร์ enableSendToFacebook (บน iOS) หรือ setFacebookNotificationsEnabled (บน Android) เป็น True

ผู้ใช้ที่เข้าสู่ระบบของแอพคุณจะได้รับข้อความยืนยันผ่านการแจ้งเตือนบน Facebook หากไม่สามารถส่ง SMS ได้ และหากหมายเลขโทรศัพท์มือถือที่ใช้เป็นหมายเลขโทรศัพท์มือถือหลักที่เกี่ยวข้องกับบัญชีผู้ใช้ Facebook

คุณจะต้องเพิ่มสิทธิ์การอนุญาตอินเทอร์เน็ตเพื่อเรียกข้อมูลวิธีการ API นอกจากนี้คุณยังสามารถเลือกที่จะเพิ่มสิทธิ์การอนุญาตเพิ่มเติม เพื่อลดความยุ่งยากในระหว่างขั้นตอนการเข้าสู่ระบบ

• สำหรับการเข้าถึงข้อความ SMS ให้เพิ่มสิทธิ์การอนุญาตRECEIVE_SMSและREAD_PHONE_STATE
• สำหรับฟีเจอร์อีเมล ให้เพิ่มสิทธิ์การอนุญาตGET_ACCOUNTS

คุณสามารถค้นหาเพิ่มเติมเกี่ยวกับการผสานรวมการทำงาน Account Kit ในแอพ Android ของคุณที่นี่

เมื่อผู้ใช้เปิดกล่องการแชร์บนมือถือหรือกล่องการแชร์บนฟีดบนมือถือ แต่ปิดกล่องไปโดยการยกเลิก แอพของคุณจะได้รับการแจ้งเตือนเกี่ยวกับการดำเนินการนี้ผ่านวิธีการเรียกกลับ onSuccess() คุณสามารถเปรียบเทียบว่าการเรียกกลับ onSuccess() เป็นกลไกหนึ่งที่ส่งสัญญาณว่ากล่องโต้ตอบนั้นปิดลงอย่างเสร็จสิ้นแล้วด้วยวิธีใดก็ตาม แต่คุณไม่สามารถใช้เพื่อทราบได้ว่ามีสิ่งที่โพสต์ไปแล้วจริงๆ หรือไม่ หากผู้ใช้ให้ขอบเขตสิทธิ์อนุญาต "publish_actions" แก่แอพของคุณ วิธีการเรียกกลับ onCancel() จะถูกเรียกใช้เมื่อทำการยกเลิก

หากต้องการดูรายละเอียดแบบเต็มเกี่ยวกับประเภทของ FacebookCallback โปรดดูเอกสารอ้างอิง

ปุ่มถูกใจแบบเนทีฟ (LikeView) ทำงานเหมือนกับปุ่มถูกใจบนเว็บ URL บน Facebook ส่วนมากไม่สามารถใช้ได้เนื่องจากความเป็นส่วนตัว ข้อยกเว้นรวมถึงเพจบน Facebook และหน้าหลักของ Facebook

คุณสามารถตรวจสอบเบื้องต้นได้โดยใช้ตัวแสดงตัวอย่างปุ่มถูกใจ

กรณีเป็นการกำหนดไว้แล้ว เราได้เห็นการรายงานสแปมหลายรายการ และการทำงานที่ไม่เหมาะสมของคุณสมบัตินี้ และเพื่อเป็นการปรับปรุงประสบการณ์ผู้ใช้โดยรวม เราตัดสินใจบังคับใช้การเปลี่ยนแปลงนี้

ดูเอกสารวิธีที่ดีกว่าในการแชร์ที่รวบรวมไว้ในเอกสารที่นี่

We’ve moved all Messenger permissions to the Permissions and Features page.

We've consolidated this into one Permissions and Features page for Business apps, where you can see what access levels you have for each permission and feature.

Yes, developers may opt out of the Business app type and return to the previous App Review process for their app by selecting “Change App Type” on the App Dashboard. However, developers may not opt back into the Business app type and will need to create a new app to do so.

Additionally, apps previously in Development Mode that opt out to the legacy experience that have been approved for Advanced Access via App Review in the new model will lose access to data beyond what their business or anyone with a role on their app owns until they turn their app to Live Mode.

No.

We have replaced Development and Live Mode with Standard and Advanced Access. Standard Access is always active and allows you to access data that a developer’s business or anyone with a role on their app owns. You may submit for App Review for permissions and features to access data owned by other businesses or people. Refer to our Access Levels document to learn more.

To access one of these fields, you will need to submit for Advanced Access for the Business Asset User Profile Access feature through App Review.

Business apps designed to help businesses and organizations manage Pages, Groups, Events, Ads, and ad-related assets.

• แอพดังกล่าวถูกย้ายไปยังธุรกิจอื่นที่ไม่ได้รับการตรวจสอบยืนยัน สิทธิ์การอนุญาตทั้งหมดที่ได้รับการอนุมัติไปก่อนหน้านี้จะถูกบล็อก

  • หากมีการย้ายแอพกลับมายังธุรกิจที่ได้รับการตรวจสอบยืนยันแล้ว สิทธิ์การอนุญาตก็จะได้รับการปลดบล็อก
• โดยระบบจะทำเครื่องหมายแอพว่าให้บริการแก่ธุรกิจอื่น แต่หลังจากนั้น ระบบจะย้ายแอพไปยังธุรกิจอื่นที่ยังไม่ได้รับการตรวจสอบยืนยัน

Yes, ALL apps that leverage permissions that require review (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions, Marketing API and Lead Ads API) must submit for app review in adherence with the communicated deadlines.

Active apps that leverage permissions with an August 1st deadline (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions) and have not yet proactively submitted for review will be auto-enrolled in the review process. You can accelerate the App Review process by submitting your app for review prior to auto-enrollment. This will give you more control over when your app is reviewed and what information is used for the review.

โปรดดูข้อมูลเพิ่มเติมที่หน้านี้ กระบวนการตรวจสอบแอพจะช่วยเปิดโอกาสให้คุณได้แจ้งรายละเอียดเกี่ยวกับสิทธิ์การอนุญาตต่างๆ ที่คุณต้องการและวิธีการนำสิทธิ์เหล่านั้นไปใช้ Facebook จะตรวจสอบกรณีการใช้งานนั้นและพิจารณาว่าสามารถอนุญาตภายใต้นโยบายของเราได้หรือไม่ หลังจากตรวจสอบสิทธิ์การอนุญาตแล้ว เราอาจมีข้อกำหนดเพิ่มเติม เช่น การตรวจสอบยืนยันธุรกิจและการลงนามในสัญญา ทั้งนี้ขึ้นอยู่กับ API/สิทธิ์การอนุญาต

ความจำเป็นสำหรับการตรวจสอบแอพนั้นขึ้นอยู่กับระดับ ID ของแอพ โดยจะต้องส่งแต่ละแอพที่ใช้สิทธิ์การอนุญาตหรือคุณสมบัติเหล่านั้นเพื่อรับการตรวจสอบ

Yes, if your apps have made calls to the Graph API in the last 28 days as of July 31, 2018 and require access to the reviewable permissions with an August 1st deadline, your app will be auto-enrolled in the app review process. We will notify you when we have a process available to send us the additional information needed to complete the review process.

As we announced earlier this year, all apps accessing the Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, and Facebook Login were expected to submit for app review by August 1.

To help protect the integrity of our platform, we have removed API access for apps that require these permissions, have not gone through app review, and have not been active within the last 28 days as of July 31, 2018. If you still need access to our APIs, we encourage you to submit for review through your app's App Dashboard.

All active apps that require these permissions will be auto-enrolled in app review in the coming weeks. Developers will be notified if we require additional information to complete the app review submission. If responses are not received in the allocated timeframe, reviewable API access will be disabled.

หากรายการส่งในปัจจุบันของคุณต้องการข้อมูลเพิ่มเติม คุณจะมีเวลา 30 วันในการจัดการและส่งเพื่อพิจารณาอีกครั้ง นับตั้งแต่วันที่ได้รับคำขอ ในระหว่างช่วง 30 วันนี้ ทีมตรวจพิจารณาแอพอาจขอให้คุณให้ข้อมูลเพิ่มเดิม โปรดทราบว่ากรอบเวลา 30 วันจะไม่มีการนับใหม่จากการส่งซ้ำในระหว่างช่วงเวลานี้

หลังจากที่แอพของคุณได้รับการตรวจสอบและเผยแพร่แล้ว ให้ใช้คุณสมบัติสร้างแอพทดสอบในแดชบอร์ดของแอพในการสร้างแบบจำลองของแอพเวอร์ชั่นใช้งานจริงของคุณเพื่อทดสอบคุณสมบัติหรือสิทธิ์การอนุญาตใหม่ ในแดชบอร์ดของแอพเวอร์ชั่นใช้งานจริง ให้คลิกลูกศรลง ซึ่งอยู่ถัดจากชื่อแอพในแผงการนำทางด้านซ้ายบน แล้วคลิกสร้างแอพทดสอบ แอพจำลองที่สร้างขึ้นโดยมีสถานะอยู่ระหว่างการพัฒนานี้จะให้สิทธิ์การเข้าถึงคุณสมบัติและสิทธิ์การอนุญาตทั้งหมดกับทุกบทบาทของแอพ

หากลูกค้าเป็น "เจ้าของ" แอพด้วยเช่นกัน ลูกค้าก็จะต้องเข้าสู่กระบวนการตรวจสอบในฐานะผู้พัฒนาโดยตรง แต่หากลูกค้ามีผู้พัฒนาซึ่งเป็นบุคคลที่สามเป็น "เจ้าของ" แอพ ผู้พัฒนารายดังกล่าวก็ต้องเข้าสู่กระบวนการตรวจสอบ

คุณจะต้องส่งคำขอสิทธิ์การอนุญาต leads_retrieval และ pages_manage_ads

คุณสามารถให้วิดีโอที่อัดหน้าจอซึ่งแสดงการผสานรวมการทำงานได้ หรือหากแอพของคุณไม่มีประสบการณ์ของผู้ใช้ปลายทาง คุณก็สามารถให้ภาพหน้าจออย่างน้อย 2 ภาพที่แสดงมุมมองการตั้งค่าของเพจ, CRM หรือตัวจัดการธุรกิจได้ รวมถึงให้ ID เพจของเพจที่คุณจะใช้ผ่านผลิตภัณฑ์เหล่านี้ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับตัวเลือกนี้ได้ที่นี่

กระบวนการตรวจสอบแอพหมายถึงแอพที่จำเป็นต้องมีสิทธิ์การอนุญาต API บางอย่าง คุณสามารถอ่านเกี่ยวกับสิทธิ์การอนุญาตที่ต้องได้รับการตรวจสอบได้ที่นี่ การตั้งค่า SDK นั้นไม่จำเป็นต้องได้รับการตรวจสอบแอพ อย่างไรก็ตาม SDK ทำให้แอพสามารถเรียกใช้ API ของ Facebook ได้ และหาก API ดังกล่าวต้องได้รับการตรวจสอบ คุณก็จำเป็นต้องส่งแอพดังกล่าวเข้ารับการตรวจสอบแอพ

หากคุณมีบัญชีผู้ใช้ตัวจัดการธุรกิจอยู่แล้ว เราขอแนะนำให้คุณเชื่อมต่อแอพเข้ากับตัวจัดการธุรกิจที่มีอยู่

หากธุรกิจมีบัญชีผู้ใช้ตัวจัดการธุรกิจมากกว่าหนึ่งบัญชี เราขอแนะนำให้พิจารณาถึงแนวคิดสำหรับบัญชีผู้ใช้ตัวจัดการธุรกิจดังกล่าว แล้วปรับแอพให้เหมาะกับตัวจัดการธุรกิจที่เหมาะสมที่สุด หากธุรกิจมีวงเงินที่กำหนดไว้ผ่านตัวจัดการธุรกิจ เราขอแนะนำให้คุณเชื่อมต่อแอพกับตัวจัดการธุรกิจที่มีวงเงินดังกล่าว

เราให้โอกาสผู้พัฒนาในการจัดเตรียมผู้ใช้ขั้นทดสอบเฉพาะในกรณีที่มีการกำหนดค่าเพิ่มเติม ไวท์ลิสต์หรือข้อมูลโปรไฟล์ผู้ใช้ขั้นทดสอบที่พวกเขาต้องการให้เราใช้ หากพวกเขาไม่ได้จัดเตรียมผู้ใช้ขั้นทดสอบ เราจะใช้ผู้ใช้ขั้นทดสอบของเราเอง ช่องกรอกข้อมูลนี้จะทำเครื่องหมายเป็น “ระบุหรือไม่ก็ได้” แม้ไม่กรอกข้อมูลก็จะไม่เป็นการบล็อกผู้พัฒนา

การตรวจสอบแอพจะต้องดำเนินการกับทุกแอพ เราขอแนะนำให้คุณตรวจสอบแดชบอร์ดของแอพเพื่อดูรายการเฉพาะของสิทธิ์การอนุญาตที่ต้องได้รับการตรวจสอบ

การตรวจสอบยืนยันธุรกิจจะต้องดำเนินการ 1 ครั้งต่อตัวจัดการธุรกิจ 1 รายการ หากคุณเลือกเชื่อมโยงแอพทั้งหมดกับตัวจัดการธุรกิจเดียวกัน คุณจะจำเป็นต้องเข้ารับการตรวจสอบยืนยันธุรกิจเพียงครั้งเดียวเท่านั้น

แอพควรมีการลิงก์กับตัวจัดการธุรกิจ สำหรับธุรกิจซึ่งเป็นเจ้าของที่แท้จริงของแอพและมีสิทธิ์การเข้าถึงข้อมูลที่สร้างขึ้นจากแอพ โดยธุรกิจดังกล่าวนี้ควรเป็นผู้ที่เข้าสู่กระบวนการตรวจสอบยืนยันธุรกิจ

Badging for FMP and IGP will resume by the end of May.

คุณสามารถค้นหาสถานะของการตรวจสอบยืนยันธุรกิจได้เสมอ โดยดูข้อตกลงและขั้นตอนที่จะดำเนินการในการตรวจสอบยืนยันธุรกิจได้ในแท็บการตรวจสอบยืนยันแอพของแดชบอร์ดของแอพ เราจะส่งการแจ้งเตือนให้กับคุณตลอดกระบวนการเพื่อแจ้งให้คุณทราบว่าจำเป็นต้องดำเนินการอะไรบ้าง

You need to initiate app review before August 1, 2018 for these APIs: Pages API, Groups API, Events API, Instagram Platform API, Messenger Platform, Business Manager API, and Facebook Login.

You need to initiate App Review before February 1, 2019 for these APIs and features: the Marketing API and the Lead Ads Retrieval feature.

ขณะนี้ เรากำลังดำเนินการกับรายการจำนวนมาก กระบวนการทั้งหมดจึงอาจใช้เวลาสูงถึงหลายสัปดาห์

• การตรวจสอบสิทธิ์การอนุญาตอาจใช้เวลาสูงถึงหลายสัปดาห์ คุณสามารถดูการอัพเดตล่าสุดเกี่ยวกับไทม์ไลน์ได้ที่นี่
• การตรวจสอบยืนยันธุรกิจควรใช้เวลาไม่กี่วัน แต่จะขึ้นอยู่กับคุณภาพของเอกสารด้วย
• คุณสามารถลงนามในสัญญาให้เสร็จสิ้นได้ทันทีที่เจ้าหน้าที่ที่คุณกำหนดได้ลงนามในสัญญา

เราอาจขอให้คุณแจ้งข้อมูลธุรกิจ เช่น ชื่อตามกฎหมายของธุรกิจ ที่อยู่ และหมายเลขโทรศัพท์ โดยเป็นส่วนหนึ่งของกระบวนการตรวจสอบ นอกจากนี้ เรายังอาจขอเอกสารทางธุรกิจจากคุณด้วย เช่น ใบเรียกเก็บเงินค่าสาธารณูปโภค ใบอนุญาต ใบรับรองการก่อตั้ง หรือเอกสารจดทะเบียนจัดตั้งธุรกิจ

Same as other permissions, you will lose access.

นับตั้งแต่วันที่ 1 สิงหาคม 2018 คุณจะต้องตรวจสอบยืนยันเพียงตัวจัดการธุรกิจที่เชื่อมต่อกับแอพเท่านั้น

เนื่องจาก API ใหม่พร้อมให้บริการแล้ว คุณจะต้องขอ API เหล่านี้ผ่านการตรวจสอบแอพ อย่างไรก็ตาม การตรวจสอบยืนยันธุรกิจจำเป็นต้องทำเพียง 1 ครั้งต่อเอนทิตีตัวจัดการธุรกิจ 1 รายการเท่านั้น ดังนั้นจึงไม่มีการกำหนดให้รับการตรวจสอบยืนยันธุรกิจอีกครั้ง หากแอพจำเป็นต้องใช้สิทธิ์การอนุญาตใหม่หรือ API ใหม่

ได้ แอพทดสอบจะได้รับสิทธิ์การอนุญาตที่ตรวจสอบได้จากแอพหลัก

โปรดดูกำหนดการคร่าวๆ ได้จากโพสต์นี้

คุณจะต้องส่งแอพทั้งหมดที่มีอยู่ที่เรียกสิทธิ์การอนุญาตการเข้าสู่ระบบด้วย Facebook แบบขยายและ API ทั้ง 6 รายการ (เพจ, Messenger, ตัวจัดการธุรกิจ, Instagram, กลุ่ม และเหตุการณ์) เข้าสู่ขั้นตอนการตรวจสอบแอพใหม่ ซึ่งจะรวมถึงการตรวจสอบยืนยันธุรกิจและการลงนามในสัญญาด้วย ควรส่งเพื่อรับการตรวจสอบแอพภายในวันที่กำหนด ซึ่งการตรวจสอบแอพให้เสร็จสิ้นอาจไม่ได้อยู่ระหว่างวันดังกล่าว หากคุณไม่ส่งภายใน 1 สิงหาคม 2018 คุณจะไม่มีสิทธิ์เข้าถึง API ในวันที่ 2 สิงหาคม 2018

คุณจะต้องส่งแอพทั้งหมดที่มีอยู่ที่เรียก API การตลาดและ API การดึงข้อมูลโฆษณาแบบกรอกฟอร์มเข้าสู่ขั้นตอนการตรวจสอบแอพใหม่ ซึ่งจะรวมถึงการตรวจสอบยืนยันธุรกิจและการลงนามในสัญญาก่อนวันที่ 1 กุมภาพันธ์ 2019

ดูรายละเอียดเพิ่มเติมได้ในหน้านี้ ขั้นตอนนี้จะให้โอกาสคุณในการแจ้งรายละเอียดว่าคุณต้องการสิทธิ์การอนุญาตใด และแจ้งว่าจะใช้สิทธิ์การอนุญาตดังกล่าวอย่างไร Facebook จะตรวจสอบกรณีการใช้งานและระบุว่าสิทธิ์การอนุญาตนั้นอยู่ภายใต้นโยบายของเราหรือไม่ หลังจากตรวจสอบสิทธิ์การอนุญาตแล้ว เราอาจมีข้อกำหนดเพิ่มเติม เช่น การตรวจสอบยืนยันธุรกิจและการทำสัญญา โดยขึ้นอยู่กับ API/สิทธิ์การอนุญาต

ธุรกิจจะต้องรับการตรวจสอบยืนยันเพียงครั้งเดียว จะต้องมีการลงนามในสัญญาเพียงครั้งเดียวที่ระดับธุรกิจ การส่งแอพครั้งถัดไปจะมีเพียงการตรวจสอบแอพเท่านั้น แต่จะไม่รวมถึงการตรวจสอบยืนยัน

ความจำเป็นในการตรวจสอบแอพจะอิงตามระดับ ID ของแอพ แอพแต่ละแอพที่ใช้สิทธิ์การอนุญาตหรือฟีเจอร์เหล่านั้นจะต้องส่งเพื่อรับการตรวจสอบ

ในวันที่ 1 พฤษภาคม 2018 เราได้ประกาศขั้นตอนการตรวจสอบแอพใหม่ที่ต้องมีสำหรับการเข้าสู่ระบบด้วย Facebook (สิทธิ์การอนุญาตแบบขยาย) และ API ทั้ง 6 รายการ (เพจ, Messenger, ตัวจัดการธุรกิจ, Instagram, กลุ่ม และเหตุการณ์) จะต้องมีการส่งเพื่อรับการตรวจสอบแอพสำหรับ API/สิทธิ์การอนุญาตเหล่านี้ก่อนวันที่ 1 สิงหาคม 2018 เพื่อรักษาสิทธิ์การเข้าถึง API ดังกล่าว

ในวันที่ 2 กรกฎาคม 2018 เราได้ประกาศ API เพิ่มเติมที่ต้องมีการตรวจสอบแอพ ได้แก่: API การตลาดและการดึงข้อมูลโฆษณาแบบกรอกฟอร์ม จะต้องมีการส่งเพื่อรับการตรวจสอบแอพสำหรับ API เหล่านี้ก่อนวันที่ 1 กุมภาพันธ์ 2019 เพื่อรักษาสิทธิ์การเข้าถึง คุณสามารถอ่านข้อมูลเพิ่มเติมเกี่ยวกับวันครบกำหนดได้ที่นี่

API ตัวจัดการธุรกิจนั้นไม่มีการเปลี่ยนแปลงใน API กราฟเวอร์ชั่น 3.0 แอพที่จำเป็นต้องเข้าถึงสิทธิ์การอนุญาต Business_Management จะต้องได้รับการตรวจสอบโดย Facebook

นโยบายการตรวจสอบแอพของ Facebook ไม่มีการเปลี่ยนแปลงใดๆ ที่ส่งผลกระทบต่อแอพที่ใช้ API การตลาดของ Facebook โปรดดูการเปลี่ยนแปลงของ API จริงที่บันทึกการเปลี่ยนแปลงของ API กราฟ

ได้รับ แอพจะเข้าถึงได้เพียงชื่อ อีเมล และรูปโปรไฟล์ของผู้ใช้เท่านั้นหากไม่ได้รับการตรวจสอบแอพ สิทธิ์การอนุญาตอื่นทั้งหมดจะต้องได้รับการตรวจสอบโดย Facebook

API ของ Instagram ไม่ได้รับผลกระทบจาก API กราฟเวอร์ชั่น 3.0 อย่างไรก็ตาม ทุกแอพที่ใช้ API ของ Instagram จะต้องได้รับการตรวจสอบโดย Facebook

ใน API กราฟเวอร์ชั่น 3.0 แอพที่เข้าถึงงานกิจกรรมจะต้องใช้สิทธิ์การอนุญาต user_events ซึ่งแอพที่ใช้สิทธิ์การอนุญาตนั้นจะต้องได้รับการตรวจสอบโดย Facebook

เราได้เลิกใช้สิทธิ์การอนุญาต user_managed_groups แล้วใน API กราฟเวอร์ชั่น 3.0 โดยแอพต่างๆ สามารถใช้ API กลุ่มใหม่ พร้อมทั้งสิทธิ์การอนุญาต publish_groups และ read_groups_user_data แทนได้ ทั้งนี้ API และสิทธิ์การอนุญาตใหม่กำหนดให้แอพต้องได้รับการตรวจสอบโดย Facebook

เราได้เลิกใช้สิทธิ์การอนุญาต publish_actions แล้วใน API กราฟเวอร์ชั่น 3.0 แต่แอพจะยังคงโพสต์เรื่องราวต่างๆ ผ่านประสบการณ์แบบมีสื่อกลางได้ เช่น กล่องการแชร์ของ Facebook, บนเว็บ หรือแผ่นการแชร์สำหรับ iOS และ Android แอพสามารถเผยแพร่ไปยังกลุ่มต่างๆ ได้ผ่านสิทธิ์การอนุญาต publish_groups ซึ่งกำหนดให้แอพต้องได้รับการตรวจสอบ

ได้รับ ในเวอร์ชั่น 3.0 ทุกๆ API ของแพลตฟอร์ม Messenger ล้วนอยู่ภายใต้สิทธิ์การอนุญาต Pages_messaging และต้องได้รับการตรวจสอบ

ได้รับ แอพที่เข้าถึงเนื้อหาของเพจสาธารณะจะต้องส่งคำขอคุณสมบัติการเข้าถึงเนื้อหาสาธารณะในเพจ และต้องได้รับการตรวจสอบโดย Facebook

ในระหว่างกระบวนการตรวจสอบ ทีมของเราจะทำตามคำแนะนำของคุณในการทำซ้ำวิธีที่แอพของคุณใช้สิทธิ์การอนุญาต หากเราไม่สามารถทำให้เกิดประสบการณ์นี้ซ้ำได้ เนื่องจากไม่สามารถทำตามคำแนะนำได้หรือไม่สามารถเข้าสู่ระบบแอพของคุณได้ และเหตุผลอื่นๆ เราก็จะไม่สามารถอนุมัติข้อมูลที่ส่งมาได้เช่นกัน

โปรดดำเนินการดังนี้เพื่อเลี่ยงปัญหานี้:

• ให้แอพในเวอร์ชั่นที่ทำงานได้ซึ่งใช้สิทธิ์การอนุญาตดังกล่าว
• ตรวจสอบให้แน่ใจว่าคำแนะนำของคุณในส่วน "เพิ่มบันทึก" มีความชัดเจน
• ตรวจสอบให้แน่ใจว่าสิทธิ์ในการเข้าสู่ระบบที่ขอจะช่วยปรับแต่งประสบการณ์ให้กับผู้ใช้และเป็นไปตามหลักการของเรา

โดยเฉพาะอย่างยิ่งสำหรับสิทธิ์การอนุญาต publish_actions โปรดยืนยันว่าคุณได้กำหนดค่าฟังก์ชันการทำงานในการเผยแพร่ของแอพอย่างถูกต้องแล้ว เนื่องจากเราจำเป็นต้องเผยแพร่เนื้อหาของแอพดังกล่าวกลับไปยัง Facebook ได้ในระหว่างกระบวนการตรวจสอบ

กระบวนการตรวจสอบแอพนั้นจะมีการโหลดแอพในแพลตฟอร์มที่รองรับแต่ละแพลตฟอร์ม การเข้าสู่ระบบด้วย Facebook และการใช้การผสานการทำงานกับ Facebook ทุกรายการที่คุณส่งคำขอในการตรวจสอบ ซึ่งมักทำให้เกิดสิ่งที่เราเรียกว่า "ปัญหาทั่วไป" ข้อผิดพลาดหรือจุดบกพร่องเหล่านี้เกี่ยวข้องกับการโหลดแอพ การเข้าสู่ระบบแอพ หรือฟังก์ชันการทำงานทั่วไปของแอพ ซึ่งหมายความว่าเราไม่สามารถทดสอบสิทธิ์การอนุญาตที่คุณร้องขอในข้อมูลที่ส่งมาได้

เนื่องจากปัญหาเหล่านี้ทำให้เราไม่สามารถตรวจสอบฟังก์ชันการทำงานของ Facebook ให้คุณได้ เราจึงไม่สามารถระบุรายละเอียดเกี่ยวกับวิธีที่แอพใช้ฟังก์ชันการทำงานของ Facebook ที่คุณได้ส่งมาให้ตรวจสอบได้ ด้วยเหตุนี้ เราจึงปฏิเสธแอพโดยให้เหตุผลเป็น "ปัญหาทั่วไป" และให้ข้อเสนอแนะเกี่ยวกับเรื่องนี้ไว้ในแต่ละแพลตฟอร์ม

หากคุณถูกปฏิเสธเพราะ "ปัญหาทั่วไป" โปรดอ่านข้อเสนอแนะทั้งหมดอย่างถี่ถ้วน แต่ละแพลตฟอร์มจะได้รับข้อเสนอแนะแยกจากกันซึ่งควรอธิบายถึงปัญหาที่เกิดขึ้นในการตรวจสอบ

คำตอบที่ได้จากการตรวจสอบจะประกอบด้วยคำอธิบายอย่างชัดเจนถึงเหตุผลที่แอพไม่ได้รับการอนุมัติ รวมทั้งขั้นตอนถัดไปที่ควรทำ เราอยากให้คุณผ่านกระบวนการนี้โดยเร็วที่สุด ดังนั้นโปรดอ่านข้อเสนอแนะนี้อย่างถี่ถ้วน หลังจากดำเนินการเปลี่ยนแปลงที่จำเป็นแล้ว คุณก็สามารถส่งข้อมูลเข้ารับการตรวจสอบได้อีกครั้ง

หากแอพของคุณใช้สิทธิ์การอนุญาตในลักษณะที่เราไม่อาจอนุมัติได้ ข้อเสนอแนะที่คุณได้รับจะอธิบายถึงประเด็นนี้ และคุณไม่ควรส่งข้อมูลเข้ารับการตรวจสอบอีกครั้ง

แอพของคุณต้องเป็นไปตามข้อกำหนดเกี่ยวกับการมีสิทธิ์ของเราจึงจะได้รับอนุมัติให้แสดงในศูนย์รวมแอพได้ แอพที่มีสิทธิ์แสดงอยู่ในศูนย์รวมแอพของ Facebook จะต้องใช้การเข้าสู่ระบบด้วย Facebook หรือมีแอพใน Facebook Canvas

แอพที่มีสิทธิ์แสดงอยู่ในศูนย์รวมแอพมีดังนี้:

• แอพใน Facebook Canvas
• แอพมือถือที่สร้างมาสำหรับ iOS หรือ Android ที่ใช้การเข้าสู่ระบบด้วย Facebook สำหรับ iOS หรือการเข้าสู่ระบบด้วย Facebook สำหรับ Android
• เว็บแอพหรือแอพมือถือที่ใช้การเข้าสู่ระบบด้วย Facebook

องค์ประกอบที่เป็นข้อความและรูปภาพเพื่อการโปรโมทของคุณต้องเป็นไปตามแนวทางของเราด้วยเช่นกัน

หากคุณใช้กล่องการแชร์หรือโซเชียลปลั๊กอินอื่นใดเพื่อเผยแพร่เนื้อหากลับไปยัง Facebook คุณก็ไม่จำเป็นต้องส่งแอพเพื่อรับการตรวจสอบ หากยังคงไม่แน่ใจ คุณสามารถดูข้อมูลเพิ่มเติมได้ในเอกสารการตรวจสอบทั่วไปของเรา

การมอบสิ่งจูงใจแก่ผู้ใช้เพื่อให้ใช้โซเชียลปลั๊กอินหรือกดถูกใจเพจนั้นถือเป็นการละเมิดนโยบายแพลตฟอร์มข้อที่ 4.5 ซึ่งรวมถึงการมอบของรางวัลหรือการจำกัดการเข้าถึงแอพหรือเนื้อหาของแอพโดยขึ้นอยู่กับว่าผู้ใช้ได้กดถูกใจเพจหนึ่งๆ หรือไม่ User_likes จะไม่ได้รับการอนุมัติสำหรับวัตถุประสงค์นี้

เพื่อรับรองถึงการเชื่อมโยงที่มีคุณภาพและช่วยให้ธุรกิจเข้าถึงผู้ที่มีความสำคัญต่อธุรกิจนั้นๆ เราจึงต้องการให้ผู้ใช้กดถูกใจเพจเนื่องจากพวกเขาต้องการเชื่อมต่อและรับข่าวสารของธุรกิจจริงๆ ไม่ใช่เพราะสิ่งจูงใจใดๆ แอบแฝง เราเชื่อว่านโยบายนี้จะเป็นประโยชน์ต่อทั้งผู้ใช้และผู้ลงโฆษณา

ทีมตรวจสอบอาจขอข้อมูลการเข้าสู่ระบบเพิ่มเติมสำหรับแอพของคุณ ทั้งนี้เพื่อดำเนินการตรวจสอบให้เสร็จสิ้น

หากแอพของคุณต้องใช้การเข้าสู่ระบบรองก่อนหรือหลังการเข้าสู่ระบบด้วย Facebook โปรดให้ชื่อผู้ใช้และรหัสผ่านเพื่อการนี้ด้วย ซึ่งอาจรวมถึงข้อมูลการเข้าสู่ระบบสำหรับเซิร์ฟเวอร์ทดสอบหรือสาธิต การเข้าสู่ระบบรองสำหรับแอพ หรือกระบวนการลงทะเบียนอีเมล

แอพที่โฮสต์ในเซิร์ฟเวอร์ที่อยู่ระหว่างการทดสอบใช้งานหรือการพัฒนานั้นอาจต้องใช้การเข้าสู่ระบบเพิ่มเติมเพื่อเข้าถึงเซิร์ฟเวอร์ของคุณ โปรดแจ้งข้อมูลการเข้าสู่ระบบที่จำเป็นทั้งหมดเพื่อการนี้ด้วย

หากยังไม่แน่ใจว่าขาดข้อมูลการเข้าสู่ระบบใด คุณสามารถแนบวิดีโอมาพร้อมข้อมูลที่ส่งในครั้งต่อไปได้ เพื่อแสดงตัวเลือกการเข้าสู่ระบบด้วย Facebook และการผสานการทำงานกับ Facebook ที่เกี่ยวข้องทั้งหมดที่คุณส่งข้อมูลมา

ทีมตรวจสอบจะต้องเข้าสู่ระบบแอพของคุณ และตรวจสอบการผสานการทำงานกับ Facebook ทั้งหมด จึงจะอนุมัติข้อมูลที่ส่งสำหรับแอพของคุณได้

หากผู้ตรวจสอบไม่สามารถโหลดหรือใช้แอพของคุณได้ โปรดตรวจสอบดังนี้:

• URL ของแอพสามารถเข้าถึงได้แบบสาธารณะ และไม่ได้กำหนดค่าเป็น localhost
• คุณได้ให้ชื่อผู้ใช้และรหัสผ่านที่ต้องใช้ในการเข้าถึงเว็บไซต์ที่อยู่ระหว่างการพัฒนาหรือการทดสอบใช้งาน
• ใบรับรองความปลอดภัยของเว็บไซต์นั้นเป็นปัจจุบันและไม่ก่อให้เกิดข้อผิดพลาดกับผู้ใช้ใหม่
• คุณสามารถเข้าสู่ระบบและใช้งานแอพได้ในฐานะผู้ใช้ขั้นทดสอบที่เพิ่งสร้างขึ้นใหม่
• รายการที่คุณส่งเพื่อรับการตรวจสอบนั้นมีการสร้างขึ้นและทำงานได้ในแอพ

หากคุณถูกปฏิเสธอีกครั้งด้วยเหตุผลเดิม ให้อัพเดตส่วนคำแนะนำสำหรับการตรวจสอบหรือเพิ่มบันทึกเพื่อขอความกระจ่างและข้อมูลเพิ่มเติมบางส่วนจากผู้ตรวจสอบ

วิดีโอที่อัดหน้าจอนั้นเป็นวิธีที่ดีในการชี้แนะแนวทางการใช้งานแอพของคุณและแสดงให้เราเห็นว่าคุณใช้สิทธิ์การอนุญาตที่ขออย่างไร ต่อไปนี้คือบางส่วนของหลักปฏิบัติที่ดีที่สุดและแหล่งข้อมูลภายนอกสำหรับการสร้างสกรีนแคสต์

วิดีโอของคุณควรแสดงวิธีที่แอพใช้สิทธิ์การอนุญาตแต่ละสิทธิ์ที่ขอมา หากคุณส่งคำขอ publish_actions วิดีโอนั้นก็ควรแสดงให้เห็นวิธีสร้างเนื้อหาจากแอพและการแชร์เนื้อหาดังกล่าวไปยัง Facebook ด้วย

ทั้งนี้ คุณไม่สามารถใช้ ID ของแอพบน Facebook ที่สร้างขึ้นไว้สำหรับเกมทันใจกับแพลตฟอร์มอื่นใดได้ โปรดดูข้อมูลเพิ่มเติมในเอกสารประกอบของเรา

ทีมตรวจพิจารณาจะใช้คำแนะนำที่คุณให้มาเพื่อทดสอบการผสานการทำงานรวมกับ Facebook ของแอพ

หากคุณรู้สึกว่าผู้ตรวจพิจารณาของคุณปฏิเสธแอพของคุณอย่างไม่ถูกต้อง คุณควรส่งแอพเพื่อรับการตรวจพิจารณาอีกครั้งพร้อมคำแนะนำที่อัพเดตซึ่งให้ข้อมูลเพิ่มเติมแก่ผู้ตรวจพิจารณา

กระบวนการตรวจพิจารณาเป็นวิธีที่ดีที่สุดในการสื่อสารกับผู้ตรวจพิจารณาโดยอัพเดตบันทึกเพื่อแก้ไขตามข้อเสนอแนะที่ได้รับ

ทีมตรวจสอบของเราใช้ผู้ใช้ขั้นทดสอบหลายรายเมื่อทำการตรวจสอบข้อมูลที่ส่งมา และเราอาจไม่ใช้ผู้ใช้ขั้นทดสอบที่คุณให้มาเสมอไป หากข้อมูลที่คุณส่งมาจำเป็นต้องได้รับการตรวจสอบโดยใช้ผู้ใช้ขั้นทดสอบใดโดยเฉพาะ โปรดแจ้งให้เราทราบในคำแนะนำสำหรับการตรวจสอบ

หากคุณให้ผู้ใช้ขั้นทดสอบไว้ ให้ตรวจสอบว่าคุณได้สร้างผู้ใช้ขั้นทดสอบไว้อย่างถูกต้องและแนบผู้ใช้ดังกล่าวมาพร้อมกับข้อมูลที่ส่ง

ไม่ต้อง หลังจากที่ได้รับการอนุมัติสำหรับสิทธิ์การอนุญาตหนึ่งแล้ว คุณจะสามารถใช้สิทธิ์นั้นกับแอพของคุณในเวอร์ชั่นใดบนแพลตฟอร์มใดก็ได้

หากคุณขยายและพัฒนาแอพในแพลตฟอร์มใหม่ คุณจะไม่จำเป็นต้องส่งเข้ารับการตรวจสอบ คุณต้องส่งแอพเข้ารับการตรวจสอบอีกครั้งก็ต่อเมื่อคุณต้องการส่งคำขอสิทธิ์การอนุญาตใหม่ เช่น เมื่อเพิ่มคุณสมบัติใหม่ในแอพ การเปลี่ยนและการส่งรายละเอียดแอพหรือการดำเนินการ Open Graph จะไม่ส่งผลกระทบต่อสิทธิ์การอนุญาตที่คุณได้รับการอนุมัติไปแล้ว

หากแอพของคุณเป็นแอพเกมและอยู่ใน Facebook Canvas

คุณสามารถเชิญผู้เล่นใหม่เข้ามาในเกมได้โดยใช้สิ่งใดก็ได้ต่อไปนี้:

• กล่องโต้ตอบคำขอ เมื่อใช้กล่องโต้ตอบคำขอ คุณสามารถตั้งค่า "filters=app_non_users" ให้กรองกล่องโต้ตอบให้แสดงต่อผู้ที่ไม่ได้ใช้แอพของคุณเท่านั้นได้ หากแอพของคุณอยู่ใน Canvas คุณสามารถใช้กล่องโต้ตอบคำขอใน iOS และ Android ได้เช่นกัน
• API เพื่อนที่เชิญได้ หากแอพของคุณเป็นแอพเกมและต้องการสร้างตัวเลือกเพื่อนครั้งละหลายคนขึ้นมาเอง คุณสามารถใช้ API เพื่อนที่เชิญได้ซึ่งจะแสดงรายชื่อเพื่อนของบุคคลดังกล่าวที่ไม่ได้ใช้แอพของคุณขึ้นมาแบบเรียงลำดับ หลังจากผู้ใช้เลือกเพื่อนที่จะเชิญจำนวนหนึ่งแล้ว คุณสามารถส่งผ่านโทเค็นที่ API เพื่อนที่เชิญได้ส่งมาไปยังช่องกล่องโต้ตอบคำขอได้ ซึ่งจะช่วยให้ผู้ใช้ส่งคำเชิญไปยังเพื่อนเหล่านั้นได้

หากแอพของคุณไม่ได้อยู่ใน Facebook Canvas

คุณสามารถใช้กล่องการส่งข้อความใน iOS และ Android หรือกล่องการส่งข้อมูลบนเว็บได้ ผลิตภัณฑ์เหล่านี้ช่วยให้ผู้ใช้ส่งข้อความถึงเพื่อนของตนได้โดยตรงพร้อมลิงก์ไปยังแอพของคุณ

ข้อความประเภทนี้เป็นช่องทางที่ดีในการสื่อสารโดยตรงกับผู้ใช้ที่มีจำนวนน้อยลง ทั้งกล่องการส่งข้อความและกล่องการส่งข้อมูลมีฟังก์ชั่นเติมข้อความล่วงหน้า ซึ่งช่วยให้ผู้ใช้เลือกเพื่อนที่ต้องการส่งคำเชิญให้แบบหลายคนได้ง่าย

ทีมตรวจสอบของเราจะทดสอบตามจริงว่า แอพของคุณใช้งานสิทธิ์การอนุญาตแต่ละสิทธิ์อย่างไรในทุกแพลตฟอร์มที่คุณระบุไว้ในส่วนการตั้งค่าของแอพ ผู้ตรวจสอบจะดูให้แน่ใจว่า การผสานการทำงานสำหรับการเข้าสู่ระบบด้วย Facebook ของคุณทำงานได้ถูกต้อง และสิทธิ์การอนุญาตแต่ละสิทธิ์ที่ขอเป็นไปตามหลักการและแนวทางด้านอรรถประโยชน์ของเราไปพร้อมๆ กับให้ประสบการณ์ที่ดีขึ้นแก่ผู้ใช้

โปรดดูข้อมูลเพิ่มเติมในหลักการและแนวทางด้านอรรถประโยชน์ของเรา

ก่อนอนุมัติคำขอสำหรับ user_likes ผู้ตรวจสอบของคุณจะต้องยืนยันว่าแอพของคุณให้ประสบการณ์ที่มีลักษณะเฉพาะตัวแก่ผู้ใช้ตามข้อมูลการกดถูกใจที่แอพได้รับจากผู้ใช้ เพื่อการนี้ ทีมตรวจสอบของเราจะทดสอบแอพของคุณกับผู้ใช้ขั้นทดสอบต่างๆ หลายราย โดยแต่ละรายจะมีความชอบและความสนใจต่างชุดกัน

เมื่อส่งคำขอสำหรับ user_likes คุณควรเขียนคำแนะนำอย่างละเอียดโดยรวมสิ่งต่อไปนี้ด้วย:

• คำอธิบายอย่างชัดเจนถึงเหตุผลที่คุณขอ user_likes และการขอนี้จะปรับปรุงประสบการณ์ของผู้ใช้ในแอพอย่างไร
• รายการเพจตัวอย่างเพื่อให้ผู้ตรวจสอบของเรากดถูกใจเพื่อตรวจสอบยืนยันการใช้ user_likes ของคุณ โปรดให้ลิงก์ตรงไปยังเพจที่ผู้ตรวจสอบของเราควรกดถูกใจก่อนทดสอบแอพของคุณ

หากคุณใช้ user_likes เป็นส่วนหนึ่งของอัลกอริทึมอยู่ ผู้ตรวจสอบของคุณจำเป็นที่จะต้องเห็นผลของอัลกอริทึมนี้และผลกระทบที่มีต่อเนื้อหาที่แสดงต่อผู้ใช้ได้

ในบางกรณี คุณอาจต้องให้ผู้ตรวจสอบทำซ้ำการดำเนินการหรือประสบการณ์บางอย่างที่มีเพียงผู้ใช้ขั้นทดสอบเท่านั้นที่ทำได้ ในกรณีนี้ คุณสามารถเพิ่มผู้ใช้นี้ในข้อมูลที่ส่งในหน้าการตรวจสอบแอพได้ ในส่วน "รายการที่อยู่ระหว่างการตรวจสอบ" คุณจะเห็นส่วน "ผู้ใช้ขั้นทดสอบ" (ระบุหรือไม่ก็ได้) ที่ให้พิมพ์ชื่อผู้ใช้ที่คุณต้องการให้นำมาใช้ในการตรวจสอบ

มีเพียงผู้ใช้ขั้นทดสอบที่อยู่ในส่วนนี้เท่านั้นที่แสดงเป็นผู้ใช้ขั้นทดสอบในส่วน "บทบาท" ของแอพ โปรดอย่าให้ข้อมูลการเข้าสู่ระบบ Facebook สำหรับผู้ใช้ในคำแนะนำสำหรับการตรวจสอบ

เรียนรู้เพิ่มเติมเกี่ยวกับวิธีสร้างผู้ใช้ขั้นทดสอบ

ไม่ คุณไม่จำเป็นต้องส่งแอพเข้ารับการตรวจสอบจึงจะแสดงโฆษณาเพื่อการติดตั้งแอพบนมือถือได้ คุณเพียงต้องมีแอพที่เผยแพร่อยู่ใน iTunes App Store หรือ Google Play Store คุณสามารถทำตามคู่มือเกี่ยวกับการสร้างโฆษณาเพื่อการติดตั้งแอพบนมือถือของเราได้

คุณจะต้องอธิบายวิธีทดสอบสิทธิ์การอนุญาตหรือคุณสมบัติแต่ละอย่างในแอพของคุณให้ชัดเจนเพื่อให้เราตรวจสอบได้ว่าแอพทำงานได้และเป็นไปตามนโยบายของเรา ทั้งนี้ เราจะไม่สามารถอนุมัติแอพให้คุณได้ หากเราไม่สามารถทดสอบวิธีการผสานการทำงานกับ Facebook ได้อย่างเต็มที่ การให้คำแนะนำอย่างละเอียดจะช่วยให้คุณมีแนวโน้มที่ไม่ต้องส่งข้อมูลเข้ารับการตรวจสอบอีก

สำหรับสิทธิ์การอนุญาตแต่ละสิทธิ์ที่คุณร้องขอ ให้แสดงคำแนะนำในการทำซ้ำแบบทีละขั้นตอน ทั้งนี้ คำแนะนำทั้งหมดต้องเป็นภาษาอังกฤษ

คำอธิบายไม่ควรมีลักษณะดังนี้:

• อ้างอิงถึงคำแนะนำจากข้อมูลที่ส่งหรือเอกสารอื่นๆ
• สรุปสิ่งที่แอพทำได้ แทนที่จะให้คำแนะนำ
• ให้รายละเอียดทางเทคนิคเกี่ยวกับวิธีการทำงานของ API ของคุณ

ตัวอย่างที่ดีของคำแนะนำแบบทีละขั้นตอนเป็นดังนี้:

1. กดปุ่ม "การตั้งค่า" ในเมนูด้านซ้าย
2. เลือกเข้าสู่ระบบด้วย Facebook
3. ดำเนินขั้นตอนที่ 3 ให้เสร็จสิ้น
4. ดำเนินขั้นตอนที่ 4 ให้เสร็จสิ้น

หากคุณยังไม่แน่ใจว่าต้องระบุข้อมูลใดบ้าง โปรดดูตัวอย่างเพิ่มเติมในส่วนตัวอย่างสำหรับการตรวจสอบแอพของเรา

เนื่องจากขั้นตอนการตรวจสอบมีการเปลี่ยนแปลงและเราคาดว่าจะมีข้อมูลที่ส่งเข้ามาเป็นจำนวนมาก การตรวจสอบแอพที่ส่งเข้ามาให้เสร็จสิ้นจึงอาจใช้เวลาหลายสัปดาห์

โปรดระบุข้อมูลให้ได้มากที่สุดเพื่อช่วยผู้ตรวจสอบ ทั้งภาพหน้าจอที่ชัดเจน คำแนะนำแบบทีละขั้นตอนโดยละเอียด และไฟล์บันทึกหน้าจอของแอพและการผสานการทำงานเข้ากับ Facebook

แอพที่ใช้ผลิตภัณฑ์ที่มีการแชร์แบบผ่านสื่อกลาง เช่น โซเชียลปลั๊กอิน กล่องการแชร์ และแผ่นการแชร์ หรือชุดย่อยของการเข้าสู่ระบบด้วย Facebook นั้นไม่ต้องได้เข้ารับการตรวจสอบโดย Facebook โปรดดูเอกสารการตรวจสอบแอพของเราเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับสิ่งที่ต้องได้รับการตรวจสอบ

เราจะตรวจสอบแอพของคุณเพื่อรับรองประสบการณ์การใช้งาน Facebook ที่มีคุณภาพสูงในทุกแอพ โดยทั่วไป ผู้ใช้จะต้องรู้ว่าตนเข้าสู่ระบบแล้วและกำลังโพสต์เนื้อหาใน Facebook ผู้ใช้ควรควบคุมข้อมูลที่ตนแชร์กับแอพของคุณหรือแชร์กลับมาที่ Facebook ได้

หมายเหตุ: ผู้ที่มีชื่ออยู่ในแท็บ "บทบาท" ของแอพจะเข้าถึงสิทธิ์การอนุญาตแบบขยายได้โดยไม่ต้องผ่านการตรวจสอบ (เช่น user_posts) อย่างไรก็ตาม เมื่อแอพเปิดใช้แบบสาธารณะแล้ว แอพจะต้องได้รับการตรวจสอบเพื่อให้มีสิทธิ์การเข้าถึงข้อมูล แม้จะเป็นผู้ที่มีบทบาทในแอพก็ตาม

ความสามารถทุกอย่างของแอพควรใช้งานได้เมื่อแอพอยู่ในโหมดการพัฒนา แต่คุณจะเข้าถึงได้เพียงข้อมูลของคุณ ข้อมูลของผู้ใช้ขั้นทดสอบ หรือข้อมูลเพจของคุณเท่านั้น หากคุณต้องการเปิดใช้งานแอพแบบสาธารณะ แม้ว่าจะมีคุณเป็นผู้ใช้เพียงคนเดียว แอพก็ต้องได้รับการตรวจสอบ

หากส่งคำขอรายการของเพจสำหรับธุรกิจผ่านทาง /BUSINESS_ID/pages ช่องกรอกข้อมูลของเพจบางช่องอาจไม่สามารถเรียกคืนตามคำขอได้ และ API อาจตอบสนองการทำงานได้อย่างไม่ถูกต้อง: (#100) Unknown fields: <FIELD_NAME>

ทั้งนี้เนื่องจากปลายทางนี้ไม่ส่งค่าอ็อบเจกต์ในเพจกลับมา ซึ่งต่างจากปลายทางที่คล้ายกันอื่นๆ หรืออาจเกิดจากคำขอที่รอดำเนินการซึ่งยังไม่อนุมัติ เป็นต้น ดังนั้นจึงเป็นไปไม่ได้ที่จะใช้การขยายช่องกรอกข้อมูลเพื่อส่งช่องกรอกข้อมูลกลับมาจากเพจ

คุณอาจใช้ “<BUSINESS_ID>/owned_pages” หรือ “<BUSINESS_ID>/client_pages” ก็ได้ เพราะปลายทางทั้งสองนี้น่าจะสามารถส่งค่าอ็อบเจกต์ในเพจกลับมาและรองรับการขยายช่องกรอกข้อมูล

ในการส่งคำขอไปยังหน้าที่ยืนยันแล้ว ตัวจัดการพาร์ทเนอร์ของ Facebook ต้องกำหนดค่าให้ธุรกิจสามารถอนุญาตการส่งคำขอดังกล่าวกับองค์กรที่เกี่ยวข้องกับหน้านั้นๆ ธุรกิจที่ไม่มีตัวจัดการพาร์ทเนอร์ Facebook จะไม่สามารถออกคำขอดังกล่าวได้

เมื่อต้องตรวจสอบการใช้งานข้อมูล ผู้ดูแลแอพจะต้องดำเนินการต่อไปนี้
1. ตรวจสอบสิทธิ์การอนุญาตและฟีเจอร์ที่ได้รับอนุมัติของแอพ
2. รับรองว่าแอพปฏิบัติตามการใช้งานที่อนุญาต
3. รับรองว่าแอพปฏิบัติตามข้อกำหนดแพลตฟอร์มและนโยบายผู้พัฒนาของ Facebook รวมถึงข้อกำหนดและนโยบายที่เกี่ยวข้องอื่นๆ ทั้งหมด

การตรวจสอบการใช้งานข้อมูลและการตรวจสอบแอพเป็นการวัดผลความสมบูรณ์ของแพลตฟอร์มสองรูปแบบที่แตกต่างกันอย่างชัดเจน แต่มีความเกี่ยวข้องกัน การตรวจสอบแอพเป็นขั้นตอนเพื่ออนาคตที่ควบคุมสิทธิ์การเข้าถึงสิทธิ์การอนุญาตของแพลตฟอร์ม Facebook บางรายการ โดยผู้พัฒนาต้องส่งแอพพลิเคชั่นเพื่อแสดงให้เห็นว่ามีสิทธิ์เข้าถึงแพลตฟอร์ม ซึ่งจะได้รับการตรวจสอบโดยทีมปฏิบัติการผู้พัฒนาของเราด้วยตัวเอง หลังจากมอบสิทธิ์การเข้าถึงแพลตฟอร์มให้แล้ว การตรวจสอบการใช้งานข้อมูลจะเป็นขั้นตอนประจำปีที่ผู้พัฒนาต้องรับรองว่าการใช้งานข้อมูล Facebook อย่างต่อเนื่องของตนเป็นไปตามข้อกำหนดแพลตฟอร์มและนโยบายผู้พัฒนาของเรา

คุณต้องรับรองในนามของทุกแอพที่ธุรกิจของคุณจัดการ

คุณจะต้องตรวจสอบแต่ละแอพที่คุณจัดการให้เสร็จสิ้น (แต่ละแอพอาจมีสิทธิ์การอนุญาตหลายรายการ) คุณสามารถรองรับให้แอพทีละแอพและจัดลำดับความสำคัญตามที่ต้องการได้ ตราบใดที่คุณดำเนินการขั้นตอนดังกล่าวเสร็จสิ้นก่อนกำหนดเวลาที่ระบุของแต่ละแอพ

คุณจะได้รับแจ้งให้รับรองสิทธิ์การอนุญาตทั้งหมดที่คุณมีสิทธิ์เข้าถึง อย่างไรก็ตาม หากคุณทราบว่าคุณไม่ต้องการเข้าถึงสิทธิ์การอนุญาตบางรายการอีกต่อไปแล้ว คุณสามารถลบสิทธิ์การอนุญาตเหล่านั้นออกได้และคุณจะไม่ต้องรับรองสิทธิ์การอนุญาตเหล่านั้นอีกต่อไป

คุณสามารถดูแอพทั้งหมดที่ต้องได้รับการตรวจสอบการใช้งานข้อมูลได้โดยไปที่หน้า “แอพของฉัน” ในแดชบอร์ดของแอพ ในหน้าดังกล่าว คุณสามารถดูแอพทั้งหมดที่คุณจัดการและกรองแอพให้เหลือเพียงแค่แอพที่ต้องได้รับการตรวจสอบการใช้งานข้อมูล

ผู้ดูแลแอพควรเป็นผู้ดำเนินการขั้นตอนดังกล่าวให้เสร็จสิ้น เข้าสู่ระบบแดชบอร์ดของแอพแล้วคลิก “บทบาท” ที่อยู่ด้านซ้ายของหน้าเพื่อตรวจสอบว่าใครที่เป็นผู้ดูแลแอพของคุณ ผู้ดูแลแอพควรอยู่ในตำแหน่งที่มีอำนาจดำเนินการในนามขององค์กรของคุณ

ผู้ดูแลแอพทุกคนสามารถรับรองให้แอพได้ หากคุณมีผู้ดูแลแอพหลายคน เฉพาะผู้ดูแลแอพคนเดียวเท่านั้นที่ต้องรับรอง

คุณจะมีเวลา 60 วันนับตั้งแต่เริ่มขั้นตอนดังกล่าว (วันที่คุณได้รับการแจ้งเตือนสำหรับผู้พัฒนาครั้งแรก) จนถึงกำหนดเวลา

หลังผ่านกำหนดเวลา เราจะเริ่มเพิกถอนสิทธิ์การเข้าถึงแพลตฟอร์มโดยการจำกัดผลลัพธ์การเรียก API ตลอดเดือนถัดจากกำหนดเวลาของคุณ ในระหว่างช่วงเวลานี้ คุณจะสามารถไปที่แดชบอร์ดของแอพและตรวจสอบการใช้งานข้อมูลให้เสร็จสิ้นเพื่อรับแอพคืนในสถานะที่เป็นไปตามข้อกำหนดและกู้คืนสิทธิ์การเข้าถึงแพลตฟอร์มอย่างเต็มรูปแบบ อย่างไรก็ตาม หลังผ่านกำหนดเวลาเป็นระยะเวลาหนึ่งเดือน เราจะเพิกถอนสิทธิ์การเข้าถึงแพลตฟอร์มทั้งหมดอย่างเต็มรูปแบบ

การตรวจสอบการใช้งานข้อมูลจะแสดงสิทธิ์การอนุญาตทั้งหมดที่แอพของคุณมีสิทธิ์เข้าถึง ไม่ว่าคุณจะใช้งานอยู่หรือไม่ก็ตาม เราแนะนำให้คุณใช้โอกาสนี้ตรวจสอบการผสานการทำงานของคุณ ทำความเข้าใจความสามารถของแอพให้ดียิ่งขึ้น และลบสิทธิ์การเข้าถึงสิทธิ์การอนุญาตใดๆ ที่คุณไม่ต้องการ

ในบางกรณี เราจะแสดงข้อมูลการใช้งาน API ในขั้นตอนการตรวจสอบการใช้งานข้อมูลโดยตรง หากมิเป็นเช่นนั้น คุณสามารถดูระดับการใช้งานสำหรับสิทธิ์การอนุญาตแต่ละรายการได้ในส่วน “สิทธิ์การอนุญาตและฟีเจอร์” ของแดชบอร์ดของแอพ เมื่อคุณเข้าสู่ระบบแล้ว ให้คลิก “การตรวจสอบแอพ” ที่อยู่ด้านซ้ายของหน้า จากนั้นเลือก “สิทธิ์การอนุญาตและฟีเจอร์” ในเมนูดร็อปดาวน์ คุณจะเห็นคอลัมน์ “การเรียก API” ซึ่งจะมีเครื่องหมายถูกสีเขียวอยู่หากบันทึกของเราแสดงว่าคุณกำลังใช้งานสิทธิ์การอนุญาตดังกล่าวเป็นประจำ โปรดอย่าลืมว่านี่เป็นเพียงการคาดคะเน คุณควรปรึกษากับทีมพัฒนาของคุณเพื่อดูว่าการผสานการทำงานของคุณต้องใช้สิทธิ์การอนุญาตดังกล่าวหรือไม่

เราจำเป็นต้องให้ผู้พัฒนารับรองสิทธิ์การอนุญาต “พื้นฐาน” ที่มอบให้โดยอัตโนมัติเหล่านี้เนื่องจากสิทธิ์การอนุญาตดังกล่าวถูกใช้ในวงกว้างและมอบสิทธิ์การเข้าถึงข้อมูลผู้ใช้ อย่างไรก็ตาม หากคุณไม่ได้ใช้ข้อมูลนี้ คุณก็ควรสะดวกใจที่จะดำเนินการขั้นตอนนี้ให้เสร็จสิ้น เนื่องจากการรับรองจะบ่งชี้ว่าการใช้งานสิทธิ์การอนุญาตทั้งหมดเป็นไปตามข้อกำหนด รวมถึงกรณีที่ไม่มีการใช้งานด้วย

ก่อนอื่นคุณควรลบสิทธิ์การอนุญาตดังกล่าวออกโดยใช้แดชบอร์ดของแอพ (คลิก “สิทธิ์การอนุญาตและฟีเจอร์ของฉัน” ที่อยู่ในเมนูดร็อปดาวน์ด้านซ้ายในหัวข้อ “การตรวจสอบแอพ”) จากนั้น คุณสามารถรับรองสิทธิ์การอนุญาตและฟีเจอร์ที่เหลือซึ่งคุณกำลังใช้งานอยู่ได้

อย่างไรก็ตาม คุณไม่สามารถลบสิทธิ์การอนุญาตที่มอบให้โดยอัตโนมัติบางรายการและเราอาจขอให้คุณรับรองสิทธิ์การอนุญาตเหล่านั้น หากคุณไม่ได้ใช้ข้อมูลนี้ คุณก็ควรสะดวกใจที่จะดำเนินการขั้นตอนนี้ให้เสร็จสิ้น เนื่องจากการรับรองจะบ่งชี้ว่าการใช้งานสิทธิ์การอนุญาตทั้งหมดเป็นไปตามข้อกำหนด รวมถึงกรณีที่ไม่มีการใช้งานด้วย

ไม่ต้อง หลังจากลบสิทธิ์การอนุญาตดังกล่าวในแดชบอร์ดของแอพแล้ว คุณสามารถรีเฟรชหน้าการตรวจสอบการใช้งานข้อมูลแล้วสิทธิ์การอนุญาตที่คุณลบออกจะหายไป

คุณจะต้องดำเนินการตรวจสอบการใช้งานข้อมูลสิทธิ์การอนุญาตทั้งหมดที่แอพของคุณมีสิทธิ์เข้าถึง

In order to comply with certain legal obligations, Meta’s developer services may not be available in all locations, including countries and regions currently subject to U.S. sanctions prohibitions.

Meta’s services are not available in all regions.

Registration reviews may take longer and you may be unable to access our service during that time. Please try again in a few days. For more information, please refer to Meta’s Terms of Service.

We are currently reviewing your registration details. This takes 24 to 48 hours. Once completed and approved, you may be able to login and complete your registration.

คุณไม่สามารถลบภาพหน้าจอหรือภาพแบนเนอร์ที่ได้รับอนุมัติสำหรับศูนย์รวมแอพแล้วได้ หากต้องการแทนที่รูปภาพเหล่านี้ด้วยรูปภาพใหม่ ให้คลิก "แก้ไข" บนภาพหน้าจอหรือแบนเนอร์และเลือกรูปภาพที่ต้องการแทนที่

ตรวจสอบว่าคุณสามารถดูข้อความแสดงข้อผิดพลาดโดยที่ไม่ต้องส่งคำขอสำหรับรูปภาพผู้ใช้และตรวจสอบยืนยันว่าข้อความแสดงข้อผิดพลาดแรกนั้นสามารถมองเห็นได้ จากนั้นส่งคำขอไปยัง me/photos และกลับไปตรวจสอบว่ายังมองเห็นข้อความแสดงข้อผิดพลาดอยู่หรือมองไม่เห็นอีกต่อไป ตรวจสอบให้แน่ใจว่าคุณได้ทำการทดสอบการเรียก me/photos โดยใช้แอพที่กำหนดการทำงานไว้ และรับโทเค็นการเข้าถึงที่ต้องมีสิทธิ์การอนุญาต user_photos จากนั้นคุณก็ดำเนินการเสร็จสิ้น!

จุดมุ่งหมายของการตรวจสอบคือการรับรองว่าผู้พัฒนาได้ทดสอบคุณสมบัติในแอพของตนครบถ้วนก่อนส่งคำขอสิทธิ์การอนุญาตเดิมให้เรา การทดสบในแอพทดสอบไม่ได้รับรองถึงลักษณะการทำงานที่เสถียรของแอพหลัก เราจำเป็นต้องให้คุณส่งคำขอการทดสอบจากแอพหลักเพื่อให้แน่ใจว่าคุณเห็นว่ามีการทำงานตามที่คาดหวังไว้ก่อนที่คุณจะเปิดใช้งานกับกลุ่มเป้าหมายภายนอก โปรดทำตามขั้นตอนที่ให้ไว้เกี่ยวกับการส่งคำขอด้วยตนเอง และตรวจสอบว่าคุณไม่มีคำเตือนนี้บนแดชบอร์ดอีกต่อไป

การย้าย 'สตรีมโพสต์ความปลอดภัยของ URL' จะหยุดแอพ Facebook ของคุณไม่ให้เผยแพร่ URL ใดๆ ที่ไม่ได้ชี้กลับไปที่โดเมนที่เป็นของแอพ โปรดอย่าใช้ตัวเลือกนี้หากแอพของคุณจะเผยแพร่ลิงก์ไปยังไซต์อื่นๆ

คุณสมบัติแดชบอร์ดนี้ถูกลบออกแล้ว คุณต้องใช้ตำแหน่งข้อมูล '/{app-id}/accounts/test-users/' เพื่อเชื่อมโยงผู้ใช้ขั้นทดสอบกับแอพพลิเคชั่น คุณสามารถอ่านเพิ่มเติมได้ที่นี่

กรณีนี้เป็นลักษณะการทำงานที่กำหนดไว้แล้ว และได้รวบรวมเป็นเอกสารไว้ที่นี่ https://developers.facebook.com/docs/apps/test-users#rules ผู้ใช้ขั้นทดสอบเป็นแฟนของเพจ Facebook สาธารณะ หรือสร้างเนื้อหาบนเพจเหล่านั้นได้ เช่น การเขียนบนกระดานข้อความของเพจ อย่างไรก็ตาม ผู้ใช้ขั้นทดสอบสามารถดูและโต้ตอบกับแท็บของแอพใดๆ บนเพจที่เชื่อมโยงกับแอพนั้นซึ่งสร้างผู้ใช้ดังกล่าวได้

กรณีเป็นการกำหนดไว้แล้ว เราไม่อนุญาตโดเมนแบบกำหนดเองหลายรายการเนื่องเพื่อความปลอดภัย

กรณีนี้เป็นลักษณะการทำงานที่กำหนดไว้ กล่องการเข้าสู่ระบบใช้ความกว้างที่กำหนดตายตัว และจะไม่ปรับขนาดให้พอดีกับหน้าจอที่ใหญ่กว่า

ซึ่งเป็นลักษณะการทำงานที่กำหนดไว้ เป็นความรับผิดชอบของผู้พัฒนาในการกำหนด 'redirect_uri' ตามอุปกรณ์ของผู้ใช้ และหากผู้ใช้ใช้งานบนอุปกรณ์มือถือ 'redirect_uri' ควรเป็น URL ไซต์บนมือถือ

กรณีนี้เป็นลักษณะการทำงานที่กำหนดไว้แล้ว เนื่องจากจะป้องกันจุดอ่อนด้านการรักษาความปลอดภัยที่อาจเกิดขึ้นได้ บางเบราว์เซอร์อาจผนวกเนื้อหาย่อยของแฮชจาก URL กับตอนท้ายของ URL ใหม่ที่ถูกเปลี่ยนเส้นทาง (หาก URL ใหม่ไม่มีเนื้อหาย่อยของแฮชเป็นของตัวเอง)

ตัวอย่างเช่น หาก example1.com ส่งคืนการเปลี่ยนเส้นทางไปยัง example2.com จากนั้นเบราว์เซอร์ที่ไปยัง example1.com#abc จะไปยัง example2.com#abc และเนื้อหาย่อยของแฮชจาก example1.com จะสามารถเข้าถึงได้จากสคริปต์บน example2.com

เนื่องจากการเปลี่ยนเส้นทางขั้นตอนสิทธิ์ไปยังอีกแห่งสามารถทำได้ การทำให้ข้อมูลสิทธิ์ที่ละเอียดอ่อนสามารถเข้าถึงได้จากอีกแห่งก็สามารถทำได้เช่นกัน การดำเนินการนี้จะถูกลดลงโดยการผนวกเนื้อหาย่อยของแฮชเข้ากับ URL เปลี่ยนเส้นทาง เพื่อป้องกันลักษณะการทำงานของเบราว์เซอร์ หากคำนึงถึงความสวยงาม หรือลักษณะการทำงานฝั่งลูกค้าของ URL ที่เป็นผลลัพธ์ การใช้ window.location.hash สามารถทำได้ (หรือแม้ว่าจะเป็นการเปลี่ยนตำแหน่งฝั่งเซิร์ฟเวอร์ของคุณเอง) เพื่อลบอักขระที่ไม่เหมาะสม

Test apps created from Business apps will have Standard Access for all permissions and features.

No. The access level model only applies to permissions and features.

No. For a given permission, Business apps have either None, Standard, or Advanced Access.

Yes. A Business app will be auto-granted Standard Access and may request Advanced Access for a given permission.

Yes. For Business apps, the Advanced Access level includes access to all data within the Standard Access level.

หากต้องการแชร์ URL รูปภาพที่เกี่ยวข้องจะต้องมีขนาดอย่างน้อย 200x200 พิกเซล หากไม่ใช่กรณีนี้ คุณจะได้รับข้อผิดพลาดที่คล้ายกับข้อนี้ "og:image ที่มีไม่ใหญ่พอ โปรดใช้รูปภาพที่มีขนาดอย่างน้อย 200x200 พิกเซล

สำหรับการเลือกรูปภาพสำหรับ URL เราต้องตรวจสอบแท็ก 'og:image' ของคุณก่อน เพื่อดูว่ามีอยู่หรือไม่ และเกินจากข้อกำหนดขนาด 200x200 พิกเซลหรือไม่ หากไม่พบแท็ก 'og:image' เราจะเลือกรูปภาพแรกที่เราพบบนหน้าเว็บ

หากคุณได้รับข้อผิดพลาดแต่คุณคิดว่ารูปภาพบนไซต์ของคุณมีขนาดใหญ่กว่า 200x200 พิกเซล คุณควรตรวจสอบยืนยันว่าคุณได้กำหนดแท็ก 'og:image' อย่างถูกต้องแล้ว เนื่องจากสาเหตุที่เป็นไปได้มากที่สุดคือเราไม่สามารถดึงรูปภาพที่ไม่ถูกต้องจากไซต์ของคุณได้

เราได้ทำการเปลี่ยนแปลงลักษณะการทำงานของปลั๊กอินตัวแชร์เพื่อให้สอดคล้องกับปลั๊กอินและคุณสมบัติอื่นๆ บนแพลตฟอร์มของเรา

ตัวแชร์จะไม่ยอมรับพารามิเตอร์ที่กำหนดเองอีกต่อไป และ Facbook จะดึงข้อมูลที่แสดงในตัวอย่างด้วยวิธีเดียวกับที่ข้อมูลจะปรากฏบน Facebook ในฐานะโพสต์ จากเมตาแท็ก URL OG

ไม่ การแทนที่ 'caption' บน URL ที่แชร์ไม่สามารถทำได้ สามารถแทนที่ได้สำหรับ 'title' และ 'description' เท่านั้น

แอพไม่สามารถอัพโหลดไปยังอัลบั้มที่สร้างโดยแอพอื่นได้

ในบางกรณี อาจมีอัลบั้มที่ไม่เชื่อมโยงกับแอพใดๆ (อัลบั้มรูปภาพบนกระดานข้อความ) เราขอแนะนำให้ตรวจสอบช่อง can_upload หากช่อง can_upload ส่งคืนค่าเท็จมา หมายความว่าผู้ใช้ไม่สามารถวางรูปภาพในอัลบั้มนี้โดยตรงผ่านการดูอัลบั้มบนโปรไฟล์ได้

การกระตุ้นให้ดำเนินการจะแสดงขึ้นภายใต้ไอคอน 'เล่นซ้ำ' เมื่อวิดีโอเสร็จสิ้น

GIF ต้องมีขนาดไม่เกิน 8 MB เพื่อให้ภาพสามารถเคลื่อนไหวได้บน Facebook

ยังไม่รองรับการสร้างความคิดเห็นสำหรับโพสต์ที่ไม่ได้เผยแพร่ผ่าน API ในขณะนี้

โพสต์วิดีโอที่สร้างแบบอินไลน์จะไม่แสดงขึ้นในตำแหน่งข้อมูล promotable_posts เพราะว่าได้รับการโปรโมทแล้ว โพสต์วิดีโอที่สร้างแบบอินไลน์คือโพสต์ที่สร้างเป็นส่วนหนึ่งของการสร้างโฆษณา ดังนั้นจึงไม่สามารถโปรโมทแยกกันได้

มีการคาดการณ์ไว้แล้วเช่นกันว่าโพสต์ที่สร้างขึ้นแบบอินไลน์จะไม่แสดงขึ้นในตำแหน่งข้อมูล /promotable_posts

กรณีนี้สามารถเกิดขึ้นได้เมื่อคุณใช้โทเค็นการเข้าถึงเพจที่ผู้ใช้ซึ่งเชื่อมโยงกับโทเค็นถูกระบุเป็นผู้วิเคราะห์ในบทบาทในเพจภายใต้การตั้งค่าของเพจของคุณ

เมื่อมีการส่งคำขอสำหรับข้อมูลโดยใช้ API กราฟ จะมีการปรับใช้กฎความเป็นส่วนตัวหลายข้อ ซึ่งอาจทำให้ข้อมูลบางอย่างไม่ถูกส่งคืนแม้ว่าคุณสามารถดูได้บนเว็บไซต์ก็ตาม ซึ่งอาจขึ้นอยู่กับหลายปัจจัย เช่น การตั้งค่าความเป็นส่วนตัวของผู้ใช้ สิทธิ์การอนุญาตของระดับแอพ ฯลฯ ซึ่งหมายความว่าข้อมูลที่ถูกส่งคืนโดย API ไม่จำเป็นต้องรวมข้อมูลที่เห็นบนเว็บไซต์เสมอไป

หากโพสต์ถูกสร้างโดยใช้ 'object_story_spec' ของ API โฆษณา โพสต์เหล่านี้จะถูกจัดหมวดหมู่เป็นแบบอินไลน์ หากต้องการดูโพสต์เหล่านี้ คุณสามารถใช้จุดเชื่อมโยง /{page-id}/promotable_posts และใช้ตัวปรับเปลี่ยน 'is_inline' ในเวอร์ชั่น 2.3 หรือต่ำกว่า และ 'include_inline' ในเวอร์ชั่น 2.4 หรือสูงกว่า คุณสามารถอ่านเพิ่มเติมได้ที่นี่

ช่องการแชร์จะส่งคืนเมื่อโพสต์ถูกแชร์มากกว่า 10 ครั้ง หากโพสต์ถูกแชร์น้อยกว่า 10 ครั้ง เราสามารถยกเว้นช่องนี้หรือพยายามส่งคืนตัวเลขได้

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับตำแหน่งข้อมูลนี้ได้ที่นี่: https://developers.facebook.com/docs/graph-api/reference/v2.4/post

กรณีนี้เป็นค่าเก่าที่ใช้บนโครงสร้างพื้นฐานเดิมของเรา ซึ่งเราเก็บรักษาไว้เพื่อความเข้ากันได้กับรุ่นก่อนหน้าก่อนที่เราจะเปลี่ยนไปใช้เวอร์ชั่นที่ใหม่กว่า

ซึ่งจะเกิดขึ้นกับโพสต์ในอดีต แต่จะไม่เกิดขึ้นกับโพสต์ล่าสุด

การทำงานนี้เป็นลักษณะการทำงานที่กำหนดไว้ ไม่มีการเชื่อมต่อระหว่างโพสต์และรูปภาพในโพสต์ เราจะส่งคืนเฉพาะรูปภาพแรกที่ถูกอัพโหลดภายในโพสต์เท่านั้น

ช่อง 'แอพพลิเคชั่น' จะไม่ถูกส่งคืนหากโพสต์ถูกระบุที่มาไปยังเว็บไซต์ Facebook หรือแอพพลิเคชั่นบนมือถือ ซึ่งมีการปรับให้สอดคล้องกับเว็บไซต์ ซึ่งจะไม่แสดงการระบุที่มาสำหรับประเภทของโพสต์เหล่านั้น

ช่อง "ความเป็นส่วนตัว" ของโพสต์จะรวมข้อมูลเกี่ยวกับการมองเห็นโพสต์บน Facebook แต่เมื่อโพสต์บนเพจถูกกำหนดเป้าหมายหรือควบคุมเป้าหมายให้สามารถมองเห็นได้สำหรับกลุ่มเป้าหมายที่เฉพาะเจาะจง ข้อมูลในช่อง "ความเป็นส่วนตัว" จะไม่แสดงตัวเลือกการกำหนดเป้าหมายที่เลือกทั้งหมด

หากต้องการดูรายละเอียดแบบเต็มว่าโพสต์ถูกกำหนดเป้าหมายหรือควบคุมเป้าหมาย ให้ตรวจสอบช่อง 'การกำหนดเป้าหมาย' (สำหรับการควบคุมเป้าหมาย) และช่อง 'feed_targeting' (สำหรับการกำหนดเป้าหมายฟีดข่าว โปรดดูเอกสาร “โพสต์” สำหรับข้อมูลเพิ่มเติมว่าช่องใดสามารถใช้งานได้

ค่า comment_count ที่ถูกส่งคืนสำหรับโพสต์อาจมีความคิดเห็นที่ถูกซ่อนหรือลบออก จำนวนความคิดเห็นที่สามารถมองเห็นได้บนโพสต์จะไม่สามารถมีมากกว่า comment_count

การแทนที่ 'caption' ของ URL ที่แชร์ไม่สามารถทำได้ คุณสามารถแทนที่เฉพาะ 'title' และ 'description' ของ URL เท่านั้น

ดูข้อมูลเพิ่มเติมและช่องที่คุณสามารถเผยแพร่ผ่าน API กราฟได้ในเอกสารประกอบของ /feed ที่นี่: https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish

การทำงานนี้เป็นไปตามการออกแบบ ซึ่งสอดคล้องกับวิธีที่แสดงเนื้อหาที่สร้างของแอพ Facebook (มือถือหรือเว็บ) (โดยที่ไม่มีการระบุที่มาไปยัง Facebook เอง)

เราได้ทำการอัพเดตทางฝั่งเราเกี่ยวกับวิธีการดึงข้อมูลและการนำเสนอสตรีมและข้อมูลโพสต์ผ่าน API

หากคุณยังพบประเด็นปัญหาเกี่ยวกับการดึงโพสต์จาก API และเชื่อว่าการทำงานไม่ตรงกับที่รวบรวมไว้ในเอกสาร โปรดตรวจสอบยืนยันถึงประเด็นต่อไปนี้

• โทเค็นการเข้าถึงที่คุณใช้มีสิทธิ์การอนุญาตที่เหมาะสมสำหรับเข้าถึงโพสต์ที่คุณสนใจ
• โปรดตรวจสอบให้แน่ใจว่าการเรียก API ที่คุณดำเนินการเพื่อดึงข้อมูลโพสต์ใช้ 'id' ที่ส่งคืนคุณในการเรียกก่อนหน้า และตรวจสอบว่าคุณไม่ได้ปรับแต่ง ID ตามเพจ ผู้ใช้ หรือ ID อื่นๆ

รูปภาพที่อัพโหลดผ่าน Instagram จะถูกเผยแพร่เป็นการดำเนินการ Open Graph และต้องมีสิทธิ์การอนุญาต Open Graph ที่เหมาะสมเพื่อให้อ่านจาก API กราฟ ได้

ในกรณีของรูปภาพบน Instagram สิทธิ์การเข้าใช้ที่ต้องมีคือ "user_actions:instapp" เนื่องจาก "instapp" คือเนมสเปซแอพพลิเคชั่นสำหรับ Instagram

การดำเนินการ Open Graph จะไม่ปรากฏขึ้นบนการเชื่อมต่อ /feed แต่จะปรากฏที่บริเวณที่อัพโหลดรูปภาพเป็นการดำเนินการ Open Graph ซึ่งสามารถเข้าถึงได้ด้วยสิทธิ์การเข้าใช้ที่เหมาะสมผ่านการเชื่อมต่ออัลบั้มของผู้ใช้ หรือการเชื่อมต่อ /photos ที่สามารถใช้งานได้

สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับสิทธิ์การเข้าใช้ Open Graph ได้ที่นี่

กรณีนี้เป็นการกำหนดไว้แล้ว ระบบของเราจะส่งคืนข้อความแสดงข้อผิดพลาดด้านล่างสำหรับอ็อบเจ็กต์ที่ถูกลบหรือมองไม่เห็นสำหรับการตรวจสอบความเป็นส่วนตัว/สิทธิ์การอนุญาต

ลักษณะการทำงานนี้เป็นไปตามที่คาดคิด และเราไม่สนับสนุนการจัดแบ่งหน้าความคิดเห็นในรูปแบบนี้

ช่องtotal_counของพารามิเตอร์สรุปสำหรับปลายทาง/{user-id}/accounts อาจส่งคืนจำนวนที่สูงกว่าที่คาดการณ์ ทั้งนี้เนื่องจากtotal_count รวมหน้าที่ลบแล้วทุกหน้าที่ผู้ใช้เป็นผู้ดูแลไว้ด้วย

แต่ข้อมูลที่ส่งคืนโดยปลายทางจะรวมเฉพาะหน้าที่ยังไม่ลบออก

ตำแหน่งข้อมูล /user/likes ได้เปลี่ยนจากการแบ่งหน้าโดยอิงจากเวลา (การใช้ 'since' และ 'until' เป็นพารามิเตอร์) เป็นการแบ่งหน้าโดยอิงจากเคอร์เซอร์ (ใช้พารามิเตอร์ 'before' และ 'after')

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับข้อแตกต่างได้ที่นี่: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging

เราได้ทำการเปลี่ยนแปลงวิธีที่ตำแหน่งข้อมูลจะส่งคืนข้อมูล ด้วยการแนะนำ ID ผู้ใช้ในเพจ

เนื่องจากเวอร์ชั่น 1.0 ถูกยกเลิกใช้งานแล้ว เราจึงเน้นไปที่เวอร์ชั่น 2.x ซึ่ง /v2.0/{id} อาจส่งคืน https://www.facebook.com/{id} หรืออาจส่งคืน https://www.facebook.com/app_scoped_user_id/{id}

กรณีเป็นการกำหนดไว้แล้ว ข้อผิดพลาดนี้หมายความว่าโทเค็นการเข้าถึงที่คุณพยายามยืดอายุนั้นไม่สามารถเข้าถึง ID ของแอพที่พยายามยืดอายุโทเค็นนั้นได้

เหตุผลที่เป็นไปได้มากที่สุดสำหรับกรณีนี้คือ การที่แอพของคุณมีข้อจำกัดทางประชากรศาสตร์ที่นำมาปรับใช้ และเราตรวจพบว่าผู้ใช้ที่มีโทเค็นที่คุณพยายามยืดอายุนั้นไม่ตรงตามข้อจำกัด (หรือไม่ตรงตามข้อจำกัดอีกต่อไป เนื่องจากผู้ใช้ได้ย้ายตำแหน่งที่ตั้ง หรือเราตรวจจับพบตำแหน่งที่ตั้งแต่แม่นยำกว่าของผู้ใช้นั้น)

เหตุผลที่เป็นไปได้รองลงมาคือ เราไม่สามารถยืนยันได้ว่าผู้ใช้ตรงตามข้อกำหนด (เช่น เราไม่ทราบตำแหน่งที่ตั้งของผู้ใช้) และข้อจำกัดของแอพขอบคุณไม่อนุญาตผู้ใช้เหล่านี้

ตั้งแต่กรกฎาคม 2013 เป็นต้นไป การใช้ตำแหน่งข้อมูลการค้นหาโดยใช้อีเมลในประเภทการค้นหาของผู้ใช้

อีกทั้งการแนะนำเวอร์ชั่น 2.0 ยังทำให้มีการเปลี่ยนแปลงกับ Graph API หลายรายการอีกด้วย ความสามารถในการค้นหาบนโพสต์สาธารณะและการค้นหาคีย์เวิร์ดยังไม่พร้อมใช้งานในเวอร์ชั่น 2.0

โปรดดูรายละเอียดเพิ่มเติมจากบันทึกการเปลี่ยนแปลง

แอพพลิเคชั่นใดๆ ที่สร้างหลังจากวันที่ 30 เมษายน 2014 จะใช้ API เวอร์ชั่น 2 ขึ้นไป ซึ่งจะส่งคืนเพื่อนในแอพของคุณพร้อมกับ /me/friends ตำแหน่งข้อมูลตามที่คุณระบุเท่านั้น นอกจากนี้ ขณะนี้ ID ผู้ใช้ทั้งหมดเป็น ID ในแอพที่ไม่ซ้ำกันและจะอยู่ในแอพที่ระบุของคุณอย่างถาวร

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับคุณสมบัติและการเปลี่ยนแปลงทั้งหมดที่แนะนำเป็นส่วนหนึ่งของเวอร์ชั่น 2.0ได้

เอกสารสำหรับช่อง email ของอ็อบเจ็กต์ User จะระบุลักษณะการทำงาน ซึ่งก็คือ “ช่องนี้จะไม่ถูกส่งคืนหากไม่มีที่อยู่อีเมลที่สามารถใช้งานได้"

มีหลายกรณีที่คุณอาจคิดว่าผู้ใช้ควรส่งคืนที่อยู่อีเมลแต่ไม่มีการส่งคืนจริง เพื่อความเป็นส่วนตัวและการรักษาความปลอดภัย การอธิบายเหตุผลที่ชัดเจนถึงการที่ไม่มีการส่งคืนที่อยู่อีเมลนั้นไม่สามารถทำได้

เหตุผลที่อาจเป็นไปได้มีดังนี้

• ไม่มีที่อยู่อีเมลในบัญชีผู้ใช้
• ไม่มีที่อยู่อีเมลที่ได้รับการยืนยันในบัญชีผู้ใช้
• ไม่มีที่อยู่อีเมลที่ได้รับการตรวจสอบยืนยันในบัญชีผู้ใช้
• ผู้ใช้เข้าสู่จุดตรวจสอบเพื่อรักษาความปลอดภัยที่กำหนดให้ผู้ใช้ยืนยันที่อยู่อีเมลของตนอีกครั้ง และผู้ใช้ยังไม่ได้ดำเนินการ
• ที่อยู่อีเมลของผู้ใช้ไม่สามารถเข้าถึงได้

โพสต์เหล่านี้ไม่สามารถดึงผ่าน API ได้เนื่องจากโพสต์ในโพสต์เหล่านี้มีเนื้อหาของผู้ใช้ที่ถูกแชร์ซ้ำบนเพจ และเนื่องจากผู้ใช้ไม่ได้อนุญาตให้แอพดูเนื้อหาของเธอ/เขาได้

โพสต์ของผู้ใช้ที่แชร์ในไทม์ไลน์ของเพจไม่สามารถใช้งานได้ผ่าน API หากผู้ใช้ไม่มีสิทธิ์อนุญาตพื้นฐานสำหรับประเภทเนื้อหาของโพสต์นั้น

ในการแก้ปัญหาเบื้องต้นเพื่อดูโพสต์รูปภาพจากแฟนที่หายไป คุณอาจสามารถดึงข้อมูลอัลบั้มของเพจโดยใช้โทเค็นการเข้าถึงของเพจได้ ซึ่งรูปภาพควรอยู่ในอัลบั้มรูปภาพบนไทม์ไลน์

ถึงแม้ว่าโพสต์จะเป็นสาธารณะและกล่าวถึงเพจที่ถูกส่งคำขอก็ตาม แอพของคุณก็ไม่สามารถเห็นโพสต์เหล่านั้นได้โดยที่ไม่มีสิทธิ์การอนุญาต read_stream จากเจ้าของของโพสต์เหล่านั้น ซึ่งหมายความว่าตำแหน่งข้อมูล {page_id}/tagged ไม่ส่งคืนโพสต์ทั้งหมด

คุณสามารถอ่านเกี่ยวกับกรณีนี้ได้ในเอกสาร “ฟีดของเพจ”

มีหลายกรณีที่แอพบางแอพ (หรือแอพใดก็ตาม) อาจไม่สามารถรับข้อมูลเกี่ยวกับผู้ใช้ Facebook เนื่องจากการตั้งค่าความเป็นส่วนตัวของผู้ใช้นั้น โดยรวมถึงเมื่อเข้าถึงโพสต์ที่สร้างโดยผู้ใช้นั้นในบริบทที่แอพของคุณคาดว่าจะสามารถเห็นโพสต์ได้ (เช่น การจัดการเพจ)

ตัวอย่างเช่น เมื่อผู้ใช้ได้บล็อกแอพ หรือได้ปิดใช้งานแอพแพลตฟอร์มทั้งหมดไม่ให้เข้าถึงข้อมูลของตนผ่าน API

เนื่องจากมีการวางจำหน่ายเวอร์ชั่น 2.1 ของกราฟ API ฟังก์ชั่นนี้จึงถูกลบออก สำหรับแอพที่สร้างก่อน 7 สิงหาคม 2014 ช่องนี้จะไม่แสดงขึ้นใน signed_request อีกต่อไป

สำหรับแอพที่สร้างก่อนวันนี้ คุณสมบัติ “ถูกใจแล้ว” จะส่งคืนค่า “จริง” เสมอ โดยไม่คำนึงว่าบุคคลนั้นได้กดถูกใจเพจหรือไม่

โปรดใช้ลิงก์ paging.next และ paging.previous ที่ส่งคืนในในการตอบกลับโดยตรงเพื่อไปยังเพจผลลัพธ์อื่นๆ การใช้ลิงก์ที่ให้ไว้จะช่วยให้มั่นใจว่าแอพพลิเคชั่นของคุณจะไม่ขัดข้องเมื่อรูปแบบของลิงก์การแบ่งหน้าเปลี่ยนแปลงในอนาคต

ไม่จำเป็นว่าคุณสมบัติและการทำงานบนไซต์จะต้องเป็นการแม็ปแบบ 1:1 เท่านั้น ซึ่งเหมือนกับรายการอื่นๆ บน API คุณสมบัติการเข้าถึงแบบออร์แกนิกของการเรียก UI ข้อมูลเชิงลึกของเพจนั้นแตกต่างและคำนวณต่างจากการเข้าถึงแบบออร์แกนิกผ่าน API

ตัวอย่างเช่น ค่า 'organic' ใน UI ข้อมูลเชิงลึกของเพจสอดคล้องกับค่า 'unpaid' ในเกณฑ์ชี้วัด page_impressions_by_paid_non_paid_unique ที่พร้อมใช้บน API กราฟ

เราต้องการปรับทั้งสองค่าให้สอดคล้องกับ แต่อาจต้องใช้เวลาสักระยะ

ข้อผิดพลาดนี้แสดงว่าผู้ใช้ที่เชื่อมโยงกับโทเค็นการเข้าถึงไม่สามารถดูเพจนี้ได้เนื่องจากเหตุผลด้านความปลอดภัย ตัวอย่างเช่น เพจอาจไม่ถูกเผยแพร่และผู้ใช้ไม่ใช่ผู้ดูแลที่ถูกต้องของเพจ

ข้อผิดพลาดนี้มักเกิดขึ้นเมื่อคุณพยายามดึงข้อมูลเชิงลึกของเพจที่กำลังใช้งาน ซึ่งนับว่ามีส่วนเกี่ยวข้อง หากคุณลดช่วงเวลาที่คุณส่งคำขอข้อมูลเชิงลึกโดยใช้ช่อง 'since' และ 'until'

กรณีนี้เป็นลักษณะการทำงานที่คาดคิดไว้ล่วงหน้าสำหรับแอพขั้นทดสอบและแอพในโหมดการพัฒนา เมื่อมีการเผยแพร่แอพ การทำงานจะเป็นไปตามที่คาดหวัง

สามารถดูจุดบกพร่องที่เกี่ยวข้องกับข้อจำกัดทางการออกแบบได้ที่นี่

เฉพาะผู้ดูแล ผู้แก้ไข หรือผู้ดูแลเท่านั้นที่สามารถอ่านและส่งข้อความได้ ผู้คนที่มีบทบาทอื่นๆ เช่น ผู้ลงโฆษณาและผู้วิเคราะห์ ไม่สามารถอ่านการสนทนาของเพจได้

โปรดไปที่หน้าความช่วยเหลือนี้เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับบทบาทในเพจต่างๆ : https://www.facebook.com/help/289207354498410

จำนวนทั้งหมดของ 'page_fans' และ 'page_fans_country' ไม่ได้เท่ากันเสมอไป มีปัจจัยหลายประการที่สามารถส่งผลต่อค่า 'page_fans_country' ตัวอย่างเช่น แฟนของเพจบางคนอาจไม่ได้กำหนดประเทศบ้านเกิดในบัญชีผู้ใช้ของตน หรือแฟนของเพจบางคนอาจมีการตั้งค่าความเป็นส่วนตัวที่ซ่อนบ้านเกิดของตนได้

เรียนรู้เพิ่มเติมเกี่ยวกับการตั้งค่าความเป็นส่วนตัวของ Facebook โดยไปที่เพจในศูนย์ช่วยเหลือ: https://www.facebook.com/help/445588775451827

โพสต์บนเพจบางรายการเป็นการแชร์เนื้อหาผู้ใช้ซ้ำ หากผู้ใช้ที่สร้างโพสต์นั้นไม่ได้ให้สิทธิ์อนุญาตที่ขอไปยังแอพ แอพจะไม่สามารถเข้าถึงโพสต์ผ่าน API กราฟ ได้ ดังนั้นจึงไม่สามารถแสดงความคิดเห็นบนโพสต์เหล่านั้นได้

โพสต์ที่สร้างแบบอินไลน์ให้เป็นส่วนหนึ่งของการสร้างชิ้นงานโฆษณาไม่สามารถโปรโมทแยกได้ ดังนั้นโพสต์เหล่านี้จึงจะไม่ปรากฏในการกระตุ้นไปยังตำแหน่งข้อมูล /promotable_posts ของเพจ

กรณีนี้เกิดได้ขึ้นหากคุณใช้แอพที่ยังอยู่ในโหมดการพัฒนาเพื่อกำหนดเวลาโพสต์ โปรดใช้แอพที่เผยแพร่แล้วและการทำงานจะกลับมาเป็นปกติ

เราขออภัยที่ขณะนี้เราไม่รองรับการสร้าง การอัพเดต หรือการลบรูปภาพหน้าปกผ่าน API

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับ API รูปภาพหน้าปก โปรดไปที่https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating

ไม่มี การแก้ไขความกว้างผ่าน API ไม่สามารถทำได้

กรณีนี้เป็นลักษณะการทำงานปัจจุบัน ผู้ดูแลเพจไม่สามารถโพสต์ไปยังเพจได้เองผ่าน API กราฟ โดยฟังก์ชั่นนี้สามารถใช้ได้บน http://www.facebook.com/ และแอพบนมือถือของเราเท่านั้น

ไม่ ไม่มีวิธีที่จะดูรายชื่อผู้ใช้ที่ถูกใจเพจได้ การทำงานนี้เป็นไปตามการออกแบบ

โปรดตรวจสอบให้แน่ใจว่าคุณใช้โทเค็นการเข้าถึงเพจเมื่อดำเนินการในฐานะเพจ ข้อความแสดงข้อผิดพลาดแสดงให้เห็นว่าคุณกำลังใช้โทเค็นการเข้าถึงผู้ใช้แทนที่จะใช้โทเค็นการเข้าถึงเพจ

คุณสามารถเรียนรู้เกี่ยวกับโทเค็นการเข้าถึงประเภทต่างๆ ได้ที่นี่: https://developers.facebook.com/docs/facebook-login/access-tokens

การดำเนินการนี้ไม่สามารถทำได้ การปักหมุดโพสต์และการอ่านโพสต์ที่ปักหมุดสามารถใช้งานได้ผ่านผลิตภัณฑ์ Facebook แบบเนทีฟเท่านั้น

หากเปิดการสะท้อนความคิดเห็นสำหรับ URL ภายนอกที่บางจุด URL จะบันทึกการตอบสนองต่อโพสต์ที่มีการสะท้อนความคิดเห็น และจะส่งคืนค่าเมื่อมีการเรียกข้อมูล {URL-id}/reactions>

ขณะนี้ระบบยังไม่รองรับการดึงข้อมูลที่มีค่าข้อมูลแยกย่อยของปลายทาง /app_insights/app_event มากกว่า 1,000 รายการ เราแนะนำให้ใช้ UI ของ Facebook Analytics เพื่อระบุจุดข้อมูลที่เฉพาะเจาะจง อย่างเช่น ระบุประเทศ หากสนใจที่จะแยกย่อยข้อมูลในบางหมวดหมู่

คุณอาจเรียกใช้ปลายทางเร็วเกินไปก่อนที่ข้อมูลจะเผยแพร่ไปยังเซิร์ฟเวอร์ของเรา

ควรรอ 1-2 วินาทีก่อนเรียก API เพื่อให้ข้อมูลเผยแพร่ไปยังเซิร์ฟเวอร์ทั้งหมดของเราก่อน

โดยทั่วไปเกณฑ์ชี้วัด 'page_fans_country' จะเป็นส่วนย่อยของจำนวนpage_fans เกณฑ์ชี้วัดนี้ครอบคลุมข้อมูลแยกย่อยตามประเทศของแฟนเพจ ซึ่งทำให้เราสามารถระบุประเทศของผู้ใช้ได้อย่างถูกต้อง

นอกจากนี้เกณฑ์ชี้วัดยังรวมเฉพาะประเทศยอดนิยม (ตามจำนวนแฟน) สำหรับแฟนเพจ ไม่ใช่ทุกประเทศที่มีแฟนเพจ สำหรับเพจที่มีแฟนอยู่ในหลายประเทศ ประเทศที่มีความนิยมต่ำสุดจะไม่รวมอยู่ในเกณฑ์ชี้วัดนี้

API ไม่รองรับการใช้การแบ่งหน้าตามออฟเซ็ต

คุณควรใช้ลิงก์ “การแบ่งหน้า” ที่ถูกส่งคืนที่ด้านท้ายของการตอบกลับแต่ละรายการ จาก API กราฟ หรือใช้การแบ่งหน้าตาม “เคอร์เซอร์” ซึ่งแนะนำให้ใช้มากที่สุดแทน

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีแบ่งหน้าอย่างถูกต้องผ่าน API กราฟที่อธิบายไว้ที่นี่: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging

มีโทเค็นการเข้าถึงอายุการใช้งานยาวและอายุการใช้งานสั้น โทเค็นการเข้าถึงอายุการใช้งานสั้นมีไว้สำหรับช่วงเวลาที่ใช้งานสั้น และโดยปกติจะหมดอายุภายในไม่กี่ชั่วโมง

คุณสามารถแลกเปลี่ยนโทเค็นการเข้าถึงอายุการใช้งานสั้นเป็นโทเค็นการเข้าถึงอายุการใช้งานยาวได้ ซึ่งจะมีอายุการใช้งานประมาณ 60 วัน

คุณสามารถอ่านเกี่ยวกับกรณีนี้ได้ในเอกสารประกอบโทเค็นการเข้าถึง

กรณีนี้เป็นลักษณะการทำงานที่มีการกำหนดไว้แล้ว โดย API การค้นหาจะเคารพความเป็นส่วนตัวบน Facebook และถูกปรับให้เหมาะสมกับผู้ใช้ที่มีโทเค็นการเข้าถึงที่คุณกำลังใช้ แต่ไม่รองรับการค้นหาแฮชแท็ก และไม่ได้ออกแบบมาเพื่อมีภาวะที่การค้นหาเดียวกันทำงานในการเติมข้อความส่วนหน้าสำหรับการค้นหาบน Facebook.com

เราไม่รองรับหรือไม่ได้มีเป้าหมายในการส่งคืน API การค้นหาด้วยผลลัพธ์ที่มีค่าเดียวกัน หรือผลลัพธ์ใดๆ ที่เป็นการค้นหาบน Facebook.com และโดยปกติแล้ว โพสตที่ถูกส่งคืนผ่าน API จะอยู่ภายใต้นโยบายการจำกัดและการตรวจสอบการรักษาความปลอดภัยมากกว่าโพสต์เดียวกันบน Facebook

ระบบของเราบังคับใช้ขีดจำกัดอัตรากับการเรียก API ที่ดำเนินการโดยแอพ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับขีดจำกัดต่างๆ และการป้องกันไม่ให้แอพของคุณถูกแบบจำกัดผลลัพธ์ โปรดไปที่ https://developers.facebook.com/docs/marketing-api/api-rate-limiting

คุณสามารถเพิ่มภาพ GIF แบบเคลื่อนไหวในบทความของคุณโดยใช้อิลิเมนต์ <figure> ซึ่งจะล้อมอิลิเมนต์ <img> ที่อ้างอิง URL ของภาพ GIF เช่นเดียวกับภาพอื่นๆ คุณสามารถเพิ่มคำบรรยายภาพและที่มาในภาพ GIF ได้

โปรดดูเอกสารประกอบสำหรับรายละเอียดเพิ่มเติมและตัวอย่างได้ ที่นี่

คุณสามารถใช้ URL ของฟีดในเพจต่างๆ ซ้ำได้ แต่โปรดทราบว่า เฉพาะบทความที่มี URL แบบบัญญัติที่ตรงกับโดเมนที่เพจอ้างสิทธิ์เท่านั้นที่จะถูกเพิ่ม

เราขอแนะนำให้ใช้ฟีด RSS ที่แตกต่างกันสำหรับแต่ละเพจโดยให้มีเฉพาะบทความที่เพจควรเพิ่มเท่านั้น

คุณสามารถเพิ่มการฝังโซเชียลที่ได้รับการสนับสนุนรวมทั้งวิดีโอได้โดยใช้การฝังโซเชียล สำหรับโปรแกรมเล่นวิดีโอของบุคคลที่สาม คุณสามารถเพิ่มในบทความของคุณเป็นการฝังแบบอินเตอร์แอคทีฟได้

คุณสามารถฝังกราฟิกและเนื้อหาแบบอินเตอร์แอคทีฟในบทความของคุณได้โดยใช้ <figure> ที่มีคลาส op-interactive ภาพควรมี <iframe> ซึ่งประกอบด้วยเนื้อหาที่ต้องการฝัง

คุณสามารถดูรายละเอียดเพิ่มเติมและตัวอย่างได้ ที่นี่

คุณสามารถระบุคำบรรยายภาพได้โดยใช้อิลิเมนต์ <figcaption> ภายในคำบรรยายภาพ คุณสามารถเพิ่มที่มาได้โดยใช้อิลิเมนต์ <cite>

คุณสามารถดูรายละเอียดเพิ่มเติมและตัวอย่างในเอกสารประกอบได้ ที่นี่

เมื่อบทความอยู่ในโหมดฉบับร่าง บทความนั้นจะปรากฏในรูปแบบบทความทันใจต่อผู้ดูแลเพจเท่านั้น เมื่อมีการเผยแพร่บทความแบบสด ทุกคนที่ใช้ Facebook จะสามารถแชร์ได้และจะแสดงเป็นบทความทันใจซึ่งทุกคนจะสามารถเห็นได้

โปรดตรวจสอบว่าคุณได้ให้สิทธิ์การอนุญาต pages_manage_instant_articles กับแอพแล้ว สิทธิ์การอนุญาตนี้มีความจำเป็นในการเรียกให้วิธีการ API อ่านและอัพเดตบทความทันใจของเพจของคุณ

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ API ได้ ที่นี่

หากคุณใช้แอตทริบิวต์ dir="rtl" ในการแสดงภาษาที่อ่านจากขวาไปซ้ายในบทความ คุณอาจกำลังดูบทความในแอพที่ไม่สนับสนุนภาษาที่อ่านจากขวาไปซ้ายในบทความทันใจ

โปรดตรวจสอบให้แน่ใจว่าคุณกำลังใช้แอพในเวอร์ชั่นล่าสุด เวอร์ชั่นแอพขั้นต่ำที่สนับสนุนภาษาที่อ่านจากขวาไปซ้าย ได้แก่

• Facebook สำหรับ iOS: 52.0
• Facebook สำหรับ Android: 69.0
• ตัวจัดการเพจสำหรับ iOS: 44.0

โปรดตรวจสอบว่าได้ตั้งค่าแอตทริบิวต์ dir=“rtl” ในแท็ก <body> ของบทความของคุณแล้ว หากบทความของคุณไม่ได้ใช้ภาษาที่อ่านจากขวาไปซ้าย คุณก็ไม่ควรตั้งค่าแอตทริบิวต์นี้ในบทความของคุณ

ตัวอย่างฟีดข่าวของบทความจะใช้ภาพที่ระบุไว้ในเมตาแท็ก og:image ในเวอร์ชั่นเว็บของบทความ คุณยังสามารถเลือกที่จะแทนที่ภาพด้วยวิดีโอได้โดยการเพิ่มคลาส “fb-feed-cover” ในวิดีโอใดๆ ในบทความของคุณ โปรดอ่านเพิ่มเติมเกี่ยวกับตัวอย่างฟีดข่าว ที่นี่

เมื่อมีการแชร์ URL ของบทความก่อนที่จะเผยแพร่บทความทันใจ จะมีการเปลี่ยนเส้นทางไปยังบทความในเวอร์ชั่นเว็บบนมือถือ เมื่อเผยแพร่บทความทันใจแล้ว การแชร์ลิงก์ทั้งหมดรวมทั้งลิงก์ที่มีการโพสต์ก่อนเผยแพร่บทความจะแสดงบทความทันใจโดยอัตโนมัติเมื่อดูบนมือถือ

เกณฑ์ชี้วัด “ยอดดู” ในขณะนี้จะพร้อมให้ผู้ใช้ iOS ดูได้เท่านั้น ยอดดูบน Android จะมีการนับแยกต่างหากไว้ในเกณฑ์ชี้วัด “android_views”

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้ ที่นี่

เรายังไม่ได้เปิดใช้งานการสนับสนุนฟีดการพัฒนาในตัวจัดการเพจสำหรับ Android วิธีทางอ้อมในการดูบทความของคุณบน Android ในขณะนี้คือ คุณสามารถลองเพิ่มบทความในฟีดการสร้างเป็นแบบฉบับร่างได้

ในการแก้ไขบทความทันใจของคุณ คุณสามารถใช้อินเทอร์เฟซเพจได้ ในการดำเนินการ โปรดไปที่เพจของคุณบนเบราว์เซอร์ จากนั้นไปที่ เครื่องมือการเผยแพร่ > บทความทันใจ คุณจะสามารถดูและแก้ไขบทความของคุณได้จากที่นั่น โปรดอ่านเพิ่มเติมได้ที่นี่: https://developers.facebook.com/docs/instant-articles/publishing

การหมดเวลาของการดาวน์โหลดฟีดขณะนี้อยู่ที่ 30 วินาที

ไม่ได้ ลิงก์ที่แชร์ต้องเป็น URL แบบบัญญัติของบทความ หาก URL เปลี่ยนไป เช่น โดยการเพิ่มพารามิเตอร์ URL นั้น จะถือเป็น URL ที่แตกต่างกัน

ข้อผิดพลาดหรือคำเตือนที่ได้รับเมื่อเพิ่มฟีด RSS จะปรากฏในแท็บบทความทันใจของเพจการตั้งค่าของคุณ คุณยังสามารถดูคำเตือนและข้อผิดพลาดของแต่ละบทความได้โดยคลิกที่บทความจากแท็บบทความทันใจของเพจเครื่องมือการเผยแพร่

โปรดตรวจสอบว่าฟีด RSS ของคุณนั้นเป็นไปตามรูปแบบที่ระบุไว้ ที่นี่

โดย URL แบบบัญญัติของบทความของคุณควรใช้โดเมนหรือโดเมนย่อยที่มีการกำหนดค่าสำหรับเพจของคุณ หากคุณเห็นว่ามีการเพิ่มบทความใหม่ แต่การอัพเดตของบทความปัจจุบันไม่ปรากฏ โปรดตรวจสอบว่าคุณได้เพิ่มการประทับเวลา “op-modified” แล้ว

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้ได้ ที่นี่

เหตุผลที่ที่พบบ่อยของการที่บทความไม่ได้รับการอัพเดตจากฟีด RSS คือ การประทับเวลา op-modified ของบทความในฟีดนั้นเป็นเวอร์ชั่นเดียวกับที่เราดึงข้อมูลมาล่าสุด เราจะอัพเดตบทความก็ต่อเมื่อการประทับเวลาเป็นเวลาหลังจากเวอร์ชั่นล่าสุดเท่านั้น

นอกจากนี้ คุณยังควรยืนยันว่ามีการใช้ URL แบบบัญญัติเดียวกันนั้นในเวอร์ชั่นอัพเดตของบทความอีกด้วย

โปรดดูเอกสารประกอบสำหรับข้อมูลเพิ่มเติมเกี่ยวกับการดึงข้อมูลบทความจากฟีด RSS ที่นี่

เราพยายามที่จะโหลดและแยกวิเคราะห์ฟีด RSS ของคุณทั้งหมดภายใน 10 วินาที ข้อผิดพลาดนี้ระบุว่าการดำเนินการนี้ล้มเหลว

วิธีหนึ่งที่จะแก้ไขปัญหานี้ได้คือการใส่รายการในฟีด RSS ให้น้อยลง เช่น โดยการใส่บทความใหม่/ที่เปลี่ยนแปลงไปเมื่อประมาณ 10 นาทีที่แล้ว เนื่องจากฟีดจะถูกดึงข้อมูลทุกๆ 3 นาที การใส่บทความที่ไม่มีการเปลี่ยนแปลงใดๆ จึงเป็นสิ่งไม่จำเป็น

เรายังไม่มีรายการที่อยู่ IP แบบคงที่สำหรับครอว์เลอร์ อย่างไรก็ตาม คุณสามารถใช้เอเจนท์ผู้ใช้ของครอว์เลอร์ของเราแทนได้: facebookexternalhit/1.1

หากการอัพเดตบทความทันใจที่มีอยู่แล้วเกิดขึ้นนานกว่า 24 ชั่วโมงเมื่อพิจารณาจากเวลาที่ผู้ควบคุมปรับเปลี่ยนแล้ว บทความดังกล่าวจะถูกละเว้นจากการดึงข้อมูลขึ้นแสดง ซึ่งหมายความว่าเวลาที่ปรับเปลี่ยนควรอยู่ในช่วง 24 ชั่วโมงหลังจากเวลาปรับเปลี่ยนที่ตั้งไว้ในบทความซึ่งไม่ใช่เวลาปัจจุบัน ในกรณีที่การอัพเดตถูกละเว้น คุณสามารถทำการเปลี่ยนแปลงกับบทความได้ด้วยตนเองผ่านเครื่องมือตัวแก้ไขบทความทันใจผ่านเว็บ

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้ได้ ที่นี่

โปรดตรวจสอบว่าบทความที่ซ้ำกันนั้นใช้ URL แบบบัญญัติที่แตกต่างกันหรือไม่ เราใช้ URL แบบบัญญัติของบทความเป็นตัวระบุที่ไม่ซ้ำกัน ดังนั้นบทความที่มี URL แบบบัญญัติที่ต่างกันจะไม่ใช่บทความเดียวกัน

ปัญหาที่พบบ่อยคือ CMS ของคุณอาจเผยแพร่บทความที่ได้รับการอัพเดตโดยใช้ URL ที่ต่างกัน จึงทำให้การอัพเดตนั้นถูกเพิ่มเป็นบทความใหม่

ควร แต่ละเพจจะถูกแม็ปไว้กับชื่อโดเมนซึ่งเป็นการแม็ปแบบ 1:1 เรากำหนดให้บทความทันใจที่เป็นของเพจต้องมี URL แบบบัญญัติที่เป็นของโดเมนหรือโดเมนย่อยเดียวกันที่ระบุ

อย่างไรก็ตาม โดเมนของ URL ของฟีด RSS นั้นไม่จำเป็นต้องตรงกับโดเมนที่แม็ปไว้กับเพจ โดยข้อจำกัดนี้ใช้กับ URL แบบบัญญัติของบทความในฟีดเท่านั้น

หากคุณต้องการเผยแพร่บทความในเพจต่างๆ ตามภาษา คุณควรตั้งค่าฟีด RSS ที่แตกต่างกันสำหรับแต่ละภาษาและกำหนดค่าให้แต่ละเพจใช้ฟีด RSS ที่เหมาะสม

ไม่ เนื่องจากบทความถูกเพิ่มจากฟีด RSS ของคุณ จึงจะยังคงถูกจัดเก็บไว้เป็นบทความทันใจจนกว่าจะถูกลบออกจากเครื่องมือการเผยแพร่ของเพจของคุณ คุณสามารถลบบทความออกจากฟีด RSS ได้อย่างปลอดภัยเพื่อเร่งการดึงข้อมูลถัดไปได้

ในขณะนี้ ยังไม่มีวิธีเผยแพร่หรือลบบทความผ่าน API แต่เรากำลังพัฒนาอยู่

ปุ่มถูกใจจะใช้สีเน้นที่มีการกำหนดค่าไว้ในการตั้งค่าลักษณะ โปรดตรวจสอบว่าคุณได้กำหนดค่าสีให้ตัดกับส่วนหัวแล้ว

นอกจากนี้ ปุ่มถูกใจจะปรากฏก็ต่อเมื่อผู้ใช้ที่ดูบทความยังไม่ได้ถูกใจเพจเท่านั้น ดังนั้นปุ่มจะไม่ปรากฏต่อผู้ดูแลเพจที่ถูกใจเพจแล้วก่อนหน้านี้

โปรดตรวจสอบว่าคุณไม่ได้ใช้แท็ก <br> หลายแท็กภายในแถวเดียว ในการแยกข้อความของบทความของคุณให้เป็นหลายย่อหน้า เราแนะนำให้ใช้แท็กย่อหน้า (<p>) แทนการแบ่งบรรทัด

โปรดตรวจสอบว่าคุณได้เพิ่มคลาส “op-tracker” ในแท็ก <figure> ที่ล้อมพิกเซลการติดตามอยู่ หากไม่มีแท็กนี้ พิกเซลการติดตามอาจถือเป็นการฝังภาพ

โปรดตรวจสอบว่าคุณได้ใช้ไฟล์วิดีโอในรูปแบบที่ได้รับการสนับสนุน คุณสามารถดูรายการรูปแบบวิดีโอที่ได้รับการสนับสนุนได้ ที่นี่

นอกจากนี้คุณยังควรตรวจสอบว่าคุณได้ล้อมการฝังวิดีโอในแท็ก <figure> อย่างถูกต้อง และคุณไม่ได้ล้อมวิดีโอไว้ในย่อหน้า (แท็ก <p>)

คำเตือนนี้มักจะปรากฏ หากคุณล้อมเนื้อหาที่ไม่ใช่ข้อความภายในย่อหน้า เช่น ภาพหรือการฝังแบบอินเตอร์แอคทีฟ (แท็ก <p>) ย่อหน้าควรมีเฉพาะข้อความส่วนเนื้อหาเท่านั้น และควรเพิ่มเนื้อหาอื่นใดภายในแท็ก <figure> หรืออิลิเมนต์คอนเทนเนอร์ที่เหมาะสมอื่นๆ

ไม่ได้ อิลิเมนต์คำบรรยายภาพ (<figcaption>) จะสนับสนุนเฉพาะแท็ก <h1>, <h2> และ <cite> เท่านั้น แท็กย่อหน้า (<p>) ไม่ได้รับการสนับสนุน

แอตทริบิวต์ “ปิดเสียง”่ ไม่ได้รับการสนับสนุนในอิลิเมนต์ <video> ในขณะนี้

โฆษณาในบทความจะถูกกำหนดโดยใช้อิลิเมนต์ HTML5 <figure> มาตรฐานที่จะล้อมอิลิเมนต์ <iframe> ที่มีมาร์กอัพสำหรับโฆษณาของคุณ คุณสามารถใช้คลาส op-ad กับอิลิเมนต์ <figure> เพื่อระบุโฆษณาในบทความได้ วิธีระบุโฆษณามีสองแบบคือ การระบุ URL ของโฆษณาโดยตรงโดยใช้แอตทริบิวต์ “src” ใน iframe หรือโดยการฝังชุด HTML แบบ Unescaped และสคริปต์ภายใน iframe

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับโฆษณาได้ที่นี่: https://developers.facebook.com/docs/instant-articles/reference/ad

อิลิเมนต์ภาพมาตรฐานไม่สนับสนุนการใช้ภาพ SVG แต่คุณสามารถใช้การฝังแบบอินเตอร์แอคทีฟ (“op-interactive”) แล้วเพิ่มอิลิเมนต์ <img> ภายใน iframe ด้วยชุดแอตทริบิวต์ “src” ของ URL ของภาพ SVG แทนได้

คุณสามารถใช้อิลิเมนต์แผนที่ตามระบุไว้ที่นี่ได้: https://developers.facebook.com/docs/instant-articles/reference/map วิธีนี้เป็นวิธีที่แนะนำในการเพิ่มแผนที่ในบทความทันใจ

หากคุณเพิ่มการฝัง Google Maps ในบทความของคุณเป็นการฝังแบบอินเตอร์แอคทีฟ เราทราบปัญหาเกี่ยวกับการทำงานของการฝังนี้ และปัญหานี้อาจทำให้แผนที่ไม่ปรากฏได้ วิธีแก้ไขปัญหานี้ทางอ้อมคือ คุณต้องใส่ iframe ที่โหลดเนื้อหาแผนที่ (“https://www.google.com/maps/embed?...”) ไว้ภายใน iframe อื่น

คุณสามารถฝังโมดูลแบบอินเตอร์แอคทีฟได้โดยใช้ op-interactive figure โปรดดูรายละเอียดเพิ่มเติมและตัวอย่างโค้ดที่นี่: https://developers.facebook.com/docs/instant-articles/reference/interactive

ในการกำหนดความสูง ให้เพิ่มแอตทริบิวต์ “ความสูง” ไปยังอิลิเมนต์ <iframe> ที่ล้อมเนื้อหาที่ถูกฝังของคุณ ค่าของแอตทริบิวต์ควรเป็นจำนวนเต็มที่ระบุความสูงเป็นพิกเซล คุณสามารถตั้งค่าความสูงได้สูงสุด 960 พิกเซล

คุณสามารถเพิ่มภาพหน้าปกได้โดยการเพิ่มแท็ก <figure> ภายในส่วนหัว คุณสามารถใช้ภาพหรือวิดีโอเป็นภาพหน้าปกได้โดยการเพิ่มแท็ก <img> หรือ <video> ภายใน figure

โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับภาพหน้าปก ที่นี่

ในการเพิ่มช่องว่างระหว่างภาพ คุณสามารถเพิ่มย่อหน้าว่างระหว่างภาพได้ เช่น <p>&nbsp;</p>

หากต้องการเพิ่มที่มา ให้ใช้อิลิเมนต์ <cite> ที่อยู่ภายในอิลิเมนต์ <figcaption>

สำหรับภาพหน้าปก คุณสามารถระบุให้ที่มาปรากฏตลอดเวลาได้โดยการระบุหนึ่งในที่มาการจัดเรียงแนวตั้งอย่างชัดเจนบนอิลิเมนต์ <cite> มิเช่นนั้น ข้อความอ้างอิงของคุณจะไม่ปรากฏบนรูปภาพจนกระทั่งจะมีการขยาย

คุณสามารถเพิ่มเนื้อหาโซเชียลแบบฝังได้โดยการเพิ่ม figure ที่มีคลาส “op-social” และเพิ่ม iframe ที่มีเนื้อหาที่จะฝัง

โปรดดู เอกสารนี้ สำหรับรายละเอียดเพิ่มเติมและตัวอย่างโค้ด

คุณต้องใช้ลิงก์ตรงไปยังไฟล์วิดีโอ (เช่น ไฟล์ mp4) เพื่อเพิ่มรูปภาพหน้าปก เนื่องจากวิดีโอที่ Facebook โฮสต์ไม่มีลิงก์ตรงให้ คุณจะต้องโฮสต์วิดีโอของคุณจากที่อื่นเพื่อใช้เป็นรูปภาพหน้าปก

คุณสามารถใช้แท็ก HTML บางแท็กที่อยู่ในรายการเพื่อเพิ่มข้อความตัวหนาหรือเพิ่มลิงก์ได้ เป็นต้น ในการปรับลักษณะสีหรือฟอนต์ คุณสามารถใช้ตัวแก้ไขลักษณะบนอินเทอร์เฟซเพจ Facebook ได้ (การตั้งค่า->บทวามทันใจ)

หากคุณฝังวิดีโอโดยใช้อิลิเมนต์ <video> HTML คุณจะไม่สามารถเพิ่มได้เนื่องจากเราไม่สนับสนุนการเล่นวิดีโอหลายวิดีโอเป็นลำดับ

แต่คุณอาจสามารถทำได้หากคุณฝังโปรแกรมเล่นวิดีโอเป็นการฝังโซเชียลใน iframe ตราบใดที่โปรแกรมเล่นวิดีโอที่ฝังนั้นให้การสนับสนุน

บล็อกคำพูดอ้างอิงไม่ได้รับการสนับสนุนและต้องวางนอกแท็กย่อหน้า

หากชื่อบทความของคุณยาวพอที่จะแสดงเต็มสองบรรทัด เฉพาะชื่อบทความเท่านั้นที่จะปรากฏในฟีดข่าว หากชื่อมีความยาวหนึ่งบรรทัด ตัวอย่างฟีดข่าวจะแสดงบรรทัดแรกๆ ของข้อความบทความ

โปรดตรวจสอบว่าคุณไม่ได้เพิ่มแอตทริบิวต์ “data-fb-disable-autoplay” ในวิดีโอของคุณ

หากวิดีโอไม่เล่นโดยอัตโนมัติต่อบุคคลหนึ่งๆ ให้ตรวจสอบว่าไม่มีการปิดใช้งานการเล่นอัตโนมัติไว้ในการตั้งค่าของแอพ Facebook คุณสามารถดูคำแนะนำในการตรวจสอบได้ ที่นี่

คุณสามารถแสดงวิดีโอในตัวอย่างฟีดข่าวสำหรับบทความได้โดยการเพิ่มคลาส “fb-feed-cover” ในวิดีโอใดๆ ในบทความของคุณ โปรดอ่านเพิ่มเติมเกี่ยวกับตัวอย่างฟีดข่าว ที่นี่

คุณจำเป็นต้องใส่อิลิเมนต์ <time> ในมาร์กอัพ HTML สำหรับบทความแต่ละบทความโดยใช้คลาส op-published เพื่อระบุวันที่/เวลาที่บทความเผยแพร่เป็นครั้งแรก

คลาส op-modified นั้นไม่จำเป็นต้องใส่ก็ได้ คุณจำเป็นจะต้องใส่อิลิเมนต์ <time> ไว้ในคลาสนี้เท่านั้น หากคุณต้องการอัพเดตเนื้อหาของบทความและต้องการให้เราอัพเดตเวอร์ชั่นของบทความของคุณที่เราจัดเก็บไว้

โปรดตรวจสอบว่าคุณได้ล้อมข้อความไว้ในย่อหน้า (แท็ก <p>) คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับการสร้างมาร์กอัพของบทความของคุณได้ ที่นี่

โปรดตรวจสอบว่า <figure> ไม่ได้อยู่ภายในย่อหน้า (แท็ก <p>) ภาพไม่ควรมีแท็ก figure ที่ฝังอยู่ในแท็กบทความ

คุณไม่สามารถใส่คำบรรยายภาพแต่ละภาพในสไลด์โชว์ได้ คุณสามารถใส่คำบรรยายเดียวในทั้งสไลด์โชว์เท่านั้น

โปรดดู เอกสารประกอบเกี่ยวกับสไลด์โชว์ สำหรับรายละเอียดเพิ่มเติม

คุณสามารถเพิ่มยอดถูกใจหรือความคิดเห็นบนภาพได้โดยระบุแอตทริบิวต์ “data-feedback” ในแท็ก <figure> ที่มีภาพ ตัวอย่างเช่น การเพิ่มแอตทริบิวต์ data-feedback=”fb:likes,fb:comments” จะแสดงทั้งยอดถูกใจหรือความคิดเห็นบนภาพ

สำหรับข้อมูลเพิ่มเติม โปรดดู ดูเอกสารประกอบสำหรับแอตทริบิวต์คำติชม

ขณะทำการระบุความกว้างสำหรับรายการ เช่น การฝังแบบอินเตอร์แอคทีฟ โปรดใช้ค่าจำนวนเต็มในการระบุความกว้างเป็นพิกเซล ตามค่าเริ่มต้น รายการต่างๆ จะแสดงในความกว้างแบบเต็มหน้าจอ

หากต้องการแสดงการฝังแบบอินเตอร์แอคทีฟโดยไม่มีขอบ คุณสามารถเพิ่มคลาส “no-margin” ใน iframe ที่มีเนื้อหาของคุณได้

หากเราได้อนุมัติฟีด RSS สำหรับเพจของคุณแล้ว คุณก็ไม่จำเป็นต้องส่งเพื่อขอรับการอนุมัติอีกครั้งหากคุณเปลี่ยน URL ของฟีด

เราจะแม็ปทุกเพจไว้กับชื่อโดเมนที่ไม่ซ้ำกัน URL ของฟีด RSS นั้นไม่จำเป็นต้องเหมือนกับชื่อโดเมนนี้ อย่างไรก็ตาม URL แบบบัญญัติของแต่ละบทความของคุณที่อยู่ภายในฟีดนั้นต้องเป็นของโดเมนหรือโดเมนย่อยเดียวกัน หากคุณเพียงต้องการเปลี่ยน URL ของฟีด RSS การดำเนินการนี้จะไม่ส่งผลให้เกิดปัญหา

หากคุณกำลังอัพเดต URL แบบบัญญัติของบทความเพื่อชี้ไปยังโดเมนใหม่ คุณจะต้องขอให้โดเมนนี้อัพเดตผ่านผู้จัดการของพาร์ทเนอร์ซึ่งจะสามารถแนะนำให้คุณทำกระบวนการนี้ได้

โปรดตรวจสอบให้แน่ใจว่าแอพพลิเคชั่น Facebook ของคุณมี ID iPhone Store (เพื่อวัตถุประสงค์ทางการทดสอบ ไม่จำเป็นต้องเป็น ID จริงของคุณ โดยคุณสามารถใช้แอพใดก็ได้บน Apple App Store) ติดตั้งและเปิดใช้งาน iOS - iPad ในแพลตฟอร์ม App Center ที่ระบุของคุณ

การทำงานนี้เป็นไปตามการออกแบบ กล่องการแชร์บนฟีดเผยแพร่เนื้อหาที่มีไฟล์แนบ ดังนั้นจึงไม่สามารถปรับแต่งไฟล์แนบเพิ่มเติมได้

โปรดอ่านเอกสารนี้สำหรับหลักปฏิบัติที่ดีที่สุดในการปรับรูปภาพให้เหมาะสมเพื่อสร้างพรีวิวที่ดูดีได้จากที่นี่

ข้อมูลคำตอบจะพร้อมให้ใช้งานก็ต่อเมื่อผู้ใช้ลงชื่อเข้าใช้แอพของคุณด้วย Facebook และได้ให้อนุญาตpublish_actionsแล้วเท่านั้น ซึ่งจะมีการรวบรวมข้อมูลไว้ในเอกสารที่นี่

กรณีนี้เป็นการเปลี่ยนแปลงที่มีการกำหนดมาแล้ว เราได้ย่อรายชื่อเพื่อนเพื่อทำให้คำเชิญเล่นเกมเกี่ยวข้องกับผู้เล่นที่เหมาะสมมากขึ้น โปรดทราบว่าผู้เล่นยังสามารถเลือกจำนวนเพื่อนได้มากเท่าที่ต้องการโดยใช้ช่องการค้นหา

ข่าวดีคือ การเปลี่ยนแปลงนี้ทำให้เราเห็นถึงจำนวนคลิกที่เพิ่มขึ้น และ CTR โดยรวมที่เพิ่มขึ้นอย่างมาก เราจะทำการปรับช่องทางนี้ให้เหมาะสมอย่างต่อเนื่อง และพยายามหาวิธีใหม่ๆ เพื่อให้แน่ใจว่าจะนำเสนอเกมให้เหมาะสมกับกลุ่มเป้าหมายได้

ครอว์เลอร์จะหาบันทึก AAAA และส่งคืนคำตอบเป็นรหัส 0 หากหาไม่พบ ตรวจสอบว่าบันทึก AAAA ของคุณได้รับการอัพเดตได้อย่างถูกต้องเมื่อคุณเปลี่ยน URL หรือเซิร์ฟเวอร์ของคุณ

โปรดดู “การอัพเดต URL” สำหรับข้อมูลเพิ่มเติม

การเปลี่ยนตัวอย่างชื่อเรื่อง ตัวอย่างภาพ และอื่นๆ จะนำไปใช้กับการแชร์ของลิงก์นั้นในอนาคต

เมื่อมีคนหรือเพจแชร์ลิงก์ และมีการโต้ตอบกับโพสต์นั้นมากกว่า 50 ครั้ง (การแสดงความคิดเห็น การกดถูกใจ การแชร์ และอื่นๆ) เช่นนั้นจะไม่สามารถเปลี่ยนแปลงชื่อเรื่องได้ สาเหตุเพื่อป้องกันไม่ให้เว็บไซต์เปลี่ยนแปลงรายละเอียดของลิงก์หลังจากที่คุณได้มีการโต้ตอบ ซึ่งจะทำให้ดูเหมือนว่าคุณกำลังโต้ตอบกับสิ่งอื่นอยู่ คุณสมบัติอื่นๆ สามารถแก้ไขได้ในภายหลัง

หากคุณได้แชร์ลิงก์และอัพเดตรูปภาพแล้ว การแชร์ที่เป็นต้นฉบับจะยังคงแสดงรูปภาพเก่า เว้นแต่ว่าคุณจะรีเฟรชรูปภาพในโพสต์นั้น

1. ไปยังโพสต์ในฟีดข่าวของคุณ
2. คลิกจุดสามจุดในส่วนมุมด้านขวาบนของโพสต์นั้น
3. เลือก “รีเฟรชสิ่งที่แนบมากับการแชร์”

เราจะระงับชื่อหลังพบว่ามีการดำเนินการกับอ็อบเจ็กต์นั้นหลายๆ ครั้ง (ดูคำอธิบายที่นี่: การอัพเดต URL

ระบบอาจครอบตัดรูปภาพโดยคำนึงถึงปัจจัยหลายประการ ตัวอย่างเช่น เราพยายามจัดให้ใบหน้าที่ตรวจจับได้อยู่ตรงกลางภาพ

ในกรณีที่รูปภาพมีขนาดใหญ่ พยายามทำให้รูปภาพของคุณมีอัตราส่วนกว้างยาวใกล้เคียงกับ 1.91:1 ให้มากที่สุด เพื่อให้รูปภาพแสดงบนฟีดได้เต็มรูปโดยไม่ต้องครอบตัด

โพสต์บนเพจมักใช้รูปภาพแนวนอนขนาดใหญ่สำหรับการแชร์ลิงก์ ซึ่งจะเหมือนกันในฟีดทั้งบนเดสก์ท็อปและบนมือถือ พยายามให้รูปภาพของคุณมีอัตราส่วนกว้างยาวใกล้เคียงกับ 1.91:1 ให้มากที่สุด เพื่อให้รูปภาพแสดงบนฟีดได้เต็มรูปโดยไม่ต้องครอบตัด

ระบบกรองเนื้อหาของเราอาจแจ้งว่าลิงก์ของคุณมีปัญหา หากคุณเชื่อว่าเป็นข้อผิดพลาด โปรดส่งรายงานไปยังไซต์ช่วยเหลือของเรา ตรวจสอบว่าคุณได้ระบุ URL ที่เกี่ยวข้องด้วย

ระบบจะแคชภาพแบบอะซิงโครนัส จึงอาจจะไม่แสดงในครั้งแรกที่ผู้อื่นแชร์เนื้อหาของคุณ คุณสามารถหลีกเลี่ยงเหตุการณ์เช่นนี้ได้ด้วยวิธีดังต่อไปนี้

• แคชภาพของคุณล่วงหน้าโดยการทริกเกอร์การดึงแยกด้วย Sharing Debugger
• ใช้ og:image:height and og:image:width tags เพื่อกำหนดภาพอย่างชัดเจน

การแชร์และการกดถูกใจทั้งหมดจะสัมพันธ์กับ URL ที่เจาะจง (เรียกว่า “URL แบบบัญญัติ”) การเปลี่ยนแปลงโครงสร้างไซต์เพื่อไปใช้แบบที่มี URL ใหม่จะเริ่มต้นการกดถูกใจและการแชร์ให้ URL ใหม่นั้น

โปรดดู “การอัพเดต URL” สำหรับข้อมูลเพิ่มเติม

การแชร์และการกดถูกใจทั้งหมดจะสัมพันธ์กับ URL ที่เจาะจง (เรียกว่า “URL แบบบัญญัติ”) การเปลี่ยนแปลงโครงสร้างไซต์เพื่อไปใช้แบบที่มี URL ใหม่จะเริ่มต้นการกดถูกใจและการแชร์ให้ URL ใหม่นั้น

โปรดดู “การอัพเดต URL” สำหรับข้อมูลเพิ่มเติม

ภาพที่มีขนาดน้อยกว่า 600 x 315 พิกเซลแต่มีขนาดใหญ่กว่า 200 x 200 พิกเซลนั้นจะแสดงเป็นภาพสี่เหลี่ยมจัตุรัสขนาดเล็ก

เราจะถือว่า URL ภาพทั้งหมดนั้นไม่สามารถเปลี่ยนแปลงได้ เนื่องจากจะนำไปใช้เพื่อแคชแหล่งข้อมูลในระดับชั้นต่างๆ ดังนั้น หากต้องการเปลี่ยนภาพ คุณจะต้องใช้ URL ใหม่ด้วย เมื่อเก็บแคชไว้นาน เราจะดึงภาพใหม่และปัญหาจะทำการแก้ไขโดยอัตโนมัติ

หากคุณใช้ URL อื่นแต่ยังเห็นภาพเก่าอยู่ คุณยังสามารถไปที่เครื่องมือตรวจสอบการแชร์ แล้วดึง URL ใหม่ได้:

URL ทั้งหมดต้องเป็นแบบเต็มเนื่องจาก URL นี้จะเป็นตัวแทนตำแหน่งที่ตั้งแบบบัญญัติของแหล่งที่มา (เพจ/ภาพ) เพื่อให้เราสามารถระบุยอดการแชร์และการกดถูกใจให้กับ URL ที่ถูกต้องและแคชภาพได้อย่างถูกต้อง

รูปภาพเดิมไม่พร้อมใช้งานอีกต่อไป อาจจะมีขนาดใหญ่เกินไปหรือไม่สามารถดึงได้เนื่องจากเกิดปัญหาชั่วคราว ตรวจสอบว่า URL รูปภาพสามารถเข้าถึงได้สำหรับครอว์เลอร์ของเรา มีขนาดน้อยกว่า 8 MB และแสดงโดยที่มีเวลาแฝงน้อยกว่า 2 วินาที

เมื่อคุณเปลี่ยนรูปภาพเดิมสำหรับเพจ ให้ตรวจสอบว่าคุณไม่ได้ลบรูปภาพเก่าจากไซต์ของคุณ เนื่องจากการแชร์ที่มีอยู่จะแสดงเป็นสีขาว

ซึ่งเกิดจากการหน่วงเวลาเพื่อการจำลองแบบในทั่วทั้งศูนย์ข้อมูล ขั้นตอนนี้ใช้เวลาหลายวินาทีและ ID ของอ็อบเจกต์จะไม่สามารถเข้าถึงผ่านทาง API ได้จนกว่าการดำเนินการนี้จะเสร็จสิ้น

หากคุณพยายามอ่านรายละเอียดของโฆษณาก่อนที่การบันทึกจะเสร็จสมบูรณ์ คุณอาจได้รับ “GraphMethodException” พร้อมข้อความอย่างเช่น “Unsupported get request. Object with ID 'XXXXXXXXXXXXXXXXXX' does not exist, cannot be loaded due to missing permissions, or does not support this operation.”

การรอสักครู่ก่อนพยายามอ่านรายละเอียดโฆษณา อาจช่วยแก้ปัญหานี้ได้

บางครั้งคุณอาจพบข้อผิดพลาดด้านการตรวจสอบความถูกต้องเมื่อใช้ชิ้นงานโฆษณาบางชิ้นภายในแคมเปญใดแคมเปญหนึ่ง กรณีนี้สามารถเกิดขึ้นได้เมื่อแคมเปญมีวัตถุประสงค์ที่เข้ากับชิ้นงานโฆษณาที่คุณใช้อยู่ไม่ได้ ตัวอย่างหนึ่งในกรณีนี้อาจเป็นเพราะชิ้นงานโฆษณาของคุณนำผู้คนไปยังเกม Canvas ขณะที่วัตถุประสงค์ของแคมเปญคือ "MOBILE_APP_INSTALLS"

หากต้องการแก้ไขข้อผิดพลาดด้ายการการตรวจสอบความถูกต้องที่คุณอาจพบ คุณสามารถทำตามหลักปฏิบัติที่ดีที่สุดของการตรวจสอบความถูกต้อง API การตลาด

โปรดตรวจสอบว่าช่วงเวลาที่ใช้งานอัพโหลดซึ่งไม่ได้ประกอบด้วยรายการในคำถามนั้นไม่มีข้อผิดพลาดใดๆ

รายการจะถูกลบออกและไม่ปรากฏบนฟีดที่มีช่วงเวลาที่ใช้งานการอัพโหลดสำเร็จเมื่อมีการกำหนดค่า deletion_enabled เป็นจริง

หากคุณพบข้อผิดพลาดนี้ โปรดตรวจสอบสถานะของบัญชีผู้ใช้โฆษณาที่ระบุ ข้อผิดพลาดนี้มักถูกส่งคืนเมื่อบัญชีผู้ใช้โฆษณาอยู่ในสถานะที่ยังไม่มั่นคง

มีการคาดการณ์ถึงลักษณะการทำงานนี้เนื่องจากระบบจัดการสำหรับข้อมูลเชิงลึกของเพจจะถูกจัดเก็บไว้เพียง 2 ปีเท่านั้น ดังนั้นจึงมีการคาดการณ์ถึงการเรียกว่าจะส่งคืนค่าเป็นศูนย์ รายการที่จะไม่มีค่าเป็นศูนย์คือ likes/comments/shares แบบอินไลน์บนโพสต์ที่มีข้อมูลที่ถูกเก็บไว้โดยโพสต์เอง

โปรดตรวจสอบรูปแบบคำสั่งของข้อมูลจำเพาะการกำหนดเป้าหมาย โดยเฉพาะตรวจสอบให้แน่ใจว่าข้อมูลจำเพาะการกำหนดเป้าหมายมีพารามิเตอร์ geo_locations และค่าที่ถูกจ้อง

เมื่อคุณสร้างโฆษณาโดยมีวัตถุประสงค์บางประการ ข้อมูลจำเพาะของคอนเวอร์ชั่นเริ่มต้นจะถูกกำหนด หากคุณทำการเปลี่ยนแปลงไปยังข้อมูลจำเพาะของคอนเวอร์ชั่น ข้อมูลจำเพาะที่มีอยู่จะถูกเขียนทับ

โปรดทราบว่าวัตถุประสงค์บางประการจะไม่มีข้อมูลจำเพาะของคอนเวอร์ชั่นเริ่มต้น และจะไม่ถูกระบุอย่างชัดเจน

กรณีนี้อาจเกิดขึ้นได้จากการที่กลุ่มเป้าหมาย work_positions ในประเทศที่คุณกำหนดเป้าหมายนั้นเล็กเกินไปจนไม่มีผลต่อค่าประมาณการเข้าถึง เรากำลังรวบรวมข้อมูลที่หวังว่าจะช่วยปรับปรุงจำนวนผู้คนที่เพิ่มไปยังการแยกกลุ่ม work_positions ซึ่งจะมีผลต่อค่าประมาณการเข้าถึง

กรณีนี้เกิดขึ้นได้เนื่องจากแอพของคุณเปิดใช้งานการย้ายสตรีมโพสต์ความปลอดภัยของ URL

หากแอพของคุณเปิดการตั้งค่าอยู่ ระบบจะไม่อนุญาตให้มีการสร้างโฆษณาลิงก์ของโพสต์ทุกประเภท หากโฆษณาไม่เปลี่ยนเส้นทางไปยัง URL Canvas ที่อ้างอิงในการตั้งค่าแอพของคุณ ไม่ควรมีข้อกำหนดให้เปิดใช้งาน หากแอพของคุณเป็นแอพ Canvas และโพสต์เฉพาะเรื่องราวที่เปลี่ยนเส้นทางกลับไปยังโดเมนแอพ Canvas

ผู้ใช้มีแนวโน้มเชื่อมโยงกับบัญชีผู้ใช้ผ่านการเชื่อมโยงตัวจัดการธุรกิจ ซึ่งจะไม่แสดงเป็นการเชื่อมโยง API กราฟที่ชัดเจน

โปรดยืนยันว่าคุณได้ระบุหมวดหมู่พาร์ทเนอร์ในช่องการกำหนดเป้าหมายที่เหมาะสม หมวดหมู่พาร์ทเนอร์ที่เรียกดูจากตำแหน่งข้อมูล “/partnercategories” ประกอบด้วยช่องชื่อว่า “targeting_type” ซึ่งระบุช่องการกำหนดเป้าหมายที่คุณต้องใช้เมื่อระบุประเภทการกำหนดเป้าหมาย

ตัวอย่างเช่น หากหมวดหมู่พาร์ทเนอร์ของคุณส่งคืน “targeting_type” ของ “ลักษณะการทำงาน” ดังนั้นในข้อมูลจำเพาะการกำหนดเป้าหมายของคุณควรใช้หมวดหมู่ของพาร์ทเนอร์ในช่อง “ลักษณะการทำงาน” นั้นของข้อมูลจำเพาะการกำหนดเป้าหมาย

สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับประเภทการกำหนดเป้าหมายและหมวดหมู่พาร์ทเนอร์ได้ใน: https://developers.facebook.com/docs/marketing-api/partnercategories/v2.3#targeting_types

ข้อผิดพลาดนี้สามารถเกิดขึ้นได้จากกลุ่มเป้าหมายที่กำหนดเองที่ไม่มีการกำหนดการรวม/การแยกกลุ่ม วิธีที่ดีที่สุดในการแก้ไขปัญหานี้คือการสร้างกลุ่มเป้าหมายที่กำหนดเองใหม่ และตรวจสอบให้แน่ใจว่าคุณได้กำหนดการรวม/การแยกกลุ่มแล้ว

สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับกลุ่มเป้าหมายที่กำหนดเองได้ที่นี่: https://developers.facebook.com/docs/marketing-api/custom-audience-targeting/v2.3

ชุดโฆษณาสามารถมีได้ทั้ง lifetime_budget และ daily_budget ค่า daily_budget ที่ระบุไว้ในสกุลเงินในบัญชีผู้ใช้ของคุณจะต้องมีอย่างน้อย 100 เซนต์ และระยะเวลาจะต้องนานกว่า 24 ชั่วโมง หากคุณสอบถามเกี่ยวกับช่องเหล่านี้ ทั้งสองรายการจะถูกส่งคืน ค่าของ 0 จะถูกส่งคืนเมื่อช่องไม่ได้ใช้งาน

หากต้องการเรียนรู้เพิ่มเติม โปรดไปที่: https://developers.facebook.com/docs/reference/ads-api/adset

ตำแหน่งข้อมูล adcampaign_groups การแบ่งหน้าตามเคอร์เซอร์ ดังนั้นจึงจะไม่ส่งคืนช่องจำนวน การจำกัด หรือออฟเซ็ต เราขอแนะนำให้ใช้การแบ่งหน้าตามเคอร์เซอร์สำหรับตำแหน่งข้อมูลทั้งหมดเพื่อรับผลลัพธ์ที่สอดคล้องกัน

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้การแบ่งหน้าตามเคอร์เซอร์ โปรดดูที่นี่: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.0#paging

กรณีนี้อาจเกิดขึ้นจากโพสต์บางรายการถูกสร้างแบบอินไลน์ หากต้องการดึงข้อมูลโพสต์แบบอินไลน์ โปรดดูโน้ตในช่อง /promotable_posts "is_inline" ที่ด้านล่างของส่วนเอกสารนี้: https://developers.facebook.com/docs/reference/ads-api/adcreative/v2.2#object_story_spec

หน้าต่างการส่งข้อความจะเปิดขึ้นเมื่อผู้ใช้ตอบคำถามแรก หากคำตอบที่ส่งมาบ่งบอกว่าผู้ใช้ไม่ผ่านเกณฑ์หรือผู้ใช้ไม่ได้ตอบคำถาม โฆษณาจะสิ้นสุดลงและโฆษณาดังกล่าวจะส่งต่อการควบคุมผ่านเธรดไปยังแอพเป้าหมายและระบุเมตาดาต้า "messenger_lead_gen_incomplete" ที่จะทำให้ธุรกิจมีทางเลือกสำรองในการเปลี่ยนผู้ที่ไม่ใช่ลูกค้าเป้าหมายให้กลายเป็นลูกค้า ดู Webhook เหตุการณ์โปรโตคอลการส่งมอบ (HOP) หลังโฆษณาแบบกรอกฟอร์ม สำหรับข้อมูลเพิ่มเติม

การส่งสรุปจะถูกเปิดใช้งานเป็นค่าเริ่มต้นเมื่อแอพถูกเลือกในกล่องโต้ตอบ "สร้างเทมเพลต" ภายในโฆษณาเท่านั้น โปรดทราบว่าคุณสามารถปิดใช้งานสรุปในโฆษณาได้หลังจากเลือกแอพที่เชื่อมต่อ แม้ว่าแอพจะไม่ถูกเลือก แต่โฆษณาการรวบรวมข้อมูลลูกค้าจะส่งต่อการควบคุมผ่านเธรดไปยังตัวรับการส่งต่อหลัก หากกำหนดไว้ หรือละทิ้งการควบคุมผ่านเธรดไป ข้อความติดตามผลหลังจากการส่งข้อมูลลูกค้าจะถูกส่งไปยังแอพที่รับข้อมูล แอพสามารถสืบค้น API การสนทนาเพื่อดึงประวัติการรับส่งข้อความและรับข้อมูลที่ถูกแชร์ในระหว่างการรวบรวมข้อมูลลูกค้าได้

ตามค่าเริ่มต้นแล้ว Send API และ Webhooks จะถูกบล็อกในขณะที่โฆษณาการรวบรวมข้อมูลลูกค้าอยู่ระหว่างการดำเนินการ ID แอพ: 413038776280800 สำหรับแอพการรวบรวมข้อมูลลูกค้าใน Messenger จะมีการควบคุมผ่านเธรด คุณสามารถปิดการดำเนินการดังกล่าวได้โดยใช้ปุ่มเปิดปิด "บล็อก Send API" บนกล่องโต้ตอบ "สร้างเทมเพลต" ในโฆษณา

หลังจากการส่งข้อมูลลูกค้าสิ้นสุดลง App จะได้รับ Webhooks ของข้อความของผู้ใช้และสามารถตอบกลับข้อความได้ หากแอพหนึ่งถูกเลือกเป็นส่วนหนึ่งของ App แอพที่เลือกนั้นจะได้รับอนุญาตให้ตอบกลับได้และจะได้รับ Webhooks ในช่องทางการส่งข้อความ โดยหน้าต่างการส่งข้อความจะเปิดขึ้นมาและ App สามารถตอบกลับได้โดยใช้ Send API

แอพถูกติดตั้งจากเว็บไซต์ของแอพโดยใช้ การเข้าสู่ระบบด้วย Facebook และมอบสิทธิ์การอนุญาต pages_messaging ให้กับบางเพจ แอพที่ได้รับอนุญาตจะแสดงในการตั้งค่าเพจภายในการส่งข้อความขั้นสูง

มีเฉพาะแอพที่ได้รับอนุญาตในเพจเท่านั้นที่จะปรากฏขึ้นมา คุณสามารถดูแอพที่ได้รับอนุญาตได้ในการตั้งค่าเพจภายในการส่งข้อความขั้นสูง โดยแอพถูกติดตั้งจากเว็บไซต์ของแอพโดยใช้ การเข้าสู่ระบบด้วย Facebook และมอบสิทธิ์การอนุญาต pages_messaging ให้กับบางเพจ

ประสบการณ์แชทอัตโนมัติ (หรือ "บอท") ควรแจ้งแก่ผู้ใช้ว่าผู้ใช้กำลังโต้ตอบกับบริการอัตโนมัติอยู่ในกรณีต่อไปนี้ ได้แก่

• เมื่อเริ่มต้นการสนทนาหรือการพูดคุยผ่านข้อความ
• หลังจากที่ไม่ได้มีการสนทนาเป็นเวลานาน
• เมื่อเปลี่ยนจากการใช้คนโต้ตอบมาเป็นการใช้บอทโต้ตอบ

เรียนรู้เพิ่มเติมเกี่ยวกับนโยบายนี้ที่นี่

ประสบการณ์แชทอัตโนมัติ (หรือ "บอท") ต้องแจ้งแก่ผู้ใช้ว่าผู้ใช้กำลังโต้ตอบกับบริการอัตโนมัติอยู่ตามที่กฎหมายที่บังคับใช้กำหนด โดยถึงแม้ว่ากฎหมายจะไม่ได้กำหนดเอาไว้ แต่คุณก็ควรแจ้งให้ทราบเพื่อให้ผู้ใช้ได้เตรียมตัวเอาไว้ก่อน คุณสามารถอ่านเพิ่มเติมเกี่ยวกับนโยบายนี้ได้ที่นี่

ได้ คุณสามารถเชื่อมโยงแอพ Facebook เดียวกับเพจหลายเพจได้ เมื่อถึงการตรวจสอบแอพ เช่น สิทธิ์การอนุญาต pages_messaging แอพสามารถเชื่อมโยงเพื่อรับ Webhook จากเพจมากกว่าหนึ่งเพจได้ โดยการรับบริบทของ Webhook แต่ละรายการบนเพย์โหลดจะขึ้นอยู่กับคุณ

ได้ คุณสามารถใช้มากกว่าหนึ่งแอพในการรับข้อมูลจากเพจได้ เมื่อใช้หลายแอพในการจัดการการสนทนาเดียวกัน ทางที่ดีที่สุดคุณควรใช้ โปรโตคอลการส่งมอบ ในการจัดการว่าจะให้บอทตัวใดเป็นเจ้าของเธรดในช่วงเวลาที่กำหนด

สิ่งนี้คือวิธีแก้ปัญหาในการใช้แพลตฟอร์มของผู้ใช้ขั้นทดสอบสำหรับการผสานแพลตฟอร์ม Messenger ของคุณ

1. จากหน้าบทบาทในแอพของคุณ ให้สร้างผู้ใช้ขั้นทดสอบใหม่โดยการคลิกที่ปุ่ม “เพิ่ม”
2. สลับเปิดปิดตัวเลือก “อนุญาตผู้ใช้ขั้นทดสอบสำหรับแอพนี้ไหม และให้สิทธิ์การอนุญาต “manage_pages” และ “page_messaging”
3. ใช้ปุ่มแก้ไขและใช้โทเค็นการเข้าถึงสำหรับผู้ใช้นี้ (ใช้ v2.6) กรุณาบันทึกไว้สำหรับครั้งต่อไป
4. ใช้ปุ่ม “แก้ไข” เพื่อเข้าสู่ระบบแบบเป็นผู้ใช้ขั้นทดสอบ
5. หลังจากทำการเข้าสู่ระบบ สร้างหน้าในฐานะผู้ใช้ขั้นทดสอบ
6. ใช้โทเค็นการเข้าถึงของผู้ใช้สำหรับผู้ใช้ขั้นทดสอบเพื่อให้ได้โทเค็นการเข้าถึงเพจสำหรับผู้ใช้นี้ คุณสามารถทำได้ด้วยการเรียกคำสั่งต่อไปนี้

   https://graph.facebook.com/v2.6/me/accounts?access_token=[TEST_USER_ACCESS_TOKEN]

   (เอกสารประกอบ)
7. ใช้โทเค็นการเข้าถึงเพจนี้เพื่อลิงก์ Facebook แอพพลิเคชั่น ของคุณกับเพจของคุณ

   https://graph.facebook.com/v2.6/me/subscribed_apps?method=POST&access_token=[TEST_USER_PAGE_ACCESS_TOKEN]
           

   (เอกสารประกอบ)
8. หลังจากคุณดำเนินการตามขั้นตอนเหล่านี้ คุณจะได้รับการอัพเดต RTU ที่หน้าทดสอบของคุณ และคุณจะสามารถรับส่งข้อความของผู้ใช้ขั้นทดสอบของคุณจากหน้าทดสอบของคุณได้ นอกเหนือจากข้างต้นแล้ว คุณสามารถแทนที่โทเค็นการเข้าถึงของคุณด้วยโทเค็นที่มีอายุการใช้งานนาน ถ้าหากว่าโทเค็นนั้นหมดอายุเร็วเกินไปสำหรับการทดสอบของคุณ กรุณาติดตามเอกสารประกอบที่นี่:

   GET /oauth/access_token?  
       grant_type=fb_exchange_token&           
       client_id={app-id}&
       client_secret={app-secret}&
       fb_exchange_token={short-lived-token} 
           

สิ่งนี้เกิดขึ้นจากหลายสาเหตุดังนี้

• คุณกำลังใช้ ID จากการเข้าสู่ระบบด้วย Facebook ID จากการเข้าสู่ระบบด้วย Facebook ไม่ได้มีจุดมุ่งหมายเพื่อทำงานร่วมกับ API ส่ง/รับ เฉพาะ ID ผู้ใช้ที่ได้จากการยืนยันตัวตนด้วยแพลตฟอร์ม Messenger เท่านั้นที่จะทำงานร่วมกับแพลตฟอร์ม Messenger ได้
• คุณกำลังใช้ ID กับโทเค็นการเข้าถึงเพจที่ไม่ถูกต้อง ID ผู้ใช้สำหรับแพลตฟอร์ม Messenger มีการจำกัดขอบเขตไว้ในเพจหนึ่งๆ ดังนั้นจึงมีลักษณะเฉพาะสำหรับเพจนั้น ถ้าคุณใช้ ID ผู้ใช้ที่ถูกต้องแต่ใช้กับโทเค็นการเข้าถึงเพจที่เชื่อมโยงกับเพจอื่น จะทำให้การเรียกใช้ไม่ทำงาน ต้องแน่ใจว่าใช้ ID ผู้ใช้ และโทเค็นการเข้าถึงเพจที่เชื่อมโยงกับหน้าเดียวกัน
• คุณกำลังส่งไปยังหมายเลขโทรศัพท์มือถือที่ไม่ได้ผ่านการตรวจสอบยืนยันเมื่อไม่นานมานี้ เมื่อใช้ “API ส่ง” กับหมายเลขโทรศัพท์มือถือ เราจะส่งข้อความถ้าหมายเลขโทรศัพท์มือถือผ่านการตรวจสอบยืนยันไม่นานมานี้แล้วเท่านั้น แม้ว่าหมายเลขโทรศัพท์มือถือจะแสดงว่าได้ผ่านการตรวจสอบแล้ว แต่ไม่ได้ผ่านการตรวจสอบเมื่อไม่นานมานี้ จะทำให้ส่งไม่สำเร็จได้ ทำการตรวจสอบยืนยันหมายเลขโทรศัพท์มือถือของคุณใหม่ และรอ 24 ชั่วโมงจึงพยายามใหม่อีกครั้ง

เมื่อใช้ปลั๊กอิน “ส่งไปยัง Messenger” คุณสามารถใช้พารามิเตอร์ data-ref เป็นพารามิเตอร์ส่งผ่านเพื่อส่งข้อมูลใดๆ ตามบริบทของการคลิกได้

ผู้คนอาจค้นพบเพจของคุณผ่านการค้นหาใน Messenger ในกรณีนี้ คุณจะไม่มีพารามิเตอร์แบบส่งผ่าน คุณสามารถใช้คุณสมบัติการลิงก์ถึงบัญชีผู้ใช้ร่วมกับเธรดไปยังบัญชีผู้ใช้งานบนเว็บไซต์ของคุณ

แดชบอร์ดของแอพใต้การตั้งค่า Messenger จะมีปุ่ม "แสดงข้อผิดพลาดล่าสุด" ที่จะแสดงสถานะว่า Webhooks ได้รับการตอบกลับ 200 หรือล้มเหลวอยู่

เรามีเครื่องมือที่จะแสดงข้อผิดพลาดล่าสุดของ Webhook ได้ โดยหากการส่งมอบ Webhooks ล้มเหลว เซิร์ฟเวอร์ของ Facebook จะเลิกรับข้อมูล URL ของคุณ หากต้องการค้นหาเครื่องมือ ให้ไปที่แดชบอร์ดของแอพ > การตั้งค่า จากนั้นในการ์ด Webhooks จะมีปุ่มแสดงข้อผิดพลาดล่าสุดอยู่

ตรวจสอบให้แน่ใจว่า Webhook ของคุณกำลังตอบสนองด้วยรหัสสถานะ 200 สิ่งนี้ไดบอกให้เราทราบว่าได้รับ Webhook สำเร็จแล้ว ถ้าคุณไม่ส่งรหัส 200 กลับมา เราจะพยายามเรียกใช้อีกจนกระทั่งสำเร็จอย่างสมบูรณ์ และถ้า Webhook ไม่ส่งรหัส 200 กลับมาในช่วงเวลาหนึ่ง เราจะส่งการแจ้งเตือนสำหรับผู้พัฒนาไป

และโปรดทราบว่ารหัสสถานะที่แสดงว่าสำเร็จจะถูกส่งกลับมาในเวลาที่เหมาะสม การเรียกใช้ Webhook จะหมดเวลาหลังจาก 20 วินาที ต้องแน่ใจว่าได้มีการออกแบบโค้ดของคุณเพื่อให้ Webhook ทำการประมวลผลแบบไม่ซิงค์กัน เพื่อให้ส่งรหัสสถานะที่ประสบความสำเร็จกลับมาได้ทันทีและประมวลผลอย่างเป็นอิสระต่อกัน

การเรียกไปยัง Webhook จะต้องมีการเติมข้อมูลในช่องกรอกข้อมูลในหัวข้อ X-Hub-Signature ซึ่งสามารถถูกนำไปใช้ในการยืนยันว่าเป็นการเรียกมาจาก Facebook

มี 2 ขั้นตอนในการรับการเรียกกลับ ขั้นตอนแรก คุณต้องแน่ใจว่า Webhook ของคุณได้ติดตั้งอย่างเหมาะสม (https://developers.facebook.com/docs/messenger-platform/webhook-reference#setup). มีตัวบ่งชี้ว่า Webhook ได้รับการติดตั้งอย่างเหมาะสม

ขั้นตอนที่สอง คุณต้องสมัครรับข้อมูลในแต่ละเพจ ทุกเพจที่สมัครรับข้อมูลแล้วจะถูกบันทึกไว้

หากการเรียกไปที่ Webhook ของคุณไม่สามารถขยายระยะเวลาใช้งานได้ แอพของคุณจะถูกยกเลิกการสมัครรับข้อมูล และคุณจะต้องเพิ่ม Webhook ของคุณใหม่ และทำการสมัครรับข้อมูลของเพจของคุณใหม่อีกครั้ง

โดยเนื้อหามีแนวโน้มต้องดึงแยกใหม่มากที่สุด ซึ่งสามารถเกิดขึ้นได้โดยอัตโนมัติใน ณ เวลาใดเวลาหนึ่ง หรือสามารถทริกเกอร์ได้ด้วยตนเองผ่านเครื่องมือการแก้ไขจุดบกพร่อง

คุณไม่สามารถควบคุมว่าโพสต์จะถูกแสดงอย่างในในฟีดข่าวหรือไทม์ไลน์เมื่อคุณแชร์เรื่องราว Open Graph นอกเหนือจากการใส่แท็ก OG สำหรับเพจของคุณ Facebook จะปรับโพสต์ให้เหมาะสมโดยอัตโนมัติ เพื่อให้แน่ใจว่าจะมีการเข้าร่วมกับเนื้อหาของคุณในระดับสุงสุด

ใช่ คุณสมบัติลิงก์การดำเนินการถูกยกเลิกใช้งานแล้ว การรองรับสำหรับลิงก์การดำเนินการได้ถูกลบออกจากไซต์ Facebook แล้ว ดังนั้นจึงถูกยกเลิกใช้งานจากแพลตฟอร์มเช่นกัน คุณสมบัตินี้อาจมีการนำกลับมาใช้อีกในอนาคต แต่ไม่ได้อยู่ในแผนแม่บทปัจจุบัน

หากเว็บเพจของคุณใช้เมตาแท็กของเราและประกอบด้วยรายการ og:image เราจะดึงรูปภาพนั้นและแสดงในตัวอย่าง นอกจากนี้ หากไซต์ของคุณมีทั้ง og:image, og:image:width และ og:image:height รูปภาพนั้นจะถูกใช้ตั้งแต่การแชร์แรกที่สร้างขึ้น

หากคุณไม่สามารถให้รูปภาพดังกล่าวได้หมายความว่าคุณต้องรอให้ครอว์เลอร์ของเราดึงและวิเคราะห์รูปภาพก่อน ดู http://ogp.me/#structured สำหรับตัวอย่างเกี่ยวกับวิธีที่สามารถดำเนินการให้สำเร็จ

การทำงานนี้เป็นไปตามการออกแบบ REST API ถูกยกเลิกใช้งานเป็นระยะเวลานานแล้ว และไม่มีการคาดการณ์ว่าจะทำงานได้ต่อไป มีข้อจำกัด คือโทเค็นการเข้าถึงเพจไม่สามารถใช้ได้กับ REST API

คุณสามารถกำหนดรูปแบบภาษาสำหรับปุ่มถูกใจโดยใช้พารามิเตอร์ 'locale' ใน JS SDK ได้ ซึ่งจะเหมาะสำหรับผู้ใช้ที่ไม่ได้เข้าสู่ระบบ หากผู้ใช้ได้เข้าสู่ระบบ ควรมีการพิจารณาการตั้งค่าภาษาของผู้ใช้ด้วย หากมีการกำหนดเป็นภาษาใดภาษาหนึ่ง ปุ่มถูกใจจะเป็นภาษานั้น

คุณสามารถทดสอบลักษณะการทำงานนี้ได้โดยไปที่ Facebook โดยที่ไม่ต้องเข้าสู่ระบบ (หรือใช้ช่วงเวลาที่ใช้งานแบบเป็นส่วนตัวบนเบราว์เซอร์ของคุณ)

การกรอกข้อมูลในพื้นที่ข้อความล่วงหน้าเมื่อแชร์ไปยัง Facebook เป็นสิ่งที่ขัดต่อนโยบาย Facebook ผู้ใช้แอพพลิเคชั่นของคุณจะต้องกรอกข้อความที่ต้องการแชร์ด้วยตัวเอง

การกรอกข้อมูลในพื้นที่ข้อความล่วงหน้าเมื่อแชร์เป็นการละเมิดนโยบายแพลตฟอร์ม 2.3 ( https://developers.facebook.com/policy/#control ) เราบังคับใช้นโยบายนี้เพื่อให้มั่นใจว่าผู้ใช้จะแชร์สิ่งที่พวกเขาต้องการแชร์บน Facebook จริงๆ และไม่ได้แชร์ข้อความที่พวกเขาไม่ได้อนุมัติโดยไม่ตั้งใจ

กรณีนี้อาจเป็นลักษณะการทำงานที่มีการคาดการณ์ไว้ หากคุณเปลี่ยนแปลงหรือแก้ไข URL ของเว็บเพจ URL แต่ละรายการที่ม่ีปลั๊กอินความคิดเห็นจะถือเป็นอ็อบเจ็กต์ Open Graph และความคิดเห็นจะถูกเชื่อมโยงกับอ็อบเจ็กต์นั้น ดังนั้น หากคุณแก้ไข URL อ็อบเจ็กต์ใหม่จะถูกสร้างขึ้น ดังนั้นความคิดเห็นที่มีอยู่อาจไม่แสดงขึ้นบนเพจ

ไม่ คุณไม่ได้รับอนุญาตให้โพสต์ความคิดเห็นไปยังปลั๊กอินผ่าน API

ตัวแชร์จะไม่อนุญาตส่งผ่านคุณเข้าไปในพารามิเตอร์ที่กำหนดเอง และจะดึงเมตาดาต้าจากเมตาแท็ก Open Graph ของเพจโดยตรงแทน

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับหลักปฏิบัติที่ดีที่สุดสำหรับการแชร์เนื้อหา โปรดอ่านเอกสารนี้: https://developers.facebook.com/docs/sharing/best-practices

Yes, Whatsapp Flows can be sent with On-Premises API. You can learn more about Whatsapp Flows here, or learn how to get started with Whatsapp Flows and On-Premises API here.

No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.

We will provide a seven day grace period post sending the warning. This will allow time for businesses to adjust their behavior. If businesses continue to exceed our internally set threshold of calls to the Contacts API vs. number of messages sent, we will permanently disable the phone number.

Interactive messages can be reopened by the user in order to resend an option. This is in case of mistyping the desired option or wanting to choose a new option.

Through user testing we’ve identified 10 as the optimal number of rows to provide a good user experience. If you have a list of more than 10 options, and cannot condense into one list message, we recommend creating an additional step in the flow and using two list messages. During testing businesses had higher response rates and conversions with this approach than using text-based lists.

Through user testing we’ve identified 3 as the optimal number of buttons to provide a good user experience. If you have a list of more than 3 options, and cannot condense it into one button message, we recommend using list messages. During testing, businesses had higher response rates and conversions with list messages than using text-based lists.

There may be a very small number of users for whom their app version does not support this feature, the business will receive a webhook notification throwing an error that describes why the message was unable to be received. It is up to the business to determine how to handle this error elegantly. Best practice would convert the interactive message to a text-based list to allow the user to complete the workflow.

If there is a delay in a subset of numbers, then it is likely not an issue affecting the customers integration but rather an issue on the recipients end, these delays in delivery can happen for a number of reasons. See Send Message Performance, Delays for more information.

ไม่ได้ ขณะนี้เราไม่รองรับการเปลี่ยนแปลงพาธที่นำไปยังพื้นที่เก็บข้อมูลสื่อตามค่าเริ่มต้น (/usr/local/wamedia/) พื้นที่เก็บข้อมูลสื่อทั้งหมดจะต้องอยู่ในตำแหน่งเริ่มต้นนี้เพื่อให้ทำงานได้อย่างถูกต้อง

ไม่มี ขณะนี้เราต้องใช้ EFS ของ AWS เพื่อแชร์ไดรฟ์ข้อมูลสื่อระหว่าง Coreapp กับ Webapp

ไม่ เนื่องจากเราไม่รองรับ KOPS ทั้งนี้ เรารองรับโซลูชั่น AWS ที่ใช้ ECS และยังมีการตั้งค่า Kubernetes minikube ทั่วไปด้วย

Coreapp จะตรวจสอบไดเรกทอรี /usr/local/waent/data และ /usr/local/waent/log ภายในคอนเทนเนอร์ Coreapp เพื่อให้แน่ใจว่ามีพื้นที่จัดเก็บข้อมูลอย่างน้อย 10 MB มิฉะนั้นจะทำให้เกิดข้อผิดพลาดร้ายแรงนี้

ตรวจสอบบันทึกและไดเรกทอรีข้อมูลของคุณเพื่อให้แน่ใจว่าคุณมีพื้นที่เพียงพอ

ไม่ได้ ในขณะนี้ คุณไม่สามารถเรียกใช้หลายหมายเลขในการตั้งค่าไคลเอ็นต์ WhatsApp Business API เดียวกันได้ ทั้งนี้เรากำลังคิดหาวิธีแก้ไขที่เหมาะสมที่จะช่วยให้ดำเนินการนี้ได้ในอนาคต

ใช้การรวบรวมขยะฐานข้อมูลตำแหน่งข้อมูล API services เพื่อล้างข้อความและการรับข้อความที่เกี่ยวข้องจากตาราง messageStore.messages และ messageStore.messages_receipt_log

ตรวจสอบการตั้งค่าการใช้งาน pass_through ของคุณอีกครั้ง คุณจะไม่ได้รับการเรียกกลับสถานะ "อ่านแล้ว" ใดๆ หากคุณเปิดใช้งาน pass_through ด้วยไคลเอ็นต์ WhatsApp Business API v2.29.1 หรือสูงกว่า

หากคุณต้องการรับการเรียกกลับสถานะ "อ่านแล้ว" ให้ปิดใช้งานการตั้งค่าการใช้งาน pass_through โปรดทราบว่าการปิดใช้งาน pass_through อาจทำให้พื้นที่จัดเก็บข้อมูลในฐานข้อมูลของคุณมีขนาดเพิ่มขึ้นได้อย่างรวดเร็ว โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการจัดการฐานข้อมูลที่เอกสารประกอบการจัดการฐานข้อมูล

การรวบรวมฐานขยะข้อมูลจะทำการล้างข้อมูลตาราง messages และ messages_reciept_log เป็นระยะๆ เพื่อช่วยในการจัดการฐานข้อมูล

ตัวรวบรวมขยะจะเก็บรักษาข้อความบางรายการเอาไว้เพื่อให้สามารถนำส่ง/ประมวลผลได้ ตัวอย่างเช่น การเก็บรักษาข้อความขาเข้าเป็นระยะเวลาช่วงหนึ่งเพื่อให้การผสานรวมธุรกิจสามารถทำเครื่องหมายข้อความดังกล่าวว่าอ่านแล้วได้

Coreapp จะทำการรวบรวมขยะโดยสุ่มเวลาแตกต่างกันไป (ทุกๆ 2-3 ชั่วโมง) ซึ่งเพื่อป้องกันไม่ให้ประสิทธิภาพการทำงานในสแตกความพร้อมใช้งานสูงลดลงอันเนื่องมาจากความขัดแย้งของฐานข้อมูล

การรวบรวมขยะไม่เกี่ยวข้องกับคิวการเรียกกลับ ตัวอย่างเช่น หากเซิร์ฟเวอร์ Webhook ไม่พร้อมใช้งานเป็นเวลา 4 วัน ระบบจะจัดเก็บการเรียกกลับไว้เพื่อนำส่งเมื่อเซิร์ฟเวอร์ Webhook กลับมาเชื่อมต่อแล้ว

ลิงก์จะแสดงผลเป็นแบบคลิกได้ก็ต่อเมื่อผู้รับได้บันทึกหมายเลขธุรกิจของคุณเป็นผู้ติดต่อหรือคุณมีบัญชีธุรกิจอย่างเป็นทางการแล้ว

ก่อนหน้า v2.29.x เคยมีความเป็นไปได้ที่คิวข้อความขาออกจะมีขนาดเพิ่มขึ้นเรื่อยๆ เนื่องจากมีจุดบกพร่อง การอัพเกรดเป็น v2.29.3 จะช่วยแก้ไขปัญหานี้ได้

คุณจะต้องรับผิดชอบในการใช้คิวอาร์โค้ดที่เหมาะสมตามตำแหน่งที่คาดหวังและภาษาของผู้ใช้

ในตอนนี้ คิวอาร์โค้ดสามารถสร้างและจัดการได้โดยตรงภายใน API การจัดการ WhatsApp Business และผู้ใช้สามารถสแกนได้ด้วยกล้อง WhatsApp, iOS หรือ Android ของตนเอง

นอกจากนี้ คิวอาร์โค้ดของ WhatsApp ยังมีคุณสมบัติต่อไปนี้

• ข้อความที่กรอกล่วงหน้าสามารถปรับแต่งได้เต็มรูปแบบ และสามารถเปลี่ยนหรือลบได้ทุกเมื่อ
• ผู้ใช้จะไปยังแอพโดยตรงเสมอโดยไม่มีหน้าคั่นใดๆ และ
• ระบบจะแสดงข้อความที่ชัดเจนให้แก่ผู้ใช้ภายในแอพ เมื่อมีการใช้คิวอาร์โค้ดที่หมดอายุแล้ว

หากผู้ใช้พยายามเข้าถึงคิวอาร์โค้ดหรือลิงก์สั้นที่ถูกลบไปแล้ว ผู้ใช้จะเห็นข้อความแสดงข้อผิดพลาดที่ระบุว่าคิวอาร์โค้ด/ลิงก์สั้นดังกล่าวหมดอายุแล้ว

หากผู้ใช้ติดตั้งไคลเอ็นต์เดสก์ท็อปของ WhatsApp อยู่แล้ว ระบบจะเปิดใช้การสนทนากับธุรกิจของคุณ หากไม่ได้ติดตั้งไว้ ระบบจะแจ้งให้ผู้ใช้ติดตั้งไคลเอ็นต์เดสก์ท็อปของ WhatsApp

ลิงก์สั้นรูปแบบใหม่ช่วยให้สามารถแก้ไขหรือลบข้อความที่กรอกล่วงหน้าที่เชื่อมโยงกับลิงก์ได้ทุกเมื่อ นอกจากนี้ยังลดรูปแบบคำสั่งของ URL ให้เป็นโค้ดแบบสุ่ม ซึ่งทำให้ไม่จำเป็นต้องฝังข้อความใน URL และยังช่วยปกปิดหมายเลขโทรศัพท์ด้วย

เราขอแนะนำให้ใช้รูปแบบไฟล์ .svg เพื่อให้สิ่งพิมพ์ออกมามีคุณภาพดีที่สุด

We are announcing the deprecation of Groups through the WhatsApp Business API. Starting July 8, 2020, only API phone numbers in a group created prior to July 8th can continue to use/manage Groups through the WhatsApp Business API. All other API phone numbers won’t be able to create/manage Groups through the Whatsapp Business API. On October 8, 2020, we will deprecate this feature for all API phone numbers (i.e., API phone numbers will be removed from their groups and no longer be able to send messages to their group).

v2.25.x จะพัฒนาประสิทธิภาพทั้งขาเข้าและขาออกให้ดีกว่ารุ่นที่ปล่อยไปก่อนหน้านี้ การปรับให้เหมาะสมนี้อาศัยการสร้างจุดเชื่อมต่อฐานข้อมูลเพิ่มเติม ซึ่งอาจทำให้จำนวนจุดเชื่อมต่อฐานข้อมูลถึงขีดจำกัดได้สำหรับการใช้งานบางรูปแบบ คุณสามารถเพิ่มจำนวนจุดเชื่อมต่อสูงสุดที่เซิร์ฟเวอร์ฐานข้อมูลของคุณสามารถยอมรับได้เพื่อรักษาประสิทธิภาพการทำงานที่เพิ่มขึ้น หากไม่สามารถทำได้ คุณสามารถเปลี่ยนพารามิเตอร์ axolotl_context_striping_disabled เพื่อปิดใช้งานลักษณะการทำงานนี้ ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีการเปลี่ยนแปลงดังกล่าวได้ที่เอกสารประกอบการตั้งค่าแอพพลิเคชั่น

หากคุณหรือลูกค้าปลายทางของคุณต้องการร้องขอที่จะเป็นบัญชีธุรกิจที่เป็นทางการของ WhatsApp ดูคำแนะนำในเอกสารประกอบการร้องขอบัญชีธุรกิจที่เป็นทางการ

ไม่ใช่ ขณะนี้ขีดจำกัดการส่งข้อความใช้กับข้อความที่ธุรกิจเริ่มขึ้นเท่านั้น (การแจ้งเตือน)

เมื่อส่งรูปภาพเป็นอัลบั้มจาก WhatsApp Business API คุณจะต้องส่งอย่างน้อย 4 รูปอย่างต่อเนื่อง ถ้าผู้ใช้กำลังใช้งานมุมมองการสนทนาอยู่ในขณะที่ได้รับรูปภาพ ผู้ใช้จะไม่สามารถใช้งานมุมมองแบบอัลบั้มได้จนกว่าจะเข้ามาใช้ในครั้งถัดไป

ระบบจะไม่สร้างอัลบั้มหากเนื้อหาเป็นไปตามเกณฑ์ใดๆ ต่อไปนี้:

1. รูปภาพที่มีคำบรรยายภาพ
2. เส้นแบ่งข้อความที่ยังไม่ได้อ่าน - ผู้ใช้เห็นรูปภาพบางส่วนแล้ว แต่ยังไม่ได้ดูส่วนที่เหลือ
3. ส่วนหัววันที่ - วันใหม่ระหว่างการส่ง

ไม่ได้ ขณะนี้ ไคลเอ็นต์ WhatsApp Business API ยังไม่ทำงานบน Docker สำหรับ Windows สำหรับความต้องการในการพัฒนา ขอแนะนำให้ใช้เครื่องเสมือนบน Linux และเรียกใช้งาน Docker ภายในนั้น สำหรับปริมาณงานในการทำงานจริง ขอแนะนำให้ใช้เซิร์ฟเวอร์ Linux เพื่อหลีกเลี่ยงปัญหาความเข้ากันได้และประสิทธิภาพการทำงาน

สำหรับไคลเอ็นต์ WhatsApp Business API ที่ทำงานในเวอร์ชั่น 2.21.6 เมื่อไคลเอ็นต์ตัดการเชื่อมต่อจากเซิร์ฟเวอร์ อาจยังคงตัดการเชื่อมต่อเพียงไม่กี่นาที (ไม่เกิน 4 นาที) แล้วจึงจะพยายามเชื่อมต่ออีกครั้ง การอัพเกรดเป็นเวอร์ชั่น 2.23.4 จะช่วยลดเวลาหยุดทำงานลงได้ เมื่อไคลเอ็นต์พยายามเชื่อมต่อกับเซิร์ฟเวอร์

รหัสข้อผิดพลาด 471 เกี่ยวข้องกับขีดจำกัดอัตราตามคุณภาพ ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบขีดจำกัดอัตราตามคุณภาพ

ธุรกิจเริ่มต้นที่ลำดับชั้นต่ำสุด และจะอัพเกรดเป็นลำดับชั้นที่สูงขึ้นเมื่อส่งข้อความที่มีคุณภาพในจำนวนที่มากขึ้น

ใช่ เมื่อส่งเทมเพลตข้อความ หากไม่สามารถแสดงบนฝั่งรับ คุณจะได้รับการเรียกกลับสถานะที่ "ไม่สำเร็จ" โดยมี "โครงสร้างใช้งานไม่ได้" ในอ็อบเจ็กต์ข้อผิดพลาดที่ระบุว่าไม่สามารถแสดงข้อความได้ นอกจากนี้ คุณยังอาจได้รับการเรียกกลับสถานะที่ "ส่งแล้ว" ซึ่งเพียงแค่บ่งบอกว่าข้อความนั้นถูกส่งไปยังผู้รับแล้ว หลังจากที่ผู้รับไม่สามารถแสดงข้อความได้ ซึ่งขึ้นอยู่กับผู้รับ

ข้อผิดพลาดการตรวจสอบความถูกต้องของด้านการส่งเทมเพลตข้อความและเหตุผลที่คุณมองเห็นข้อผิดพลาดดังกล่าวมีดังต่อไปนี้

• "ไม่มีเทมเพลตข้อความในภาษา your-language" หรือ "ไม่มีเทมเพลตข้อความในภาษา your-languageและรูปแบบภาษา your-locale" — ไม่มีชุดภาษาที่ระบุ ตรวจสอบตัวจัดการธุรกิจของคุณ
• "ไม่มีเทมเพลต your-template-name ในภาษา your-language" หรือ "ไม่มีเทมเพลต your-template-name ในภาษา your-languageและรูปแบบภาษา your-locale" — คุณกำลังพยายามใช้เทมเพลตที่ไม่มีอยู่ (ยังไม่ได้สร้างขึ้นหรือยังไม่ได้รับอนุมัติ) หากคุณพยายามส่งข้อความที่มีเทมเพลตที่ถูกลบออกไปแล้ว คุณจะได้รับข้อผิดพลาดนี้เช่นกัน
• "จำนวน localizable_params num1 ไม่ตรงกับจำนวน params num2 ที่คาดหวัง" — คุณกำลังพยายามส่งเทมเพลตข้อความที่มีพารามิเตอร์ไม่ตรงกับจำนวนพารามิเตอร์ที่คาดหวัง โปรดตรวจสอบการเรียกใช้ API ของคุณเพื่อดูความถูกต้อง
• "your-template-name เป็นเทมเพลตที่สมบูรณ์และจำเป็นต้องใช้ API ข้อความเทมเพลต" — คุณกำลังพยายามส่งเทมเพลตข้อความสื่อเป็นเทมเพลตข้อความทั่วไป โปรดตรวจสอบให้แน่ใจว่าประเภทข้อความคือ template โปรดดูข้อมูลเพิ่มเติมที่เอกสารประกอบเทมเพลตข้อความสื่อ
• เมื่อเทมเพลตได้รับอนุมัติในตัวจัดการธุรกิจแล้ว (หรือลบออก) ไคลเอ็นต์ WhatsApp Business API อาจใช้เวลานานถึง 20 นาทีจึงจะได้รับเทมเพลตที่อัพเดตแล้ว หากคุณพยายามส่งข้อความที่มีเทมเพลตที่เพิ่งได้รับอนุมัติ และคุณได้รับข้อผิดพลาดที่ระบุว่าไม่มีเทมเพลต คุณสามารถลองส่งข้อความนั้นใหม่ได้หลังจากที่รอเป็นเวลาตามที่ระบุข้างต้นแล้ว

สามารถส่งข้อความซ้ำไปยัง WhatsApp Webhook ได้ โดยเป็นการรับประกันเพียงอย่างเดียวว่าจะได้รับข้อความอย่างน้อยหนึ่งครั้ง (โดยตรงข้ามกับเพียงครั้งเดียว) หากการดำเนินการดังกล่าวกระทบต่อวิธีการประมวลผลข้อความทางฝั่งคุณ เราขอเสนอให้ยกเลิกการซ้ำข้อความ Webhook โดยใช้ ID ข้อความ

ถ้าหมายเลขโทรศัพท์นั้นยังไม่เคยใช้บน WhatsApp Business API คุณสามารถใช้หมายเลขโทรศัพท์นั้นได้ ทำตามขั้นตอนการย้ายที่ระบุไว้ที่นี่ เพื่อนำหมายเลขโทรศัพท์มาใช้ซ้ำ

เริ่มจากรุ่น v2.18.26 ตำแหน่งข้อมูลสถิติแอพอนุญาตให้ส่งออกเกณฑ์ชี้วัดภายในในรูปแบบตัวอักษร Prometheus ได้ ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบการติดตามอินสแตนซ์

ถ้าโปรไฟล์ธุรกิจถูกสร้างขึ้นเพียงบางส่วน จะส่งคืนอ็อบเจ็กต์ profile ที่ว่าง กรุณาอัพเกรดเป็น v2.21.4 เพื่อแก้ไขปัญหาดังกล่าว

ดูข้อมูลเพิ่มเติมเกี่ยวกับการกรอกโปรไฟล์ธุรกิจของคุณได้ในเอกสารประกอบการตั้งค่าโปรไฟล์ธุรกิจ

หากคุณได้รับข้อผิดพลาดที่คล้ายคลึงกันนี้ในขณะตั้งค่าการนำ AWS ไปใช้งาน ให้ลองเปลี่ยนเป็นชื่อสแตกที่ใช้อักขระไม่เกิน 8 ตัว

ชื่อประเทศ (รหัส 2 ตัวอักษร) [AU]:ชื่อรัฐหรือมณฑล/จังหวัด (ชื่อเต็ม) [Some-State]:ชื่อท้องที่ (เช่น เมือง) []:ชื่อองค์กร (เช่น บริษัท) [Internet Widgits Pty Ltd]:ชื่อหน่วยงานในองค์กร (เช่น ฝ่าย) []:ชื่อทั่วไป (เช่น เซิร์ฟเวอร์ FQDN หรือชื่อของคุณ) []:สตริงยาวเกินไป จะต้องมีความยาวน้อยกว่า 64 ไบต์ ชื่อทั่วไป (เช่น เซิร์ฟเวอร์ FQDN หรือชื่อของคุณ) []:ที่อยู่อีเมล []:ข้อผิดพลาด ไม่ได้ระบุอ็อบเจ็กต์ในไฟล์ config ปัญหาในการสร้างคำขอใบรับรอง คีย์อุปกรณ์ที่สร้างขึ้นสำหรับ internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com

ไม่มีการจำกัดจำนวนพารามิเตอร์ที่อนุญาตในเทมเพลตข้อความ

บัญชี WhatsApp Business มีเทมเพลตข้อความได้สูงสุด 250 เทมเพลต

หากไม่ได้ส่งเหตุการณ์ Webhook ด้วยเหตุผลใดก็ตาม (เช่น ไคลเอ็นต์ออฟไลน์อยู่) หรือคำขอ Webhook ส่งคืนรหัสสถานะ HTTP อื่นนอกเหนือจาก 200 เราจะลองส่ง Webhook อีกครั้ง เราจะลองส่งใหม่ต่อไปโดยเลื่อนเวลาเพิ่มขึ้นจนหมดเวลา (24 ชั่วโมงโดยทั่วไป แต่ก็อาจแตกต่างออกไป) หรือจนกว่าจะส่งได้สำเร็จ

อาจมีบางกรณีที่คุณจำเป็นต้องใช้เวลามากขึ้นในการจัดการคำถามของลูกค้า และอาจสามารถให้คำตอบหลังจาก 24 ชั่วโมงไปแล้วเท่านั้น เราขอแนะนำให้สร้างเทมเพลตข้อความดังนี้

• ส่งผลลัพธ์ให้แก่ผู้ใช้ หรือ
• ขึ้นข้อความแจ้งให้ผู้ใช้ตอบกลับ เพื่อเปิดใช้งานหน้าต่างการบริการลูกค้า

ในทั้งสองกรณี คุณต้องระบุบริบทสำหรับเทมเพลตข้อความให้มากที่สุดเท่าที่เป็นไปได้ ตัวอย่างเช่น:

• "เรียน {{1}} ในส่วนของปัญหาที่ท่านแจ้งไปก่อนหน้านี้ เราเสียใจที่จะแจ้งให้ท่านทราบว่า {{2}} ขออภัยในความไม่สะดวกที่เกิดขึ้น"
• เรามีอัพเดตเกี่ยวกับบัตรขอรับความช่วยเหลือของท่าน โปรดตอบกลับ หากท่านยังต้องการความช่วยเหลือ"

WhatsApp ดำเนินการทดลองเพื่อวัดและทำความเข้าใจผลกระทบของการแจ้งเตือน WhatsApp Business API เกี่ยวกับประสบการณ์ผู้ใช้และผลิตภัณฑ์โดยรวมโดยทั่วไป หากผู้ใช้ที่คุณกำลังส่งข้อความถึงอยู่ในการทดลองดังกล่าว พวกเขาอาจจะไม่ได้รับการแจ้งเตือนจากคุณ แม้ว่าได้เลือกที่จะรับข้อความแล้วก็ตาม

หากคุณสำรองข้อมูลการตั้งค่าปัจจุบันของคุณ แล้วกู้คืนบนเครื่องใหม่ ข้อมูลการลงทะเบียนควรย้ายไปพร้อมกับการนำมาใช้งานส่วนที่เหลือของคุณ ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบการตั้งค่าการสำรองข้อมูลและกู้คืนข้อมูล

มี การหมุนเวียนบันทึกสำหรับคอนเทนเนอร์ของ Webapp และคอนเทนเนอร์ของ Coreapp มีลักษณะการทำงานที่แตกต่างกันเล็กน้อยดังนี้

• Webapp: เก็บรักษาไฟล์บันทึก 30 ไฟล์สุดท้าย ไฟล์บันทึกจะมีการหมุนเวียนก็ต่อเมื่อมีขนาดเกิน 20 MB
• Coreapp: เก็บรักษาไฟล์บันทึก 30 ไฟล์สุดท้าย ไฟล์บันทึกจะมีการหมุนเวียนก็ต่อเมื่อมีขนาดเกิน 15 MB ไฟล์ที่หมุนเวียนจะถูกบีบอัด

โปรดติดต่อฝ่ายสนับสนุน พร้อมด้วยข้อมูลใดๆ ที่คุณมี เราจะสืบสวนและปิดการใช้งานหมายเลขปลอมใดๆ

บิวด์ทั้งหมดของไคลเอ็นต์ WhatsApp Business API มีเวลาหมดอายุ 6 เดือนนับจากวันที่ออก หากคุณเห็นข้อผิดพลาดนี้ ให้อัพเกรดเป็นเวอร์ชั่นที่ออกล่าสุดในทันทีที่เป็นไปได้

คุณต้องตรวจสอบก่อนว่าผู้ติดต่อนั้นมีอยู่ไม่ ก่อนที่จะส่งข้อความ ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีดำเนินการดังกล่าวได้ในเอกสารประกอบผู้ติดต่อ

ข้อผิดพลาดนี้เกิดขึ้นเนื่องจากยังไม่ได้เริ่มต้นใช้งาน Coreapp ซึ่งหมายความว่าการลงทะเบียนอาจยังไม่เสร็จเรียบร้อย โปรดลองลงทะเบียนอีกครั้งก่อนที่จะโทรไปยังปลายทางอื่น หลังจากที่ติดตั้ง WhatsApp Business API ขั้นตอนแรกคือการเข้าสู่ระบบ ขั้นตอนที่สองคือการลงทะเบียน สองขั้นตอนนี้เป็นขั้นตอนที่จำเป็นก่อนที่จะทำการร้องขอไปยังปลายทางอื่นใด

หมายเหตุ: เราได้เลิกใช้นโยบายภาษา fallback แล้วโดยเริ่มตั้งแต่ v2.27.8 และขณะนี้ นโยบายภาษา deterministic จะเป็นนโยบายที่เป็นค่าเริ่มต้น

หากคุณสร้างคำแปลในภาษาใหม่ คุณจะต้องแปลองค์ประกอบทั้งหมดที่คุณใช้เป็นภาษานั้นๆ มิฉะนั้น คุณอาจได้รับข้อผิดพลาด "โครงสร้างใช้งานไม่ได้" เนื่องจากโทรศัพท์ของผู้รับไม่พบองค์ประกอบที่คาดหวังสำหรับภาษานั้นๆ โดยจะพบข้อผิดพลาดโครงสร้างใช้งานไม่ได้เหล่านี้ เมื่อส่งข้อความเทมเพลตโดยใช้นโยบายแบบสำรอง

หากคุณไม่ได้เลือกที่จะสร้างคำแปลภาษาในขณะนี้ คุณสามารถใช้นโยบายแบบกำหนดชัดเจนเพื่อหลีกเลี่ยงข้อผิดพลาดเหล่านี้ได้

เพย์โหลดข้อความจากผู้ใช้สามารถเป็นได้ทั้งไฟล์ข้อความหรือไฟล์สื่อ

สำหรับข้อความ เชื่อว่าไม่มีอันตรายที่ได้รับการระบุใดๆ

สำหรับไฟล์สื่อ:

• โดยปกติ คาดว่าธุรกิจจะมีการนำซอฟต์แวร์ป้องกัน (เช่น โปรแกรมต่อต้านไวรัส โปรแกรมต่อต้านมัลแวร์ เป็นต้น) มาใช้งาน เพื่อวิเคราะห์การคุกคามใดๆ ที่เป็นไปได้
• WhatsApp ไม่สามารถระบุหรือตรวจสอบเนื้อหาของไฟล์ที่กำลังถ่ายโอนได้ เนื่องจากมีการเข้ารหัสตั้งแต่ต้นทางถึงปลายทาง (ใช้หลักการเดียวกันกับเนื้อหาที่เป็นข้อความอย่างเดียว)
• มีตัวเลือกเพื่อป้องกันไม่ให้ดาวน์โหลดไฟล์สื่อลงในไคลเอ็นต์ WhatsApp Business API โดยอัตโนมัติ หากธุรกิจไม่ต้องการได้รับไฟล์ใดๆ จากผู้ใช้ สามารถตั้งค่าฟิลด์ auto_download เป็นอาร์เรย์เปล่าได้

ไม่ได้ ไม่มีวิธีการใดที่จะใช้ WhatsApp Business API ตรวจหาอุปกรณ์หลายเครื่องที่ใช้หมายเลขเดียวกันได้เลย

ข้อผิดพลาด "structure unavailable" (โครงสร้างไม่พร้อมใช้งาน) จะเกิดขึ้นเมื่อโทรศัพท์ไม่สามารถอ่านข้อความเทมเพลตได้

เทมเพลตได้รับการจัดเก็บไว้บนเซิร์ฟเวอร์ เมื่อส่งข้อความเทมเพลตโดยใช้โหนด messages แล้วระบบจะส่งเฉพาะเนมสเปซ ภาษา ชื่อองค์ประกอบ และพารามิเตอร์ที่แปลเป็นภาษาท้องถิ่นไปยังโทรศัพท์ แต่จะไม่ได้ส่งข้อความทั้งหมด เมื่อค่าเหล่านี้ส่งไปถึงโทรศัพท์แล้ว ระบบจะพยายามแสดงข้อความดังกล่าว

หากมีข้อผิดพลาดใดๆ เกิดขึ้นระหว่างการแสดงผล ระบบจะส่งข้อผิดพลาด structure unavailable (โครงสร้างไม่พร้อมใช้งาน) ไปยัง URL การเรียกกลับ ซึ่งประกอบด้วย ID ผู้รับและ ID ข้อความ ข้อผิดพลาดเหล่านี้อาจเกิดขึ้นได้เนื่องจากเนมสเปซไม่ถูกต้อง พารามิเตอร์ที่แปลเป็นภาษาท้องถิ่นไม่ตรงกัน ชื่อองค์ประกอบไม่ถูกต้อง ฯลฯ

ไปที่ตัวจัดการ WhatsApp ในตัวจัดการธุรกิจของ Facebook เพื่อดูจำนวนพารามิเตอร์ที่ถูกต้อง ตรวจซ้ำว่าเนมสเปซนั้นถูกต้องและมีชื่อองค์ประกอบอยู่

ข้อผิดพลาดนี้มีแหล่งที่มาโดยทั่วไปจากการไม่ได้สร้างคำแปลสำหรับเทมเพลตทั้งหมดที่ใช้ ตัวอย่างเช่น หากคุณมี 2 เทมเพลตที่คุณใช้ส่งโดยทั่วไป และคุณเพิ่มคำแปลภาษาใหม่ให้กับเทมเพลตหนึ่ง คุณต้องเพิ่มคำแปลภาษาใหม่นั้นให้กับอีกเทมเพลตด้วย หากคุณมีแผนที่จะรองรับมากกว่า 1 ภาษา คุณต้องจัดให้มีคำแปลสำหรับเทมเพลตทั้งหมดในทุกภาษาที่รองรับ

ข่าวดีก็คือข้อผิดพลาด structure unavailable (โครงสร้างไม่พร้อมใช้งาน) มักเกิดจากข้อผิดพลาดในการเรียกใช้ API messages และสามารถแก้ไขได้โดยการเปลี่ยนเพย์โหลดการส่ง

คุณสามารถลงทะเบียนหมายเลขโทรศัพท์ใหม่และลบหมายเลขเก่าในบัญชี WhatsApp ของคุณได้ในตัวจัดการธุรกิจของ Facebook

1. ในบัญชี WhatsApp ของคุณ ไปที่การตั้งค่า
2. คลิกตัวจัดการ WhatsApp
3. เลือกแท็บหมายเลขโทรศัพท์ คุณสามารถจัดการหมายเลขโทรศัพท์ทั้งหมดสำหรับบัญชีนี้ได้ที่นี่

สำหรับรูปภาพ คำบรรยายจะถูกเพิ่มเป็นคำอธิบาย ข้อความของคำบรรยายจะปรากฏเต็มความยาวสำหรับรูปภาพทั้งบน Android และ iPhone

สำหรับเอกสาร คำบรรยายจะแทนที่ชื่อไฟล์ ซึ่งไม่ได้หมายความว่าจะแสดงบนอุปกรณ์ของผู้ใช้เป็นคำอธิบาย แต่เพื่อแสดงชื่อของไฟล์ iPhone จะแสดงข้อความทั้งหมดในขณะที่ Android จะตัดทอนชื่อไฟล์ ซึ่งเป็นข้อจำกัดทางเทคนิคของการนำ WhatsApp มาใช้ล่าสุดบนอุปกรณ์ทั้งสองชนิด

ถ้าลงทะเบียนกับ "SMS" ล้มเหลวเนื่องจากพยายามหลายครั้งเกินไป และมีข้อความ "การเข้าถึงถูกปฏิเสธ" โปรดลองลงทะเบียนอีกครั้งด้วย "เสียง"

ขณะนี้เป็นเวลา 7 วัน หากแคชไม่ได้รับการอัพเดตนานกว่า 7 วัน ก็จะดึงชุดภาษาล่าสุดจากเซิร์ฟเวอร์โดยไม่คำนึงว่าองค์ประกอบมีอยู่แล้วในชุดภาษาหรือไม่

อุปกรณ์จะโหลดจากแคชก่อน และถ้ามีองค์ประกอบอยู่ ก็จะแยกข้อความโดยใช้เทมเพลตข้อความดังกล่าว ดังนั้น แทนที่จะปรับเปลี่ยนเทมเพลตข้อความ การเพิ่มเทมเพลตข้อความใหม่ด้วยชื่อองค์ประกอบที่ต่างออกไปจึงเป็นวิธีที่ปลอดภัยที่สุด ซึ่งจะรับประกันได้ว่าชุดภาษาจะถูกดาวน์โหลดอีกครั้ง หากไม่พบองค์ประกอบนั้น เทมเพลตข้อความใช้พื้นที่ในการจัดเก็บน้อยมาก จึงแทบไม่มีความจำเป็นต้องลบเทมเพลตข้อความเลย

ดูข้อมูลเพิ่มเติมได้ที่การส่งเทมเพลตข้อความ — ภาษา

เพื่อให้มั่นใจว่าจะได้รับประสบการณ์คุณภาพสูงสำหรับธุรกิจและผู้ใช้ เราอยู่ในการการดูตัวอย่างสาธารณะที่จำกัด หากคุณต้องการทำงานกับเรา ส่งข้อมูลเพิ่มเติมเกี่ยวกับธุรกิจของคุณเพื่อการพิจารณา ในขณะที่เราขยายความพร้อมใช้งานของเราต่อไป หรือติดต่อผู้แทน Facebook ของคุณ ถ้ามี

การนำผู้ใช้ออกจากระบบผ่านทางตำแหน่งข้อมูล users จะเลิกใช้โทเค็นการยืนยันตัวตนทั้งหมดที่กำหนดให้แก่บัญชีนั้น การลบผู้ใช้จะให้ผลลัพธ์เดียวกัน แต่มีความรุนแรงกว่ามาก โปรดทราบว่าการนำผู้ใช้เข้าสู่ระบบผ่านทางตำแหน่งข้อมูล users จะส่งคืนโทเค็นการยืนยันตัวตนใหม่ แต่จะไม่เลิกใช้โทเค็นการยืนยันตัวตนที่ใช้งานอยู่แล้วสำหรับผู้ใช้รายนั้น ผู้ใดก็ตามที่มีโทเค็นที่จัดให้ก่อนหน้านี้จะยังคงสามารถใช้โทเค็นนั้นต่อไปได้ จนกว่าจะหมดอายุหรือถูกเลิกใช้ผ่านทางวิธีการใดวิธีการหนึ่งที่กล่าวถึงก่อนหน้านี้

หากคุณมองเห็นข้อผิดพลาดนี้ แต่พารามิเตอร์ที่จำเป็นที่ขาดหายไปที่อ้างถึงนั้นถูกกำหนดในเนื้อหา JSON ของคุณ แสดงว่าอาจเป็นข้อผิดพลาดในการแยกวิเคราะห์ JSON ข้อผิดพลาดนี้สามารถเกิดขึ้นได้ เมื่อเพย์โหลด JSON ทั้งหมดไม่สามารถแยกวิเคราะห์ได้ เนื่องจากข้อผิดพลาดในการจัดรูปแบบของ JSON ตรวจหาอักขระที่ไม่ถูกต้องของ JSON ในค่าของพารามิเตอร์เหล่านั้น เช่น อักขระขึ้นบรรทัดใหม่ที่ตอนท้าย บางครั้งอาจมีการคัดลอกอักขระเว้นวรรคเพิ่มเติมที่อาจมีอักขระที่ทำให้ JSON เสียหายเข้ามาในพารามิเตอร์

มีเหตุผลหลายข้อสำหรับข้อผิดพลาดนี้ Coreapp อาจกำลังใช้งานไม่ได้ หรือไม่ได้ตั้งค่าฐานข้อมูลของคุณอย่างถูกต้อง หากไม่ใช่กรณีดังกล่าว โปรดดูบันทึก Coreapp ของคุณ (หรือบันทึก Coreapp หลัก หากคุณกำลังใช้การเชื่อมต่อหลายจุด) หากคุณเห็นข้อผิดพลาดในการเชื่อมต่อฐานข้อมูล มีแนวโน้มว่าฐานข้อมูลของคุณมีการเชื่อมต่อไม่เพียงพอ ดูเอกสาร MySQL หรือเอกสาร PostgreSQL เกี่ยวกับข้อผิดพลาดนี้

ขอแนะนำให้เพิ่มจำนวนการเชื่อมต่อฐานข้อมูลกับฐานข้อมูลของคุณ 1000 การเชื่อมต่อฐานข้อมูลควรเป็นจำนวนที่ปลอดภัย แต่คุณควรตัดสินใจจำนวนการเชื่อมต่อด้วยตัวเองโดยมีข้อมูลสนับสนุน หากข้อผิดพลาดยังคงมีอยู่ เปิดบัตรขอรับความช่วยเหลือ

เหตุผลที่เทมเพลตข้อความอาจถูกปฏิเสธมีดังนี้

• ประกอบด้วยเนื้อหาที่อาจไม่เหมาะสม เช่น ภาษาที่ไม่เหมาะสมหรือเนื้อหาที่คล้ายสแปม
• ประกอบด้วยเนื้อหาส่งเสริมการขาย
• ไม่ตรงกับประเภทแท็กที่เลือก
• จัดรูปแบบไม่ถูกต้อง

ข้อผิดพลาด "การเชื่อมต่อถูกปฏิเสธ" น่าจะหมายถึง Coreapp ไม่ทำงาน ใช้ docker ps เพื่อตรวจดูว่า Coreapp ทำงานหรือไม่ ถ้าไม่ทำงาน ให้ตรวจดูบันทึก Docker Coreapp อาจไม่สามารถเชื่อมต่อกับฐานข้อมูลก็ได้ ตรวจสอบให้แน่ใจว่าตั้งค่าฐานข้อมูลไว้อย่างถูกต้อง

ซึ่งเกิดขึ้นเมื่อตัวเชื่อม Docker เสียหาย วิธีแก้ไขที่ดีที่สุดคือหยุดบริการ Docker และเริ่มใหม่อีกครั้ง คุณสามารถลอง docker restart บนคอนเทนเนอร์ของคุณได้เช่นกัน

WhatsApp จะตรวจสอบยืนยันให้แน่ชัดว่าหมายเลขที่ให้มานั้นเป็นของโทรศัพท์จริงๆ หรือไม่ ข้อเท็จจริงที่ผู้ใช้มีบัญชี WhatsApp เป็นข้อพิสูจน์ว่าพวกเขายืนยันหมายเลข และไม่มีผู้อื่นใช้หมายเลขนั้นเพื่อลงทะเบียนบน WhatsApp ตามมา อย่างไรก็ตาม นี่ไม่ใช่การรับประกันตำแหน่งทางกายภาพของ SIM การ์ด

ในทางตรงกันข้าม หากโทรศัพท์ของผู้ใช้สูญหายหรือถูกขโมย ก็สามารถปิดใช้งานบัญชี WhatsApp ของตนได้ เพื่ออ่านเพิ่มเติมว่าผู้ใช้ปิดใช้งานบัญชีของตนอย่างไร ดูคำถามที่พบบ่อยเกี่ยวกับโทรศัพท์ที่สูญหายและถูกขโมย

ถ้าหมายเลขโทรศัพท์ของลูกค้าไม่ได้ใช้งานแล้ว แต่ลูกค้ายังใช้ WhatsApp อยู่ ลูกค้าจะยังคงมีสิทธิ์เข้าถึง WhatsApp ต่อไปจนกว่า/หากหมายเลขโทรศัพท์ถูกกำหนดใหม่หรือลงทะเบียนใหม่

WhatsApp strongly verifies whether number provided actually belongs phone. The fact that a user has a WhatsApp account is proof that they confirmed the number and no one else has used that number to register on WhatsApp subsequently. However, It is not a guarantee of the physical location of the sim.

On the other hand, if users phone is lost or stolen, they can deactivate their WhatsApp account. You may read to know more about how users can deactivate their account here.

ข้อผิดพลาดนี้เกิดขึ้นเมื่อไม่ได้ตั้งค่าฐานข้อมูลอย่างถูกต้อง

• ตรวจสอบให้แน่ใจว่าคุณใช้ MySQL 5.7 ขึ้นไปหรือ PostgreSQL 9.5.x, 9.6.x, 10.x
• รหัสผ่านของฐานข้อมูลไม่ควรมีอักขระใดๆ ต่อไปนี้: ?{}&~!()^
• หากคุณกำลังใช้ AWS สแตกของคุณต้องมีชื่อที่สั้น ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบการติดตั้ง

จำเป็น การเชื่อมต่อ TCP เป็นสิ่งจำเป็น ถ้าธุรกิจของคุณไม่สามารถเปิดพอร์ตเพิ่มเติมได้ คุณสามารถใช้ SSL ที่สิ้นสุดแล้วได้

ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบข้อกำหนดของเครือข่าย

นี่คือปัญหาที่ทราบอยู่แล้ว บางครั้ง การอัพเกรดไคลเอ็นต์ WhatsApp Business API โดยใช้สคริปต์ CloudFormation สิ้นสุดด้วยการขอให้อัพเดตสแตก RDS DB อีกด้วย สแตก RDS ใหม่จะมีชื่อโฮสต์ไม่เหมือนสแตกเดิม และคอนเทนเนอร์ Docker จะไม่สามารถเชื่อมต่อกับฐานข้อมูลได้ วิธีแก้ไขคือการเพิ่ม SSH ในอินสแตนซ์ EC2 ที่สร้างโดย CloudFormation และอัพเดตไฟล์ whatsapp.conf ด้วยชื่อโฮสต์ใหม่ แล้วจึงรีสตาร์ทคอนเทนเนอร์ Docker เพื่อให้รับการตั้งค่าใหม่

จำเป็น ต้องส่งการเรียก API ไปยังโหนด contacts ก่อนที่จะส่งข้อความ ข้อมูลจากการตรวจสอบ contacts จะถูกแคชไว้ในคอนเทนเนอร์ และหากไม่ทำเช่นนี้ อาจส่งผลให้เกิดข้อผิดพลาด Unkown Contact ได้ ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบการตรวจสอบผู้ติดต่อ

Use the mcdockerreset script and tear down the webapps then use the mcdockersetup script to bring up a new webapp.

Reason: When the webapp first connects to the DB, it creates the database.yml file. it will never try to create it again. The coreapps will just not start up on a bad DB config; however, the webapp will, so you see the master and slave nodes in your DB because they were setup correctly once you got around all the DB and script issues but the webapps were started by the script in a bad state to begin with.

ถ้า Webhook ไม่สามารถส่งการเรียกกลับได้ การเรียกกลับจะถูกใส่ไว้ในคิวการลองอีกครั้ง โดยจะไม่สามารถได้รับการเรียกกลับใดๆ ที่ส่งหลังจากที่การเรียกกลับครั้งแรกล้มเหลว หลังจากการเรียกกลับที่ล้มเหลวครั้งแรกนั้นกลับมาทำงานได้ ส่วนที่เหลือจึงจะตามมา

ไคลเอ็นต์ WhatsApp Business API ส่งการเรียกกลับ Webhook ให้คุณผ่านทางคอนเทนเนอร์ Coreapp ดังนั้นจึงจำเป็นต้องกำหนดค่าตำแหน่งข้อมูล Webhook ของคุณจึงจะรับคำขอที่เข้ามาจาก Coreapp ได้

คุณควรลงทะเบียนหมายเลขโทรศัพท์ที่สอง และเรียกใช้สแตก CloudFormation ที่สองหรืออินสแตนซ์ Docker สำหรับการทดสอบ หากคุณมีไคลเอ็นต์ WhatsApp Business API สองตัวที่กำลังใช้งานโดยใช้หมายเลขโทรศัพท์เดียวกัน เซิร์ฟเวอร์จะนำคุณออกมาเพราะคีย์การเข้ารหัสจะขัดแย้งกัน เราแนะนำให้มีสิ่งแวดล้อมที่สองที่คุณสามารถใช้เพื่อทดสอบอินสแตนซ์ที่ไม่ใช่การใช้งานจริงของคุณ ก่อนที่คุณจะทำการย้ายระบบประเภทใดก็ตามบนไคลเอ็นต์การทำงานจริงของคุณ

ต้องใช้ MySQL 5.7.x, PostgreSQL 9.5.x, 9.6.x, 10.x การใช้เวอร์ชั่นก่อนหน้าจะทำให้เกิดข้อผิดพลาด Unable to initialize config store

เมื่อคุณส่งข้อความ ในทันทีที่คุณได้รับ ID ข้อความ แสดงว่าคำขอข้อความถูกจัดเก็บไว้ในฐานข้อมูลแล้ว ไคลเอ็นต์ WhatsApp Business API จะพยายามส่งข้อความนั้นจนกว่าเซิร์ฟเวอร์ WhatsApp จะรับทราบ กระบวนการนี้ไม่มีเวลาสิ้นสุด จากนั้น เซิร์ฟเวอร์ WhatsApp จะพยายามส่งข้อความนั้นไปยังโทรศัพท์ของผู้ใช้ ถ้าโทรศัพท์ของผู้ใช้ไม่ได้ออนไลน์ ข้อความจะถูกจัดเก็บเป็นเวลา 30 วันก่อนที่เซิร์ฟเวอร์ WhatsApp จะทิ้งไป

ตารางของฐานข้อมูลจัดเก็บข้อมูลเกี่ยวกับการตั้งค่าแอพ เธรดการแชท ข้อความ สื่อ ฯลฯ ซึ่งแอพต้องใช้ทั้งหมดนี้ในการทำงาน

ธุรกิจของคุณจะไม่ได้รับแจ้งเมื่อลูกค้าเปลี่ยนหมายเลขโทรศัพท์ WhatsApp ของตน เมื่อคุณใช้โหนด contacts สถานะสำหรับหมายเลขนั้นจะเป็น invalid

ไม่ได้ คุณสามารถเรียกใช้ได้เพียงบัญชีเดียวต่อหนึ่งอินสแตนซ์เท่านั้น หากคุณต้องการใช้บัญชีทดสอบที่สอง คุณต้องใช้หมายเลขที่แตกต่างกันสำหรับอินสแตนซ์ที่สองนั้น

การตรวจสอบสถานภาพไม่มีค่าใช้จ่าย และสามารถสอบถามได้บ่อยเท่าที่จำเป็น

อ่านเอกสารประกอบสถิติ เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับสถิติแอพพลิเคชั่นและฐานข้อมูลที่คุณสามารถสอบถามได้ สถิติแอพพลิเคชั่นจัดเก็บไว้ในหน่วยความจำและสามารถสอบถามข้อมูลในราคาถูก สถิติฐานข้อมูลต้องใช้ทรัพยากรมากกว่า และควรสอบถามเท่าที่จำเป็นเท่านั้น

เมื่อใช้โหนด messages คุณจำเป็นต้องตั้งค่าส่วนหัว Content-Type เป็น application/json เพื่อให้ไคลเอ็นต์ WhatsApp Business API แยกวิเคราะห์เนื้อหาข้อความได้อย่างถูกต้อง นอกจากนี้ยังมีส่วนหัว Authorization ที่จำเป็นต้องตั้งค่า และต้องมีโทเค็นการเข้าถึงที่ยังไม่หมดอายุ ดูข้อมูลเกี่ยวกับวิธีรับโทเค็นและเวลาหมดอายุได้ในเอกสารประกอบการเข้าสู่ระบบและการยืนยันตัวตน

ระบบของคุณอาจเริ่มทำงานช้าลงเมื่อพื้นที่เต็ม ซึ่งอาจเกิดจากการมีไฟล์สื่อ ข้อความ และไฟล์บันทึกขนาดใหญ่จำนวนมาก ไฟล์บันทึกมีการหมุนเวียนโดยอัตโนมัติ แต่ถ้าเริ่มมีขนาดใหญ่ขึ้น ก็สามารถลบออกได้อย่างปลอดภัย

ข้อความถูกจัดเก็บไว้ในฐานข้อมูล คุณสามารถลบข้อความออกได้ตามความจำเป็น นอกจากนี้ หากตั้งค่า pass_through เป็น false ในการตั้งค่าแอพพลิเคชั่น ข้อความทั้งหมดก็จะได้รับการบันทึกไว้ในฐานข้อมูลจนกว่าจะถูกลบทิ้งอย่างชัดเจน

ไฟล์สื่อที่ผู้ใช้ส่งให้คุณจะถูกดาวน์โหลดลงในไดรฟ์ข้อมูลสื่อ ธุรกิจต้องตัดสินใจเอาเองว่าจะลบไฟล์ใด แต่โดยทั่วไปแล้ว สามารถลบไฟล์สื่อใดก็ได้อย่างปลอดภัย คุณสามารถใช้ docker inspect your-container-id เพื่อตรวจหาตำแหน่งของโฟล์เดอร์ไดรฟ์ข้อมูลสื่อ

ติดตั้ง MySQL ในเครื่องโดยใช้ Docker โดยทำตามคู่มือ Docker MySQL

ติดตั้ง PostgreSQL ในเครื่องโดยใช้ Docker โดยทำตามคู่มือ Docker PostgreSQL

ในกรณีส่วนใหญ่ คุณควรเรียกใช้ฐานข้อมูลบนเซิร์ฟเวอร์ต่างหากจากคอนเทนเนอร์ Core และ Web เซิร์ฟเวอร์ของฐานข้อมูลควรมีเวลาแฝงจากเครื่องประมวลผลเพียงไม่กี่มิลลิวินาทีเท่านั้น

คุณจะลบสื่อเมื่อใดก็ได้แล้วแต่คุณ

หลังจากที่อัพโหลดสื่อ คุณจะได้รับ ID สื่อ ซึ่งคุณสามารถใช้เพื่อส่งข้อความที่มีองค์ประกอบสื่อที่อัพโหลดนั้นได้ เมื่อส่งข้อความสื่อแล้ว WhatsApp Business API จะเข้ารหัสและอัพโหลดสื่อไปยังเซิร์ฟเวอร์ WhatsApp ซึ่งจะยังคงอยู่ในนั้นเป็นเวลา 14 วัน หลังจากนั้น คุณสามารถตัดสินใจว่าจะลบสื่อนั้นได้โดยระบุ ID สื่อ หรือจะเก็บไว้ใช้งานในภายหลังก็ได้ ในขณะที่เราแนะนำให้เก็บสื่อไว้เป็นเวลา 30 วัน คุณสามารถตัดสินใจนโยบายการเก็บรักษาได้โดยใช้นโยบายของธุรกิจของคุณหรือกรณีการใช้งานของธุรกิจของคุณ

ได้ สามารถใช้ฐานข้อมูลในวิธีอื่นๆ ได้โดยไม่แตะต้องตารางที่เกี่ยวข้องของ WhatsApp

ก่อนอื่น ตรวจสอบการเรียกกลับสำหรับข้อผิดพลาดวิกฤตเพื่อวินิจฉัยปัญหา

หากคุณมองเห็น "ข้อขัดแย้ง: ตรวจพบหลายอินสแตนซ์ที่ใช้หมายเลขเดียวกัน" คุณจำเป็นต้องตรวจสอบคอนเทนเนอร์ สาเหตุที่เป็นไปได้มากที่สุดคือคุณมีคอนเทนเนอร์ Docker หลายตัวที่พยายามเชื่อมต่อกับเซิร์ฟเวอร์ WhatsApp โดยใช้บัญชี WhatsApp เดียวกัน ตรวจสอบให้แน่ใจว่าคุณมีเพียงคอนเทนเนอร์เดียวที่กำลังทำงาน หากคุณมีคอนเทนเนอร์เก่า ให้ปิดการทำงานคอนเทนเนอร์เหล่านั้น แล้วปัญหาจะหายไปเอง

หากคุณต้องการทดสอบโซลูชั่นความพร้อมใช้งานสูงที่ซับซ้อนยิ่งขึ้นของเรา โปรดดูเอกสารประกอบความพร้อมใช้งานสูง

คุณสามารถสร้างรายการที่อนุญาตด้วยชื่อโฮสต์หรือที่อยู่ IP ก็ได้

โปรดดูข้อมูลเพิ่มเติมที่ส่วนชื่อโฮสต์ในเอกสารประกอบข้อกำหนดของเครือข่าย

ได้ WhatsApp อนุญาตให้คุณจัดรูปแบบตัวอักษรที่เลือกภายในข้อความเป็นแบบตัวหนา ตัวเอียง ขีดทับ หรือระยะห่างเท่ากัน

รองรับ เทมเพลตข้อความรองรับอักขระและรูปแบบการส่งข้อความทั้งหมดของ WhatsApp รวมทั้งอีโมจิ ตัวหนา ตัวเอียง ฯลฯ สำหรับอีโมจิ คุณจะต้องใช้อักขระอีโมจิ (คัดลอก/วาง) แทนที่จะใช้ Unicode

อนุญาตให้ใช้หมายเลขโทรฟรีได้ตราบใดที่รวมรหัสประเทศด้วย เหตุผลก็คือ ไม่สามารถระบุหมายเลขโทรฟรีที่ไม่มีรหัสประเทศว่าไม่ซ้ำกันได้ ซึ่งหมายความว่าอาจมีการนำหมายเลขเดียวกันไปใช้สำหรับสองประเทศได้

โปรดทราบด้วยว่ามีความซับซ้อนเพิ่มขึ้นอีกเกี่ยวกับหมายเลขโทรฟรี โดยปกติแล้ว หากคุณโทรด้วยหมายเลขโทรฟรีที่มีรหัสประเทศเมื่อคุณอยู่ภายในประเทศ คุณจะโทรไม่ได้ ซึ่งหมายความว่ามีโอกาสที่ลูกค้าของคุณจากประเทศของคุณจะพยายามโทรด้วยหมายเลขตามที่ปรากฏในรายชื่อผู้ติดต่อของธุรกิจ (รวมรหัสประเทศ) และพวกเขาก็จะไม่สามารถติดต่อคุณได้ หากคุณกังวลในสิ่งนี้ คุณจะต้องแจ้งให้พวกเขาทราบอย่างชัดเจน

อ่านเพิ่มเติมเกี่ยวกับหมายเลขโทรฟรีได้ที่นี่

ไม่ได้ ในเวลาใดก็ตาม คุณสามารถมีไคลเอ็นต์ WhatsApp Business API ได้เพียงอินสแตนซ์เดียวที่กำลังใช้งานสำหรับหมายเลขโทรศัพท์เดียวเท่านั้น ในทันทีที่คุณลงทะเบียนอินสแตนซ์ที่สอง อินสแตนซ์แรกของคุณจะถูกนำออกและใช้งานไม่ได้ เรากำลังทำงานเพื่อค้นหาวิธีแก้ไขที่เหมาะสมที่จะทำให้คุณดำเนินการดังกล่าวได้ เราจะแจ้งให้คุณทราบถึงการอัพเดตใดๆ

WhatsApp พิจารณาว่าการสื่อสารกับผู้ใช้ Business API ที่จัดการตำแหน่งข้อมูล API บนเซิร์ฟเวอร์ที่ตนควบคุมนั้นมีการเข้ารหัสแบบต้นทางถึงปลายทาง เนื่องจากบุคคลภายนอกไม่สามารถเข้าถึงเนื้อหาระหว่างตำแหน่งข้อมูลได้

บางองค์กรอาจเลือกที่จะมอบหมายให้ผู้ให้บริการด้านโซลูชั่นทางธุรกิจจากภายนอกเป็นผู้จัดการตำแหน่งข้อมูล WhatsApp Business API ของตน ในกรณีเหล่านี้ การสื่อสารจะยังคงใช้การเข้ารหัสโปรโตคอลสัญญาณแบบเดียวกันนี้ แต่ WhatsApp จะไม่พิจารณาข้อความเหล่านี้ว่ามีการเข้ารหัสแบบต้นทางถึงปลายทาง เนื่องจากผู้ใช้ WhatsApp Business API ได้เลือกให้บุคคลภายนอกมาจัดการตำแหน่งข้อมูลของตน อนาคตในปี 2021 การพิจารณาในลักษณะนี้จะมีผลกับธุรกิจที่เลือกใช้ API เวอร์ชั่นบนระบบคลาวด์ที่โฮสต์โดย Facebook ด้วยเช่นกัน

นอกจากนี้ หากคุณกำลังใช้ HTTPS เมื่อเรียกใช้ไคลเอ็นต์ WhatsApp Business API ข้อมูลดังกล่าวจะถูกเข้ารหัส SSL (จากไคลเอ็นต์แบ็กเอนด์ของคุณไปยังไคลเอ็นต์ WhatsApp Business API)

โปรดดูรายละเอียดเพิ่มเติมได้ในเอกสารข้อมูลทางเทคนิคเรื่องภาพรวมการเข้ารหัสของ WhatsApp ของเรา

ข้อผิดพลาดนี้เกิดจากจุดบกพร่องในไคลเอ็นต์ iOS เวอร์ชั่นเก่า เราคาดหวังว่าข้อผิดพลาดนี้จะลดลงในระยะยาวเมื่อคนทั่วไปอัพเกรด

ไม่ได้ ไม่สามารถรับประกันได้ว่าข้อความจะมาถึงในลำดับเดียวกันกับที่ส่งมา ถ้าการเรียงลำดับมีความสำคัญต่อกรณีการใช้งานของคุณ ขอแนะนำให้รอการติดต่อการเรียกกลับที่ส่งไปแล้วของข้อความแรก ก่อนที่จะส่งข้อความที่สอง

มีสคริปต์ที่สามารถสั่งทำงานได้จากภายนอกเพื่อล้างบันทึกเก่าของคอนเทนเนอร์:

docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh

สคริปต์ใช้งานได้กับทั้งคอนเทนเนอร์ Webapp และ Coreapp การเรียกใช้สคริปต์จะลบไฟล์บันทึกเก่าออกไปเพื่อให้เหลือเพียง 30 ไฟล์บนคอนเทนเนอร์

หมายเหตุ: โปรดอย่าส่งข้อความเดิมถึงผู้รับคนเดิมซ้ำๆ โดยใช้ WhatsApp Business API

การที่อัตราการนำส่งไม่เป็น 100% อาจมีได้หลายสาเหตุ กรณีหนึ่งที่พบบ่อย ได้แก่ การที่ผู้ใช้มีการเข้าถึงเครือข่ายนานๆ ครั้งหรือไม่ได้ใช้งานเป็นเวลานาน หรือต้องการสร้างประสบการณ์ผู้ใช้ที่มีคุณภาพสูง

ข้อความที่สามารถส่งถึงผู้รับด้วย WhatsApp จะมีอัตราการนำส่งที่สูงมาก อย่างไรก็ตาม มีหลายเหตุผลที่อธิบายว่าเหตุใดจึงอาจไม่สามารถส่งข้อความถึงผู้รับได้ คุณจะมีสิทธิ์เข้าถึงสถานะที่แน่นอนของข้อความด้วยการติดตามการเรียกกลับของคุณ ซึ่งจะแตกต่างจากการส่งข้อความด้วยวิธีอื่นๆ เช่น SMS ที่คุณจะไม่สามารถเข้าถึงสถานะการนำส่งขั้นสุดท้าย และการส่งข้อความซ้ำอาจทำให้เกิดผลลัพธ์ที่แตกต่างออกไป

ข้อความอาจยังคงไม่ได้ส่ง เพราะโทรศัพท์ของผู้ใช้อาจเสียหรือแบตเตอรี่หมด หรือสูญหายและกำลังจะได้เครื่องใหม่ และได้ปิดใช้งาน SIM เอาไว้ เป็นไปได้หรือไม่ที่ลูกค้าธุรกิจะมีข้อผิดพลาดในการเชื่อมต่อกับเครือข่าย นอกจากนี้ ยังเป็นไปได้ที่การเรียกกลับ (Webhooks) ไม่ได้ถูกส่งไป คุณสามารถติดตามสถานการณ์เหล่านี้ได้โดยใช้โหนด health คุณสามารถเปิดการเรียกกลับการรับของเซิร์ฟเวอร์เพื่อให้ทราบว่าข้อความได้ไปถึงคลาวด์ของเซิร์ฟเวอร์ WhatsApp แล้ว

ถ้าและเมื่อผู้ใช้เชื่อมต่อกับเครือข่ายได้อีกครั้งแล้ว ข้อความทั้งหมดที่คุณส่งก็จะถูกส่งให้กับผู้รับ การได้รับมากกว่าหนึ่งข้อความที่มีเนื้อหาเดียวกันจะเป็นประสบการณ์ที่เลวร้ายสำหรับผู้รับ พวกเขาจะมีแนวโน้มสูงขึ้นที่จะบล็อกคุณหรือร้องเรียน คุณจะมีแนวโน้มสูงขึ้นที่จะถูกแบน

หากคุณส่งข้อความและได้รับ ID ข้อความจาก API แสดงว่าคุณได้ทำสิ่งที่สามารถทำได้เพื่อส่งข้อความนี้แล้ว อย่าส่งเนื้อหาเดิมซ้ำถึงผู้รับคนเดิม

หากคุณประสบปัญหาอัตราการนำส่งต่ำติดต่อกันเป็นเวลานาน โปรดส่งบัตรคำร้องขอรับความช่วยเหลือกับ ฝ่ายความช่วยเหลือโดยตรง

ไคลเอ็นต์ API ภายในองค์กรของ WhatsApp Business จำเป็นต้องมีฐานข้อมูลเพื่อจัดเก็บคีย์ต่างๆ ในการถอดรหัสข้อความที่ส่งระหว่างธุรกิจกับลูกค้า ระบบจะเข้ารหัสข้อความทั้งหมดบน WhatsApp ด้วยคีย์ผู้ส่งและคีย์ผู้รับ คีย์ของลูกค้าจะจัดเก็บอยู่บนอุปกรณ์มือถือของลูกค้านั้นๆ ส่วนคีย์ของธุรกิจก็จะอยู่ในฐานข้อมูลของธุรกิจ โปรดเรียนรู้เพิ่มเติมเกี่ยวกับการรักษาความปลอดภัยของ WhatsApp

คุณสามารถเลือกใช้ API ระบบคลาวด์ของ WhatsApp Business แทนได้ ซึ่ง Meta จะโฮสต์ฐานข้อมูลของธุรกิจเอาไว้ โดย API ระบบคลาวด์ช่วยให้คุณสามารถใช้ WhatsApp Business API ได้โดยไม่ต้องเสียค่าใช้จ่ายไปกับการโฮสต์เซิร์ฟเวอร์ของคุณเอง เรียนรู้เพิ่มเติม

ไม่จำเป็น ไคลเอ็นต์ WhatsApp Business API เปิดการเชื่อมต่อ TCP ขาออกไปยังพอร์ต 5222 หรือ 443 บนเซิร์ฟเวอร์ WhatsApp ปริมาณข้อมูลบน TCP เกิดขึ้นบนการเชื่อมต่อที่ใช้งานมานาน โดยปกติ ไฟร์วอลล์จะจำแนกประเภทเป็นการอนุญาต “ปริมาณข้อมูลขาออกและปริมาณข้อมูลที่จัดทำขึ้นแล้ว” แน่นอนว่า แพคเก็ตสามารถย้ายกลับไปกลับมาได้เมื่อจัดทำการเชื่อมต่อแล้ว แต่จุดเริ่มต้นของการเชื่อมต่อนั้นมาจากไคลเอ็นต์ WhatsApp Business API ดังนั้นจึงไม่จำเป็นต้องมีกฎที่อนุญาตการเชื่อมต่อขาเข้า

รองรับ MySQL และ PostgreSQL หากคุณเรียกใช้ Docker ด้วยตัวเอง คุณต้องจัดเตรียมฐานข้อมูล MySQL/PostgreSQL ไว้ให้คอนเทนเนอร์เชื่อมต่อ ตามค่าเริ่มต้น การใช้เทมเพลต AWS จะติดตั้งฐานข้อมูล MySQL

ข้อกำหนดต่างๆ ขึ้นอยู่กับปริมาณข้อมูลและสถานการณ์ของคุณ วิธีการนี้จะทำงานบนเครื่องที่มีการเชื่อมต่ออินเทอร์เน็ตที่เรียกใช้ Docker ตัวอย่างเช่น สามารถทำการทดสอบง่ายๆ ได้บนแล็ปท็อปได้

สำหรับรูปแบบของเซิร์ฟเวอร์ในการใช้งานจริงแบบอินสแตนซ์เดียว เราแนะนำให้ใช้ 250 GB SSD, 16 GB RAM และ 4 core CPU เป็นอย่างน้อย ไม่แนะนำให้ใช้ HDD เนื่องจากความเร็วของ I/O จะอยู่ในสภาวะคอขวดเมื่อมีข้อมูลในปริมาณสูง

สำหรับรูปแบบของเซิร์ฟเวอร์ในการใช้งานจริงแบบมีการเชื่อมต่อหลายจุด เราแนะนำให้ใช้ 50 GB SSD, 4 GB RAM และ 2 core CPU เป็นอย่างน้อยสำหรับคอนเทนเนอร์ Coreapp/Master/Webapp แต่ละตัว

ในกรณีส่วนใหญ่ คุณควรเรียกใช้ฐานข้อมูลบนเซิร์ฟเวอร์ต่างหากจากคอนเทนเนอร์ Core และ Web เซิร์ฟเวอร์ของฐานข้อมูลควรมีเวลาแฝงจากเครื่องประมวลผลเพียงไม่กี่มิลลิวินาทีเท่านั้น

รูปแบบนี้รองรับการส่งข้อความประมาณ 20 ข้อความต่อวินาที

แน่นอน โปรดติดต่อตัวแทน WhatsApp ของคุณและส่งคำขอดังกล่าว

ขณะนี้ยังไม่มีวิธีในการดำเนินการเช่นนั้น หากคุณไม่สามารถจัดการการตอบกลับที่เข้ามาจากผู้ใช้ของคุณบน WhatsApp ขอแนะนำให้ส่งข้อความตอบกลับอัตโนมัติที่จะส่งต่อข้อความไปยังช่องทางที่รองรับที่เหมาะสมของคุณ

ในกรณีผู้บริโภคทั่วไป นี่คือการออกแบบสำหรับกรณีที่ผู้ส่งไม่ได้อยู่ในสมุดรายชื่อของคุณ และคุณไม่เคยส่งข้อความไปยังผู้ส่งรายนี้ ในกรณีองค์กร ธุรกิจควรใช้เทมเพลตข้อความเพื่อสร้าง "ความน่าเชื่อถือ" ในครั้งแรกกับผู้ใช้ เมื่อดำเนินการดังกล่าว ไคลเอ็นต์ WhatsApp Business API จะสามารถอ่านลิงก์และทำให้คลิกได้

ในกรณีผู้บริโภคทั่วไป นี่คือการออกแบบสำหรับกรณีที่ผู้ส่งไม่ได้อยู่ในสมุดรายชื่อของคุณ และคุณไม่เคยส่งข้อความไปยังผู้ส่งรายนี้ ในกรณีองค์กร ธุรกิจควรใช้เทมเพลตข้อความเพื่อสร้าง "ความน่าเชื่อถือ" ในครั้งแรกกับผู้ใช้ เมื่อดำเนินการดังกล่าว ไคลเอ็นต์ WhatsApp Business API จึงจะทำตามการตั้งค่าการดาวน์โหลดอัตโนมัติในแอพ

คุณจะต้องเลือกหมายเลขโทรศัพท์อื่นที่สามารถรับ SMS หรือการโทรด้วยเสียงได้ เพื่อให้เราสามารถส่งรหัสการลงทะเบียนได้ ในอดีต เราเคยอนุญาตรหัสการลงทะเบียนด้วยตนเอง แต่ไม่รองรับอีกต่อไปแล้ว โดยยังคงรองรับหมายเลขโทรศัพท์ที่เคยใช้รหัสการลงทะเบียนด้วยตนเองมาก่อนต่อไปตามที่ต้องการ สำหรับหมายเลขโทรศัพท์ใหม่ใดๆ เราจะส่งรหัสการลงทะเบียนผ่านทาง SMS หรือการโทรด้วยเสียงเท่านั้น

หากคุณต้องการใช้หมายเลข 1800 หรือหมายเลขโทรฟรี โปรดอ่านคู่มือฉบับนี้

ขณะนี้ยังไม่มีวิธีใดในการดูว่ามีผู้ใช้กี่รายหรือรายใดบล็อกธุรกิจของคุณ ตัวบ่งชี้ที่ดีที่สุดคือการรอติดต่อการเรียกกลับสถานะ และถ้าคุณไม่ได้รับสถานะ delivered แสดงว่ามีผู้ใช้บล็อกธุรกิจของคุณ หรือไม่ก็ไม่มีการเชื่อมต่อเครือข่าย ดูรายละเอียดเพิ่มเติมได้ในเอกสารประกอบ Webhook

ถ้ามีผู้ใช้บล็อกธุรกิจของคุณ API ผู้ติดต่อจะยังคงส่งคืนหมายเลขโทรศัพท์นั้นเป็นผู้ใช้ WhatsApp ที่ถูกต้อง อย่างไรก็ตาม เมื่อคุณส่งข้อความ จะไม่มีวันถูกส่งถึง ถ้าเป็นข้อความที่มาจากโฆษณา คุณจะไม่ถูกเรียกเก็บค่าบริการ

ได้ เราสามารถตั้งค่าหมายเลขโทรศัพท์ใหม่หรือเปลี่ยนชื่อที่ตรวจสอบยืนยันแล้วได้ เมื่อคุณพร้อมที่จะเริ่มใช้งานจริง

การอัพโหลดไฟล์มีขนาดสูงสุด 64 MB ซึ่งหมายความว่าขีดจำกัดนี้ใช้กับรูปภาพ เอกสาร หรือวิดีโอใดๆ ที่คุณส่งมากับข้อความ

ไม่ได้ โซลูชั่น WhatsApp Business API กำหนดให้ใช้หมายเลขที่ไม่เคยใช้

เพื่อค้นหาตำแหน่งเมาต์ของไดรฟ์ข้อมูลสื่อ คุณสามารถเรียกใช้คำสั่ง docker ได้

คำขอ

docker volume inspect whatsappMedia

การตอบกลับ

[
    {
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data",
        "Name": "whatsappMedia",
        "Options": {},
        "Scope": "local"
    }
]

จากนั้น เพื่อดูไฟล์สื่อที่เข้ามาทั้งหมด คุณสามารถเรียกใช้คำสั่ง ls พร้อมด้วยพาธไฟล์ Mountpoint ที่ได้รับ:

ls /var/lib/docker/volumes/whatsappMedia/_data/

สำหรับการตั้งค่า AWS ไดรฟ์ข้อมูลสื่อจะถูกเมาต์ที่พาธ /mnt/wa/media บนโฮสต์

ไม่มีกลไกการล้างข้อมูลสำหรับไฟล์สื่อทั้งที่ออกไปหรือเข้ามา คุณสามารถลบไฟล์สื่อได้ด้วยตนเองโดยการค้นหาตำแหน่งไฟล์ในระบบไฟล์ของคุณ

คุณสามารถรีสตาร์ทคอนเทนเนอร์ Docker ได้ด้วยการเรียกใช้โค้ดต่อไปนี้:

คอนเทนเนอร์ Coreapp Docker

docker restart wacore<Current_WABA_Version>

คอนเทนเนอร์ Webapp Docker

docker restart webapp<Current_WABA_Version>

คุณสามารถตรวจสอบว่าคุณกำลังเรียกใช้เวอร์ชั่นใดได้

docker ps

ควร ตามค่าเริ่มต้น ไคลเอ็นต์ WhatsApp Business API พยายามสื่อสารโดยใช้ chatd บนพอร์ต 5222 เพื่อประสบการณ์ที่ดีที่สุด ให้เปิดพอร์ต 5222 สำหรับปริมาณข้อมูลขาออกทั้งหมด ซึ่งไม่ได้ทำให้เกิดปัญหาการรักษาความปลอดภัย เนื่องจากปริมาณข้อมูลนั้นเป็นเพียงขาออกจากศูนย์ข้อมูลของคุณ

หากคุณไม่สามารถเปิดพอร์ต 5222 ได้ ไคลเอ็นต์ WhatsApp Business API จะพยายามใช้พอร์ต 443 หากไฟร์วอลล์หรือพร็อกซียังคงตัดการเชื่อมต่อ โปรดติดต่อทีมงาน WhatsApp โดยส่งคำถามผ่านทางความช่วยเหลือโดยตรง เพื่อแก้ไขจุดบกพร่อง

• The Page must be categorized as "App Page"
• You should have access to the page via a role
• The App Page should not already be linked to an existing app
• The Page must have the same name (or a subset of the name) of the app

• An admin of the campaigns
• A full admin of the page

• คำเชิญเล่นเกมที่ส่งจากแอพไปยังผู้ใช้จะส่งผ่านปลายทาง API /apprequests โดยจะมีการสร้างคำขอในฟีดกิจกรรมเกี่ยวกับเกม แต่จะไม่สร้างการแจ้งเตือนในเว็บไซต์ https://developers.facebook.com/docs/graph-api/reference/app-request#Creating
• คำเชิญเล่นเกมที่ส่งจากผู้ใช้ไปยังผู้ใช้จะส่งผ่านกล่องโต้ตอบของคำขอ โดยจะมีการสร้างคำขอในฟีดกิจกรรมเกี่ยวกับเกม และการแจ้งเตือนในเว็บไซต์ https://developers.facebook.com/docs/games/services/gamerequests
• นอกจากนี้ยังมีการแจ้งเตือนจากแอพไปยังผู้ใช้ ด้วยการส่งผ่านปลายทาง API /notifications โดยจะมีการสร้างการแจ้งเตือน แต่จะไม่สร้างคำขอในฟีดกิจกรรมเกี่ยวกับเกม https://developers.facebook.com/docs/games/services/appnotifications