Întrebarea pe care și-o pun acum marketerii de ecommerce nu mai e doar "cum mă găsește Google", ci "cum mă găsește agentul cumpărătorului". Shopify a mutat discuția un pas mai departe: storefront-urile pot expune acum, prin protocolul UCP, date despre magazinele fizice ale comerciantului, iar un agent poate interoga acele date direct. Anunțul e tehnic, dar miza e comercială. Cine are magazine fizice și le ține curat în platformă începe să fie vizibil într-un strat nou de descoperire. Cine le ignoră rămâne invizibil acolo.

Ce s-a schimbat concret afli din nota oficială a Shopify, pe care o citez ca atribuire: Discover a merchant's retail stores with UCP location search and lookup. Restul analizei e comentariul meu, cu limitele și pașii pe care i-aș pune pe masă într-un cont real.

Ce face de fapt capabilitatea UCP location

Pe scurt, un storefront care are cel puțin o locație retail activă își listează cele două capabilități în profilul de descoperire, la /.well-known/ucp. Dacă agentul negociază aceste capabilități, endpoint-ul MCP al storefront-ului expune două unelte. Prima, search_locations, listează magazinele comerciantului și permite filtrare după nume de magazin sau oraș, după distanță cu un centru explicit și o rază maximă în metri, și după variantă de produs. A doua, lookup_locations, returnează locații după ID, procesând primele 10 ID-uri distincte, cu un mesaj de limită dacă trimiți mai multe.

Fiecare locație vine cu id, nume, adresă și coordonate geografice, atunci când comerciantul le-a setat. Căutarea returnează implicit 10 locații, până la 250 cu paginare setată, iar pagina următoare se ia cu cursorul returnat. Filtrarea pe produs acceptă până la 10 ID-uri de variantă și o locație se califică doar dacă toate variantele sunt disponibile acolo.

Aici e nuanța care contează cel mai mult pentru un operator: disponibilitatea urmează regulile existente de store availability din Shopify. Nu e stoc, nu e promisiune de ridicare, nu e rezervare. Documentația spune explicit că potrivirile pe produs trebuie tratate ca provizorii și confirmate în coș și checkout înainte de a-i spune cumpărătorului că produsul e gata. Merită repetat, pentru că e locul unde apar cele mai multe greșeli de implementare.

Ce nu e acoperit și de ce contează

Shopify nu suportă filtrele de program și facilități, filtrele custom sau relația "serves". Cererile care le includ primesc invalid_input, nu sunt ignorate în tăcere. Nu există nici checkout cu ridicare din locația selectată. Adică un agent poate afla că magazinul X are produsul, dar nu poate finaliza o ridicare prin acest mecanism.

Din perspectivă de marketing, asta e o jumătate de funcție bine gândită. Jumătatea care lipsește e exact partea care închide bugetul: conversia cu ridicare. Nu e un defect, e o limită de versiune. Dar înseamnă că orice strategie construită acum pe "agentul vinde cu ridicare" e o ipoteză, nu o realitate. Și, ca regulă generală de verificare, absența unei funcții într-o documentație de versiune nu dovedește că nu va exista, doar că nu există în această versiune. O verificare incompletă nu e o dovadă de absență.

Mai e un detaliu care merită subliniat: centrul pentru filtrarea pe distanță vine doar din locația pe care cumpărătorul a ales să o partajeze. Shopify nu deduce centrul din context sau din adresa IP. E o decizie corectă de privacy și o informație utilă pentru orice discuție despre date și consimțământ. Nu extrapola de aici la alte platforme.

Ce se schimbă în structura de descoperire

Până acum, un comerciant cu magazine fizice avea două canale paralele: magazinul online, optimizat pentru motoare de căutare și, mai nou, pentru răspunsuri AI, și magazinele fizice, optimizate pentru trafic pietonal și hărți. UCP location lipește cele două. Un agent care ajută un cumpărător să decidă poate întreba "am nevoie de varianta asta, e în magazinele din orașul meu?" și poate primi un răspuns structurat.

Asta schimbă felul în care trebuie să arate datele, nu doar campaniile. Numele magazinului nu mai e un detaliu de back-office, e un câmp de căutare. Orașul nu mai e doar o adresă, e un filtru. Coordonatele geografice nu mai sunt opționale dacă vrei să apari într-o căutare pe rază. Iar cine a lăsat locațiile necompletate sau le-a marcat greșit nu va apărea, pentru simplul motiv că platforma nu anunță capabilitatea dacă nu există cel puțin o locație retail activă, setată pentru vânzare în persoană și activată ca magazin fizic.

Pe partea de SEO și GEO, discuția despre citarea de către LLM-uri capătă o dimensiune nouă. Nu mai e doar despre textul paginii și despre schema markup. E despre date operaționale pe care agentul le poate interoga direct. Despre cum se leagă asta de vizibilitatea în răspunsuri AI am scris separat, în Indexarea nu mai aduce vizite: ce schimba AI Search in 2026, iar mecanica de monetizare a agenților e tratată în ChatGPT Ads: cum funcționează licitația și ce nu spune OpenAI. Ambele se citesc altfel acum, când storefront-ul devine o sursă structurată pentru agenți.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Dacă ai un magazin online pe Shopify și unul sau mai multe puncte fizice, primul pas nu e tehnic, e de igienă a datelor. Intră în setările de locații și verifică ce e activ, ce e marcat ca magazin fizic, ce are adresă completă și coordonate. Un magazin care există în realitate, dar nu e configurat ca locație retail activă, nu va apărea în profilul de descoperire. Și nu vei ști că lipsește, pentru că nu primești notificare, pur și simplu nu ești acolo.

Al doilea pas ține de produse. Dacă filtrarea pe variantă e folosită de agenți, atunci acuratețea disponibilității pe locație devine vizibilă comercial. Nu stocul exact, ci disponibilitatea. Un produs afișat ca disponibil într-un magazin unde de fapt nu mai e pe raft produce o experiență proastă pentru cumpărător și un motiv în plus să nu te mai recomande. Nu pot să-ți spun câte procente pierzi, pentru că nu am datele. Pot să-ți spun că e un risc de încredere, nu doar de vânzare.

Al treilea pas e de poziționare. Dacă ai magazine în orașe diferite, gândește-te la ele ca la niște landing page-uri locale. Numele, orașul, cartierul contează pentru că sunt câmpuri de căutare reale. Un magazin numit generic pierde din start. Unul cu un nume clar și un oraș corect scris câștigă.

Al patrulea pas, mai ales pentru retail-ul cu produse greu de livrat sau cu valoare mare, e un scenariu de test. Nu o promisiune, ci o întrebare de verificat: dacă un agent ajunge la pagina ta și vede un magazin aproape de cumpărător cu produsul disponibil, ce urmează? Momentan, pasul următor e online, nu ridicare. Deci întrebarea ta e dacă experiența online compensează lipsa finalizării cu ridicare. Dacă da, capabilitatea îți aduce trafic relevant. Dacă nu, e doar o informație în plus pe un drum care se rupe la checkout.

Pentru cei care lucrează cu ecommerce pe alte platforme, întrebarea de verificat e simplă: are platforma mea un echivalent? Nu presupune că da. Nu presupune nici că nu. Verifică documentația versiunii curente, pentru că anunțurile de acest tip apar și dispar în funcție de stadiul de lansare. Și, dacă lucrezi cu feeds și personalizare, logica de disponibilitate pe locație seamănă mai mult cu ce se discută în Product feeds personalizate în Klaviyo: ce poți controla și ce nu decât cu o pagină de produs clasică.

Limite, riscuri și ce trebuie confirmat înainte de a te baza pe asta

Sunt câteva lucruri pe care le-aș pune pe listă înainte ca cineva din echipă să construiască o strategie în jurul acestor capabilități. Toate sunt întrebări de verificat, nu concluzii.

Primul: versiunea. Capabilitatea apare din UCP 2026-08-25. Integrările care negociază o versiune anterioară nu sunt afectate și nu vor vedea unelte noi. Dacă lucrezi cu un vendor de agenți, întreabă explicit ce versiune de UCP negociază.

Al doilea: tratarea potrivirilor ca provizorii. Documentația recomandă confirmarea în coș și checkout. Asta înseamnă că orice mesaj care spune "produsul e disponibil în magazin" trebuie tratat cu prudență. Nu afirma disponibilitate pe baza unui singur apel de API.

Al treilea: filtrele neacceptate. Cererile cu program, facilități, filtre custom sau relația "serves" returnează invalid_input. Un agent care trimite astfel de cereri va primi eroare, nu un răspuns parțial. Dacă construiești un client, validează parametrii înainte de a trimite.

Al patrulea: dimensiunea lotului. lookup_locations procesează primele 10 ID-uri distincte. Peste asta primești un mesaj de limită. Dacă lucrezi cu un catalog mare de magazine, planifică paginarea și loturile.

Al cincilea: datele de localizare. Centrul pentru distanță vine doar de la cumpărător. Nu presupune nimic din IP. Orice implementare care încearcă să deducă altfel locația merge împotriva notei oficiale.

Astea sunt lucruri de validat tehnic, nu de dezbătut strategic. Strategic, miza e mai simplă: ai sau nu ai date curate despre punctele tale fizice.

FAQ

Afectează schimbarea magazinele care nu au locații fizice? Nu. Storefront-urile fără locații retail active nu anunță aceste capabilități și nu expun uneltele. Integrările care nu declară capabilitățile sau negociază o versiune anterioară de UCP nu sunt afectate.

Poate un agent să finalizeze o ridicare din magazin prin acest mecanism? Nu în această versiune. Checkout-ul cu ridicare din locația selectată nu e suportat. Agentul poate afla că produsul e disponibil într-un magazin, dar finalizarea cu ridicare nu trece prin acest canal.

Disponibilitatea returnată e un stoc exact? Nu. Urmează regulile de store availability din Shopify și e tratată ca provizorie. Nu e număr de stoc, nu e promisiune de ridicare, nu e rezervare. Recomandarea din documentație e confirmarea în coș și checkout.

AI-ul ajută, dar execuția rămâne umană

Un model poate face triajul rapid: îți citește documentația de versiune, îți listează câmpurile disponibile, îți pune întrebările corecte despre locații și îți schițează pașii de validare. Poate rula o analiză pe datele tale de locații și poate semnala câmpurile lipsă. Dar decizia despre ce înseamnă disponibilitate corectă pentru un produs, despre cum arată un mesaj către cumpărător și despre ce faci când potrivirea e provizorie rămâne a unui om. Un media buyer sau un operator de ecommerce care înțelege fluxul până la checkout ia decizia. Agentul execută.

Noi, la ALLSoft Agency, punem pe masă partea de structurare a datelor, de prioritizare a locațiilor și de legare a acestora cu campaniile și cu raportarea. Nu promitem cifre pe care nu le-am măsurat și nu vindem o capabilitate ca soluție completă atunci când checkout-ul lipsеște. Dacă vrei să verifici ce ai acum în cont și ce ar trebui curățat înainte să te bazezi pe agenți, începe de la ALLSoft Agency.