DocumentazioneJourney OptimizerGuida di Journey Optimizer

Risolvere i problemi relativi all’esecuzione live del percorso troubleshooting-execution

Ultimo aggiornamento: 23 ottobre 2026
  • Si applica a:
  • Journey Orchestration

Creato per:

  • Intermedio
  • Utente

In questa pagina: scopri come risolvere i problemi relativi all’esecuzione di un percorso live, tra cui la verifica dell’invio degli eventi, la conferma dell’immissione e dell’avanzamento dei profili nel percorso e la verifica della consegna dei messaggi.

style
shade-box

In questa sezione, scopri come risolvere i problemi relativi agli eventi di percorso, verificare se i profili sono entrati nel percorso, come ci si sposta e se i messaggi vengono inviati.

È inoltre possibile risolvere gli errori prima di testare o pubblicare un percorso. Scopri come in Risolvere i problemi prima di testare o pubblicare il percorso.

Se utilizzi azioni in entrata, scopri come risolverle in Risoluzione dei problemi relativi alle azioni in entrata nei percorsi.

Verifica che gli eventi siano inviati correttamente checking-that-events-are-properly-sent

Il punto di partenza di un percorso è sempre un evento. Puoi eseguire i test utilizzando strumenti come Postman.

Puoi verificare se la chiamata API inviata tramite questi strumenti viene inviata correttamente o meno. Se ricevi nuovamente un errore, significa che la chiamata presenta un problema. Controlla di nuovo il payload, l’intestazione (e in particolare l’ID organizzazione) e l’URL di destinazione. Puoi chiedere all’amministratore qual è l’URL corretto da utilizzare.

Gli eventi non vengono inviati direttamente dall’origine ai percorsi. I percorsi si basano infatti sulle API Streaming Ingestion di Adobe Experience Platform. Di conseguenza, in caso di problemi relativi agli eventi, puoi fare riferimento alla Adobe Experience Platform documentazione per la risoluzione dei problemi relativi alle API Streaming Ingestion.

Se il percorso non è in grado di abilitare la modalità di test con l’errore ERR_MODEL_RULES_16, verificare che l’evento utilizzato includa uno spazio dei nomi identità quando si utilizza un’azione del canale.

Lo spazio dei nomi dell’identità viene utilizzato per identificare in modo univoco i profili di test. Ad esempio, se per identificare i profili di test si utilizza l’e-mail, deve essere selezionato lo spazio dei nomi dell’identità E-mail. Se l’identificatore univoco è il numero di telefono, deve essere selezionato lo spazio dei nomi dell’identità Telefono.

Controlla se le persone entrano nel percorso checking-if-people-enter-the-journey

Il reporting percorso misura le entrate delle persone in un percorso in tempo reale.

Se l’invio dell’evento è stato completato con successo ma non viene visualizzata alcuna entrata nel percorso, significa che si sono verificati errori tra l’invio dell’evento e la ricezione dell’evento nel percorso.

Per iniziare la risoluzione dei problemi, consulta le domande seguenti:

  • Hai la certezza che il percorso in cui prevedevi che arrivasse l’evento fosse in modalità di test o live?

  • Hai salvato l’evento prima di copiare il payload dall’anteprima del payload?

  • Il payload dell’evento contiene un ID evento?

  • Hai raggiunto l’URL giusto?

  • Hai seguito la struttura del payload delle API di acquisizione in streaming utilizzando l’anteprima della struttura del payload nel riquadro di configurazione dell’evento? Vedi Anteprima payload.

  • Hai utilizzato le coppie chiave-valore corrette nell’intestazione dell’evento?

    code language-none 
    X-gw-ims-org-id - your organization's ID
Content-type - application/json

  • Condizione evento e tipi di dati dello schema - Verificare che i tipi di dati utilizzati nella condizione evento (regola) corrispondano allo schema evento. I tipi non corrispondenti (ad esempio, stringa vs. numero intero) causano un errore di valutazione della regola e l’eliminazione degli eventi. Vedere Verifica identità evento.

  • Evento ignorato - condizione di qualifica non soddisfatta - Per gli eventi basati su regole, se la condizione di qualifica non è soddisfatta dal payload dell’evento (ad esempio, se un campo obbligatorio è vuoto o mancante oppure una condizione come isNotEmpty in un campo non riesce), l’evento è ricevuto ma scartato e il percorso non viene attivato. Registri e tracce Splunk possono mostrare che l’evento è stato ricevuto ma scartato perché non soddisfa la condizione di qualifica, con codici di eliminazione come notSuitableInitialEvent. Questo è il comportamento previsto: se la condizione di qualifica non viene soddisfatta, l’evento verrà scartato e il percorso non verrà attivato per quel profilo. Verifica che il payload dell’evento contenga i campi e i valori previsti e che la regola nella configurazione dell’evento corrisponda ai dati inviati. Se l’evento viene attivato da una azione personalizzata da un altro percorso, vedere Gestione degli eventi di eliminazione e dei timeout di inattività nella risoluzione dei problemi relativi alle azioni personalizzate.

​>>
Per i percorsi di qualificazione del pubblico con pubblico in streaming: se utilizzi un’attività di qualificazione del pubblico come punto di ingresso del percorso, tieni presente che non tutti i profili idonei per il pubblico entreranno necessariamente nel percorso a causa di fattori di tempistica, uscite rapide dal pubblico o se i profili erano già presenti nel pubblico prima della pubblicazione. Ulteriori informazioni sulle considerazioni sulla tempistica di qualificazione del pubblico in streaming.

Verifica identità evento verify-event-identity-and-rule-data-types

Durante la configurazione di un percorso basato su eventi, verifica che il campo di identità del payload corrisponda allo spazio dei nomi ​ selezionato nell’evento. Se l’evento include campi per la corrispondenza del profilo, verificare la corrispondenza tra maiuscole e minuscole lettere e il tipo di dati ​​nella condizione dell’evento con i dati in entrata. Se, ad esempio, lo schema evento definisce roStatus come stringa, anche la regola di percorso deve valutarlo come stringa. I tipi di dati non corrispondenti (ad esempio, stringa vs. numero intero) causano un errore di valutazione della regola e l’eliminazione di eventi validi. Analogamente, se l’evento ha una condizione di qualifica (ad esempio, un campo non deve essere vuoto), gli eventi che non soddisfano tale condizione vengono scartati e non attivano il percorso; i registri possono mostrare codici di eliminazione come notSuitableInitialEvent.

Per convalidare la condizione evento in Journey Optimizer, utilizza l’anteprima del payload nella configurazione dell’evento e assicurati che i tipi e i valori nella regola corrispondano alla struttura del payload. Scopri come visualizzare in anteprima il payload e configurare gli eventi basati su regole.

Risolvere i problemi relativi alle transizioni della modalità di test troubleshooting-test-transitions

Se i profili di test non riescono ad avanzare nel percorso in modalità di test o il flusso visivo non visualizza frecce verdi che indicano la progressione del passaggio, il problema può essere correlato alla convalida della transizione. Questa sezione fornisce indicazioni sulla diagnosi e la risoluzione di problemi comuni relativi alla modalità di test.

Profili di test non in avanzamento test-profiles-not-progressing

Se i profili di test entrano nel percorso ma non superano il passaggio iniziale, verifica quanto segue:

  • Data di inizio Percorso - La causa più comune è quando la data di inizio del percorso è impostata in futuro. I profili di test vengono eliminati immediatamente se l’ora corrente non rientra nella finestra date/ore di inizio e fine configurata dal percorso, generando la voce di registro: DISPATCHER DISCARD #16 — unqualified on journey version enablements. Per risolvere:

    • Verifica che la data di inizio del percorso non sia impostata in futuro
    • Assicurarsi che l’ora corrente rientri nell’intervallo di date attivo del percorso
    • Se necessario, imposta temporaneamente la data di inizio a un’ora precedente al momento corrente per il test, quindi ripristinala prima di pubblicarla

  • Configurazione profilo di test - Verificare che il profilo sia contrassegnato correttamente come profilo di test in Adobe Experience Platform. Per ulteriori informazioni, vedere come creare profili di test.

  • Mancata corrispondenza dello spazio dei nomi dell’identità - Una mancata corrispondenza dello spazio dei nomi causa un calo invisibile all’utente: l’evento viene accettato e restituisce una risposta di successo, ma il profilo non entra mai nel percorso e non viene visualizzato alcun errore nell’interfaccia utente. Verificare che lo spazio dei nomi nell’Identificatore profilo corrisponda esattamente allo spazio dei nomi definito nello schema eventi (distinzione maiuscole/minuscole). Per informazioni dettagliate, vedere il formato espressione Identificatore profilo.

Indicatori di transizione nulli null-transition-indicators

Durante la risoluzione dei problemi tecnici, è possibile che nei dettagli tecnici del percorso venga rilevata una proprietà isValidTransition impostata su null. Questa proprietà di sola interfaccia utente non influisce sull’elaborazione back-end o sulle prestazioni del percorso. Tuttavia, un valore null può indicare:

  • Configurazione errata del Percorso - La data di inizio del percorso è impostata in futuro, causando l’eliminazione silenziosa degli eventi di test
  • Transizione danneggiata - In rari casi, potrebbe essere necessario riconnettere i nodi del percorso

Se riscontri problemi di transizione persistenti:

  1. Verifica che la data di inizio del percorso sia corrente
  2. Disattivare e riattivare la modalità di test
  3. Se il problema persiste, è consigliabile duplicare i nodi del percorso interessati e riconnetterli
  4. Per i casi non risolti, contatta il supporto con i registri di percorso, gli ID profilo interessati e i dettagli sulla transizione null
NOTE
Gli eventi inviati al di fuori della finestra della data attiva del percorso vengono eliminati automaticamente con la voce di registro DISPATCHER DISCARD #16 — unqualified on journey version enablements e nessun errore nell'interfaccia utente. Verifica sempre la configurazione degli intervalli di percorso prima di risolvere i problemi relativi alla progressione del profilo di test.

Controllare il modo in cui le persone si spostano nel percorso checking-how-people-navigate-through-the-journey

Il reporting di percorso misura il progresso delle persone all’interno di un percorso. È facile identificare in che punto una persona si è fermata e per quale motivo.

Verifica quanto segue:

  • È dovuto a una condizione che esclude la persona? Ad esempio, la condizione è “genere = uomo” e la persona in oggetto è una donna. Questo controllo può essere eseguito da un utente aziendale, se la condizione non è troppo complessa.
  • È dovuto a una chiamata a un’origine dati che non risponde? Quando il percorso è in modalità di test, queste informazioni possono essere visualizzate nei registri in modalità di test. Quando il percorso è live, un amministratore può testare le chiamate dirette all’origine dati e verificare la risposta ricevuta. Un amministratore può anche duplicare il percorso e testarlo.
TIP
Puoi anche utilizzare l'abilità Profilo Percorso di traccia in Coworker per indagare su un percorso pubblicato. Chiedi quanti profili sono entrati in ciascun nodo e come si suddividono in rami, quali profili hanno generato errori e perché, o quale percorso ha seguito un singolo profilo. Ulteriori informazioni sulle abilità dei collaboratori per i percorsi

Eventi eliminati a causa di un’istanza di percorso bloccata max-instance-stack-events-reached

Se vengono visualizzati eventi scartati con il motivo maxInstanceStackEventsReached, il runtime di percorso ha raggiunto il limite interno di 10 eventi per stack di eventi per profilo per una versione di percorso specifica. Si tratta di un guardrail di sicurezza che impedisce l’accumulo di troppi eventi in sospeso mentre è ancora in corso l’elaborazione di un altro evento per lo stesso profilo.

non è un limite di intervallo di tempo o di velocità effettiva. Si verifica quando l’istanza di percorso del profilo è bloccata su un passaggio di lunga durata (ad esempio, un lungo periodo di attesa, un arricchimento o nuovi tentativi di azione personalizzati) e gli eventi per lo stesso profilo, utilizzati anche in quel percorso, si accumulano oltre il limite di 10 eventi.

Per identificarlo, eseguire una query sugli eventi dei passaggi del percorso in cui il motivo dell’eliminazione è uguale a maxInstanceStackEventsReached (ad esempio, in serviceEvents.stateMachine.eventType o campi simili). Ulteriori informazioni sui tipi di evento eliminati sono disponibili nell’elenco dei campi evento passaggio. Per i campi degli eventi dei passaggi del percorso, vedi Riferimento schema di Adobe Journey Optimizer.

Operazioni possibili

  • Riduci le lunghe attese o i passaggi lenti sui percorsi che possono riattivarsi frequentemente.
  • Deduplicare o annullare gli eventi a monte quando possibile.
  • Suddividi gli scenari a lunga durata in più percorsi per evitare lo stacking.

Verifica che i messaggi siano inviati correttamente checking-that-messages-are-sent-successfully

Se gli individui si spostano nel modo giusto all’interno del percorso ma non ricevono i messaggi che dovrebbero ricevere, puoi verificare se:

  • Journey Optimizer ha preso correttamente in considerazione la richiesta di invio del messaggio. Gli utenti aziendali possono accedere al messaggio che doveva essere stato inviato e verificare se l’ora dell’esecuzione più recente corrisponde all’orario di esecuzione del percorso. Può anche controllare le ultime chiamate/eventi API ricevuti.
  • Journey Optimizer ha inviato correttamente il messaggio. Controlla la segnalazione del percorso per assicurarti che non ci siano errori.

Nel caso di un messaggio inviato tramite un’azione personalizzata, l’unica cosa che è possibile controllare durante il test di percorso è il fatto che la chiamata del sistema dell’azione personalizzata conduca o meno a un errore. Se la chiamata al sistema esterno associata all’azione personalizzata non genera un errore ma non causa l’invio di un messaggio, esegui un’analisi sul lato del sistema esterno.

NOTE
Per le azioni native del canale Journey Optimizer, esegui una query sul set di dati dell'evento di feedback del messaggio per confermare lo stato di consegna, ad esempio sent o bounce. In Adobe Journey Optimizer, sent è lo stato rilevante per i risultati di recapito dei messaggi; il valore delivered non è utilizzato nei set di dati evento di feedback dei messaggi di Adobe Journey Optimizer. Per le azioni personalizzate, esegui una query sul set di dati Evento passaggio di Percorso per confermare che Journey Optimizer ha eseguito correttamente l’azione; una chiamata HTTP di per sé non conferma che il sistema esterno ha recapitato un messaggio. Scopri come scegliere il set di dati corretto per il tuo caso d'uso.

Informazioni sulle voci duplicate negli eventi dei passaggi del Percorso duplicate-step-events

Utilizzare questa sezione per comprendere il motivo per cui le righe duplicate possono essere visualizzate negli eventi dei passaggi del percorso.

Perché trovo più voci con lo stesso ID istanza di percorso, profilo, nodo e richiesta? duplicate-entries-why

Quando si esegue una query sui dati degli eventi delle fasi del percorso, è possibile osservare occasionalmente voci di registro duplicate per la stessa esecuzione del percorso. Queste voci condividono valori identici per:

  • profileID - Identità del profilo
  • instanceID - Identificatore dell’istanza del percorso
  • nodeID - Nodo percorso specifico
  • requestID - Identificatore della richiesta

Tuttavia, queste voci hanno valori _id diversi, che è l’indicatore chiave che distingue questo scenario dalla duplicazione effettiva dei dati.

Da cosa deriva questo comportamento? duplicate-entries-cause

Ciò si verifica a causa di operazioni di ridimensionamento automatico back-end (detto anche “ribilanciamento”) nell’architettura dei microservizi di Adobe Journey Optimizer. Durante i periodi di carico elevato o di ottimizzazione del sistema:

  1. Un evento del passaggio di percorso inizia l’elaborazione e viene registrato nel set di dati Eventi del passaggio di Percorso
  2. Un’operazione di ridimensionamento automatico ridistribuisce il carico di lavoro tra le istanze del servizio
  3. Lo stesso evento può essere rielaborato da un’altra istanza del servizio, creando una seconda voce di registro con un _id diverso

Si tratta di un comportamento di sistema previsto e funziona come previsto.

Vi è un impatto sull’esecuzione del percorso o sulla consegna dei messaggi? duplicate-entries-impact

No L’impatto è limitato solo alla registrazione. Adobe Journey Optimizer dispone di meccanismi di deduplicazione incorporati a livello di esecuzione dei messaggi che garantiscono:

  • Un solo messaggio (e-mail, messaggio mobile, notifica push, ecc.) viene inviato a ogni profilo
  • Le azioni vengono eseguite una sola volta
  • L’esecuzione del percorso procede correttamente

È possibile verificare questa situazione eseguendo una query su ajo_message_feedback_event_dataset o controllando i registri di esecuzione dell’azione. Si noterà che è stato effettivamente inviato un solo messaggio, nonostante le voci di evento del passaggio di percorso duplicate.

Come posso identificare questi casi nelle mie query? duplicate-entries-queries

Quando si analizzano i dati degli eventi delle fasi del percorso:

  1. Controllare il campo _id: i duplicati a livello di sistema effettivi avrebbero lo stesso _id. Valori _id diversi indicano voci di registro separate dallo scenario di ribilanciamento descritto sopra.

  2. Verifica recapito messaggi: riferimento incrociato con i dati di feedback del messaggio per confermare che è stato inviato un solo messaggio:

    code language-sql 
    SELECT
  timestamp,
  _experience.customerJourneyManagement.messageExecution.messageExecutionID,
  _experience.customerJourneyManagement.messageDeliveryfeedback.feedbackStatus
FROM ajo_message_feedback_event_dataset
WHERE
  _experience.customerJourneyManagement.messageExecution.journeyVersionID = '<journeyVersionID>'
  AND TO_JSON(identityMap) like '%<profileID>%'
ORDER BY timestamp DESC;

  3. Raggruppa per identificatori univoci: durante il conteggio delle esecuzioni, utilizza _id per ottenere conteggi accurati:

    code language-sql 
    SELECT
  COUNT(DISTINCT _id) as unique_executions
FROM journey_step_events
WHERE
  _experience.journeyOrchestration.stepEvents.journeyVersionID = '<journeyVersionID>'
  AND _experience.journeyOrchestration.stepEvents.profileID = '<profileID>'

Cosa devo fare se osservo questo? duplicate-entries-action

Si tratta di un comportamento normale del sistema e non è richiesta alcuna azione. La registrazione duplicata non indica un problema nella configurazione del percorso o nella consegna del messaggio.

Se si creano report o analisi in base agli eventi dei passaggi del percorso:

  • Usa _id come chiave primaria per il conteggio degli eventi univoci
  • Riferimento incrociato con i set di dati di feedback dei messaggi durante l’analisi della consegna dei messaggi
  • Tieni presente che l’analisi dei tempi può mostrare voci raggruppate in pochi secondi l’una dall’altra

Per ulteriori informazioni sull’esecuzione di query sugli eventi dei passaggi del Percorso, vedere Esempi di query.

Risolvere i problemi relativi alle discrepanze nelle metriche del dashboard dashboard-metrics

Se le metriche visualizzate nel dashboard Panoramica non corrispondono al numero effettivo di percorsi nella scheda Sfoglia, verificare quanto segue:

  • Assicurati che i percorsi in questione abbiano avuto traffico nelle ultime 24 ore, in quanto i percorsi senza attività recente vengono esclusi dal dashboard.
  • Verifica di disporre delle autorizzazioni di accesso appropriate per visualizzare tutti i percorsi dell’organizzazione.
  • Attendi fino a 30 minuti per l’aggiornamento delle metriche dopo aver apportato modifiche ai percorsi.

Se le discrepanze persistono, contatta il supporto Adobe con le schermate delle schede Panoramica e Sfoglia per ulteriori informazioni.

Parametri di tracciamento che mostrano segnaposto vuoti nei percorsi chiusi tracking-parameters-closed-journeys

Se gli URL di tracciamento nelle e-mail inviate contengono segnaposto vuoti come cid=em-acou-adob{}, potrebbe essere impossibile risolvere un campo di contesto come context.system.source.actionId. Ciò si verifica quando un percorso è stato chiuso e non è stato ripubblicato dopo una modifica rilevante del prodotto; solo i percorsi ripubblicati compilano correttamente questi campi di contesto negli URL di tracciamento.

Per risolvere il problema, ripubblicare il percorso (crea una nuova versione e pubblicarla) oppure rimuovere il riferimento al campo di contesto interessato dai parametri di tracciamento URL nella configurazione del canale o nel contenuto dell’e-mail.

AI Knowledge Reference

This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.

For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.

  • TL;DR: This page is a troubleshooting reference for live journey execution in Adobe Journey Optimizer, covering event delivery, profile entry, test mode transition issues, discarded events, duplicate journey step event entries, message delivery checks, dashboard metric discrepancies, and empty tracking parameter placeholders.

Intents:

  • Diagnose why events are not entering a journey by checking payload structure, headers, event condition data types, and qualification conditions
  • Verify whether profiles are entering and progressing through a journey in test mode or live
  • Resolve test profiles that do not progress, using the journey start date, test profile configuration, and identity namespace checks
  • Understand and handle the maxInstanceStackEventsReached discard reason for blocked journey instances
  • Identify and correctly query duplicate Journey Step Events entries that have different _id values
  • Investigate missing messages by checking journey reporting, message feedback, and custom action call results
  • Fix empty tracking URL placeholders in emails from closed journeys

Glossary:

  • Journey Step Events: The dataset to which journey step events are logged; queried to find discard reasons and duplicate rows, and to confirm that Journey Optimizer executed a custom action (product-specific)
  • notSuitableInitialEvent: A discard code that logs can show when an event was received but discarded because it did not meet the qualification condition (product-specific)
  • maxInstanceStackEventsReached: A discard reason that appears when the journey runtime reaches its internal per-profile event stack limit for a specific journey version (see Guardrails) (product-specific)
  • isValidTransition: A UI-only property in the journey’s technical details; the page states it does not impact backend processing or journey performance, and a null value can indicate a journey misconfiguration (start date set in the future) or a corrupted transition (product-specific)
  • Qualification condition: A condition on rule-based events; when the event payload does not satisfy it (for example, a required field is empty or missing), the event is received but discarded and the journey is not triggered
  • Rebalancing: A backend auto-scaling operation in Adobe Journey Optimizer’s microservices architecture that can cause the same event to be reprocessed by another service instance, creating a second log entry with a different _id

Guardrails:

  • Events sent outside the journey’s active date window are discarded silently with the log entry DISPATCHER DISCARD #16 — unqualified on journey version enablements and no UI error
  • The journey runtime has an internal per-profile event stack limit of 10 events for a specific journey version; events beyond it are discarded with maxInstanceStackEventsReached. This is not a time-window or throughput limit
  • The namespace in the Profile Identifier must match the namespace defined in the event schema exactly (case-sensitive); a mismatch causes a silent drop: the event is accepted and returns a success response, but the profile never enters the journey and no error is surfaced in the UI
  • Overview dashboard metrics only include journeys that had traffic in the last 24 hours; allow up to 30 minutes for metrics to refresh after changes
  • Only republished journeys correctly populate context fields in tracking URLs; a closed journey that was not republished after a relevant product change can show empty placeholders

Terminology:

  • Canonical name: Journey Step Events — variants: journey step events, Journey Step Events dataset, step events
  • Synonyms: “rebalancing” = “auto-scaling” (the backend operation that can create duplicate log entries)
  • Do not confuse: entries with the same _id (duplicates at system level) ≠ entries with different _id values (separate log entries from the rebalancing scenario)
  • Do not confuse: sent ≠ delivered — in Adobe Journey Optimizer Message Feedback Event datasets, sent is the relevant status for successful message delivery outcomes and the delivered value is not used

FAQ:

  • Q: Why are my events not entering a journey even though they are sent successfully? — Check that the journey is in test mode or live, that the event was saved before copying the payload from the payload preview, that the payload has an event id and follows the streaming ingestion APIs payload structure, that the URL and the header key-value pairs (X-gw-ims-org-id, Content-type) are right, that the data types in the event condition match the event schema, and that the qualification condition is satisfied.
  • Q: Why does the journey fail to enable test mode with ERR_MODEL_RULES_16? — Ensure the event used includes an identity namespace when using a channel action.
  • Q: Why do test profiles enter the journey but not advance past the initial step? — The most common cause is a journey start date set in the future; events outside the active date window are discarded silently. Also check the test profile configuration and the identity namespace.
  • Q: What does maxInstanceStackEventsReached mean? — The journey runtime has reached its internal per-profile event stack limit of 10 events for a specific journey version, because the profile’s journey instance is blocked on a long-running step. Reduce long waits or slow steps, deduplicate or debounce upstream events, or split long-running scenarios into multiple journeys.
  • Q: I see duplicate rows in journey step events - is something wrong? — No. Entries with the same profileID, instanceID, nodeID, and requestID but different _id values are expected system behavior from backend auto-scaling; the impact is limited to logging, and only one message is sent. Verify with ajo_message_feedback_event_dataset.
  • Q: Why do tracking URLs in emails show empty placeholders like cid=em-acou-adob{}? — A context field such as context.system.source.actionId could not be resolved because the journey was closed and not republished after a relevant product change. Republish the journey, or remove the reference to the affected context field from the URL tracking parameters.
  • Q: Why does the Overview dashboard show different numbers than the Browse tab? — Check that the journeys had traffic in the last 24 hours, that you have the access permissions to view all journeys in your organization, and allow up to 30 minutes for metrics to refresh.

Related pages:

  • Troubleshooting errors before testing or publishing a journey: Troubleshoot errors before testing or publishing your journey (building-journeys/troubleshooting.md)
  • Troubleshooting inbound actions: Troubleshoot inbound actions in journeys (building-journeys/troubleshooting-inbound.md)
  • Understanding journey step events: Journey step events (reports/journey-step-events-overview.md)
  • Journey error codes: Error codes reference (building-journeys/error-codes-reference.md)
recommendation-more-help
journey-optimizer-help