خط‌مشی‌های یکپارچه‌سازی پایان به انتها رزرواسیون

خط‌مشی‌های یکپارچه‌سازی زیر برای ادغام سرتاسر رزرواسیون اعمال می‌شود.

سیاست های پایان به انتها

لطفاً قبل از شروع یکپارچگی، معیارهای واجد شرایط بودن ادغام زیر را مطالعه کنید. شرکا باید شرایط و خط مشی های زیر را رعایت کنند تا واجد شرایط ادغام با ادغام سرتاسری رزرواسیون مرکز اقدامات باشند.

در حالی که الزامات زیر اجزای ضروری واجد شرایط بودن برای برنامه Action Center هستند، رعایت شرایط تضمین نمی‌کند که شریک واجد شرایط ادغام یا شروع به فعالیت با مرکز اقدامات باشد.

عدم رعایت الزامات و خط‌مشی‌ها ممکن است منجر به ادغام، تاجر یا خدمات به حالت تعلیق یا حذف از پلتفرم شود.

الزامات پلتفرم عمومی

1. شرکا باید همه داده‌های تاجر و کاربر، از جمله هرگونه اطلاعات شناسایی شخصی، را به روشی مطابق با مقررات حفاظت از داده‌های عمومی (GDPR) و سایر قوانین مربوط به حریم خصوصی جمع‌آوری و مدیریت کنند.
2. شرکا باید مجاز به رزرو از طرف تاجران خود باشند.

3. شرکا باید مستقیماً به موقعیت‌های دسترسی/زمان تاجران دسترسی داشته باشند (یعنی شرکا باید بتوانند در کمتر از ۱ ثانیه به درخواست‌های در دسترس بودن از طرف Google پاسخ دهند).

   • مورد خاص : ما از رزروهایی پشتیبانی می‌کنیم که نیاز به تأیید ناهمزمان تاجر دارند، اما جریان رزرو باید بر اساس یک بازه زمانی موجود باشد. شرکا باید در دسترس بودن زمان واقعی، یعنی از طریق سیستم های آنلاین تاجر، حتی اگر برای نهایی کردن رزرو نیاز به تایید تاجر داشته باشند، در دسترس باشند.

4. شرکا باید موجودی جامعی برای بازرگانان خود داشته باشند. تجار با موجودی جزئی یا مشکل دار ممکن است واجد شرایط نباشند.

5. شرکا باید 30 روز یا بیشتر از تاجران در دسترس باشند.

6. شرکا باید از لغو آنلاین رزرو پشتیبانی کنند.

7. شرکایی که به پیش پرداخت نیاز دارند باید از خط مشی پرداخت Action Center پیروی کنند، پردازشگرهای پرداخت آنها باید در لیست پشتیبانی شده زیر باشند و پرداخت های رمزگذاری شده را بپذیرند.

8. شرکا باید بتوانند داده های دقیق قیمت گذاری را برای هزینه خدمات ارائه دهند و از خط مشی قیمت گذاری Action Center پیروی کنند.

9. شرکا باید بتوانند شرایط ادغام سرتاسری رزرواسیون فنی Action Center را برآورده کنند.

10. شرکا باید الزامات واجد شرایط بودن خدمات و بازرگانان Action Center را رعایت کنند.

11. شرکا باید از دستورالعمل‌های پشتیبانی و نگهداری Action Center پیروی کنند.

12. شرکا باید نرخ خطای قابل قبولی را که در دستورالعمل های راه اندازی و نظارت تعریف شده است حفظ کنند.

13. همه رزروها باید به طور خودکار در زمان واقعی تأیید شوند، به استثنای رزروهایی که با یکپارچه سازی همگام سازی شده اند. رزروهای انجام شده از طریق یکپارچه سازی async باید از دستورالعمل Async پیروی کنند.

14. شرکا باید از خط‌مشی‌های عمودی یا ویژگی‌های خاص مرکز اقدامات ( پیشنهادات ، پرداخت ، خدمات آنلاین و غذاخوری ) پیروی کنند.

15. شریک باید محتوای با کیفیت استاندارد را برای نام تاجر، آدرس، نام خدمات و توضیحات بر اساس دستورالعمل حفظ کند.

ترجمه: صفحه_نوع انسان: lcat

خط مشی ارائه می دهد

صفحه فرود (صفحه تلفن همراه و برنامه)

• همه پیشنهادهای به اشتراک گذاشته شده با Google برای هر رستورانی باید با تمام اطلاعات مرتبط حداقل در صفحه فرود تلفن همراه قابل مشاهده باشد.
  • ارزش پیشنهاد و متن توضیحات باید مستقیماً در صفحه فرود قابل مشاهده باشد.
  • صفحات فرود باید به طور واضح و جامع شرایط واجد شرایط بودن هر پیشنهاد را مشخص کنند. این شامل محدودیت‌های مربوط به بخش‌های کاربر، روش‌های پرداخت، روزها یا زمان‌های خاص، حداقل مقدار هزینه و تعداد دفعاتی است که می‌توان از پیشنهاد استفاده کرد.
  • همه محدودیت‌های پیشنهادی دیگر (مثلاً: شرایط واجد شرایط بودن، دستورالعمل بازخرید، شرایط ...) باید در صفحه مقصد قابل مشاهده باشند یا با 1 کلیک روی صفحه مقصد قابل دسترسی باشند (مثلاً: گفتگوی بازشو).
• برای همه پیشنهادها به جز پیشنهادات OFFER_MODE_WALK_IN ، جریان اقدام مرتبط با پیشنهاد (مثلاً رزرو میز) باید به کاربر اجازه دهد پیشنهاد(های) مربوط به انتخاب خود را انتخاب کند (مثلاً برای رزرو، پیشنهادهای قابل اعمال برای بازه زمانی و اندازه مهمانی انتخاب شده)
• دستورالعمل‌ها و روش‌های بازخرید باید به وضوح بیان شده و قابل اجرا باشد (مثلاً: اگر بازخرید پیشنهاد مستلزم پرداخت صورت‌حساب در سیستم شریک در هنگام تسویه‌حساب است، دستورالعمل پرداخت در سیستم باید ذکر شود و کاربر باید بتواند قبض را در تاریخ پرداخت کند. سیستم شریک در پرداخت).
• هنگامی که URL پیشنهاد به برنامه تلفن همراه نصب شده شریک هدایت می شود، صفحه مقصد برنامه باید همه الزامات ذکر شده در این بخش را برای صفحات فرود پیشنهاد برآورده کند.
  • پس از بازگشت (به عنوان مثال، استفاده از دکمه برگشت، پیمایش اشاره ای) بلافاصله پس از تعامل با یک پیشنهاد در یک تجربه Google، کاربران باید به تجربه اصلی Google برگردند.

داده ها و قالب ها را ارائه می دهد

• شرکا باید به الزامات فنی مشخص شده و فرمت های داده مندرج در اسناد مربوطه پایبند باشند. عدم رعایت این الزامات می تواند منجر به خطا یا تاخیر در پردازش خوراک شود.
• این پیشنهاد باید به طور کلی برای هر کاربر در دسترس باشد. پیشنهادها ممکن است به اشتراک پولی نیاز داشته باشند، تا زمانی که همه بتوانند مشترک شوند.
• تمام ابرداده های ارائه شده باید در زمان آپلود فید دقیق و به روز باشند (حداقل باید به صورت روزانه آپلود شوند). پیشنهادات لیست شده باید فعال و در دسترس کاربران باشد، فوراً یا از قبل همانطور که در ValidityPeriod نشان داده شده است. پیشنهادهای قدیمی، فروخته شده یا منقضی شده باید از فید حذف شوند.
• شرکا باید از قالب‌های پیشنهادی ثابت در سراسر پلتفرم‌ها استفاده کنند. اختلاف بین جزئیات پیشنهاد در فید و موارد نمایش داده شده در برنامه یا وب سایت شریک ممنوع است.
• شرکا باید جزئیات پیشنهادی واضح و مختصر را در قسمت offer_display_text ارائه کنند که دقیقاً ارزش پیشنهاد و هرگونه محدودیت را منعکس کند.
• شرکا باید به وضوح دسته پیشنهاد (پیشنهاد پایه یا پیشنهاد افزودنی) و حالت‌های پیشنهاد قابل اجرا ( OFFER_MODE_FREE_RESERVATION ، OFFER_MODE_PAID_RESERVATION ، OFFER_MODE_WALK_IN ) را برای هر پیشنهاد مشخص کنند.
• شرکا باید از نگاشت دقیق انواع ابزار پرداخت برای هر پیشنهاد اطمینان حاصل کنند.

خط مشی و الزامات منوی غذا

لطفاً قبل از شروع یکپارچگی، معیارهای واجد شرایط بودن ادغام زیر را مطالعه کنید. شرکا باید به سیاست های منوی غذا پایبند باشند و شرایط زیر را رعایت کنند تا واجد شرایط ادغام شوند. لطفاً توجه داشته باشید که Google این حق را برای خود محفوظ می‌دارد که داده‌های منو و غذا را به روش‌هایی که برای کاربران مفید باشد نشان دهد.

عدم رعایت الزامات و خط‌مشی‌ها ممکن است منجر به ادغام، تعلیق یا حذف تاجران یا خدمات از پلتفرم شود.

سیاست و الزامات

1. شرکا نباید اطلاعات ممنوعه ( به جزئیات را ببینید) در فید منو مانند زبان ناپسند، تصاویر ممنوع، اطلاعات شناسایی شخصی (PII) یا محتوای تولید شده توسط کاربر ارسال کنند.
2. شرکا نباید از فید منو برای به اشتراک گذاشتن موارد غیر منو مانند خدمات (مثلاً حاشیه، کدهای تبلیغاتی و غیره) استفاده کنند.
3. شرکا موظفند تمام اطلاعات مورد نیاز را در مشخصات منوی Reservations E2E یا مشخصات منوی تغییر مسیر سفارش (حداکثر اندازه فایل 2 مگابایت) ارائه دهند. الزامات فنی در مشخصات منوی رزرواسیون E2E یا مشخصات منوی تغییر مسیر سفارش با علامت‌گذاری فیلدها به‌عنوان اختیاری/الزامی بررسی می‌شوند.
4. شرکا فقط باید آیتم های منوی موجود برای مکان های رستوران مربوطه را ارائه دهند.
5. شرکا باید یک منوی کامل برای هر مکان ارسال کنند. تاجرانی که منوهای ناقص دارند ممکن است واجد شرایط نمایش نباشند.
6. شرکا و بازرگانان موظفند از دقیق بودن منوها اطمینان حاصل کنند و باید به‌روزرسانی‌های روزانه را ارائه دهند.
7. عکس‌های آیتم‌های منو باید دارای نور کافی باشند، دارای یک آیتم منو در فوکوس باشند، نباید شامل افراد یا سایر تصاویر غیرغذایی باشند و باید با مشخصات تصویر مطابقت داشته باشند (به دستورالعمل‌های عکس مراجعه کنید).
8. قیمت‌ها باید به ازای هر آیتم منو، بدون راهنمایی، مالیات یا هزینه نشان داده شوند. مگر اینکه توسط قوانین و مقررات محلی الزامی باشد. شرکا باید به صراحت ارز محلی را ارائه دهند.
9. منوهای تخصصی پشتیبانی می شوند و زمانی که دیگر در دسترس نیستند باید حذف شوند (مثلاً: تخفیف ویژه، فصلی، ویژه زمان محدود).

سیاست های تغییر مسیر پرداخت ها

این بخش خط مشی های کلی و ویژگی های خاص را برای اجرای تغییر مسیر پرداخت ها در Action Center مشخص می کند. برای اطمینان از تجربه یکنواخت برای مصرف‌کنندگان، بازرگانان و شرکای استفاده‌کننده از Action Center، موجودی‌هایی که نیاز به پرداخت دارند باید از دستورالعمل‌های مناسب پیروی کنند. عدم رعایت این سیاست ها منجر به تعلیق ادغام شما می شود.

ژنرال

این خط‌مشی‌ها برای همه تراکنش‌های پرداخت و موجودی موجود در Reserve with Google اعمال می‌شود:

1. مبلغی که از کاربر دریافت می‌شود باید همان مقداری باشد که در شرایط تراکنش مشخص شده است، مطابق با قوانین قابل اجرا.
2. شرکا مسئول به‌روزرسانی در دسترس بودن با استفاده از به‌روزرسانی بی‌درنگ (RTU) یا اطمینان از اینکه تماس‌های BatchAvailabilityLookup منعکس‌کننده در دسترس بودن اسلات دقیق هستند.
3. برای تراکنش های مورد نیاز با کارت اعتباری نباید هیچ هزینه ای از کاربر دریافت شود.
4. همانطور که با استفاده از فرآیند پیکربندی پرداخت ما بیان شده است، هیچ هزینه ای نباید برای کاربری که صراحتاً با آن موافقت نشده است در هنگام تسویه حساب دریافت کنید.
   • شرایط پرداخت موجود در صفحه «شرایط خدمات» پیوند شده، این شرط را برآورده نمی کند.
5. برای خدمات حضوری ¹ ، تمام پرداخت ها باید در زمان رزرو یا فقط حضوری انجام شود. درخواست پرداخت از هر طریق دیگری اکیدا ممنوع است.
6. تراکنش باید به واحد پول محل تاجر نمایش و شارژ شود (ارز با استفاده از فرآیند پیکربندی پرداخت ها مشخص می شود). هیچ تبدیل ارز ممکن است انجام شود.

^{1. کلیه خدمات حضوری، بدون احتساب خدمات ارائه شده از طریق این ادغام مانند پیش پرداخت و سپرده}

الزامات صفحه فرود

1. صفحه فرود باید شروع جریان رزرو باشد و اندازه مهمانی و فاصله زمانی از پیش انتخاب شده باشد.
2. صفحه فرود نباید صفحه اصلی ارائه دهنده پلت فرم یا هر صفحه دیگری باشد.
3. اولین مرحله از صفحه فرود پیوند عمیق نمی‌تواند یک دیوار پرداخت باشد، جایی که کاربران نمی‌توانند ابرداده‌های مربوط به رزرو خود را مشاهده کنند، مگر اینکه جزئیات پرداخت را ارائه کنند.
4. اولین مرحله از صفحه فرود پیوند عمیق نمی تواند یک صفحه ورود باشد. جریان رزرو باید شامل گزینه پرداخت مهمان باشد، جایی که کاربران می توانند بدون ورود به سیستم یا ایجاد حساب کاربری، رزرو را تکمیل کنند.
5. پیوند و صفحه فرود نمی تواند نیاز به دانلود یک برنامه توسط کاربر برای تکمیل جریان رزرو داشته باشد.