Din API-ul 2027-01, extensiile de checkout și customer account din Shopify pot trimite App Events direct, fără backend și fără acces la rețea. Practic, evenimentele din zona de plată ajung în logs fără infrastructură suplimentară, dar numai după consimțământul cumpărătorului. Este o schimbare opțională, documentată de Shopify în changelog pe 28.10.2026.

Ce s-a schimbat, concret, în App Events

Shopify a introdus metoda shopify.appEvents.emit(), disponibilă în extensiile de Checkout UI și Customer Account UI care rulează pe versiunea de API 2027-01 sau mai nouă. Metoda trimite un eveniment definit printr-un handle și atribute opționale. Platforma atașează automat aplicația și magazinul la fiecare eveniment, deci nu mai e nevoie de token de acces sau de shop ID. Evenimentele apar în Dev Dashboard logs, alături de cele trimise prin API-ul server-side App Events.

Diferența operațională e simplă și importantă. Înainte, o extensie avea nevoie de acces la rețea și de un backend al aplicației pentru a trimite evenimente. Acum, extensia poate emite direct, din pagina în care se produce acțiunea. Extensiile pot trimite și evenimentele standard declarate pentru Shopify Analytics, iar comercianții le văd în analytics.

Sunt însă și limite care contează pentru un marketer serios: evenimentele pleacă doar după ce cumpărătorul permite procesarea analytics. Până atunci stau în pagină, iar dacă refuză sau părăsește pagina, nu se mai trimit. Fiecare extensie poate trimite un burst de 20 de evenimente, apoi 2 pe secundă. Când emit() nu reușește, returnează {success: false, error}. Evenimentele din extensii nu intră în facturare pentru Shopify App Pricing, iar checkout-urile din aplicația Shop nu trimit evenimente din extensii. Server App Events API rămâne neschimbat.

De ce contează pentru măsurare, nu doar pentru dezvoltatori

Marea majoritate a discuțiilor despre tracking în ecommerce se învârt în jurul pixelilor și al server-side tagging. Aici vorbim despre altceva: evenimente care descriu ce face cumpărătorul în interiorul unei extensii instalate în checkout sau în contul clientului. Un exemplu generic: un upsell afișat în sumarul comenzii, o ofertă de bundle, un pas suplimentar de configurare. Înainte, pentru a ști dacă acea componentă a fost văzută sau folosită, aveai nevoie de un drum prin backend. Acum poți emite evenimentul exact acolo unde se întâmplă.

Ce nu rezolvă această schimbare, și e esențial de spus clar: nu înlocuiește măsurarea de conversie clasică, nu înlocuiește deduplicarea dintre pixel și API-ul de conversii, nu rezolvă atribuirea. Este un strat suplimentar de vizibilitate asupra comportamentului din zone pe care de obicei le vezi doar ca o cutie neagră. Dacă echipa ta de marketing a avut vreodată întrebarea „ce procent din cumpărători interacționează cu oferta din checkout”, ăsta e tipul de instrument care poate răspunde, cu condiția să fie implementat corect și să existe consimțământ.

Merită citită și discuția despre consimțământ. Faptul că evenimentele sunt reținute până la acceptarea procesării analytics nu este un detaliu tehnic minor, ci o constrângere de conformitate care influențează direct volumul de date pe care îl vei vedea. Într-o piață precum România, unde rata de acceptare a cookie-urilor variază mult de la un magazin la altul, diferența dintre „evenimente emise” și „evenimente primite” poate fi semnificativă. Orice raport construit pe aceste date trebuie citit cu această rezervă.

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

Traducem în viața de zi cu zi a unui magazin online de la noi. Ai un magazin pe Shopify, ai instalat una sau două aplicații care modifică checkout-ul, probabil un upsell sau un modul de livrare. Ai întrebat echipa sau agenția: „funcționează acea componentă?”. Răspunsul de până acum era adesea un „credem că da”, pentru că datele erau fie inexistente, fie împrăștiate.

Cu App Events din extensii, ai o cale nouă de a vedea aceste lucruri în Dev Dashboard logs, alături de restul activității aplicației. Nu e un panou de marketing gata făcut, nu îți dă ROAS sau CPA pe loc. Dar îți dă materie primă pentru întrebări mai bune: câți cumpărători au văzut oferta, câți au apăsat, în ce etapă a checkout-ului. Dacă ai un program de selling plans în draft orders, de exemplu, astfel de evenimente pot completa imaginea despre cum interacționează clientul cu opțiunile de abonament.

Al doilea lucru pe care îl schimbă este costul de implementare. Fără backend, fără acces la rețea, fără token de acces. Pentru un business mic sau mediu, asta poate însemna că o funcționalitate care părea rezervată echipelor cu dezvoltatori dedicați devine accesibilă prin simpla actualizare a versiunii de API a extensiei, dacă aplicația terță o suportă. Aici e nuanța: tu, ca comerciant, nu implementezi direct, ci depinzi de furnizorul aplicației. Dacă aplicația nu a trecut pe 2027-01, nu vei vedea nimic nou.

Al treilea aspect, mai puțin confortabil: datele nu sunt procesate pentru facturare. Asta înseamnă că, dacă folosești Shopify App Pricing și raportezi usage, trebuie să continui să trimiți evenimentele de facturare din backend. Nu confunda evenimentele de analiză cu cele de facturare. E o distincție pe care mulți o trec cu vederea și care poate crea discrepanțe în raportare.

Ce verifici înainte să te bazezi pe aceste date

Primul pas este să afli ce versiune de API folosesc extensiile din checkout-ul tău. Dacă sunt pe versiuni anterioare, shopify.appEvents nu există și nu ai ce măsura. Al doilea pas: întreabă furnizorul aplicației dacă a adoptat 2027-01 și dacă emite evenimente. Al treilea: verifică în Dev Dashboard logs dacă evenimentele apar, în magazinul de dezvoltare sau în producție, după caz.

Atenție la o capcană de interpretare. O verificare incompletă nu dovedește absența unei funcții. Dacă nu vezi evenimente, poate fi pentru că nu ai acceptat procesarea analytics în testul tău, pentru că ai depășit limita de rată, pentru că evenimentul e invalid sau pentru că aplicația nu emite deloc. Nu trage concluzia „nu funcționează” dintr-un singur test eșuat.

Nu în ultimul rând, respectă regula din documentație: nu pune informații personale în atributele evenimentelor. Nu ai nevoie de email, nume sau telefon ca să numeri câți oameni au văzut o ofertă. Dacă furnizorul aplicației face asta, e un semnal de discuție.

Dacă vrei să înțelegi mai bine unde se duce măsurarea în ecosistemul Shopify, inclusiv în zona de agenți AI care influențează vânzările, avem o analiză pe Shopify și comisionul pe vânzările aduse de agentul AI al clientului. Iar dacă întrebarea ta reală este despre performanța reclamelor și nu despre tracking, e util să citești și despre de ce mai multe reclame paid social nu rezolvă problema de creativ.

Limite, riscuri și ce nu promite acest update

Să fim transparenți. Shopify nu anunță rezultate, nu promite creșteri de conversie, nu promite CPA mai bun. Vorbim despre o metodă nouă de a emite evenimente, opțională, fără acțiune obligatorie. Orice interpretare de tipul „îți crește vânzările” este speculație și nu are suport în materialul sursă.

Limitele reale sunt cele patru enumerate deja: consimțământul analytics, rata de 20 la burst plus 2 pe secundă, lipsa procesării pentru facturare și faptul că checkout-urile din Shop app nu trimit evenimente din extensii. Adaugă la asta dependența de versiunea de API și de furnizorul aplicației. Rezultatul: un instrument util, dar cu acoperire parțială, care trebuie combinat cu restul surselor de date, nu folosit izolat.

Un scenariu ipotetic, ca să fie clar că e ipoteză: un magazin cu un modul de upsell în checkout ar putea, după ce furnizorul aplicației adoptă 2027-01, să numere câți cumpărători au văzut oferta și câți au acceptat-o, doar pentru utilizatorii care au permis analytics. Cifrele ar fi mai mici decât realitatea, din cauza consimțământului, dar ar fi consistente în timp și ar permite comparații între perioade. Asta e o presupunere de lucru, nu un rezultat măsurat.

FAQ

Trebuie să fac ceva dacă am un magazin pe Shopify? Nu. Shopify spune explicit că acțiunea nu este obligatorie. Schimbarea e opțională și se aplică doar extensiilor care trec pe API 2027-01 sau mai nou.

Voi vedea aceste evenimente în analytics? Doar evenimentele standard declarate pentru Shopify Analytics apar în analytics pentru comercianți, și doar după ce cumpărătorul permite procesarea. Evenimentele custom apar în Dev Dashboard logs, nu automat în analytics.

Pot folosi aceste evenimente pentru facturare? Nu. Evenimentele din extensiile UI nu sunt procesate pentru facturare. Pentru Shopify App Pricing, continuă să trimiți evenimentele de facturare din backend-ul aplicației.

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

Un update ca acesta e exact tipul de lucru în care AI-ul își are locul, dar nu locul principal. Un model bun poate citi documentația, poate genera codul de emisie, poate propune o schemă de atribute curată și poate structura un plan de test. Ce nu poate face este să decidă ce merită măsurat în magazinul tău, să judece dacă un eveniment este relevant pentru o decizie de buget sau să evalueze dacă datele sunt destul de solide încât să schimbi ceva.

Decizia rămâne la media buyer și la omul din spatele contului: ce întrebări pui, ce accepți ca dovadă, ce faci cu ce afli. Iar pasul concret, de la documentație la implementare și la un setup de măsurare coerent, îl face ALLSoft Agency. Fără hype, fără promisiuni de cifre pe care nu le putem susține cu date.