AMPscript vs SSJS in Salesforce Marketing Cloud: quando usare cosa

Se costruisci qualcosa di non banale in Salesforce Marketing Cloud (SFMC), prima o poi arrivi allo stesso bivio: questa logica va scritta in AMPscript o in Server-Side JavaScript (SSJS)? Entrambi girano lato server al momento del send o del render, entrambi leggono e scrivono Data Extensions, ed entrambi sembrano sovrapporsi per circa il 70%. È proprio quella sovrapposizione a rendere confusa la scelta.

Dopo anni a costruire automazioni di marketing su SFMC, la mia risposta breve è: AMPscript come default, SSJS quando AMPscript inizia a far male. Ecco la risposta lunga.

Per cosa è davvero bravo ciascuno

AMPscript è un linguaggio di templating e personalizzazione. È nato per vivere dentro un’email, una CloudPage o un SMS e portare il valore giusto nel punto giusto. Il suo punto di forza:

Stringhe di personalizzazione e sostituzione AttributeValue / %%campo%%
Lookup, LookupRows, LookupOrderedRows sulle Data Extensions
Contenuti condizionali semplici (IF ... THEN ... ENDIF)
InsertData / UpsertData per scritture leggere
Logica al momento del send che deve essere veloce e prevedibile

AMPscript è conciso, veloce e la piattaforma è costruita attorno ad esso. Il costo è che diventa doloroso nel momento in cui servono vere strutture dati, cicli con stato complesso o gestione degli errori.

SSJS è (un dialetto di) JavaScript eseguito sul server. Il suo punto di forza:

Iterare e trasformare array e oggetti — qualsiasi cosa abbia struttura annidata
Chiamare WSProxy / la Core API per manipolare gli oggetti SFMC (Data Extensions, subscriber, automazioni) in modo programmatico
Fare il parsing e costruire JSON, ad esempio per chiamate REST da una CloudPage
Gestione degli errori con try/catch e logica multi-step più leggibile

Il costo di SSJS sono performance e verbosità: è più pesante in fase di render, e fare semplice personalizzazione in SSJS è come usare un muletto per spostare una tazzina.

La mia regola pratica

Usa AMPscript per renderizzare e personalizzare. Usa SSJS per elaborare e integrare. Quando vanno bene entrambi, scegli AMPscript per la performance al send.

In concreto:

Personalizzazione email, blocchi di contenuto dinamico, lookup al momento del send → AMPscript. È più veloce su larga scala e ogni sviluppatore SFMC dopo di te lo leggerà senza battere ciglio.
CloudPage che riceve un POST da form, lo valida, chiama un’API esterna e riscrive i dati → SSJS. Ti serviranno gestione JSON, try/catch e WSProxy.
Preference center → di solito ibrido: SSJS per la logica di lettura/scrittura, AMPscript per il markup e la personalizzazione.

Il pattern che uso davvero: ibrido, con un confine chiaro

Una trappola che vedo in molte org è mischiare i due linguaggi riga per riga finché nessuno riesce più a seguire il flusso. Il pattern manutenibile è tenere un confine pulito: fai l’elaborazione pesante in un unico blocco SSJS, riversa i risultati in variabili AMPscript, poi lascia che AMPscript renderizzi.

%%[
  /* AMPscript: dichiara ciò che serve al template */
  VAR @firstName, @offerCode
]%%

<script runat="server">
  Platform.Load("Core","1.1.1");
  // SSJS: il lavoro pesante — chiamata API, parsing JSON, regole di business
  var offer = resolveOffer(Attribute.GetValue("subscriberKey"));
  Variable.SetValue("@offerCode", offer.code);
</script>

%%[
  /* Di nuovo in AMPscript: render */
  SET @firstName = AttributeValue("firstName")
]%%
Ciao %%=v(@firstName)=%%, il tuo codice è %%=v(@offerCode)=%%.

Variable.SetValue / Variable.GetValue è il ponte tra i due mondi. Attraversalo di proposito, una volta sola, invece di saltare avanti e indietro.

Note sulle performance che contano sui volumi

Su volumi di invio alti, i lookup AMPscript al send costano meno di SSJS. Se un valore si risolve con un singolo Lookup, non tirare in ballo SSJS.
Fai il lavoro costoso prima del send, non durante. Se chiami un’API per ogni subscriber in fase di render, stai costruendo un sistema fragile, lento e a rischio rate-limit. Pre-calcola in una Data Extension con un’automazione, poi lascia che AMPscript legga.
WSProxy in SSJS è potente ma non è gratis. Fai operazioni in batch; non ciclare una chiamata API per riga quando basterebbe una retrieve filtrata.

Quando SSJS è l’unica risposta vera

Devi creare o modificare oggetti SFMC in modo programmatico (es. generare Data Extensions al volo, gestire subscriber via API).
Stai costruendo una CloudPage come mini-app — form, sessioni, API JSON.
Ti serve gestione strutturata degli errori perché un fallimento va intercettato e loggato, non renderizzato silenziosamente come vuoto.

In sintesi

AMPscript e SSJS non sono concorrenti; sono un layer di templating e un layer di scripting. I team che restano lucidi li trattano così. Parti da AMPscript — è più veloce e più idiomatico per l’80% del lavoro fatto di personalizzazione e lookup — e introduci SSJS di proposito per elaborazione, integrazione e gestione errori, con un passaggio di consegne pulito tra i due.

Azzecca il confine e il tuo codice SFMC resta leggibile per il prossimo architetto. Sbaglialo e ogni template diventa un piccolo progetto di archeologia.