أفضل الممارسات
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تنطبق أفضل الممارسات التالية على عملية دمج "إعلانات الخدمات المحلّية" الشاملة
في "مركز الإجراءات"، ويمكن الاستفادة منها لتجنّب مشاكل الاستخدام والأداء.
قد تؤدي جودة البيانات المنخفضة إلى إزالة المستودع الإعلاني.
الخلاصات
خادم الحجز
لتحسين عملية دمج واجهة برمجة التطبيقات Maps Booking API، اتّبِع الخطوات التالية:
- استخدِم دائمًا الطوابع الزمنية لنظام التشغيل يونكس بتنسيق التوقيت العالمي المنسق.
- إنشاء معرّف حجز فريد عند طلب حجز جديد في واجهة برمجة التطبيقات
CreateBooking
تحديثات في الوقت الفعلي
لضمان تقديم أفضل تجربة للمستخدم أثناء عملية الحجز، يُرجى اتّباع الخطوات التالية:
- لتنفيذ عادي، استخدِم واجهة برمجة التطبيقات BookingNotifications API لتغيير وقت البدء
ومدّة الموعد وحالة الحجز، مثل الإلغاء أو عدم الحضور.
- عند إجراء أي تغيير على الحجز في "مركز الإجراءات" من جانبك، أرسِل دائمًا تعديلات الحجز
في الوقت الفعلي من النظام باستخدام واجهة برمجة التطبيقات BookingNotification API في الوقت الفعلي كي لا تصبح البيانات
قديمة من جانب "مركز الإجراءات". على سبيل المثال، يمكنك إلغاء حجز أو إعادة جدولته أو تعديله
من نظامك في
مركز الإجراءات.
- عند إجراء تعديل على حجز من
UpdateBookingRequest،
تأكَّد من أنّ قيمة UpdateBookingResponse تحتوي على
معرّف الحجز وأنّ جميع الحقول المعدَّلة يجب أن تعرض القيمة الجديدة.
-
في حال تنفيذ الإصدار العلني من ميزة "الإعلانات للمنتجات داخل المتجر"
- يمكنك تعديل مدى التوفّر فقط في دفعات تضمّ من 100 إلى 1,000 خانة لكل طلب بيانات من واجهة برمجة التطبيقات.
-
استخدِم حقول
*Restrict (مثل startTimeRestrict) لتضييق نطاق
تعديل المحتوى، وخفض حجم الحمولة، وتجنُّب إعادة إرسال الكثير من البيانات التي لم يتم تغييرها.
-
إذا كنت تُنشئ عدة سلاسل محادثات، نفِّذ
وقت انتظار متزايد
لمنع أخطاء الحدّ من السرعة. في حال عدم تنفيذ مهلة انتظار تصاعدية بشكل صحيح، قد
تظهر لك رسالة خطأ
RESOURCE_EXHAUSTED
خطأ في الحصة.
يمكنك إعادة محاولة الانتظار التزايدي للتعامل مع هذه الأخطاء، ولكن إذا لاحظت أنّ
الخادم يصل غالبًا إلى الحصص عند تشغيل ReplaceServiceAvailability، عليك ضبط
الخادم على
الاستبدال المجمّع لضمان التوفّر.
يمنع هذا الحلّ أخطاء الحصة لأنّه يقلل من عدد طلبات البيانات من واجهة برمجة التطبيقات التي يجب أن يُجريها خادمك.
- اضبط حدود وقت الاستجابة لطلبات البيانات من واجهة برمجة التطبيقات على أقل من ثانية واحدة. تأكَّد
من أنّ خادمك يمكنه معالجة خمسة طلبات بحث في الثانية (QPS) بوقت استجابة أقل من ثانية
في% 95 من الوقت على الأقل.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eMaintain high data quality in feeds to prevent inventory removal and ensure accurate service representation.\u003c/p\u003e\n"],["\u003cp\u003eUtilize the BookingNotifications API for real-time updates to booking details like start times, duration, and status changes.\u003c/p\u003e\n"],["\u003cp\u003eOptimize the Booking Server integration by using UTC timestamps and generating unique booking IDs for new bookings.\u003c/p\u003e\n"],["\u003cp\u003eWhen implementing Inventory Real-Time Updates, use batch updates, restrict edit targets, and incorporate exponential backoff to avoid errors.\u003c/p\u003e\n"],["\u003cp\u003eEnsure API response times are under one second and the server can handle at least five queries per second with minimal latency.\u003c/p\u003e\n"]]],["Integrate feeds with specific `Category` values and set service durations in `duration_sec`, avoiding zero values. Use `gzip` for feed compression. In the booking server, employ UNIX timestamps, generate unique booking IDs, and ensure real-time updates via the BookingNotifications API for any booking changes. Update availability in batches, use `Restrict` fields, and manage threads with exponential backoff to avoid quota errors. Maintain API response times under one second, and five QPS at sub-second latency.\n"],null,["# Best practices\n\nThe following best practices apply to the Actions Center Local Services Ads End-to-End\nintegration and can be leveraged to avoid usability and performance issues.\nLow data quality might lead to inventory takedown.\n\nFeeds\n-----\n\n- If a service doesn't have a set length, set `duration_sec` in the Availability feed to one of the following:\n - The number of seconds it takes to perform the service in a reasonable manner.\n - The average number of seconds required to complete the service.\n\n | **Note:** If a length of `0` is submitted in the feed, our system counts that availability slot as invalid and doesn't show it on the Actions Center.\n- Make the `Category` field input in the merchant's feed is specific. For example, a restaurant might submit a specific type, such as French or Japanese. For details, see [Place types](/maps/documentation/places/web-service/supported_types) for potential category values.\n- Set merchant-specific terms of service in the `Terms` field\n of the Merchant feed so that the following note appears below the\n **Book** button:\n\n \u003cbr /\u003e\n\n \u003e By continuing, you agree to \u003cvar translate=\"no\"\u003e<merchant>\u003c/var\u003e's Terms of Service.\n In this case, \"Terms of Service\" is a link that, when clicked, displays the text set in the *terms* text field.\n\n \u003cbr /\u003e\n\n- [Compress your feeds using `gzip`](/actions-center/verticals/local-services/e2e/reference/tutorials/compression)\n\nBooking Server\n--------------\n\nTo optimize your integration of the Maps Booking API, do the following:\n\n- Always use UNIX timestamps in UTC format.\n- Generate a unique booking ID when a new booking in the [`CreateBooking`](/actions-center/verticals/local-services/e2e/reference/booking-server-api-rest/e2e-methods/createbooking-method) API is called.\n\nReal-time updates\n-----------------\n\nTo ensure the best user experience during the booking process, do the\nfollowing:\n\n- For a standard implementation, use the BookingNotifications API to change the start time, duration, and booking state, such as cancellation or no-show, of an appointment.\n- Upon any change on the Actions Center booking from your side, always send real-time booking updates from the system with the BookingNotification API in real-time so that the data doesn't become stale on the Actions Center side. For example, you can cancel, reschedule, or update a booking from your system in the Actions Center.\n- For every booking update from `UpdateBookingRequest`, make sure that the `UpdateBookingResponse` value contains the booking ID and that **all** updated fields must reflect the new value.\n- If [Inventory RTU](/actions-center/verticals/local-services/e2e/integration-steps/real-time-api-updates) are implemented\n - Only update availability in batches of 100-1000 slots per API call.\n - Use `*Restrict` (such as `startTimeRestrict`) fields to narrow the edit target, reduce payload size and avoid re-sending too much unchanged data.\n - If you spin off several threads, implement an [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff) to prevent throttle errors. If you don't implement an exponential backoff correctly, you might get a `RESOURCE_EXHAUSTED` [quota error](/actions-center/verticals/local-services/e2e/integration-steps/real-time-api-updates#api-quotas). You can retry the exponential backoff to handle them, but, if you find that your server often reaches quotas when you run `ReplaceServiceAvailability`, configure your server to [batch replace for availability](/maps-booking/reference/maps-booking-api/rest/v1alpha/inventory.partners.availability/replace). This solution prevents quota errors because it reduces the number of API calls your serve has to make.\n- Set your API call response time limits to less than one second. Ensure that your server can handle five queries per second (QPS) with sub-second latency at least 95% of the time."]]
