Shop SDK lead capture acceptă acum Rich Authorization Requests: ceri câmpurile de profil de care ai nevoie, marchezi ce e obligatoriu și ce e opțional, iar integrarea veche funcționează neschimbată. E opt-in, nu o migrare forțată. Pentru marketeri, avantajul real nu e colectarea, ci calitatea datelor și logica de follow-up.

Ce s-a schimbat, concret

Pe 28.10.2026, Shopify a publicat în changelog o modificare tehnică pentru aplicațiile care folosesc Shop SDK lead capture. Lead capture acceptă un atribut nou, authorizationDetails, care primește un array JSON serializat. În el listezi câmpurile pe care le vrei și le marchezi individual ca obligatorii sau opționale. Câmpurile disponibile prin RAR sunt: prenume, nume, număr de telefon și data nașterii.

Diferența față de mecanismul vechi e importantă și merită subliniată. Scopurile OAuth existente, shop_app:user:profile și shop_app:user:phone, îți permit să citești nume și telefoane care există deja în profilul Shop al utilizatorului. Nu îl determină însă pe utilizator să completeze ce lipsește. Cu RAR, înainte de autorizare, Shop îi cere explicit câmpurile pe care nu le-a partajat cu aplicația ta. Cele obligatorii trebuie completate, cele opționale pot fi sărite.

Trei detalii operaționale contează pentru cine implementează:

Mai există un detaliu care privește direct calitatea bazei de clienți: un număr de telefon autorizat și returnat de Shop poate înlocui un număr diferit aflat pe fișa clientului din magazin. Numele existente nu sunt înlocuite. Iar datele cerute nu vin în evenimentul din browser: primești tokenul, îl trimiți la server, îl schimbi prin fetchTokensForUser pe Shop Partners API și citești câmpurile autorizate, tratând null pentru ce nu a fost acordat sau nu are valoare.

De ce asta e o știre de marketing, nu doar de dezvoltare

La prima citire pare documentație pentru dezvoltatori. În practică, atinge exact zona care decide performanța pe e-commerce: calitatea datelor de contact și predictibilitatea fluxului de lead-uri.

Gândește-te la câte campanii de email sau SMS mor din cauza unui câmp lipsă. Ai numele, dar nu ai telefonul. Ai telefonul, dar nu ai data nașterii pentru segmentarea de aniversări. Ai toate câmpurile, dar jumătate sunt completate greșit pentru că formularul tău clasic e lung și oamenii îl abandonează la al treilea input.

RAR mută colectarea în momentul autorizării, în interfața Shop, unde utilizatorul are deja contextul. Nu mai e un formular separat pe care trebuie să îl vinzi; e o cerere clară, cu câmpuri marcate obligatoriu sau opțional. Pentru un magazin care rulează lead capture ca sursă de dobândire, asta schimbă rata de completare a profilului, cel puțin în teorie. Și aici trebuie făcută prima distincție serioasă.

Constatare măsurată vs. ipoteză

Materialul sursă confirmă mecanismul: ce câmpuri poți cere, cum se marchează obligatoriu/opțional, ce se întâmplă la refuz, cum se citesc datele de pe server, ce eroare apare la JSON malformat (invalid_authorization_details în onError).

Materialul sursă nu confirmă nicio cifră de conversie, nicio creștere de rată de completare, niciun impact pe venit. Orice articol care îți promite „+30% lead-uri calificate” pe baza acestui changelog inventează. Nu avem studiu, nu avem benchmark publicat, nu avem test.

Deci ce putem spune cu certitudine și ce rămâne de verificat în contul tău:

Cert: mecanismul există, e opt-in, cere server, returnează token, datele se citesc prin API. Ipoteză: mai mulți utilizatori completează câmpurile cerute în fluxul Shop decât într-un formular propriu, pentru că fricțiunea e mai mică și contextul e de încredere. Ipoteză: marcarea agresivă a câmpurilor ca obligatorii scade rata de autorizare, pentru că utilizatorul are mai mult de completat.

A doua ipoteză e cea care ar trebui să te țină treaz. RAR îți dă control, dar controlul nu e gratis: fiecare câmp obligatoriu în plus e o barieră în plus înainte de butonul de autorizare. Iar dacă utilizatorul refuză, nu primești token și, practic, pierzi lead-ul din acel flux.

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

Dacă ai un magazin pe Shopify și folosești (sau vrei să folosești) lead capture prin Shop SDK, ai trei decizii de luat, în ordinea asta.

1. Ce îți trebuie cu adevărat în CRM. Nu cere tot ce poți cere. Întreabă-te la ce folosește fiecare câmp în următoarele 90 de zile. Telefonul pentru SMS-uri de coș abandonat? Atunci e obligatoriu. Data nașterii pentru campanie de aniversare? Dacă nu ai campania construită, lasă-l opțional sau scoate-l. Un câmp colectat și nefolosit e doar cost de fricțiune.

2. Ce faci când lipsește tokenul. Aici e capcana de operare. Dacă echipa ta tratează absența shopConsentToken ca pe un bug și începe să „repare” fluxul, vei pierde timp pe dezvoltare fără rost. Refuzul e un rezultat normal, documentat. Fluxul tău trebuie să aibă un fallback: fie ceri datele altfel, fie continui fără ele, fie marchezi lead-ul ca incomplet pentru un follow-up ulterior. Ce nu trebuie să faci e să tratezi refuzul ca pe o eroare de sistem.

3. Ce faci cu telefonul care se suprascrie. Un număr autorizat de Shop poate înlocui numărul existent pe fișa clientului. Dacă ai automatizări care depind de numărul vechi (de exemplu, un flow construit pe un număr validat manual), acea suprascriere e un eveniment pe care trebuie să îl tratezi explicit. Nu e o problemă tehnică, e o problemă de guvernanță a datelor. Ia decizia înainte de lansare: accepți suprascrierea ca sursă de adevăr sau păstrezi ambele valori cu marcaj de sursă?

Pentru un marketer român, contextul local adaugă un strat. Baza de date construită prin formulare clasice are de obicei câmpuri obligatorii puține, pentru că rata de abandon doare. RAR îți permite să separi fin: nume și telefon obligatorii, restul opțional. Asta e o schimbare de design de flux, nu doar de cod. Merită discutată cu cineva care se uită la date, nu doar la specificație.

Testele pe care le ceri înainte de lansare

Documentația sursă listează patru scenarii de testat înainte de a livra. Le preiau pentru că sunt exact lista de verificare pe care ai vrea să o vezi înainte ca echipa să dea drumul la flux:

  1. Autorizare completă. Utilizatorul completează tot și autorizează. Verifici că tokenul ajunge la server și că datele se citesc corect.
  2. Câmp opțional sărit. Utilizatorul sare peste un câmp marcat opțional. Verifici că tratezi null fără să rupi fluxul.
  3. Autorizare refuzată. Utilizatorul refuză. Verifici că absența tokenului e tratată ca outcome normal.
  4. JSON malformat. authorizationDetails invalid returnează invalid_authorization_details în onError. Verifici că eroarea e prinsă și logată, nu aruncată în fața utilizatorului.

Un audit incomplet nu dovedește că o funcție lipsește. Dacă nu ai testat scenariul 3, nu poți spune că fluxul tău e rupt; poți spune doar că nu ai verificat. Diferența pare academică, dar în practică decide dacă arunci o zi de dezvoltare pe o problemă inexistentă sau o lași netestată și o descoperi în producție.

Dacă vrei să vezi cum arată o discuție similară despre date și control în alt context, avem o analiză pe Copilot, date sintetice și încredere și una despre ce faci când clientul cumpără prin AI fără să-ți calce site-ul. Ambele ating aceeași întrebare de fond: cine deține datele și cine decide ce se întâmplă cu ele.

Limitele poveștii și ce urmărești în continuare

Nu avem, din materialul sursă, informații despre disponibilitatea geografică, despre costuri sau despre cât de des apare fluxul Shop în fața utilizatorilor români. Nu știm dacă RAR e activ pentru toate piețele sau dacă are limitări pe anumite conturi. Nu știm cum arată rata de autorizare în practică.

Ce știm e că e opt-in, deci poți rula în paralel. O integrare veche nu se strică dacă nu faci nimic. Asta înseamnă că poți lansa RAR pe un segment, cu câmpuri minime, și să compari în timp, cu propriile date, nu cu promisiuni de pe bloguri.

Recomandarea mea de proces: pornește cu numele și telefonul ca obligatorii, restul opțional, măsoară rata de autorizare și rata de completare a profilului pe 30 de zile, apoi decide dacă merită să adaugi câmpuri. Nu invers. Și documentează în interior ce faci cu refuzurile, ca să nu ai surprize când echipa de vânzări întreabă de ce lipsesc lead-uri.

FAQ

Trebuie să modific integrarea existentă ca să funcționeze în continuare? Nu. RAR e opt-in, iar integrările existente de lead capture continuă să funcționeze fără modificări. Modifici doar dacă vrei să ceri câmpuri noi sau să marchezi obligatoriu/opțional.

Ce câmpuri pot cere prin RAR? Prenume, nume, număr de telefon și data nașterii. Pentru identificator și email setezi separat attributes.scope pe shop_app:oauth.

Ce fac dacă utilizatorul refuză autorizarea? Evenimentul onComplete nu include shopConsentToken, chiar dacă utilizatorul s-a autentificat în magazin. Tratează absența tokenului ca rezultat așteptat și construiește un fallback, nu o eroare.

Arc final: AI ajută, omul decide, agenția execută

Uneltele AI sunt bune la partea de analiză: să structureze o listă de câmpuri și scenarii de test, să compare fluxuri, să draftuiască logica de fallback pentru token lipsă. Nu sunt bune la decizia de business: ce câmp e cu adevărat necesar, ce faci cu un telefon care se suprascrie, cum arată follow-up-ul după un refuz. Acolo e nevoie de un media buyer senior care se uită la date și la operațiune, nu doar la cod.

Pasul concret îl face ALLSoft Agency: pornim de la întrebarea „ce date îți trebuie ca să vinzi mai bine”, trecem prin logica de captare și testele obligatorii, și lăsăm execuția acolo unde contează, la om. Fără promisiuni de cifre pe care nu le-am măsurat.