Skip to main content
Questa pagina è il riferimento autorevole per ogni regola strutturale che Switchbord verifica prima di inviare un modello a Meta. Ogni sezione è collegata al codice di errore emesso dal validatore lato client (vedi BORD-335), così puoi passare direttamente da un banner rosso nell’editor alla soluzione. Tutte le regole sono applicate sia dal linter lato client di Switchbord sia dal validatore di Meta al momento dell’invio. Il revisore umano di Meta aggiunge un secondo livello di controlli sul contenuto (vedi Modelli di marketing).

name-regex

I nomi dei modelli vengono usati come identificatori stabili su Meta, nei webhook e nel nostro database. Meta impone caratteri solo minuscoli affinché i nomi siano compatibili con gli URL e facilmente confrontabili tra i diversi BSP. Regola: ^[a-z][a-z0-9_]{0,511}$ — solo lettere minuscole, cifre e underscore. Nessuno spazio, trattino, maiuscola, punto o carattere accentato. Deve essere univoco per WABA e per lingua. DA FARE
DA NON FARE
Documentazione Meta: Linee guida sui modelli — denominazione.

leading-variable

Meta rifiuta un testo del corpo che inizia con un segnaposto, perché appare goffo su mobile e non fornisce al modello alcun punto di riferimento per la classificazione della categoria. Un corpo che inizia con un nome o un saluto si legge come un messaggio; uno che inizia con {{1}} si legge come una fuga di dati del modello. DA FARE
DA NON FARE
Documentazione Meta: Linee guida sui modelli di messaggio.

trailing-variable

Lo speculare della regola leading-variable. Un corpo che termina con {{N}} — anche con un punto finale — viene rifiutato. Aggiungi almeno una parola fissa dopo l’ultimo segnaposto, idealmente una frase completa di contesto. DA FARE
DA NON FARE
Documentazione Meta: Linee guida sui modelli di messaggio.

adjacent-variables

Due segnaposto con solo spazi o punteggiatura tra loro vengono rifiutati. Meta non riesce a rendere il confine in modo pulito e non può classificare l’intento quando il corpo è di fatto un elenco di parametri. Metti almeno una parola vera tra ogni coppia. DA FARE
DA NON FARE
Documentazione Meta: Linee guida sui modelli di messaggio.

missing-example

Ogni {{n}} in un HEADER, BODY, o in un bottone URL dinamico deve avere un esempio realistico corrispondente. Meta usa gli esempi per generare l’anteprima mostrata ai revisori e per classificare la categoria del modello. Un modello con segnaposto ma senza esempi viene rifiutato al momento dell’invio. DA FARE
DA NON FARE
Documentazione Meta: Creare e inviare un modello.

example-count-mismatch

La lunghezza dell’array di esempi deve essere uguale al numero di segnaposto distinti. Tre token {{n}} richiedono esattamente tre stringhe di esempio — non due, non quattro. Questo controllo viene eseguito per ogni componente (corpo, testo dell’intestazione, bottone URL). DA FARE
DA NON FARE
Documentazione Meta: Parametri dei modelli.

numeric-only-example

I valori di esempio devono essere realistici — cioè devono contenere caratteri alfabetici o un token alfanumerico chiaramente significativo (un importo con simbolo di valuta, una data, un codice ordine). Un numero nudo, un singolo simbolo o una stringa simile a un codice senza contesto viene rifiutato perché non rappresenta come un destinatario reale vedrà effettivamente il messaggio. DA FARE
DA NON FARE
Incorpora l’unità di misura direttamente nell’esempio — scrivi "20%", non "20" con il % adiacente nel corpo. Questo elimina l’euristica del “numero nudo” e produce lo stesso risultato visivo. Documentazione Meta: Valori di esempio.

sequential-numbering

I segnaposto devono iniziare da {{1}} e procedere in sequenza senza salti né duplicati. {{1}}, {{2}}, {{3}} è valido; {{1}}, {{3}} non lo è; {{2}}, {{3}} non lo è (deve iniziare da 1). Il validatore estrae gli indici univoci, li ordina e verifica che l’elenco risultante sia uguale a [1..N]. DA FARE
DA NON FARE
Documentazione Meta: Parametri dei modelli.

params-words-ratio

Un modello in cui i segnaposto dominano rispetto al testo fisso si legge come un dump di dati grezzi e viene segnalato durante la revisione del contenuto. Il linter di Switchbord avvisa quando il rapporto tra variabili e parole totali supera circa 1 su 4 — un modello con tre token {{n}} dovrebbe avere almeno dodici parole di testo fisso attorno a esse. DA FARE
(12 parole fisse attorno a 3 segnaposto) DA NON FARE
(3 segnaposto, 2 token fissi) Documentazione Meta: Qualità dei modelli.

length-caps

Ogni componente ha un limite massimo di caratteri rigido. Conta la stringa grezza del modello, inclusi i segnaposto — l’espansione in fase di esecuzione non conta rispetto al limite. DA FARE
DA NON FARE
Documentazione Meta: Componenti dei modelli.

button-limits

I bottoni hanno limiti massimi rigidi per tipo. Superare uno qualsiasi di questi limiti fa rifiutare l’intero modello al momento dell’invio. I bottoni URL dinamici devono avere {{1}} come unica variabile, presente alla fine del percorso URL o del valore di query — mai nel nome host. DA FARE
DA NON FARE
Documentazione Meta: Bottoni dei modelli.

component-ordering

I componenti di un modello devono apparire nell’ordine HEADER → BODY → FOOTER → BUTTONS. Ogni componente può apparire al massimo una volta, eccetto BODY che è richiesto esattamente una volta. Meta normalizza l’ordine in alcuni casi ma rifiuta i duplicati e i tipi sconosciuti con il codice 100. DA FARE
DA NON FARE
Documentazione Meta: Componenti dei modelli. I footer servono per testo statico e legalmente rilevante — l’identità del mittente, l’istruzione di opt-out, un’informativa. Non possono contenere segnaposto {{n}}. Metti i dati generati in fase di esecuzione nel corpo. DA FARE
DA NON FARE
Documentazione Meta: Componenti dei modelli — footer.

Set di regex di riferimento rapido

Se stai scrivendo il tuo validatore o degli script per controlli in blocco, le regex canoniche sono:

Vedi anche