Alternative ai servizi Google in Magento 2

Prima identifica l'integrazione esistente

Tema, moduli e tag manager possono caricare lo stesso servizio in punti diversi. Verifica pagine prodotto, carrello, checkout e moduli, sia per utenti autenticati sia per ospiti.

Stabilisci cosa preservare prima di disattivare la vecchia integrazione: eventi di conversione, preferenze di consenso o validazioni dei moduli. Lavora in un ambiente di test e verifica la versione di Magento e l'architettura del tema.

Aggiungi i font al sorgente del tema

Per un tema basato sulla libreria UI di Magento, Adobe consiglia i file dei font in web/fonts e la loro dichiarazione in web/css/source/_typography.less del proprio tema. Non modificare il tema predefinito o i file styles-m.css generati: le modifiche devono resistere alla rigenerazione delle risorse.

L'esempio seguente illustra la dichiarazione di un font locale. Sostituisci nome e percorso con i file autorizzati del progetto. Per un tema senza libreria UI, usa il meccanismo CSS e il processo di build di quel tema.

.lib-font-face(
  @family-name: 'Project Sans',
  @font-path: '@{baseDir}fonts/project-sans-regular',
  @font-weight: 400,
  @font-style: normal,
  @font-display: swap
);

Migra la misurazione, non solo lo script

Una visualizzazione di pagina non equivale a un ordine. Definisci esplicitamente gli eventi rilevanti: visualizzazione prodotto, aggiunta al carrello, avvio del checkout e ordine confermato. Verifica valuta, valore ed eventuali duplicazioni.

Se scegli Matomo o un'altra piattaforma, verifica l'integrazione disponibile per la versione e il frontend del negozio. Un modulo adatto a un tema classico può richiedere adattamenti in un frontend su misura. Configura i dati inviati ed evita email o altri dati del cliente negli eventi senza una chiara giustificazione.

Proteggi l'endpoint del modulo

Aggiungere un widget antispam al template non basta. Il token deve essere trasmesso e verificato dal backend prima dell'operazione protetta. La chiave segreta resta sul server.

Con Turnstile verifica anche l'azione e l'hostname attesi. Considera fallita la verifica di token scaduti, riutilizzati o non validi. Un messaggio chiaro deve permettere di ripetere la verifica senza riscrivere il modulo.

Cosa verifichiamo prima del lancio

Percorriamo le pagine e i flussi interessati su mobile e desktop. Verifichiamo font e caratteri accentati, errori del browser ed eventuali blocchi causati dalla Content Security Policy.

Per la misurazione confrontiamo gli eventi attesi con quelli ricevuti. Per i moduli testiamo sia l'invio valido sia il token mancante o non valido. Nel checkout verifichiamo che la modifica non interferisca con l'ordine.

Pubblichiamo solo dopo la validazione nell'ambiente di test e documentiamo i passaggi di ripristino. Il costo corretto della migrazione include questa verifica e la manutenzione successiva, non solo l'installazione di un'estensione.