Shopify ritira gli ScriptTag: come verificare app e tracciamenti senza sorprese

Shopify ha annunciato il 24 agosto 2026 il percorso finale di ritiro degli ScriptTag, un meccanismo usato da alcune applicazioni per caricare codice nelle pagine del negozio o in parti del percorso cliente. La tabella ufficiale indica che gli ScriptTag nella pagina di stato dell’ordine smettono di funzionare il 26 agosto 2026; la documentazione precisa che sulle pagine di stato dell’ordine dei negozi Plus si sono già fermati. Dal 1° ottobre 2026 non sarà più possibile creare o aggiornare uno ScriptTag. Dal 1° marzo 2027 gli ScriptTag smetteranno di funzionare nelle pagine del negozio online.

Le date non dicono da sole quale effetto avrà il cambiamento su un negozio online. Uno ScriptTag può sostenere un tracciamento, inserire un elemento visibile, collegare un servizio esterno o appartenere a un’app ormai inutilizzata. La priorità è quindi costruire un inventario che leghi ogni presenza tecnica a una funzione commerciale o operativa. Aggiornare tutte le app senza sapere che cosa fanno può introdurre nuovi errori; ignorare il tema fino al 2027 può lasciare troppo poco tempo per provare le alternative.

Per chi gestisce il negozio, lo ScriptTag raramente compare con questo nome nell’attività quotidiana. Può essere nascosto dietro un’app per analisi, marketing, assistenza, personalizzazione o collegamento con altri strumenti. Il fatto che un’app sia installata non dimostra che usi ancora questo meccanismo; allo stesso modo, rimuovere un frammento senza ricostruirne lo scopo può eliminare una funzione necessaria.

La domanda corretta non è «quanti ScriptTag abbiamo?», ma «quali risultati dipendono da ciascuno?». Un tracciamento può alimentare report e campagne. Un elemento nella pagina può informare il cliente. Un collegamento sullo stato dell’ordine può sostenere assistenza o servizio post-vendita. Solo dopo avere identificato proprietario, scopo e dati coinvolti è possibile scegliere una sostituzione proporzionata.

Un inventario operativo può raccogliere nome dell’app o integrazione, fornitore, area del negozio coinvolta, funzione visibile, dati raccolti o inviati, referente interno, contratto e livello di criticità. Conviene distinguere le pagine del negozio dalla pagina di stato dell’ordine, perché le scadenze e le alternative sono diverse. Per ogni elemento va registrato anche il modo in cui si può dimostrare che la sostituzione funziona.

Segnali che richiedono una verifica prioritaria

• App che inseriscono elementi o messaggi nelle pagine del negozio.

• Strumenti di analisi o pubblicità che raccolgono eventi dal comportamento degli utenti.

• Personalizzazioni della pagina di stato dell’ordine o dell’area cliente.

• Integrazioni installate da un fornitore che non segue più il progetto.

• Funzioni duplicate da più app o da codice aggiunto nel tema.

• Report importanti che nessuno sa collegare a una fonte tecnica precisa.

L’inventario non richiede di pubblicare dettagli tecnici o credenziali. Deve essere abbastanza chiaro da permettere al proprietario del negozio, al responsabile marketing e allo sviluppatore di parlare dello stesso elemento. Se non è possibile assegnare uno scopo, l’elemento non va eliminato alla cieca: va osservato in un ambiente di prova e confrontato con il comportamento attuale.

Per ogni riga conviene indicare una decisione provvisoria: mantenere e migrare, sostituire con un’altra soluzione, rimuovere perché non serve più oppure approfondire. La decisione deve riportare dipendenze e condizione di arresto. Se un’app alimenta sia una funzione visibile sia un report, per esempio, non può essere trattata come un solo blocco: le due parti potrebbero richiedere alternative e prove diverse.

Shopify indica le theme app extensions, cioè estensioni gestite dalle applicazioni nel tema, per sostituire gli ScriptTag che caricano codice nelle pagine del negozio. Per uno ScriptTag usato soltanto per raccogliere dati di analisi o conversione, Shopify indica i web pixel, componenti dedicati alla raccolta degli eventi. Per personalizzazioni della pagina di stato dell’ordine, la direzione è rappresentata dalle customer account UI extensions, cioè estensioni dell’interfaccia utente dell’area cliente.

La scelta dipende dalla funzione, non dalla preferenza tecnica. Un elemento visivo non dovrebbe essere trasferito automaticamente in un pixel, che ha uno scopo di raccolta dati; un tracciamento non dovrebbe essere ricreato come modifica del tema se la piattaforma prevede un canale dedicato. Anche la disponibilità delle estensioni e il supporto dell’app devono essere verificati sul negozio reale. Il fornitore dovrebbe spiegare quale alternativa usa, quali dati cambia, come verrà testata e che cosa succede in caso di ritorno alla configurazione precedente.

Quando uno ScriptTag sostiene la misurazione di analisi o campagne, la migrazione deve partire dall’elenco degli eventi realmente utilizzati: visualizzazione di prodotto, aggiunta al carrello, inizio del pagamento, acquisto o altri passaggi pertinenti. Non è utile replicare automaticamente ogni segnale storico. Occorre verificare nomi, condizioni di attivazione, dati associati e sistemi che ricevono l’informazione.

Il passaggio offre anche l’occasione per controllare duplicazioni e consenso. Due strumenti possono registrare lo stesso acquisto, oppure un vecchio frammento può continuare a inviare dati dopo l’installazione del nuovo pixel. Il confronto va eseguito in un periodo controllato, documentando differenze attese e anomalie. Le scelte sulla protezione dei dati e le valutazioni legali dipendono dal caso concreto: la migrazione tecnica non costituisce automaticamente una verifica di conformità.

Una migrazione è pronta quando il negozio dimostra che le funzioni essenziali continuano a lavorare. Il piano di prova dovrebbe includere almeno navigazione mobile, varianti prodotto, aggiunta e rimozione dal carrello, applicazione di condizioni pertinenti, completamento di un ordine di prova, conferme e pagina di stato. Se l’integrazione riguarda assistenza o area cliente, vanno testati anche accesso, permessi e visibilità delle informazioni.

Ogni esito deve avere un responsabile e una prova leggibile: schermata, evento registrato, messaggio ricevuto o confronto tra sistemi. Non serve introdurre modifiche tecniche direttamente sul negozio online senza un piano. Un ambiente di prova, una finestra controllata e la possibilità di tornare indietro riducono il rischio di scoprire un problema durante un picco di vendite.

Prima della sostituzione è utile conservare una base di confronto: quali elementi appaiono, quali eventi arrivano e quali comunicazioni riceve il cliente. Dopo il cambio si ripetono gli stessi casi. Le differenze non sono automaticamente errori, ma devono essere spiegate e approvate. Il ritorno alla configurazione precedente va previsto prima del rilascio, indicando chi decide e quali segnali rendono necessario interrompere il passaggio.

Il primo traguardo è arrivare prima del 1° ottobre 2026 con un inventario delle dipendenze e un referente per ciascuna app. Il secondo è ottenere dai fornitori un piano che indichi alternativa, tempi, prove e compatibilità. Il terzo è completare il collaudo con margine rispetto al 1° marzo 2027, senza concentrare tutte le modifiche nelle settimane finali. Le personalizzazioni legate alla pagina di stato dell’ordine richiedono una verifica immediata, dato che la scadenza indicata è già trascorsa.

Quando il tema, più app, i tracciamenti e i sistemi esterni sono collegati, una consulenza informatica può aiutare a costruire l’inventario e assegnare le priorità. Se servono integrazioni non coperte dalle app standard, lo sviluppo di applicazioni può essere valutato soltanto dopo avere chiarito requisiti e alternative supportate. Il ritiro degli ScriptTag non richiede panico: richiede sapere che cosa è in esecuzione, perché serve e come dimostrare che la sostituzione conserva il risultato senza introdurre nuovi rischi.