Din octombrie 2026, dezvoltatorii de aplicații Shopify pot activa capabilitatea analytics_queryable direct din fișierul shopify.app.toml, pentru definițiile de metafield și metaobject. Practic, câmpurile custom pe care aplicația ta le declară devin dimensiuni și filtre în Shopify Analytics și ShopifyQL, fără apeluri GraphQL Admin API. Asta mută datele de nișă în raportarea nativă.

Ce s-a schimbat concret în TOML

Anunțul din changelogul Shopify (20.10.2026) e scurt, dar are greutate pentru cine construiește aplicații pe platformă. Până acum, ca să faci o definiție de metafield sau metaobject să fie interogabilă în analytics, trebuia să treci prin GraphQL Admin API: apeluri metafieldDefinitionCreate, metafieldDefinitionUpdate, metaobjectDefinitionCreate sau metaobjectDefinitionUpdate, cu analyticsQueryable setat pe true. Acum, aceeași capabilitate se poate declara direct în configurația aplicației, prin capabilities.analytics_queryable = true. La deploy (shopify app deploy), Shopify distribuie definiția către fiecare magazin unde aplicația e instalată.

Concret, într-un TOML, o definiție de metafield pentru clienți arată așa: secțiunea [customer.metafields.app.membership_level] cu name, type single_line_text_field și capabilities.analytics_queryable = true. Pentru un metaobject, [metaobjects.app.ingredient] cu capabilities.analytics_queryable = true, plus câmpurile definite separat, de exemplu name ca text și calories ca number_integer.

Diferența nu e cosmetică. Înainte, capabilitatea trăia în codul de migrare sau în logica de instalare a aplicației, ceea ce însemna un apel API pentru fiecare magazin, gestionat de dezvoltator. Acum definiția e declarativă, versionată în cod și distribuită automat. Pentru echipele care livrează aplicații către comercianți, asta reduce suprafața de eroare și mută configurarea într-un singur loc, ușor de revizuit în pull request.

Ce înseamnă "queryable" pentru un magazin online

Merită să traducem termenul tehnic în efect practic. Un metafield queryable înseamnă că valorile lui pot fi folosite ca dimensiuni și filtre în Shopify Analytics și în ShopifyQL. Adică poți segmenta rapoartele pe un atribut custom pe care platforma nu îl are nativ: nivel de membership, categorie de fidelitate, tip de client B2B, regiune proprie, sursă internă de lead. Pentru metaobiecte, logica e similară: dacă metaobiectul e eligibil, valorile lui devin interogabile.

Aici e nuanța importantă pe care changelogul o spune explicit și pe care mulți o vor sări: nu orice tip de metafield poate fi interogat în analytics. Ca să confirmi dacă o definiție poate folosi capabilitatea, trebuie verificat câmpul eligible din capabilitatea analyticsQueryable. La metaobiecte, definiția poate folosi capabilitatea doar dacă cel puțin unul dintre câmpurile ei are un tip compatibil cu analytics. Cu alte cuvinte, nu poți presupune că un câmp devine dimensiune doar pentru că ai bifat o opțiune în TOML.

Capabilitatea e disponibilă pentru definițiile de metafield aplicate pe customer, order, product și product variant. Asta acoperă exact zonele în care marketerii vor să taie rapoartele: cine cumpără, ce cumpără, cât cheltuiește, ce variantă se vinde.

De ce contează pentru raportare și pentru GEO

Pentru un marketer de ecommerce, valoarea nu stă în faptul că Shopify a adăugat un flag. Valoarea stă în faptul că datele care înainte trăiau în aplicații externe sau în exporturi CSV pot intra în raportarea nativă, alături de metricile de vânzări, fără un pipeline separat. Asta schimbă felul în care construiești segmentele: nu mai compari manual două surse, ci filtrezi direct în Analytics pe un atribut care există deja pe client sau pe comandă.

E relevant și pentru discuția mai largă despre măsurare. În 2026, din ce în ce mai mult trafic vine din suprafețe care nu trimit click-uri curate, iar diferența dintre ce raportează platformele și ce se întâmplă de fapt în magazin devine tot mai greu de reconciliat. Am atins problema în analiza despre măsurarea AI Search fără click-uri. Cu cât mai multe atribute proprii ajung în raportarea nativă, cu atât ai mai multe unghiuri de segmentare pentru a izola efectele pe surse și pe tipuri de client.

Atenție însă la o confuzie frecventă: capabilitatea analytics_queryable nu creează automat rapoarte și nu garantează că un anumit câmp apare în dashboardul comerciantului. Ea face valori interogabile, atât timp cât tipul e eligibil. Restul ține de cum construiește comerciantul raportul.

Ce se aplică pentru unul care construiește o aplicație Shopify

Dacă ești dezvoltator sau lucrezi într-o echipă care livrează o aplicație pe Shopify App Store, schimbarea are trei consecințe directe.

Prima: mută capabilitatea în TOML și tratează-o ca pe orice altă configurație versionată. Dacă ai azi logică în cod care apelează mutațiile GraphQL pentru analyticsQueryable, poți evalua migrarea către declarația din TOML. Nu e obligatoriu să migrezi, dar e o simplificare reală, mai ales când ai multe magazine instalate.

A doua: verifică eligibilitatea înainte de a promite ceva comercianților. Documentația menționează câmpul eligible din analyticsQueryable. Dacă un tip de câmp nu e compatibil, setarea nu produce efectul așteptat. O verificare incompletă, repet, nu dovedește absența funcției; dovedește doar că nu ai confirmat încă.

A treia: gândește-te la documentația pentru comercianți. Când lansezi o versiune cu capabilities.analytics_queryable = true, definiția ajunge la fiecare magazin la deploy. Comerciantul trebuie să știe ce a câștigat, adică un atribut nou pe care îl poate folosi ca filtru în Analytics, nu doar să vadă o notă de versiune tehnică.

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

Să luăm un caz concret: un magazin online din România pe Shopify, cu clienți B2B și B2C amestecați. Are un metafield de tip membership_level, populat de o aplicație de fidelizare sau de un câmp custom din cont. Până acum, pentru a raporta vânzările pe nivel de membership, trebuia fie să exporți comenzile, fie să construiești un raport în altă parte. După ce aplicația care declară câmpul activează capabilitatea și livrează versiunea, valorile devin interogabile în Shopify Analytics și ShopifyQL, deci poți tăia raportul pe segment direct în platformă.

Al doilea scenariu, tot ipotetic: ai un catalog cu metaobiecte pentru ingrediente sau specificații tehnice, iar aplicația care le administrează le face queryable. Poți analiza vânzările pe un atribut de produs care nu există nativ în Shopify. Pentru un magazin de suplimente, alimente sau echipamente, asta poate însemna o dimensiune nouă de raportare, dacă tipul câmpului e eligibil.

Ce trebuie să reții ca operator: funcția nu rezolvă problema datelor murdare și nu înlocuiește disciplina de măsurare. Dacă metafield-ul e populat haotic, queryable sau nu, raportul va reflecta haosul. Ordinea corectă e: definești clar câmpul, te asiguri că se completează consecvent, apoi îl faci interogabil. Și, dacă lucrezi și pe SEO, merită să ai în vedere și analiza despre Semrush vs Moz în 2026, pentru că aceeași logică de surse de date curate se aplică și acolo.

Întrebări de verificat înainte să te bazezi pe asta

Câteva lucruri pe care le-aș pune pe listă înainte de a promite ceva unui client sau de a modifica o aplicație.

Primul: tipul câmpului tău e eligibil? Verifică analyticsQueryable și câmpul eligible pe definiția concretă, nu pe intuiție.

Al doilea: ai magazine reale pe care să testezi distribuția după shopify app deploy? Comportamentul la scară, cu multe instalări, merită observat.

Al treilea: ce se întâmplă cu definițiile existente pe care le-ai setat anterior prin GraphQL? Documentația nu promite o migrare automată, așa că nu presupune că totul se mută singur.

Al patrulea: echipa de marketing știe ce dimensiuni noi are la dispoziție? O capabilitate tehnică nefolosită e cost fără beneficiu.

FAQ

Pot activa analytics_queryable pentru orice metafield? Nu. Capabilitatea e disponibilă pentru definițiile de metafield aplicate pe customer, order, product și product variant, iar tipul câmpului trebuie să fie eligibil. Confirmarea se face prin câmpul eligible din analyticsQueryable.

Trebuie să folosesc GraphQL Admin API ca înainte? Nu mai e necesar pentru definițiile declarate în shopify.app.toml. Poți seta capabilities.analytics_queryable = true direct în configurație, iar Shopify distribuie definiția la deploy către magazinele unde aplicația e instalată.

Un metaobject devine automat interogabil dacă activez capabilitatea? Doar dacă cel puțin unul dintre câmpurile lui are un tip compatibil cu analytics. Altfel, setarea nu produce efectul scontat.

Concluzia ALLSoft

Unelte ca aceasta ajută: AI-ul poate accelera analiza, poate propune structuri de raportare și poate tria rapid ce definiții merită migrate. Dar decizia despre ce câmpuri contează pentru business, ce segmente au sens și ce înseamnă cifrele rămâne umană, la nivel de media buyer și de echipă de date. Iar execuția, adică auditul definițiilor, verificarea eligibilității și implementarea curată în TOML, e pasul concret pe care îl face ALLSoft Agency. Fără promisiuni de rezultate care nu stau pe date măsurate, ci cu verificare pas cu pas.