Settimana scorsa ho passato 20 minuti a capire perché Meta rifiutava un template WhatsApp che a occhio era perfetto.
Il body diceva tutto il necessario. Le variabili erano nominate bene. Il tono era pulito. Mandato in review → rifiuto. Subcode 2388293. Motivo: "rapporto parole/parametri supera il limite".
Non ero stato generico. Avevo solo tagliato troppo.
Il template che è caduto due volte
Stavo editando el_notifica_risposta_salone_v2: il template — un messaggio WhatsApp pre-approvato che usi per notifiche automatiche — che avvisa la segretaria di Extension Lounge quando arriva una risposta da un lead del salone. La versione live diceva:
"Il drip e stato interrotto automaticamente. Nuova risposta da {{1}} {{2}}..."
Due problemi: l'accento mancante su "è", e la parola "drip". La segretaria del salone non sa cosa sia un drip — è gergo da automazione, non da chi sta in cassa.
Ho tagliato. Body nuovo, più asciutto, più umano. Submit a Meta via Graph API. Risposta: 400 Bad Request, subcode 2388293.
Ho riletto. Aggiunto due righe descrittive. Submit. 200 OK. Approvato in pochi minuti.
La differenza tra i due tentativi era una cosa sola: la quantità di testo statico attorno alle stesse variabili.
La regola che Meta non documenta
I template WhatsApp Business hanno un controllo nascosto: il rapporto fra parole non-variabili e parametri dinamici nel body. Sotto una certa soglia, Meta classifica il template come "troppo simile a uno spam generico" — la stessa logica che usa per bloccare i messaggi marketing mascherati da notifica transazionale.
La soglia non sta nella documentazione ufficiale. La trovi solo se la sbatti. Dopo averla sbattuta, ho misurato il body accettato:
Hai ricevuto una nuova risposta WhatsApp da un lead del salone Extension Lounge.
Nome: {{1}} {{2}}
Telefono: {{4}}
Messaggio del cliente:
"{{3}}"
19 parole non-variabili, 4 variabili. Ratio: 4.75 parole per ogni {{n}}.
Il body precedente — quello rifiutato — era sotto 3 parole per variabile. Da lì la regola empirica: se hai meno di 4-5 parole statiche per ogni variabile, Meta blocca. Sopra, passa.
Non è un limite assoluto. È una soglia, e sotto quella soglia un template "asciutto e diretto" diventa indistinguibile da un messaggio di phishing nei filtri Meta.
Perché lo racconto
Non per il subcode in sé — quello lo trovi su Stack Overflow se cerchi 10 minuti. Lo racconto per il principio sotto: i sistemi che usi ogni giorno hanno regole non scritte che scopri solo quando le rompi.
Meta non ti dice "minimo 4 parole per variabile" perché la regola cambia continuamente — è un modello di rilevamento spam, non una validazione sintattica. Documentarla la renderebbe aggirabile. Lasciarla nascosta la mantiene utile.
La conseguenza pratica per chi costruisce automazioni serie: ogni piattaforma su cui costruisci ha questo tipo di regole. La differenza tra chi spedisce e chi resta bloccato non è sapere tutte le regole in anticipo — è misurare la regola la prima volta che la sbatti, scriverla da qualche parte, e non sbatterla più.
Nel mio caso: il body rifiutato + il body accettato sono finiti nel memory log del progetto, con il subcode e il ratio. La prossima volta che edito un template WABA — mio o di un cliente MAD UNITE — guardo prima il rapporto parole/variabili. 30 secondi di check, zero rifiuti.
Cosa fare adesso
Se gestisci o stai per costruire template WhatsApp Business, fai una cosa oggi: apri il body di ogni template attivo, conta le parole non-variabili, dividi per il numero di {{n}}. Se il ratio è sotto 4, il template è a rischio rifiuto al prossimo edit — Meta riesegue i controlli a ogni submit, anche se la versione precedente era passata.
Sopra 4-5 stai tranquillo. Sotto 3, riscrivi prima di toccarlo.
È il tipo di micro-regola che separa un'automazione che funziona da una che ti tiene fermo un pomeriggio.
Vuoi il prossimo articolo?
Iscriviti alla newsletter — 3 volte a settimana, lun/mer/ven.
