Google Universal Commerce Protocol-ը 2026-ին առցանց խանութի պատրաստվածության ուղեցույց

AI-ով գնումների փորձառությունը աստիճանաբար անցնում է ապրանքի հայտնաբերումից դեպի գործարք։ Google Universal Commerce Protocol-ը կամ UCP-ն առցանց խանութներին ու AI ծառայություններին տալիս է ապրանքի, զամբյուղի, checkout-ի, վճարման և պատվերի տվյալները փոխանակելու ընդհանուր ձևաչափ։ Բայց խանութի համար սա Google Ads-ում մի կարգավորում միացնելու աշխատանք չէ։ Ներդրումը պահանջում է ճշգրիտ առևտրային տվյալներ, հուսալի checkout և կարգավորված առաքման ու վերադարձի գործընթացներ։

Այս ուղեցույցը պարզաբանում է՝ ինչ է անում UCP-ն, որտեղ է Google-ը հիմա աջակցում այն և ինչպես գնահատել խանութի պատրաստվածությունը։ Նպատակը սեփականատիրոջը, մարքեթինգային և տեխնիկական թիմերին օգնելն է կազմել հիմնավորված պլան՝ մինչև ինտեգրման վրա ռեսուրս ծախսելը։

Ինչ է անում Google Universal Commerce Protocol-ը

Google-ը UCP-ն ներկայացնում է որպես բաց commerce ստանդարտ, որը նախատեսված է Google Search-ի AI Mode-ում և Gemini-ում agentic գործողությունների համար։ Այն ստեղծում է ընդհանուր միջերես, որի միջոցով խանութը կարող է հասանելի դարձնել զամբյուղի ստեղծումը, checkout-ը, վճարման մշակումը, զեղչերը, հաշվի կապումը և պատվերի կարգավիճակի թարմացումները։

Խանութը շարունակում է մնալ Merchant of Record՝ գործարքի պաշտոնական վաճառողը։ Հաճախորդի հարաբերությունը, վաճառքը, առաքումը, աջակցությունն ու հետվաճառքային սպասարկումը մնում են բիզնեսի պատասխանատվության տակ։ UCP-ն չի փոխարինում կատալոգը, checkout-ի կանոնները, պահեստի համակարգը, վճարային ծառայությունը կամ հաճախորդների սպասարկումը։ Այն ստանդարտ ձևով հասանելի է դարձնում այդ համակարգերի ընտրված հնարավորությունները։

Google-ը հիմա փաստաթղթավորում է ինտեգրման երկու հիմնական ուղի․

• Native checkout․ գնորդը գործարքն ավարտում է Google-ի AI միջավայրում, իսկ խանութը պետք է ապահովի checkout-ի, վճարման և պատվերի հետագա կարգավիճակների աշխատանքը։
• Cart handoff․ AI միջավայրը պատրաստում է զամբյուղը և գնորդին տեղափոխում խանութի կայք՝ գնումն ավարտելու համար։

Google-ը նաև հայտարարել է բազմապրանք զամբյուղի, կատալոգից իրական ժամանակի տվյալների և identity linking-ի լրացուցիչ հնարավորությունների մասին։ Դրանք կարող են agent-ին փոխանցել տարբերակների, մնացորդի, գնի, loyalty արտոնությունների և առաքման պայմանների ընթացիկ տվյալները, սակայն հասանելիությունը տարբեր է՝ կախված հարթակից ու ներդրման փուլից։

Նախ ստուգեք հասանելիությունը

UCP-ն դեռ զարգացող ստանդարտ է և հասանելի չէ բոլոր շուկաներում։ Google-ի Merchant Center ինտեգրման ուղեցույցը նշում է, որ onboarding hub-ը փուլերով ներդրվում է ԱՄՆ-ում, իսկ Ավստրալիան ու Կանադան սպասվում են ավելի ուշ։ Վաղ հասանելիության փուլում գործիքը վերաբերում է ԱՄՆ-ում վաճառվող ապրանքներին և ընտրված վաճառողներին։

Hub-ին դեռ հասանելիություն չունեցող բիզնեսները կարող են ուսումնասիրել direct API ուղին, սակայն Google-ի հաստատումը միևնույն է անհրաժեշտ է՝ AI Mode-ում կամ Gemini-ում գործարկվելու համար։ Ուստի մինչև աշխատանքի գնահատումը պետք է հստակեցնել ծրագրի հասանելիությունը, աջակցվող շուկաները, e-commerce հարթակի հնարավորությունները և Google-ի հաստատման ընթացքը։

Եթե Հայաստանում գրանցված ընկերությունը վաճառում է այլ շուկայում, որոշիչ է ոչ միայն գրանցման երկիրը, այլ նաև ապրանքի վաճառքի ու առաքման աշխարհագրությունը։ Թիմը պետք է փաստաթղթավորի թիրախային երկրները, արժույթները, հարկերը, առաքման տարածքը, վերադարձի հասցեները և վճարային հասանելիությունը։

Սկսեք ապրանքային տվյալների որակից

AI checkout-ը չի շտկի թույլ կատալոգը։ Եթե գինը, մնացորդը, տարբերակները, առաքումը կամ վերադարձի պայմանները հակասական են, ավելի արագ միջերեսը պարզապես ավելի շուտ կբացի նույն խնդիրը գնորդի առաջ։

Մինչ API աշխատանքը ստուգեք հետևյալ տվյալները․

Տվյալի ոլորտ	Պատրաստվածության հարց	Կանխվող խնդիր
Ապրանքի նույնականացում	Յուրաքանչյուր վաճառվող ապրանք ունի՞ կայուն ID և canonical URL	Կրկնվող կամ սխալ ապրանք
Տարբերակներ	Չափը, գույնը, նյութը և հասանելիությունը միասնական ներկայացվա՞ծ են	Անհնար համադրություն կամ սպառված տարբերակ
Գին	Համակարգը վերադարձնո՞ւմ է ընթացիկ գինը, արժույթը, զեղչը և պայմանները	Checkout-ում գնի անհամապատասխանություն
Մնացորդ	Պահեստային տվյալը թարմացվո՞ւմ է վաճառքի արագությանը համապատասխան	Սպառված ապրանքի պատվեր
Առաքում	Ուղղությունը, արժեքը, ժամկետը և սահմանափակումները ճի՞շտ են հաշվարկվում	Չկատարվող առաքման խոստում
Վերադարձ	Ժամկետը, վճարները և ապրանքային բացառությունները հստա՞կ են	Հետվաճառքային վեճ

Google-ի ներդրման հերթականությունը սկսվում է Merchant Center-ի պատրաստումից՝ product feed, առաքում և վերադարձ։ Սա պատահական հերթականություն չէ։ Տեխնիկական թիմը չի կարող API-ով ճշգրիտ դարձնել չսահմանված առևտրային քաղաքականությունը։

Նկարագրեք checkout-ի և պատվերի ամբողջ ընթացքը

Native checkout-ի և cart handoff-ի միջև ընտրությունից առաջ քարտեզագրեք պատվերի ընթացքը՝ ապրանքի ընտրությունից մինչև վերադարձված գումար։ Ներառեք բոլոր որոշումները, որոնք կարող են փոխել վերջնական արժեքը կամ որոշել՝ պատվերն ընդունվում է, թե ոչ։

Checkout-ի որոշումներ

Փաստաթղթավորեք՝ ինչպես է խանութը մշակում․

• գնորդի հասցեն և առաքման հասանելիությունը,
• հարկերը, մաքսային վճարները, առաքման գինը և խոստացված ժամկետը,
• կուպոնները, ակցիաները, նվազագույն պատվերը և gift card-երը,
• account login-ը, guest checkout-ը և loyalty արտոնությունները,
• տարիքային, ապրանքային կամ շուկայական սահմանափակումները,
• պահեստի ամրագրումն ու վերջնական գնի վերահաստատումը։

Վճարում և նույնականացում

Google-ի direct integration ուղեցույցը պահանջում է պաշտպանել API endpoint-երը։ Native checkout-ի ուղին ներառում է նաև Google Pay payment handler և պատվերի հետագա կարգավիճակների փոխանցում։ Տեխնիկական պլանում պետք է ներառվեն authentication-ը, request validation-ը, բանալիների կառավարումը, tokenized վճարումները, կրկնվող request-երից պաշտպանությունը, rate limit-երը, logging-ը և անվտանգ error response-երը։

Ներքին commerce ծառայությունները մի բացեք հանրային ինտերնետի համար առանց անվտանգության ստուգման։ Հանրային UCP profile-ը հայտարարում է աջակցվող հնարավորություններն ու endpoint-երը և պետք է ցուցադրի միայն ստանդարտով պահանջվող տվյալները։ Գաղտնաբառերը, private key-երը, ներքին hostname-երը և debugging տվյալները չպետք է հայտնվեն հանրային profile-ում կամ հաճախորդին տեսանելի սխալի հաղորդագրությունում։

Պատվերից հետո

Գործարքը չի ավարտվում հաջող վճարմամբ։ Խանութը պետք է ճշգրիտ փոխանցի կարգավիճակի փոփոխությունները և մշակի չեղարկումը, առաքումը, tracking-ը, վերադարձն ու գումարի վերադարձը։ Սահմանեք՝ որ համակարգն է յուրաքանչյուր կարգավիճակի աղբյուրը և ինչպես են լուծվելու warehouse-ի, payment provider-ի, commerce platform-ի և customer support-ի տվյալների հակասությունները։

Ընտրեք իրատեսական առաջին ինտեգրում

Ամենահարուստ տեխնիկական տարբերակը միշտ չէ, որ լավագույն pilot-ն է։ Սկսեք ամենապարզ ուղուց, որը կարող է վստահելի ապացույց տալ։

Սկզբնական վիճակ	Ավելի հարմար առաջին քայլ	Պատճառ
Կայքի checkout-ը կայուն է, API-ները՝ սահմանափակ	Cart handoff	Վճարումն ու բարդ կանոնները մնում են գործող կայքում
Commerce API-ները հասուն են, fulfilment-ը՝ կանխատեսելի	Native checkout pilot	Հնարավոր է վերահսկվող end-to-end գործարք
Ապրանքի, առաքման կամ վերադարձի տվյալները թերի են	Տվյալների շտկում	Ինտեգրումը կավտոմատացնի հակասական տեղեկությունը
Ծրագրային հասանելիությունը հաստատված չէ	Պատրաստվածության աուդիտ և waitlist	Թիմը չի կառուցի ենթադրվող մեկնարկի ամսաթվի համար

Cart handoff-ի դեպքում էլ կայքը պետք է հուսալի աշխատի։ Փոխանցված զամբյուղը պետք է արագ բացվի mobile-ում, պահպանի ճիշտ ապրանքներն ու քանակները, հստակ ցուցադրի վերջնական արժեքը և չկորցնի referral կամ campaign պարամետրերը։ Boost iT-ի կայքերի և e-commerce լուծումների ծառայությունը ներառում է առցանց խանութների մշակում, performance, analytics integration և conversion աշխատանքներ, որոնք կարող են անհրաժեշտ լինել մինչև agentic checkout-ի փորձարկումը։

Թեստավորման պլանը գրեք մինչև մշակումը

Ընդունման չափանիշները սահմանեք մինչև ինտեգրումը։ Լավ test suite-ը ներառում է սովորական գնումը, սահմանային դեպքերը և ձախողումները։

Ֆունկցիոնալ թեստեր

Ստուգեք ապրանքի ու տարբերակի ընտրությունը, գնի փոփոխությունը, սպառված ապրանքը, առաքման սահմանափակումը, հարկը, ակցիան, վճարման ձախողումը, կրկնվող request-ը, չեղարկումը, մասնակի առաքումը, վերադարձն ու refund-ը։ Եթե Google-ը տրամադրում է sandbox կամ Merchant Center validation գործիք, օգտագործեք այն մինչև production փորձարկումը։

Փորձառության թեստեր

Համեմատեք AI միջավայրում ցուցադրված տվյալը product page-ի և վերջնական պատվերի հետ։ Ապրանքի անունը, պատկերը, տարբերակը, ընդհանուր գինը, առաքման ժամկետը, վաճառողի ինքնությունն ու քաղաքականության ձևակերպումը պետք է համընկնեն։ Գնորդը պետք է հասկանա՝ ով է վաճառողը, ինչ գումար է գանձվելու և որտեղ դիմել աջակցության համար։

Գործառնական թեստեր

Հաստատեք, որ warehouse-ը պատվերը ստանում է մեկ անգամ, payment provider-ը գրանցում է նախատեսված գումարը, հաճախորդը ստանում է ճիշտ ծանուցումը, իսկ support-ը կարողանում է գտնել գործարքը։ Փորձարկեք նաև cancellation-ն ու refund-ը։ Միայն հաջող գնումը չի ապացուցում ամբողջ order lifecycle-ի աշխատանքը։

Բիզնես արժեքը չափեք զգուշորեն

UCP-ի արդյունքը մի գնահատեք միայն click-երով։ Բիզնես արժեքը կախված է ավարտված և չվերադարձված պատվերներից։

Հետևեք առնվազն․

• eligible ապրանքների ցուցադրումներին և սկսված cart կամ checkout գործողություններին,
• checkout completion rate-ին և տեխնիկական սխալների տոկոսին,
• վճարման authorization ու fraud review արդյունքներին,
• cancellation, return և refund տոկոսներին,
• gross margin-ին՝ զեղչից, առաքումից, վճարումից ու support-ից հետո,
• նոր ու վերադարձող հաճախորդներին, երբ դա իրավաչափ և տեխնիկապես հասանելի է,
• մեկ պատվերի հաշվով support հարցումներին ու fulfilment բացառություններին։

Արդյունքները համեմատեք գործող checkout-ի հետ՝ նման ապրանքների, շուկաների և ժամանակահատվածների համար։ Վաղ տվյալները դիտարկեք որպես pilot-ի արդյունք, քանի դեռ հասանելիությունը, Google surface-երը և աջակցվող հնարավորությունները շարունակվում են փոխվել։

30 օրվա պատրաստվածության պլան

1-ից 7-րդ օրեր Հստակեցրեք ծավալն ու հասանելիությունը

Սահմանեք թիրախային շուկան, ապրանքների խումբը, Merchant Center account-ը, commerce platform-ը, payment provider-ը և fulfilment-ի պատասխանատուին։ Հաստատեք՝ Google-ը, commerce platform-ը կամ implementation partner-ը հիմա աջակցո՞ւմ է անհրաժեշտ UCP ուղին։

8-ից 14-րդ օրեր Ստուգեք տվյալներն ու քաղաքականությունները

Ընտրեք տարբեր կատեգորիաներից ու տարբերակներից ապրանքներ։ Համադրեք Merchant Center-ի ու commerce backend-ի գինը, մնացորդը, առաքումը, վերադարձը, հարկը և քաղաքականությունները։ Գրանցեք բոլոր բացառությունները, որոնք դեռ պահանջում են ձեռքով մշակում։

15-ից 21-րդ օրեր Քարտեզագրեք համակարգերն ու ռիսկերը

Նկարագրեք checkout-ի և պատվերի lifecycle-ը՝ authentication, վճարում, status update, cancellation, return, refund, logging և incident ownership։ Որոշեք՝ cart handoff-ը, թե native checkout-ն է ավելի անվտանգ առաջին pilot-ը։

22-ից 30-րդ օրեր Սահմանեք pilot-ը

Ընտրեք սահմանափակ ապրանքային խումբ և շուկա։ Գրեք ֆունկցիոնալ, անվտանգության, փորձառության ու գործառնական ընդունման չափանիշները։ Նախապես սահմանեք չափման baseline-ը, մեկնարկի սահմանափակումները և rollback-ի պայմանը։

Եզրակացություն և հաջորդ քայլ

UCP-ն կարող է կրճատել AI-ով ապրանքի հայտնաբերումից մինչև գնում ճանապարհը, բայց չի փոխհատուցի սխալ ապրանքային տվյալը կամ անկայուն պատվերի գործընթացը։ Ճիշտ առաջին քայլը պատրաստվածության աուդիտն է, որը միավորում է առևտրային քաղաքականությունը, Merchant Center-ի տվյալները, կայքի performance-ը, checkout-ի տրամաբանությունը, անվտանգությունը, fulfilment-ը և չափումը։

Ձեր խանութի անհրաժեշտ աշխատանքը գնահատելու համար պատվիրեք e-commerce պատրաստվածության աուդիտ։ Boost iT-ը կարող է ստուգել գործող ապրանքային ու checkout ընթացքը, առանձնացնել տվյալների և տեխնիկական բացերը և սահմանել փուլային աշխատանք՝ առանց ենթադրելու, որ ծրագրային հասանելիությունը կամ կոնկրետ հնարավորությունն արդեն բաց է։