HighLevel aggiunge il Message ID agli Email Events nel Dynamic Picker

TL;DR: HighLevel ha aggiornato gli eventi email rendendo disponibile un Message ID univoco nel Dynamic Picker dei workflow. Il valore può essere inserito nel payload dell’azione Send Webhook quando il workflow parte dal trigger Email Events. In questo modo, aperture e clic possono essere ricondotti alla precisa email che li ha generati: le aperture ripetute della stessa email mantengono lo stesso ID, mentre messaggi diversi ricevono ID diversi. L’aggiornamento è utile soprattutto per agenzie, team marketing e sviluppatori che inviano i dati di engagement email a dashboard, database o altri sistemi esterni e devono evitare attribuzioni errate o duplicati.

In sintesi

HighLevel interviene su un limite operativo degli Email Events nei workflow: fino a questo aggiornamento, un evento di apertura o clic poteva essere intercettato e inoltrato a un sistema esterno tramite webhook, ma non trasportava un riferimento capace di identificare con affidabilità il messaggio email di origine.

Secondo il changelog ufficiale, il nuovo Message ID è ora disponibile come valore selezionabile nel Dynamic Picker, cioè nel selettore dei valori dinamici usato per costruire dati e payload nelle automazioni. Il campo può essere aggiunto al corpo della richiesta nell’azione Send Webhook, purché il workflow inizi con il trigger Email Events.

La novità riguarda entrambi gli eventi indicati dalla fonte: Email Opened ed Email Clicked. Il comportamento dichiarato è lineare ma rilevante per la qualità dei dati: ogni apertura o clic riferito allo stesso messaggio conserva lo stesso Message ID; un’altra email genera invece un ID differente. Inoltre, l’ID accompagna l’evento, quindi anche un’apertura ricevuta in ritardo continua a puntare al messaggio che l’ha prodotta.

La fonte di riferimento è il changelog ufficiale HighLevel dedicato al Message ID negli Email Events, pubblicato il 19 agosto 2026. Nomi delle funzioni, posizione dei controlli e disponibilità effettiva possono cambiare dopo questa data di verifica.

Cosa cambia per i workflow con Email Events

L’elemento centrale dell’aggiornamento non è un nuovo trigger, ma un dato aggiuntivo associato agli eventi già generati da HighLevel per aperture e clic email. Nella pratica, chi costruisce un’integrazione webhook può includere nel payload un identificatore stabile del messaggio.

Prima di questa modifica, un sistema esterno poteva ricevere informazioni su un’apertura o un clic, ma non disponeva necessariamente di una chiave affidabile per stabilire quale invio avesse generato l’interazione. Cercare di dedurre l’email interrogando l’API sulla base dell’ultimo messaggio inviato, come osserva HighLevel, può produrre risultati sbagliati quando il contatto apre un’email meno recente.

Questo caso è meno raro di quanto sembri. Un destinatario può ricevere più campagne o comunicazioni automatiche, poi riaprire un messaggio di qualche giorno prima. Se il sistema di reporting attribuisce l’evento all’email inviata più di recente invece che a quella realmente aperta, le metriche per campagna, contenuto e sequenza diventano meno attendibili.

Con il Message ID disponibile nel picker dinamico, l’attribuzione può essere costruita direttamente sul valore ricevuto nell’evento. Non si tratta quindi di una semplice etichetta aggiuntiva: è un riferimento utile per collegare l’engagement alla risorsa corretta nel sistema di destinazione.

A chi serve maggiormente

L’aggiornamento interessa in modo particolare chi usa HighLevel o GoHighLevel come origine di dati per strumenti esterni, non solo come piattaforma di invio e automazione.

Le agenzie possono usarlo per alimentare dashboard proprietarie o report per cliente, distinguendo con maggiore precisione le interazioni registrate su campagne diverse. Un team marketing che centralizza dati CRM, advertising, analytics ed email in un data warehouse può usare il Message ID come chiave di collegamento tra evento e messaggio. Anche chi sviluppa integrazioni custom con webhook, CRM esterni o sistemi di business intelligence ha ora un dato più solido da passare nel flusso.

La funzione può risultare utile anche nelle organizzazioni che applicano regole di deduplicazione. HighLevel chiarisce infatti che Email Opened viene generato a ogni apertura, comprese le riaperture dello stesso messaggio. Se il report esterno conta ogni evento senza una logica di consolidamento, il numero di aperture può trasformarsi impropriamente in un numero di engagement unici.

In questo contesto il Message ID non elimina da solo i duplicati: mette però a disposizione un riferimento stabile con cui definire una regola nel sistema ricevente. Per esempio, un’integrazione può decidere di consolidare più aperture dello stesso contatto sullo stesso ID email in un singolo record di engagement. La regola concreta dipende dall’architettura del database, dai campi inviati e dagli obiettivi di reporting.

Come funziona secondo la documentazione ufficiale

HighLevel descrive un percorso specifico e circoscritto. In un workflow che inizia con Email Events, occorre aprire l’azione Send Webhook e selezionare Message ID dal custom value picker durante la costruzione del payload.

La fonte non dettaglia la struttura completa del payload, i nomi tecnici delle proprietà da usare né eventuali requisiti di autenticazione dell’endpoint webhook. Per questo non è corretto trattare tali aspetti come configurazioni standard garantite. L’implementazione dovrebbe rispettare il formato richiesto dal servizio esterno e le convenzioni già adottate nell’integrazione.

I punti confermati dal changelog sono invece questi:

• il Message ID è disponibile nei workflow che partono da Email Events;
• può essere scelto come custom value nell’azione Send Webhook;
• si applica agli eventi Email Opened e Email Clicked;
• resta uguale per eventi ripetuti relativi allo stesso messaggio;
• cambia quando cambia l’email;
• rimane associato all’evento anche se l’apertura arriva in ritardo.

Per chi mantiene documentazione interna delle automazioni, è opportuno annotare che il valore identifica il messaggio e non, da quanto emerge dalla fonte, una singola apertura. Questa distinzione è essenziale per non confondere una chiave di messaggio con un identificatore univoco di evento.

Benefici per reporting, attribuzione e deduplica

Il beneficio più immediato è una maggiore affidabilità nell’attribuzione. Quando nel sistema esterno arrivano più eventi, il Message ID permette di associare ciascuno alla specifica email invece di ricostruire il legame usando ipotesi temporali, come “l’ultimo messaggio inviato”.

Un secondo vantaggio riguarda la deduplica. L’esempio fornito da HighLevel parla di un’agenzia che invia due campagne email nella stessa settimana e trasferisce aperture e clic verso una dashboard proprietaria. Se lo stesso contatto apre una delle email quattro volte, gli eventi condividono il medesimo Message ID. La dashboard può quindi, se progettata per farlo, consolidarli in un solo record di engagement per quel messaggio invece di trattarli automaticamente come quattro interazioni indipendenti.

C’è poi il tema della coerenza storica. Poiché l’ID viaggia con l’evento, un’apertura tardiva non dovrebbe essere riassegnata a una campagna più recente solo perché nel frattempo sono state inviate altre email. Per chi analizza finestre temporali, sequenze di nurturing o performance di campagne, questo aiuta a mantenere più chiaro il rapporto tra invio e risposta.

La stessa attenzione alla qualità dei dati è rilevante anche quando i workflow raccolgono e trasferiscono altre informazioni operative. Ad esempio, HighLevel ha recentemente aggiornato Forms, Surveys e Quizzes con raggruppamento e inserimento multiplo dei campi personalizzati: in ecosistemi con molte fonti, convenzioni coerenti e identificatori affidabili diventano ancora più importanti.

Limiti da considerare

È importante non attribuire a questa novità capacità che la fonte non dichiara. Il Message ID serve a identificare il messaggio nei dati dell’evento; non viene presentato come una soluzione completa di analytics, come un contatore di aperture uniche già pronto o come un sistema automatico di deduplicazione all’interno di qualunque dashboard esterna.

La deduplica resta una responsabilità della logica costruita a valle del webhook. Per distinguere correttamente le metriche, chi implementa l’integrazione dovrà valutare quali chiavi combinare, quali eventi conservare e quando consolidarli. Un singolo Message ID può essere sufficiente per identificare l’email, ma un report potrebbe dover considerare anche il contatto, il tipo di evento, la campagna o altre informazioni disponibili nel proprio stack.

Inoltre, la fonte non afferma che il campo sia disponibile in tutti gli altri trigger, azioni, endpoint o aree di HighLevel. Il perimetro annunciato è preciso: Email Events e selezione del valore nel body di Send Webhook. Evitare estensioni non documentate riduce il rischio di progettare automazioni su presupposti non confermati.

Errori da evitare nell’implementazione

Il primo errore è usare il Message ID come se rappresentasse una singola apertura. HighLevel specifica che le aperture ripetute dello stesso messaggio inviano lo stesso valore: è quindi un identificatore del messaggio, non un ID nuovo per ogni evento.

Il secondo è deduplicare indiscriminatamente tutti gli eventi basandosi solo sul Message ID. Se il report deve distinguere aperture e clic, o segmentare per contatto, sarà probabilmente necessario modellare la logica con campi aggiuntivi presenti nel proprio flusso. La fonte conferma la stabilità dell’ID per messaggio, ma non prescrive una formula universale per le chiavi di deduplica.

Il terzo errore è continuare a risolvere l’attribuzione tramite “email inviata più di recente” quando il webhook può già trasportare il riferimento al messaggio. Questa euristica è proprio il caso problematico evidenziato nel changelog per le aperture di messaggi più vecchi.

Infine, conviene evitare modifiche non testate nei workflow di produzione. Prima di aggiornare dashboard e automazioni esistenti, è prudente verificare come l’endpoint esterno riceve e archivia il nuovo campo, documentare il mapping e controllare che le regole di consolidamento riflettano le metriche desiderate. Questo vale soprattutto per le agenzie che amministrano numerosi sub-account e flussi SaaS, scenario in cui HighLevel ha introdotto anche aggiornamenti relativi alla sincronizzazione degli abbonamenti dei sub-account dopo upgrade e downgrade.

Impatto pratico per le agenzie HighLevel

Per una realtà che usa GoHighLevel come piattaforma white label, il dato può rendere più ordinato il collegamento tra automazioni email e reporting personalizzato. Invece di limitarsi a sapere che un contatto ha aperto o cliccato, l’integrazione può conservare il riferimento al messaggio preciso da cui è partita l’azione.

Questo rende più semplice analizzare performance per singola email in una sequenza, campagna o periodo, purché il sistema esterno riceva anche una mappatura coerente degli invii. Il vantaggio è particolarmente concreto quando un cliente riceve comunicazioni ravvicinate e torna a interagire con email non recenti.

Per impostare workflow e integrazioni in modo sostenibile, non basta però aggiungere un campo al payload: servono naming chiari, criteri di reporting condivisi e test sui casi di riapertura. I risultati variano in base al contesto, alla struttura delle automazioni e alla qualità del sistema esterno che riceve i dati.

Se stai valutando HighLevel per workflow, email e integrazioni, consulta il nostro bonus WhatsApp per GoHighLevel per maggiori informazioni.